前端安全防范
总结
- XSS：跨站点脚本攻击（代码注入）
- 持久型：服务器注入
- 非持久型：修改URL参数
- 防御：
- 转义字符（尖括号、引号、斜杠）
- 白名单（较多，显示富文本）：
- CSP:脚本加载来源白名单
- 转义字符（尖括号、引号、斜杠）
- CSRF：跨域请求伪造（浏览器引导点击）
- 防御：都是通过防御第三方网站的请求
- Cookie:SameSite禁止第三方访问cookie
- 验证Referer
- token
- 要点：
- get请求不修改数据
- 第三方网站不能访问Cookie
- 阻止第三方网站的请求接口
- 使用验证码或token
- 防御：都是通过防御第三方网站的请求
- 点击劫持
- 利用iframe诱导点击
- 防御：禁用iframe标签
- X-FRAME-OPTIONS
- JS禁用：通过iframe加载内容，不显示网页。
- 中间人攻击：
- 自身成为客户端服务端的数据转发中转站
- 防御：HTTPS，增设安全通道进行通信
感觉防御方式来说，其实很多都是通用的。点击劫持通过限制第三方请求貌似也可以防御。
XSS
跨站点脚本攻击
面试题目：什么是XSS攻击？如何防范XSS攻击？什么是CSP？
XSS：攻击者想尽办法将可以执行的代码注入到网页中
XSS攻击分类：
持久型
攻击的代码被服务端写入数据库中，危害很大。会导致正常访问页面的用户都收到攻击
对于评论功能，需要防范持久型XSS攻击，评论会被存储到数据库中，每个打开页面的用户都会被攻击到
非持久型
一般通过修改URL参数的方式加入攻击代码，诱导用户访问链接从而进行攻击。危害较小
问题1:需要诱导用户点击，涉及到跨域吧？而且可以使用点击劫持的方式诱导用户点击
如果页面需要从URL中获取某些参数作为内容，不经过过滤就会导致攻击代码被执行
http://www.domain.com?name=
如果使用Chrome这类浏览器，浏览器就能自动帮助用户防御攻击。
防御方式
转义字符
对于用户的输入应该是永远不信任的。最普遍的做法就是转义输入输出的内容。对引号、尖括号、斜杠进行转移
function escape(str) {
str = str.replace(/&/g, '&')
str = str.replace(//g, '>')
str = str.replace(/"/g, '&quto;')
str = str.replace(/'/g, ''')
str = str.replace(/`/g, '`')
str = str.replace(/\//g, '/')
return str
}
// -> <script>alert(1)</script>
escape('')
但是对于显示富文本，不能这样转义所有字符，会把需要的格式也过滤掉。可以通过白名单/黑名单的方式过滤。但是考虑到需要过滤的标签和标签属性实在是太多，更推荐使用白名单
CSP
参考：
CSP本质上就是建立白名单，开发者明确告诉浏览器哪些外部资源可以加载和执行。只要配置规则，如何拦截由浏览器自己实现。
CSP通过制定有效域 —— 即浏览器认可的可执行脚本的有效来源 —— 使服务器管理者有能力减少或消除XSS攻击所依赖的载体。一个CSP兼容的浏览器将会仅执行从白名单域获取到的脚本文件，忽略其他所有脚本
CSP开启方式：
- 设置HTTP Header 中的
Content-Security-Policy：policy - 设置
meta标签的方式
对于这种方式来说，只要开发者配置了正确的规则，即使网站存在漏洞，攻击者也不能执行它的攻击代码，而且CSP的兼容也不错。
问题：如何设置规则？在哪里设置规则？
CSRF
中文名为跨域请求伪造。原理就是攻击者构造出一个后端请求地址，诱导用户点击或者通过某些途径自动发起请求。如果用户是在登陆状态下，后端就认为是用户在操作，从而进行相应的逻辑。
攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己曾经认证过的网站并进行一些操作。由于浏览器认证过，所以被访问的网站会认为是真正的用户操作而去运行。
保持登录状态：网站在一次登陆后很久都不用登录了
利用漏洞：简单的身份验证只能保证请求发自某个用户的浏览器，却不能保证请求本身是用户资源发出的
感觉也是可以利用类似点击劫持的方式诱导用户使用自己的浏览器发送请求
问题：如何获取目标特定（想要的）数据？如何保证用户在登陆状态下点击？
使用POST方式提交也并不安全，攻击者可以诱导用户进入某个页面，在页面中通过表单提交POST请求
感觉和钓鱼网站类似
防御
- Get请求不对数据进行修改（一般使用get方式发送请求）
- 不让第三方网站访问到用户Cookie
- 阻止第三方网站请求接口（诱导用户的点击行为一般都是在第三方网站进行）
- 请求时附带验证信息，比如验证码或者Token
token：服务端生成的一串字符串，以作客户端进行请求的一个令牌，当第一次登陆后，服务器生成一个Token便将此Token返回给客户端，以后客户端只需带上这个Token前来请求数据即可，无需再次带上用户名和密码。是为了减轻服务器的压力，减少频繁地查询数据库，使服务器更加健壮
问题1:查询token似乎并不能防御CSRF啊，而且token这种机制似乎就是CSRF攻击的漏洞？？
SameSite
对Cookie设置SameSite属性。该属性表示Cookie不随着跨域请求发送，可以很大程度减少CSRF攻击，但是并不是所有浏览器兼容。
验证Referer
对于要防范的CSRF请求，可以通过验证Referer来判断该请求是否为第三方网站发起的
问题：如果是第三方网站发起的请求又该如何处理？全部禁止的话，跨域访问就不可以了
Token
服务器下发一个随机Token，每次发起请求时将Token携带上，服务器验证Token是否有效。
问题1:诱导用户点击发起的请求应该也会带上token吧？毕竟是用户自身的行为，虽然不是自愿的
点击劫持
这是一种视觉欺骗的攻击手段。攻击者需要将攻击的网站通过iframe嵌套在自己的网页中，并将iframe设置为透明，在页面中透出一个按钮诱导用户点击。
主要利用了iframe这个标签，防御的时候也是通过禁止iframe标签
防御
X-Frame-OPTIONS
X-Frame-OPTIONS是一个HTTP响应头，有很好的支持。就是为了防御iframe嵌套的点击劫持攻击
该响应头有三个值可选，分别是
- DENY，表示页面不允许通过 iframe 的方式展示
- SAMEORIGIN，表示页面可以在相同域名下通过 iframe 的方式展示
- ALLOW-FROM，表示页面可以在指定来源的 iframe 中展示
JS防御
某些远古的浏览器不支持上面的方式。
当通过iframe的方式加载页面时，攻击者的网页直接不显示所有内容
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-jGfXXH7G-1571707598207)(media/15716751910663/15716774781368.jpg)]
iframe正逐渐淘汰，浏览器也因为跨域的原因，阻止对iframe加载的页面的一些操作
中间人攻击
攻击方同时与服务端和客户端建立起了链接，并让双方认为链接是安全的，但实际上整个通信过程都被攻击者控制了。攻击者不仅能获得双方的通信信息，还能修改通信信息
通常不建议使用公共的wi-fi，容易发生中间人攻击。
自身就像一个路由器一样，同时与服务端、客户端建立连接。可能还是利用客户端传来的信息与服务端建立的连接，然后利用服务端传来的信息取信客户端以进一步获取信息。
防御
增加一个安全通道来传输信息。HTTPS就是来防御中间人攻击，但使用HTTPS之后并不是完全安全，如果没有完全关闭HTTP访问，攻击方可以通过某些方式将HTTPS降级为HTTP从而实现中间人攻击