一、XSS 攻击

XSS 攻击的全称为 跨站脚本攻击（Cross Site Scripting）

为什么不叫CSS ，那是因为为了不跟层叠样式表（Cascading Style Sheet，CSS）混淆

XSS攻击 是 Web 应用中最常见到的攻击手段之一。跨站脚本攻击，关键词 脚本。攻击者常常在网页中嵌入了恶意的脚本程序，当用户打开该网页的时候，脚本程序便开始在客户端的浏览器后台执行，常用于盗取客户端的 cookie，用户名密码，下载执行病毒的木马程序，以及获取客户端 Admin 权限。

1. 攻击原理

前端常用表单的形式向后台提交信息

<input type="text" name="username" value="cbuc" />  

很普通的一段html代码，向后台提交 username 的信息，正常情况下，用户一般会输入自己的 username，这个时候毫无问题，但是在不正常的情况下，用户输入的不是一个正常的字符串，而是 "/><script> alert("bingo") </script><!- 。按这个时候表单的内容就会变成

<input type="text" name="username" value=""/><script> alert("bingo") </script><!-" />  

这个时候向后台提交参数，由于 username 的不合法性，校验可能不通过，服务端就重定向会该页面，并且带上以上参数，这个时候页面就会弹出一个警告框：

警告框问题不是很大，是因为取决于这段脚本，如果攻击者稍做修改，那么性质可能就不一样了~甚至，攻击者可以对URL进行操作，正常提交的地址为

www.xxx.com/login?username="/><script> alert("bingo") </script><!-"  

攻击者可以对 URL 进行编码用来迷惑用户：

www.xxx.com/login?username="%2F%3E%3Cscript%3E%20alert(%22bingo%22)%20%3C%2Fscript%3E%3C!-"  

2. 防护手段

知道了如何攻击，防护起来就不难，我们对症下药即可。既然输入的参数不合法，我们就很有必要对入参进行校验，比如 <、>、"、"、'、'  这些特殊字符我们很有必要进行转义与校验。

二、CSRF 攻击

CSRF 攻击全称 跨站请求伪造 (Cross site request forgery)。是一种对网站的恶意利用，我们上面说到的 XSS攻击 是利用站点内的信任用户，自己去触发脚本而导致的攻击。而 CSRF 则是通过伪装来自受信任用户的请求去利用受攻击的网站。

CSRF 攻击，关键词：伪造。

攻击者盗用了访问用户的身份，以访问者的名义向第三方网站发送恶意请求，常用于利用访问者的身份发送消息，进行交易转账以及盗取账号。

1. 攻击原理

受害者首先在信任站点完成了登录，并且生成了 Cookie，Cookie会在浏览器保存一定的时间。到这一步，用户如果在没有登出 信任站点 的情况下，访问了 恶意站点，这个时候 恶意站点 就会向 信任站点 发起请求，这个请求就会带上以上生成的 Cookie，当恶意请求来到 信任站点，信任站点 看到请求携带的 Cookie，就会判断该请求是 受害者 发出的。因此 信任站点 就会根据 受害者 的权限来完成 恶意请求 的指令，而这个指令可能是利用 受害者 的身份发送消息，转账支付等等操作，这样 恶意站点 就达到了伪造 受害者 请求 信任站点 的目的。看到这个流程不知道你是否有所启发，不知道屏幕前的小伙伴是否有过 QQ 被盗用的经历，当然，有些盗用的手段与上面的流程是相似的。该攻击手段在日常中十分常见。如果某个支付系统的转账地址为 www.xxx.com/pay?accountNum=xxxx&money=xxx。其中 accountNum 为转账目的的账户，money 为转账金额。那这个时候如果你刚巧登录过了该支付系统，又没有及时的登出，在访问恶意站点的时候，如果你点开了某张图片，而图片的地址为 ：

<img src="www.xxx.com/pay?accountNum=xxxx&money=xxx" />  

当你美滋滋地浏览图片的时候，却不知道此时你的账户上已经悄悄的少了指定金额！这就是因为你没有及时的登出支付系统，而又点击了 恶意站点的 恶意链接，携带了你未过期的 Cookie，成功窃取了你的金额。

2. 防护手段

同样知其症下其药！防护手段如下：

• 将 cookie 设置为 HttpOnly

CSRF 攻击的关键就在于利用了用户未过期的 Cookie，那么为了防止 Cookie 的盗取，就需要在 Cookie 中设置 HttpOnly 属性，这样通过程序（XSS 攻击）就无法读取到 Cookie 信息，避免了攻击者伪造 Cookie 的情况出现。

• 增加 token

该防护手段还是针对 Cookie 的盗取，由于请求中所有的用户验证信息都存放于 Cookie 中，因为我们抵御 CSRF 的关键就在于：如何在请求中放入攻击者所不能伪造的信息，并且该信息不能存放在 Cookie 中。那么我们就可以在请求返回中加入一个随机生成的 token，当请求来到时进行 token 的校验，如果校验不通过则认为是 CSRF 攻击而拒绝该请求。

• 通过 Referer

根据 HTTP 协议，在 HTTP 请求头上有一个字段叫做 referer，它记录了该Http 请求的来源地址。在通常情况下，访问一个安全受限的页面的请求都来自同一个网站。在 CSRF 中恶意请求是从 恶意站点 发出的，因此要防御 CSRF 攻击，需要对每一个请求验证其 referer 值即可。

参考文章链接

前端安全系列（一）：如何防止XSS攻击？ (opens new window)
前端安全系列（二）：如何防止CSRF攻击？ (opens new window)