前端网络安全：SQL 注入、XSS、CSRF

SQL 注入

某网站登录验证的查询句：

strSQL = "SELECT * FROM users WHERE (name = '" + userName + "') and (pw = '"+ passWord +"');"
1

而恶意用户输入的参数为：

userName = “1’ OR ‘1’='1”;
passWord = “1’ OR ‘1’='1”;

直接做拼接：

strSQL = "SELECT * FROM users WHERE (name = '1' OR '1'='1') and (pw = '1' OR '1'='1');"
// 相当于
strSQL = "SELECT * FROM users;"
1
2
3

参数化查询来避免直接将参数与查询句拼接，并进行适当的输入检查、插入转义字符、严格设定程序权限，就能够有效避免 SQL 注入了。

XSS（跨站攻击/JavaScript 注入）

网站被恶意用户植入了其他代码，通常发生在网站将用户输入的内容直接放到网站内容时。

绝大多数的 XSS 方式，都是通过各个元素的 background-image 属性或者元素上的各种事件回调来实现
特别值得注意的是 SVG，由于 SVG 中可以写入任意 HTML，还可以加上 onload 事件，如果把 SVG 当成普通图片处理，直接作为网站内容使用，如果遇到恶意用户的话，后果不堪设想。所以在上线上传图片功能时，务必要把 SVG 过滤掉！

避免 XSS 的方法其实也很简单，只要在数据输入输出时做好字符转换，使恶意代码不被执行，而是被解析成字符就可以了。

CSRF（跨站请求伪造）

是一种利用 Cookie 及 Session 认证机制进行攻击的手段

银行的转账网址：

http://www.examplebank.com/withdraw?account=AccoutName&amount=1000&for=PayeeName

恶意用户如果在网站中注入

<img src="http://www.examplebank.com/withdraw?account=Alice&amount=1000&for=Badman">
1

当不知情的用户浏览到攻击者的网站时，<img / > 会自动发出这个请求，如果登录银行的 Session 尚未过期，那么这个请求很可能就会被银行接受，最后会在用户本人不知情的情况下“被”转帐。

这种攻击方式可以与前面所说的 XSS 是相辅相成，例如在没有防范 XSS 的论坛网站中植入 < img/>，那么其 src 属性就应该是获取敏感信息的 API URL。

方法

检查 Referer：在服务器端检查请求头中 Referer 的值，也就是检查请求的来源，如果是来自允许的网站，才会正常执行 API 的功能。
CSRF Token：在 Cookie 及请求发送的数据中都加上 csrftoken，并检查值是否相同，如果请求来源是自己的网站验证就会通过；反之，由于外部网站无法在代码中得到其他网站的 Cookie，因此无法在请求中带上 csrftoken。
SameSite Cookie：在 Cookie 中加上 SameSite 属性，确保 Cookie 仅能在自己的网站使用。

JSON 劫持是利用现代网站前后端通过 API 进行数据交换的特性，只要能获得使用者权限，并调用获取资料的 API，再加上改写原生的 JavaScript 对象，就可以窃取用户的敏感信息。

获得权限的部分于 CSRF 相同，通过

看起来很恐怖，那么该如何解决呢？除了前面所说的 CSRF Token 外，许多大公司还采用了另一种有趣的解决方式。即 API 的响应内容开头为 for ( ; ; );，这也是利用 了< script > 引入的 JavaScript 会立即执行的特性，把攻击者的网站卡死在循环里。