Loading... # XSS 跨站脚本攻击 XSS 可分为两种： 1. 持久型攻击，恶意脚本没有存储到数据库 2. 非持久型攻击，而已脚本存储到数据库 或者分为三种类型： 1. 反射型 比如说通过参数传入的恶意脚本直接在页面 echo 出来 2. 存储型 比如说通过评论区或者参数传入的恶意脚本在后端被存储到数据库中，然后访问其它页面时被显示出来 3. DOM-Based 比如说通过参数传入的恶意脚本在页面的某个 DOM 节点中被引用显示 防御 XSS 攻击主要的方法就是对输入进行过滤（和SQL注入的基本防御思路一致），比如过滤 `<script>`、`eval()`、`<onerror>` 等，还要注意大小写，还可以对长度进行控制，可以指定输入格式等。 典型的攻击比如说可以通过存储型 XSS 攻击，恶意脚本为获取当前页面的 cookie，并发送给攻击者，攻击者即可利用该 cookie 来伪造用户登录。或者进一步构造 CSRF 攻击。 参考： https://zhuanlan.zhihu.com/p/26177815 https://blog.csdn.net/u011781521/article/details/53894399 # CSRF 跨站请求伪造 CSRF 攻击即跨站请求伪造，一般可以和 XSS 攻击一起利用。比如说在 XSS 攻击成功恶意脚本得到利用后，利用恶意脚本在页面的合法权力，冒充正当用户发出恶意请求。比如说类似qq空间的页面中通过恶意脚本点赞指定说说等。该类型 CSRF 可以获取 cookie。 参考：https://zhuanlan.zhihu.com/p/22521378 又或者用户已经合法登录了网站A后，又登录了一个钓鱼网站B，网站B中通过代码向网站A发起了恶意请求，此时因为域名相同，浏览器会自动把网站A的 cookie（带有 session id）给带上，因此该恶意请求得以成功执行。这也是 CSRF，而且是发生在第三方网站的 CSRF，该种 CSRF 不能获取 cookie，只能使用。 参考：https://blog.csdn.net/yexudengzhidao/article/details/93527586 防御 CSRF 的方法有： 1. 同源检测，即限制对指定域名的请求只允许从同域名发起，该检测可以限制第三方网站发起的 CSRF，但有限制，比如对网站自身的 XSS 漏洞导致的 CSRF 无法防御 2. CSRF token，在建立连接时服务端返回一个token，并插入到页面的每一处节点中，在发起请求时都带上该token，在服务端再进行校验。网上说这是一种很好的防御 CSRF 的方法，但似乎也无法防御 XSS 类型的 CSRF 攻击？只要 XSS 恶意脚本有能力获取 token 即可绕过。 # Cookie及Session cookie存储在客户端浏览器中，每一次同名域名的请求都会自动戴上。session 的设计目的是一种用于识别用户身份信息的机制。session存储在服务端，每一个 session 对应一个 session id，这个 session id 往往存储在 cookie 中。因此 cookie 可以说是 session 的一种实现方式。 参考：https://www.zhihu.com/question/19786827 最后修改：2022 年 03 月 22 日 03 : 19 PM © 允许规范转载