这是我参与「第五届青训营 」笔记创作活动的第8天。

一、重点内容

• 攻击角度
• 防御角度

二、详细知识点介绍

攻击篇

跨站脚本攻击（XSS)

访问页面时被攻击 主要利用了：开发者盲目信任用户提交的内容。前端工程师直接把用户提交的string转化成dom。 特点：通常难以从UI上感知（因为是暗地执行）；窃取用户消息；绘制UI（例如弹窗），诱骗用户点击、填写表单。
存储型XSS（Stored XSS)
恶意脚本存储到数据库中，用户访问页面（读数据）就会被攻击。（危害最大，因为对全部用户可见） 例：
反射型XSS（Reflected XSS）
注入脚本是在服务端进行注入，不涉及数据库，从URL上攻击。
基于Dom的XSS（DOM-based XSS)
完全在浏览器完成整个闭环(发起+执行），不需要服务器的参与。
基于浏览器的XSS（Mutation-based XSS）
拿捏了不同浏览器的渲染DOM机制差异，按浏览器进行区别攻击。

CSRF（Cross-site request forgery)

特点：在用户不知情的情况下，利用用户权限，构造指定HTTP请求，窃取或修改用户敏感信息。

injection注入

不局限于SQL，还可以用CLI，os command。 服务端伪造请求（SSRF）严格而言不是injection，但是原理相似。

Dos

通过某种方式（构造特定请求），导致服务器资源被显著消耗，来不及响应更多请求，导致请求挤压，进而雪崩效应。

ReDos

基于正则表达式（贪婪模式）不断进行回溯的Dos。

DDos

来自大量僵尸设备的洪水攻击，大量的请求堆积，使得服务器崩溃。

中间人攻击

发生条件：明文传输；信息篡改不可知；对方身份未验证。

防御篇

应对XSS攻击

永远不要相信用户的提交内容，不要将用户提交的内容直接转换成DOM。 现成工具：前端：主流框架都默认防御XSS;google-closure-library。服务端：DOMPurify。

Same-origin Policy（SOP）同源策略

查看/协议、域名、端口

Content Security Policy（CSP）

来自安全源的脚本可以执行，否则直接抛出错误 。禁止eval+inline script。

应对CSRF

判断请求来自于合法来源：origin+referer/服务器接收过页面请求则可以标识。（token需要过期时间，以防某天用户token被窃取）

三、个人总结

安全问题可以说是可能会被用户忽视但是又非常重要的一环，作为开发者，我们应该熟悉如何进行攻击（为了站在攻击者的角度检查被攻击的可能性）和防御。这次课对于一些攻击类型有了初步了解，也学习了常用的防御方法。