前端安全-SQL注入、XSS、 CSRF

1.SQL注入

1.1定义

所谓SQL注入式攻击，就是攻击者把SQL命令插入到Web表单的输入域或页面请求的查询字符串，欺骗服务器执行恶意的SQL命令。 攻击者通过在应用程序预先定义好的SQL语句结尾加上额外的SQL语句元素，欺骗数据库服务器执行非授权的查询,篡改命令。

1.2原理：

假设的登录查询的正确sql为

　　SELECT * FROM users WHERE username = 'admin' AND password = '123'
Sever端代码(node)这么写的

const sql = `
        select * from user where username='${username}' and password='${password}'
    `
check(sql)

但是如果后端没做防注入处理，用户输入为

username-Input: xxx' or '1=1
password-Input: xxx or '1=1

　　实际执行的sql变为

  select * from user where username='xxx' or '1=1' and password='xxx' or '1=1'

我们知道 在sql里面 --空格 表示注释后面的语句
如果用户输入为

username-Input: admin' --空格
password-Input: xxx

此时执行的sql代码就是

 select * from user where username='admin' -- ' and password='xxx' //--空格后面的就无效了，也就是不校验密码，账号存在就能登录

1.3措施

我们可以看出之所以能入侵是因为用户输入的'和我们后端代码的'起了反应，造成了相关的漏洞所以我们应该避免这种情况

• 前端对用户的输入做限制
• 后端对用户的输入做转义 比如利用mysql库提供的escape方法把 ' 转义成 \'

const escape = mysql.escape
username = escape(username)
password = escape(password)
// 后面再执行sql就ok了

2.XSS

2.1 定义

XSS利用的是用户对网站的信任
XSS 全称(Cross Site Scripting) 跨站脚本攻击， 是Web程序中最常见的漏洞。指攻击者在网页中嵌入客户端脚本(例如JavaScript), 当用户浏览此网页时，脚本就会在用户的浏览器上执行，从而达到攻击者的目的. 比如获取用户的Cookie，导航到恶意网站,携带木马等

2.2原理

存储型 XSS

注入型脚本永久存储在目标服务器上。当浏览器请求数据时，脚本从服务器上传回并执行。

反射型 XSS

当用户点击一个恶意链接，或者提交一个表单，或者进入一个恶意网站时，注入脚本进入被攻击者的网站。Web服务器将注入脚本，比如一个错误信息，搜索结果等 返回到用户的浏览器上。由于浏览器认为这个响应来自"可信任"的服务器，所以会执行这段脚本。

基于 DOM 的 XSS

通过修改原始的客户端代码，受害者浏览器的 DOM 环境改变，导致有效载荷的执行。也就是说，页面本身并没有变化，但由于DOM环境被恶意修改，有客户端代码被包含进了页面，并且意外执行。

2.3措施

1. 对输入(和URL参数)进行过滤，对输出进行编码
反正就是前端不要太相信后端的数据 比如对于后端返回数据中的< 我们映射到html上应该是<
同理前端最好对用户输入的<做下转义再给后端，当然这玩意后端是一定得做防XSS攻击的。

一般都有现成的库或者框架帮我们做这种处理。以vue为例

2. 内容安全策略( CSP )
CSP了解一下？简单的说就是提前各种资源必须从哪下载，防止被篡改下载源从恶意源下载到恶意代码。

//html里面设置
<meta http-equiv="Content-Security-Policy" content="default-src 'self'; img-src https://*; child-src 'none';">


// node里面 helmet设置
app.use(
    helmet({
        contentSecurityPolicy: {
            directives: {
                defaultSrc: ["'self'"],
                scriptSrc: ["'self'", "https://maps.googleapis.com", "https://www.google.com", "https://www.gstatic.com"],
                connectSrc: ["'self'", "https://some-domain.com", "https://some.other.domain.com"],
                styleSrc: ["'self'", "fonts.googleapis.com", "'unsafe-inline'"],
                fontSrc: ["'self'", "fonts.gstatic.com"],
                imgSrc: ["'self'", "https://maps.gstatic.com", "https://maps.googleapis.com", "data:", "https://another-domain.com"],
                frameSrc: ["'self'", "https://www.google.com"]
            }
        },
    })
);

3.CSRF

3.1定义

跨站请求伪造（英语：Cross-site request forgery），通常缩写为 CSRF 或者 XSRF。 是一种挟制用户在当前已登录的Web应用程序上执行非本意的操作的攻击方法

3.2原理

CSRF利用的是网站对用户网页浏览器的信任
跨站请求攻击，简单地说，是攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己曾经认证过的网站并运行一些操作（如发邮件，发消息，甚至财产操作如转账和购买商品）。由于浏览器曾经认证过，所以被访问的网站会认为是真正的用户操作而去运行。这利用了web中用户身份验证的一个漏洞：简单的身份验证只能保证请求发自某个用户的浏览器，却不能保证请求本身是用户自愿发出的。

3.3措施

• 添加校验token

由于CSRF的本质在于攻击者欺骗用户去访问自己设置的地址，所以如果要求在访问敏感数据请求时，要求用户浏览器提供不保存在cookie中，并且攻击者无法伪造的数据作为校验，那么攻击者就无法再运行CSRF攻击。这种数据通常是窗体中的一个数据项。服务器将其生成并附加在窗体中，其内容是一个伪随机数。当客户端通过窗体提交请求时，这个伪随机数也一并提交上去以供校验。正常的访问时，客户端浏览器能够正确得到并传回这个伪随机数，而通过CSRF传来的欺骗性攻击中，攻击者无从事先得知这个伪随机数的值，服务端就会因为校验token的值为空或者错误，拒绝这个可疑请求。

• 检查referer字段

前端加密

最后再谈一下前端加密。
其实无论前端怎么加密，黑客总有办法解密。所谓道高一尺，魔高一丈！
那么我们为什么还要加密呢？为了增加黑客的解密成本，成本一高，也许黑客就不黑我们的网站了。
最极端的情况，前端总不能账号密码不加密，明文传输，并存在localstorage里面吧？从安全性上来说这无异于在web上裸奔...

所以加密的意义还是有的 (前三其实就是https的意义)

• 机密性。（第三方截获数据无法知道明文是什么）
• 数据完整性。（第三方篡改数据，会使得数据变得无效）
• 认证。（交流双方可以确认对方的身份，第三方无法伪装成任何一方进行交流）
• 利于闭源生态，从技术上遏制第三方应用和机器人的存在（账号密码token花样式加密）

参考

wiki-跨站请求伪造
wiki-跨站脚本
聊一聊WEB前端安全那些事儿
MDN-跨站脚本攻击
Web攻防之XSS,CSRF,SQL注入