前端安全
XSS
XSS(Cross-Site-Scripting)，跨站脚本攻击，因为缩写和 CSS 重叠，被别人抢先了，所以只能叫做 XSS。
攻击者可以利用这种漏洞在网站上注入恶意的客户端代码。若受害者运行这些恶意代码，攻击者就可以突破网站的访问限制并冒充受害者。
举例
假设一个博客网站允许用户发表评论，并将评论内容直接显示在页面上。如果没有进行转义或编码处理，攻击者可以在评论中插入恶意脚本。例如：
用户评论：
<script>alert('XSS Attack');</script>
如果评论内容未经过转义或编码，这段恶意脚本将在其他用户浏览该页面时被执行。
<img src="1" onerror="alert(document.cookie)">
<a href="javascript:alert('霓虹灯');">是兄弟就来砍我</a>
防御XSS
1、转义：
最常见的方法就是对尖括号标签转义成实体字符存储：
const htmlEncode = function (handleString){
return handleString
.replace(/&/g,"&")
.replace(/</g,"<")
.replace(/>/g,">")
.replace(/ /g," ")
.replace(/\'/g,"'")
.replace(/\"/g,""");
}
2、内容白名单
比如常规文章、评论富文本，肯定是不需要
3、内容安全性政策 (CSP)
内容安全性政策 (CSP) 是一个可显著降低现代浏览器中 XSS 攻击的风险和影响的防护功能。 它允许网页的作者控制可以从哪里加载和执行JavaScript（和其他资源）。
CSRF
CSRF（Cross Site Request Forgery，跨站域请求伪造）CSRF主要就是在用户看不见的时候使用他们的Cookie来达到自己的目的。
这个漏洞主要依赖于浏览器的cookie是有一定时效的，只要不关闭浏览器或者退出登录，cookie都一直存在。
通常都是将目的隐藏在一个页面中，然后诱导用户去访问这个网站，在用户访问这个页面的时候，这个页面就会利用用户的cookie去向真正的服务器提交一些攻击者伪造的请求。这时候，如果服务器没有验证机制就可以攻击成功了。
防御CSRF
1、Referer Check
在 HTTP 头中有一个字段叫 Referer，它记录了该 HTTP 请求的来源地址。通过 Referer Check，可以检查请求是否来自合法的"源"。
Referer Check 不仅能防范 CSRF 攻击，另一个应用场景是 “防止图片盗链”。（防止不了先跳转到源网站再发请求）
2、token
CSRF 攻击之所以能够成功，是因为黑客可以完全伪造用户的请求，该请求中所有的用户验证信息都是存在于 cookie 中，因此黑客可以在不知道这些验证信息的情况下直接利用用户自己的 cookie 来通过安全验证。要抵御 CSRF，关键在于在请求中放入黑客所不能伪造的信息，并且该信息不存在于 cookie 之中。可以在 HTTP 请求中以参数的形式加入一个随机产生的 token，并在服务器端建立一个拦截器来验证这个 token，如果请求中没有 token 或者 token 内容不正确，则认为可能是 CSRF 攻击而拒绝该请求。
3、验证码
CSRF 攻击往往是在用户不知情的情况下构造了网络请求。而验证码会强制用户必须与应用进行交互，才能完成最终请求。因为通常情况下，验证码能够很好地遏制 CSRF 攻击。（但用户体验差）
SQL注入
SQL 注入：攻击者通过在页面输入框中输入特定的字符来执行 SQL 语句，从而获取敏感数据。防范措施包括过滤用户输入、使用参数化查询等。
Web 前端处理用户敏感信息的方法
首先要知道为什么要处理，就是防止敏感信息泄露。泄露方式有 2 种，一是普通用户越权看到，二是被爬虫批量收录。防止普通用户看到比较好办，常做是用 * 代替部分字符。申请查看后记录日志并显示完整字符。防爬虫主要是防源码泄露，这个就复杂了。有用 css 技术错位，有用特殊字符代替等。目的是让爬虫难以识别，但又不能防碍普通用户阅读。
使用加密技术，对敏感信息加密。
cookie session token
关于Cookie
为了解决http无状态链接的问题，出现了cookie机制。
Cookie工作原理介绍如下:
(1)用户从客户端通过浏览器输入用户名和密码，登录网站。
(2)网站的服务端返回登录成功信息的同时，在响应头返回一些键值对，这些键值中包含用户的用户名和密码等相关身份信息，这些信息被保存在浏览器的缓存中，这一步叫做set-Cookie.
(3)当完成登录操作的用户，再次访问网站的其他网页时，每次从客户端浏览器送给服务器的数据请求，请求头中都会带上之前的Cookie键值对，服务器端通过对这Cookie数据的检验判断用户已经登录，并返回已经登录的用户才能访问的数据内容。
Cookie的特点:
1、保存在用户的浏览器中。（如果不设置过期时间则关闭浏览器就删除，存在内存中，如果设置存在磁盘中。浏览器目录下）
2、可以主动清除。
3、可以被伪造。
4、不可以跨站共享Cookie.
关于Session
Session机制的工作原理与Cookie的签名加密机制的原理相似。区别在于，Cookie 机制是将用户的信息存储在客户端浏览器里，而Session机制是将用户的信息存储于服务端的一个散列表里，返回给用户-一个Session_ id, 让用户在登录成功后的每一次数据请求都带上Session jid, 服务端根据Session id来创建和更新Session表中的数据，并返回给用户特定的数据。
session的优势：
服务器端存储： Session 数据存储在服务器端，增加安全性，减少用户信息展示，客户端无法直接篡改，避免用户直接修改或访问数据。
支持复杂数据结构： Session 可以存储复杂的数据结构，如对象和数组，更灵活地维护用户会话状态。Cookie只有键值对。
减少网络传输： 只需要传递SessionID，减少了网络传输的数据量。
session局限性
1、服务器压力增大通常session是存储在内存中的，每个用户通过认证之后都会将session数据保存在服务器的内存中，而当用户量增大时，服务器的压力增大。
2、CSRF跨站伪造请求攻击session是基于cookie进行用户识别的, cookie如果被截获，用户就会很容易受到跨站请求伪造的攻击。
3、扩展性不强如果将来搭建了多个服务器，虽然每个服务器都执行的是同样的业务逻辑，但是session数据是保存在内存中的（不是共享的），用户第一次访问的是服务器1，当用户再次请求时可能访问的是另外一台服务器2，服务器2获取不到session信息，就判定用户没有登陆过。
Token
从各个终端与数据库进行数据交互的身份验证的字符串，就是Token。Token被翻译为“令牌”，顾名思义，起作用是给每一次需要身份验证的从客户端向服务端发送的数据请求一张代表了权限的"令牌"。
JWT的原理
JsonWebToken，简称JWT，
token的验证机制：
token与session的不同主要在
①认证成功后，会对当前用户数据进行加密，生成一个加密字符串token，返还给客户端（服务器端并不进行保存）
②浏览器会将接收到的token值存储在Local Storage中，（通过js代码写入Local Storage，通过js获取，并不会像cookie一样自动携带）
③再次访问时服务器端对token值的处理：服务器对浏览器传来的token值进行解密，解密完成后进行用户数据的查询，如果查询成功，则通过认证，实现状态保持，所以，即时有了多台服务器，服务器也只是做了token的解密和用户数据的查询，它不需要在服务端去保留用户的认证信息或者会话信息，这就意味着基于token认证机制的应用不需要去考虑用户在哪一台服务器登录了，这就为应用的扩展提供了便利，解决了session扩展性的弊端。
JWT的数据结构是很长一段字符串，其有三个部分，依次为Header头部、Payload负载、Signature签名。
Token优势
支持跨域访问: Cookie是不允许垮域访问的，token支持；
避免了大量session对象的存储带来的内存消耗，和各服务器之间session的复制或者专门用于存储session的服务器宕机带来的问题。
参考：
https://blog.csdn.net/weixin_43523043/article/details/126413109
https://zhuanlan.zhihu.com/p/38327058/
https://blog.csdn.net/DisMisPres/article/details/128486386
版权归原作者 小小小菜鱼 所有， 如有侵权，请联系我们删除。