系统安全漏洞

1    跨站请求伪造漏洞
1.1    概述
跨站请求伪造CSRF(Cross Site Request Forgery)是指攻击者可以在第三方站点制造HTTP请求并以用户在目标站点的登录态发送到目标站点，而目标站点未校验请求来源使第三方成功伪造请求。
CSRF(Cross-site request forgery跨站请求伪造，也被称成为“one click attack”或者session riding，通常缩写为CSRF或者XSRF，是一种对网站的恶意利用。
1.2    为什么会有CSRF?
JS控制浏览器发送请求的时候，浏览器是根据目标站点，而不是来源站点，来发送cookie的，如果当前会话中有目标站点的cookie，就发送出去。核心问题是浏览器的会话机制，是跨站请求伪造漏洞的根源。
1.3    CSRF攻击原理
    CSRF攻击原理比较简单，如下图所示。其中Web A为存在CSRF漏洞的网站，Web B为攻击者构建的恶意网站，User C为Web A网站的合法用户。
  
1. 用户C打开浏览器，访问受信任网站A，输入用户名和密码请求登录网站A;
2.在用户信息通过验证后，网站A产生Cookie信息并返回给浏览器，此时用户登录网站A成功，可以正常发送请求到网站A;
3. 用户未退出网站A之前，在同一浏览器中，打开一个TAB页访问网站B;
4. 网站B接收到用户请求后，返回一些攻击性代码，并发出一个请求要求访问第三方站点A;
5. 浏览器在接收到这些攻击性代码后，根据网站B的请求，在用户不知情的情况下携带Cookie信息，向网站A发出请求。网站A并不知道该请求其实是由B发起的，所以会根据用户C的Cookie信息以C的权限处理该请求，导致来自网站B的恶意代码被执行。
1.4    CSRF的危害
伪造请求登录目标系统，为所欲为。
1.5    CSRF漏洞防御
CSRF漏洞防御主要可以从三个层面进行，即服务端的防御、用户端的防御和安全设备的防御。
1.5.1    服务端的防御
1.5.1.1    验证HTTP Referer字段
根据HTTP协议，在HTTP头中有一个字段叫Referer，它记录了该HTTP请求的来源地址。在通常情况下，访问一个安全受限页面的请求必须来自于同一个网站。比如某银行的转账是通过用户访问http://bank.test/test?page=10&userID=101&money=10000页面完成，用户必须先登录bank.test，然后通过点击页面上的按钮来触发转账事件。当用户提交请求时，该转账请求的Referer值就会是转账按钮所在页面的URL(本例中，通常是以bank.test域名开头的地址)。而如果攻击者要对银行网站实施CSRF攻击，他只能在自己的网站构造请求，当用户通过攻击者的网站发送请求到银行时，该请求的 Referer是指向攻击者的网站。因此，要防御CSRF攻击，银行网站只需要对于每一个转账请求验证其Referer值，如果是以bank. test开头的域名，则说明该请求是来自银行网站自己的请求，是合法的。如果Referer是其他网站的话，就有可能是CSRF攻击，则拒绝该请求。
这种方法的显而易见的好处就是简单易行，网站的普通开发人员不需要操心 CSRF 的漏洞，只需要在最后给所有安全敏感的请求统一增加一个拦截器来检查 Referer 的值就可以。特别是对于当前现有的系统，不需要改变当前系统的任何已有代码和逻辑，没有风险，非常便捷。
然而，这种方法并非万无一失。Referer 的值是由浏览器提供的，虽然 HTTP 协议上有明确的要求，但是每个浏览器对于 Referer 的具体实现可能有差别，并不能保证浏览器自身没有安全漏洞。使用验证 Referer 值的方法，就是把安全性都依赖于第三方（即浏览器）来保障，从理论上来讲，这样并不安全。
1.5.1.2    在请求地址中添加token并验证
CSRF攻击之所以能够成功，是因为攻击者可以伪造用户的请求，该请求中所有的用户验证信息都存在于Cookie中，因此攻击者可以在不知道这些验证信息的情况下直接利用用户自己的Cookie来通过安全验证。由此可知，抵御CSRF攻击的关键在于：在请求中放入攻击者所不能伪造的信息，并且该信息不存在于Cookie之中。鉴于此，系统开发者可以在HTTP请求中以参数的形式加入一个随机产生的token，并在服务器端建立一个拦截器来验证这个 token，如果请求中没有token或者token内容不正确，则认为可能是CSRF攻击而拒绝该请求。
但这种方式涉及到页面交互，在通常情况下，验证码能很好遏制CSRF攻击。但是出于用户体验考虑，网站不能给所有的操作都加上验证码。这样可以解决大部分的请求，但是对于在页面加载之后动态生成的 html 代码，这种方法就没有作用，还需要程序员在编码时手动添加 token。因此验证码只能作为一种辅助手段，不能作为主要解决方案。
该方法还有一个缺点是难以保证 token 本身的安全。特别是在一些论坛之类支持用户自己发表内容的网站，黑客可以在上面发布自己个人网站的地址。由于系统也会在这个地址后面加上 token，黑客可以在自己的网站上得到这个 token，并马上就可以发动 CSRF 攻击。为了避免这一点，系统可以在添加 token 的时候增加一个判断，如果这个链接是链到自己本站的，就在后面添加 token，如果是通向外网则不加。不过，即使这个 csrftoken 不以参数的形式附加在请求之中，黑客的网站也同样可以通过 Referer 来得到这个 token 值以发动 CSRF 攻击。这也是一些用户喜欢手动关闭浏览器 Referer 功能的原因。
1.5.1.3    在HTTP头中自定义属性并验证
自定义属性的方法也是使用token并进行验证，和前一种方法不同的是，这里并不是把token以参数的形式置于HTTP请求之中，而是把它放到 HTTP头中自定义的属性里。通过XMLHttpRequest这个类，可以一次性给所有该类请求加上csrftoken这个HTTP头属性，并把 token值放入其中。这样解决了前一种方法在请求中加入token的不便，同时，通过这个类请求的地址不会被记录到浏览器的地址栏，也不用担心 token会通过Referer泄露到其他网站。
然而这种方法的局限性非常大。XMLHttpRequest 请求通常用于 Ajax 方法中对于页面局部的异步刷新，并非所有的请求都适合用这个类来发起，而且通过该类请求得到的页面不能被浏览器所记录下，从而进行前进，后退，刷新，收藏等操作，给用户带来不便。另外，对于没有进行 CSRF 防护的遗留系统来说，要采用这种方法来进行防护，要把所有请求都改为 XMLHttpRequest 请求，这样几乎是要重写整个网站，这代价无疑是不能接受的。

1.5.1.4    Java 代码示例
下文将以 Java 为例，对上述三种方法分别用代码进行示例。无论使用何种方法，在服务器端的拦截器必不可少，它将负责检查到来的请求是否符合要求，然后视结果而决定是否继续请求或者丢弃。在 Java 中，过滤器是由 Filter 来实现的。我们可以编写一个 Filter，并在 web.xml 中对其进行配置，使其对于访问所有需要 CSRF 保护的资源的请求进行拦截。
在 filter 中对请求的 Referer 验证代码如下：
 // 从 HTTP 头中取得 Referer 值
 String referer=request.getHeader("Referer");
 // 判断 Referer 是否以 bank.example 开头
 if((referer!=null) &&(referer.trim().startsWith(“bank.example”))){
    chain.doFilter(request, response);
 }else{
request.getRequestDispatcher(“error.jsp”).forward(request,response);
 }
 如果要进一步验证请求中的 token 值，代码如下：
HttpServletRequest req = (HttpServletRequest)request;
 HttpSession s = req.getSession();
 // 从 session 中得到 csrftoken 属性
 String sToken = (String)s.getAttribute(“csrftoken”);
 if(sToken == null){
    // 产生新的 token 放入 session 中
    sToken = generateToken();
    s.setAttribute(“csrftoken”,sToken);
    chain.doFilter(request, response);
 } else{
    // 从 HTTP 头中取得 csrftoken
    String xhrToken = req.getHeader(“csrftoken”);
    // 从请求参数中取得 csrftoken
    String pToken = req.getParameter(“csrftoken”);
    if(sToken != null && xhrToken != null && sToken.equals(xhrToken)){
        chain.doFilter(request, response);
    }else if(sToken != null && pToken != null && sToken.equals(pToken)){
        chain.doFilter(request, response);
    }else{
request.getRequestDispatcher(“error.jsp”).forward(request,response);
    }
 }
除了在服务器端利用 filter 来验证 token 的值以外，我们还需要在客户端给每个请求附加上这个 token，在客户端 html 中，主要是有两个地方需要加上 token，一个是表单 form，另一个就是链接 a。 
如果你的网站使用 XMLHttpRequest，那么还需要在 HTTP 头中自定义 csrftoken 属性。 
1.5.2    其他防御方法
1.    CSRF攻击是有条件的，当用户访问恶意链接时，认证的cookie仍然有效，所以当用户关闭页面时要及时清除认证cookie，对支持TAB模式(新标签打开网页)的浏览器尤为重要。
1.6    CSRF漏洞的检测
待补。
2    XSS攻击
2.1    概述
“XSS是跨站脚本攻击(Cross Site Scripting)，为不和层叠样式表(Cascading Style Sheets, CSS)的缩写混淆，故将跨站脚本攻击缩写为XSS。恶意攻击者往Web页面里插入恶意Script代码，当用户浏览该页之时，嵌入其中Web里面的Script代码会被执行，从而达到恶意攻击用户的目的。”
其实归根结底，XSS的攻击方式就是想办法“教唆”用户的浏览器去执行一些这个网页中原本不存在的前端代码。
2.2    利用与绕过
那xss漏洞很容易被利用吗？那倒也未必。
毕竟在实际应用中web程序往往会通过一些过滤规则来阻止恶意代码的用户输入被显示。
不过，这里还是可以给大家总结一些常用的xss攻击绕过过滤的一些方法，算是抛砖引玉。
2.2.1    大小写绕过
这个绕过方式的出现是因为网站仅仅只过滤了<script>标签，而没有考虑标签中的大小写并不影响浏览器的解释所致。具体的方式就像这样：
利用语句：
http://192.168.1.1/xss/example2.php?name=<sCript>alert("hey!")</scRipt>
2.2.2    过滤后返回语句再次构成攻击语句
我们直接敲入script标签发现返回的网页代码中script标签被去除了，但其余的内容并没有改变。
于是我们就可以人为的制造一种巧合，让过滤完script标签后的语句中还有script标签（毕竟alert函数还在），像这样：
http://192.168.1.102/xss/example3.php?name=<sCri<script>pt>alert("hey!")</scRi</script>pt>
2.2.3    不是只有script标签才可以插入代码
例如这里我们用<img>标签做一个示范。
我们利用如下方式：
http://192.168.1.102/xss/example4.php?name=<img
src='w.123' οnerrοr='alert("hey!")'>
就可以再次愉快的弹窗。原因很简单，我们指定的图片地址根本不存在也就是一定会发生错误，这时候onerror里面的代码自然就得到了执行。
以下列举几个常用的可插入代码的标签。
<a οnmοusemοve=’do something here’> 
当用户鼠标移动时即可运行代码
<div οnmοuseοver=‘do something here’> 
2.2.4    编码脚本代码绕过关键字过滤
有的时候，服务器往往会对代码中的关键字（如alert）进行过滤，这个时候我们可以尝试将关键字进行编码后再插入，不过直接显示编码是不能被浏览器执行的，我们可以用另一个语句eval（）来实现。eval()会将编码过的语句解码后再执行，简直太贴心了。
例如alert(1)编码过后就是
\u0061\u006c\u0065\u0072\u0074(1)
所以构建出来的攻击语句如下：
http://192.168.1.2/xss/example5.php?name=<script>eval(\u0061\u006c\u0065\u0072\u0074(1))</script>
2.2.5    组合各种方式
在实际运用中漏洞的利用可能不会这么直观，需要我们不断的尝试，甚至组合各种绕过方式来达到目的。
2.3    XSS分类
XSS攻击大致上分为两类：
一类是反射型XSS，又称非持久型XSS，
一类是储存型XSS，也就是持久型XSS。
2.3.1    什么是反射型XSS
其实，我们上面讲XSS的利用手段时所举的例子都是非持久型XSS。
也就是攻击相对于访问者而言是一次性的，具体表现在我们把我们的恶意脚本通过url的方式传递给了服务器，而服务器则只是不加处理的把脚本“反射”回访问者的浏览器而使访问者的浏览器执行相应的脚本。
也就是说想要触发漏洞，需要访问特定的链接才能够实现。
2.3.2    什么是储存型XSS
它与反射型XSS最大的不同就是服务器再接收到我们的恶意脚本时会将其做一些处理。
例如储存到数据库中，然后当我们再次访问相同页面时，将恶意脚本从数据库中取出并返回给浏览器执行。这就意味着只要访问了这个页面的访客，都有可能会执行这段恶意脚本，因此储存型XSS的危害会更大。
2.4    XSS的危害
2.4.1    窃取cookie值
在网页浏览中我们常常涉及到用户登录，登录完毕之后服务端会返回一个cookie值。这个cookie值相当于一个令牌，拿着这张令牌就等同于证明了你是某个用户。
如果你的cookie值被窃取，那么攻击者很可能能够直接利用你的这张令牌不用密码就登录你的账户。
2.4.2    劫持流量实现恶意跳转
这个很简单，就是在网页中想办法插入一句像这样的语句：
<script>window.location.href="http://www.baidu.com";</script>
那么所访问的网站就会被跳转到百度的首页。
早在2011年新浪就曾爆出过严重的xss漏洞，导致大量用户自动关注某个微博号并自动转发某条微博。
2.5    实例应用
2.5.1    劫持访问
劫持访问就是在恶意脚本中插入诸如的代码，那么页面就会跳转到百度首页。
劫持访问在持久型和非持久型XSS中都比较常被利用。持久型XSS中劫持访问的危害不用说大家都清楚，但有人会问非持久型XSS中劫持访问有什么作用呢？
很简单，试想下像http://qq.com，http://baidu.com这样的域名下出现非持久型XSS，那么在发送钓鱼链接时就可以通过http://qq.com等域名进行跳转，一般人一看到http://qq.com之类的域名警惕性会下降，也就更容易上当了。
2.5.2    盗用cookie实现无密码登录
如果想要通过script脚本获得当前页面的cookie值，通常会用到document.cookie。
试想下如果像空间、说说中能够写入xss攻击语句，那岂不是看了你说说的人的号你都可以登录（不过某些厂商的cookie有其他验证措施如：Http-Only保证同一cookie不能被滥用）
由于盗取的cookie需要传回给攻击者，因此往往需要一个服务器来接收盗取的cookie，这也就是xss平台的作用了。
2.5.3    配合csrf攻击完成恶意请求
<script type="text/javascript" src="http://127.0.0.1/test/vulnerabilities/csrf/?password_new=123456&password_conf=123456&Change=Change#"></script>
2.6    防范手段
    首先是过滤。对诸如<script>、<img>、<a>等标签进行过滤。
    其次是编码。像一些常见的符号，如<>在输入的时候要对其进行转换编码，这样做浏览器是不会对该标签进行解释执行的，同时也不影响显示效果。
    最后是限制。通过以上的案例我们不难发现xss攻击要能达成往往需要较长的字符串，因此对于一些可以预期的输入可以通过限制长度强制截断来进行防御。
2.7    XSS漏洞的检测
待补。