web安全

目录

1、XSS跨站脚本攻击：

2、CSRF跨站请求伪造：

3、CSRF和XSS的区别有哪些呢？

---

1、XSS跨站脚本攻击：

答：XSS（Cross-Site Scripting）跨站脚本攻击是一种常见的安全漏洞，恶意攻击者在用户提交的数据中加入一些代码，将代码嵌入到了Web页面中，从而可以盗取用户资料，控制用户行为或者破坏页面结构和样式等。为了和 CSS 区分，这里把攻击的第一个字母改成了 X，于是叫做 XSS。

XSS产生原因：

XSS产生的原因是过于信任客户端的数据，没有做好过滤或者转义等工作。如果客户端上传的数据中插入一些符号以及javascript代码，那么这些数据将会成为应用代码中的一部分了，这样就造成了XSS攻击。

XSS分类：

• 存储型：攻击者将恶意代码存储到了数据库中，在响应浏览器请求的时候返回恶意代码，并且执行。这种攻击常见于带有用户保存数据的网站功能；
• 反射型：将恶意代码放在URL中，将参数提交到服务器。服务器解析后响应，在响应结果中存在XSS代码，最终通过浏览器解析执行；
• DOM型：取出和执行恶意代码由浏览器端完成，属于前端 JavaScript的安全漏洞。

常见的攻击情景：

1、反射性XSS

用户A访问安全网站B，然后用户C发现B网站存在XSS漏洞，此时用户C向A发送了一封邮件，里面有包含恶意脚本的URL地址（此URL地址还是网站B的地址，只是路径上有恶意脚本），当用户点击访问时，因为网站B中cookie含有用户的敏感信息，此时用户C就可以利用脚本在受信任的情况下获取用户A的cookie信息，以及进行一些恶意操作。

2、持久性XSS

假设网站B是一个博客网站，恶意用户C在存在XSS漏洞的网站B发布了一篇文章，文章中存在一些恶意脚本，例如img标签、script标签等，这篇博客必然会存入数据库中，当其他用户访问该文章时恶意脚本就会执行，然后进行恶意操作。这种攻击方式叫做，将携带脚本的数据存入数据库，之后又由后台返回。

XSS防御：

• 对重要的 cookie设置 httpOnly, 防止客户端通过document.cookie读取 cookie；
• 对输入内容的特定字符进行编码，前端后端都可以对传入的内容进行过滤，去掉带javascript等字段的输入
• 过滤或移除特殊的Html标签， 例如:

过滤时机：应该是提交内容的时候
用正则表达式：
var filterHTMLTag = function (msg) {
        var msg = msg.replace(/<\/?[^>]*>/g, ''); //去除HTML Tag
        msg = msg.replace(/[|]*\n/, '') //去除行尾空格
        msg = msg.replace(/&npsp;/ig, ''); //去掉npsp
        return msg;
}

• 过滤JavaScript 事件的标签。例如 "οnclick=", "onfocus" 等等。

2、CSRF跨站请求伪造：

答：CSRF（ Cross-site request forgery）跨站请求伪造，也是一种常见的安全漏洞。XSS相当于是控制了站点内的信任用户，而CSRF则通过伪装成受信任用户的请求来利用受信任的网站。

CSRF举例：

用户登录受信任网站A，并在本地生成登录态Cookie。（如果用户没有登录网站A，那么网站B在获取A网站的信息并且去请求网站A的接口时，会提示登录）在不登出A的情况下，访问恶意网站B，那么网站B得到了网站A的所有信息，然后B网站去请求A网站的接口，伪装成A网站的正常请求为所欲为。

常见攻击情景：

用户A经常访问博客网站B，用户C发现网站B存在CSRF漏洞，想尽了各种办法勾引用户A访问了C写好的危险网站D，而此时用户A的cookie信息还没有失效，危险网站D中有向网站B求请求的非法操作，这样用户在不知情的情况下就被操控了。

CSRF漏洞检测：

检测CSRF漏洞是一项比较繁琐的工作，最简单的方法就是抓取一个正常请求的数据包，去掉Referer字段后再重新提交，如果该提交还有效，那么基本上可以确定存在CSRF漏洞。

CSRF防御： 要抵御 CSRF，关键在于在请求中放入黑客所不能伪造的信息，并且该信息不存在于 cookie 之中。

• Referer 头验证：在 HTTP 头中有一个字段叫 Referer，它记录了该 HTTP 请求的来源地址。

Referer 的值是由浏览器提供的，虽然 HTTP 协议上有明确的要求，
但是每个浏览器对于 Referer 的具体实现可能有差别，并不能保证浏览器自身没有安全漏洞。
使用验证 Referer 值的方法，就是把安全性都依赖于第三方（即浏览器）来保障，从理论上来讲，这样并不安全。

• Token验证：可以在 HTTP 请求中以参数的形式加入一个随机产生的 token，并在服务器端建立一个拦截器来验证这个 token，如果请求中没有 token 或者 token 内容不正确，则认为可能是 CSRF 攻击而拒绝该请求。

token 可以在用户登陆后产生并放于 session 之中，然后在每次请求时把 token 从 session 中拿出，与请求中的 token 进行比对,
通常使用的方法就是在每次页面加载时，使用 javascript 遍历整个 dom 树，对于 dom 中所有的 a 和 form 标签后加入 token。
对于 GET 请求，token 将附在请求地址之后，这样 URL 就变成 http://url?csrftoken=tokenvalue。
而对于 POST 请求来说，要在 form 的最后加上 <input type="hidden" name="csrftoken" value="tokenvalue"/>，这样就把token以参数的形式加入请求了。
这样可以解决大部分的请求，但是对于在页面加载之后动态生成的 html代码，这种方法就没有作用，还需要程序员在编码时手动添加 token。

• 双重Cookie验证：利用恶意网站无法获取cookie信息，仅可冒用的特点，我们将cookie中的参数取出来，加入到请求参数中，服务端进行校验，如果参数中没有附加额外的cookie中的参数，那么就拒绝请求。
• 尽量不要在页面的链接中暴露用户隐私信息。
• 对于用户修改删除等操作最好都使用post操作 。
• 避免全站通用的cookie，严格设置cookie的域。

3、CSRF和XSS的区别有哪些呢？

• CSRF攻击需要用户先登录网站A，恶意网站B获取到A网站用户的 cookie；

• XSS攻击则不需要登录。

• CSRF攻击本质是利用网站A本身的漏洞，去请求网站A的相关接口；

• XSS攻击向网站 A 注入恶意代码，然后通过执行恶意代码，篡改了网站A的内容。