我主要是通过各种手段得到代码/伪代码再百盒分析，所以本文按百盒的视角记录的，持续更新....

漏洞挖掘套路

可以把漏洞挖掘技能归纳为三点：

基础知识：各种漏洞定义，原理，危害，绕过等...
技巧：各种经验技巧，需要多看多挖多总结...
套路：也就是方法论，先怎么再怎么...

基础知识

漏洞出现可以归因为两点，不知道有这个问题与没有注意到有这个问题，前面是开发者能力局限，他们并没有意识到这样写代码会存在安全问题，如他们不知道拼接SQL会导致SQL注入，不知道采用的过滤手段可以被一些方法绕过，而后者是他们知道这些问题但是由于系统的复杂性有些点被忽略掉了。现在人们喜欢分的WEB方向和二进制方向其实在漏洞特性上也是比较明显的，由于Native语言接近底层漏洞类型比较少，基本都知道怎么写是不安全的，因此内存安全上更容易出现后种漏洞，这类漏洞更常见的挖掘方法是先分析哪些点复杂容易出错(JIT/异常处理等)再针对性的挖掘，或是开发自动化工具(如Fuzz)；而WEB这种开发比较上层，基于大量组件因此难以详尽的了解到各个细节，更容易出现前种漏洞。

作为安全人员是不能偏科的，无论所谓二进制WEB都需要了解，尽可能多的知道有哪些安全问题，即针对第一点去塑造信息差，利用不对等才能尽可能多的挖掘漏洞。

技巧

这是经验部分，挖多了就知道哪些点容易出问题了...

套路

组合拳：

搭好环境，配好调试
分析攻击面，一般WEB应用就它本身，可能会携带容器，WEB应用里如业务逻辑，框架，组件等
分析整体架构，URL路由
开搞，上方法论

方法论：

正向追踪：一般对授权前页面分析
逆向追踪：从危险点向前找看是否能控制输入
定向审计：凭经验看哪些地方容易出问题先重点看
历史漏洞：分析有哪些组件，分析它们的历史漏洞看容易出什么问题，看是否都修了

于是打算写下几篇笔记，来记录这些东西，本文聚焦在基础知识部分。下面列出了一些漏洞挖掘点，这其实就是挖掘面，这需要不断的积累(持续更新)，否则漏洞摆在那也不知道，详细的细节可查看备忘录datasheets和测试向导web-secruity-testing-guide...

历史漏洞

包括组件本身及自身的依赖，在必要时进行Component Analysis，它会分析引入的三方库的多维度信息，最终决定是否是危险组件，若是危险组件可从已公开漏洞或自行审计的角度进行分析，cyclonedx可用于组织依赖信息。可去tanable plugin搜索漏洞插件，例如编辑器就容易出1day，java里常见的shiro，struts等也是...

通用漏洞

这里只记录和语言无关的漏洞，其他的在特定语言处记录...针对特定类型漏洞，需要先分析该项目中是怎么使用它的，如SQL注入先分析都怎么使用SQL功能的，之后就可以通过则快速筛选出所有的SQL操作来挨个审计，这里的筛选必须要完全，昂就是多分析...

注入类

SQL注入(SQLI)

若使用了SQL那看看它是咋处理输入的，是否都是用的预编译方式：

若是比较热门的框架(如sqlalchemy)啥的就不先看这本身是否有问题了，去找找是不是所有地方都是用的这种方式，有没有地方漏掉了或误用了(有些会先拼接再预编译或混合使用部分代码直接使用拼接，如Like语句参数化查询，列名无法动态编译)
对于没有用框架的看看是怎么处理的，若是过滤就看能不能绕，绕的思路就是前后端处理不一致，如编码/大小写/添加无效字符/内联注释/多重敏感词/等价替换/宽字节注入/溢出截断，必要时可fuzz不一致的符号。

注：模拟预编译是PHP层次的预编译，它会使用一些转义，但是对于宽字节注入等依然可以绕过，另一种在SQL端预编译相对更安全。

附注入方式：

方法	说明
Union注入	NULL
报错注入	开启错误输出时，可使用updatexml/floor/exp
带外注入	把数据通过其他方式传出，如DNS查询时带出
堆叠注入	能堆叠那不是为所欲为，MSSQL默认有滴
布尔型盲注	返回的信息能不一致时用它
时间型盲注	返回一样时根据时间来，如sleep/benchmark
二次注入	能修改/增加数据且可插入'等符号，会获取数据拼接入语句再次查询

查找时，可使用一些监控软件辅助，如开启MySQL执行监控：

set global general_log=on;
set global log_output='table';
select * from mysql.general_log;
# 或者输出到文件里
SET global general_log_file='/tmp/mysql.log'; 
SET global log_output = 'file';

类似的，sqlserver可用profier监视，但很难用。

存在漏洞时，要仔细研究它的影响，如：

若支持堆叠注入，则能执行任意语句，如插入自定义数据。
若支持文件读写，可尝试直接写webshell。
是否支持命令执行，如mssql...

XML外部实体注入(XXE)

在用户可以控制xml解析的内容时，看看它是否支持外部实体解析功能，是否开启了该功能(可以先搜索该库是否有相关漏洞，然后本地喂最简单的payload用dnslog检测)，可以就搞事情，参考[3, 4]，在利用时若不能外连可试试[5] [6]，可以逐步测是否支持实体，外部实体：

<?xml version=”1.0" encoding=”UTF-8"?>
<!DOCTYPE example [
  <!ENTITY betamao "Hello World!" >
]>
<example>&betamao;</example>

与

<?xml version=”1.0" encoding=”UTF-8"?>
<!DOCTYPE example [
  <!ENTITY betamao SYSTEM "file:///etc/passwd" >
]>
<example>&betamao;</example>

参考

[0] Don’t open that XML: XXE to RCE in XML plugins for VS Code, Eclipse, Theia, … -- thezero (2019)

[1] XXE-scape through the front door: circumventing the firewall with HTTP request smuggling -- pieter (2020)

[2] Misconfigurations in Java XML Parsers -- Immunity Inc (2021)

[3] xxe / XML External Entity Prevention Cheat Sheet

[4] Pre-authentication XXE vulnerability in the Services Drupal module -- Renaud Dubourguais (2015)

[5] Exploiting XXE with local DTD files -- Arseniy Sharoglazov (2018)

[6] https://twitter.com/phithon_xg/status/1073845338606194689 -- Phith0n (2018)

[7] From XML External Entity to NTLM Domain Hashes -- Gianluca Baldi (2018)

[8] From blind XXE to root-level file read access -- peter (2018)

[9] XML entities/Finding and exploiting blind XXE vulnerabilities/XML external entity (XXE) injection -- portswigger

命令注入

黑盒可以凭直觉猜哪些地方的功能使用了外部工具，如网络相关的，系统相关的设置等，都比较喜欢偷懒觉得用外部工具一条命令的事；有代码当然是直接根据语言查找对应的危险函数，找到后看命令是否可控，是怎么过滤的，如果使用语言提供的过滤功能一般就没命令注入了，但可以再注意下参数注入，如果自己实现的过滤，参考shell部分看是否可以绕过。

在命令注入里，还得注意参数注入，有时它本身参数已经防护到位了，但是其处理程序在处理参数时又不小心使用了危险的方法，此时也会造成漏洞，当参数拼接给shell脚本时尤其需要注意！

代码注入

比较少见，就找根据语言找对应的代码执行危险函数，特定的脚本执行/编译库，语言特性函数(反射等)...

CRLF注入

在写日志(隐匿痕迹)，写配置(修改任意配置)，解析头部(SSRF或修改任意头[1])等位置要小心，在存在CRLF时可能转换为SSRF(LDAP,)...

参考

服务端模板注入(SSTI)

目标使用模板引擎时，若它会动态生成语句且输入的部分用户可控(即模板的内容用户可控)时就存在模板注入[0] ，此时根据模板引擎提供的功能可能实现信息泄漏或者代码执行。

注：有时模板引擎提供沙盒，此时要能绕过沙盒实现非预期功能才算存在漏洞。

参考

[0] Server-Side Template Injection -- James Kettle (2015)

LDAP注入

LDAP比较常出现在认证部分，通常需要我们先配置LDAP服务器，所以可以预先搭建一个环境以后经常会用得上。可以先搜索一下使用的库看是否有相关的问题，比如一些人会在ldap库官方询问是否对该问题有防护以及推荐的操作，不确定时再分析它最底层生成的查询语句，可以直接下断点或使用抓包工具查看，如果没过滤就可以搞事情，可见[0]

参考

[0] LDAP注入与防御解析

CSV注入

CSV本身是很简单的格式，但是一些软件会去做一些高级的解析(参考1, 2, 3)这时可能造成问题，一般这都是危害客户端的，但是也可能危害服务端，若服务端用重型软件解析CSV时就要注意了(案例:1, payload：1)

ESI/SSI注入

这东西我没见过，但这种思路却是有用，有很多前端服务器会处理上游的特定数据，如果能通过某种方式(XSS/文件上传)控制上游返回的数据，则可根据特定功能造成漏洞...

ESI在处理<esi:标签时注意下[0,1,2]，如果真的要挖就准备个dnslog的payload看会不会被处理，SSI在apache加载mod_include，nginx使用ssi on指令时可以注意下。

参考

[0] Beyond XSS: Edge Side Include Injection -- Louis Dion-Marcil

[1] ESI Injection Part 2: Abusing specific implementations -- Louis Dion-Marcil

[2] Beyond XSS: Edge Side Include Injection Abusing Caching Servers into SSRF and Client-Side Attacks

XPath注入

emmm，实际还没遇到过，反正就是注意吧看有没有用xpath进行查询且语句部分可控。

文件相关

文件上传

找上传点，分析怎么过滤的(主要是文件路径限制)，研究是否可以绕：文件类型，文件头，文件后缀，文件包含，解析问题，系统特性等...

文件上传有个高危点就是升级(升级包校验是否可绕)与备份恢复，这两点极易造成任意命令/代码执行。

‼️目录穿越

就是看../这种能不能过，还有软连接问题，在遇到压缩/归档文件时，也要留意下目录穿越，这个其实可以准备一堆畸形文件运行试试，或者直接看它的解压代码有没有对文件名进行过滤，现在有名的库的最新版基本都没问题，如果遇到老版本或不知名/自己实现的库则要注意，可参考zip-slip-vulnerability对比版本。在可上传压缩包时有很多点可审计，如让压缩包解压一般崩溃，让压缩包携带恶意文件等...

除了目录穿越，压缩文件还可能存在解压炸弹，在解压时未限制资源则可能存在问题...

还有符号连接，zip/tar等都支持符号链接，通过它也可能造成任意文件读写(目录软连接穿越)...

文件读取与包含

本地与远程文件包含(PHP中开启allow_url_include)，这里先记录下系统特性，Windows下FindFirstFileExW，FindFirstFile存在如下特性：

大于号 > 等价于通配符？ 0次或1次

小于号 < 等价于通配符 * 0次或多次

双引号 " 等价于通配符 . 匹配除换行符(\n, \r)之外的任意单个字符

https://www.secshi.com/16971.html

上传时evil.php. evil.php 会被去掉， %00``%80-%90会被截断，另外还有NTFS ADS特性

短文件名能穿越且是黑名单时可覆盖.htaccess

媒体处理

这里指很多种文件的处理，如图像，office等，此时需要具体到应用或库：

PDF：
Image：
Office：

不一致问题

这是当下的热点，在各种防护绕过技术中都使用到了不一致问题，当作用点与防护点不同时，就可考虑是否存在不一致，而这种不同很可能就能绕过限制实现利用，由于设计多层导致难以防御，所以对安全做的好的产品可重点关注这点！

‼️请求走私(Request Smuggling)

在设备中常见存在多层服务，并在第一层(前端)做些处理后给第二层(后端)，如nginx作为网关再将指定数据转发给后端的apache，这里面可能会涉及到对请求分包不一致问题，此时就可能存在漏洞，根据XC大佬的总结：

若后端支持从一个连接中获取多个请求包(如支持keepalive)
前后端分包解析存在不一致

这就可能存在漏洞，在我们的场合中请求走私更像一种SSRF，能携带任意HTTP包到后端，即造成一些服务端攻击：

绕过限制：可能前端需要对请求做某些处理(添加请求头，限制URL或参数等)后再发到后端，此时构造的数据将会被修改，而通过走私能控制整个请求数据包，或是前端在未授权前能访问后端特定接口，则可利用走私访问同服务其他接口
类似CSRF：将自己构造的头部与其他用户构造的头部合并，以利用其他用户的token进行操作
ETC...

另外它还可以攻击客户端，即异步(DeAsync)攻击，造成如缓存投毒等危害，具体来说就是由于前端以为只放过一个请求而后端给了多个响应，导致前端处理后续请求与响应不匹配，攻击者可借此为受害者返回错误的信息。

如果前端支持HTTP2，而到最终服务的过程中转换成了HTTP1那么也可能存在漏洞[16,17,18,19]。而如果支持websocket，可检查前端有没有正确处理协商过程，如果前端以为协商成功并升级为WS而实际并没有协商成功，那么将可以直接绕过前端[15]。

参考

[1] 协议层的攻击——HTTP请求走私 -- mengchen (2019)

[2] HTTP Desync Attacks: Request Smuggling Reborn -- James Kettle (2019)

[3] HTTP request smuggling -- portswigger

[4] Critical Vulnerability in HAProxy (CVE-2021-40346): Integer Overflow Enables HTTP Smuggling -- Ori Hollander & Or Peles (2021)

[5] Practical HTTP Header Smuggling: Sneaking Past Reverse Proxies to Attack AWS and Beyond -- Daniel Thatcher (2021)

[6] Empirical Study of HTTP Request Smuggling in Open-Source Servers and Proxies -- MATTIAS GRENFELDT &ASTA OLOFSSON (2021)

[7] Breaking the chains on HTTP Request Smuggler -- James Kettle (2019)

[8] HTTP请求走私攻击-学习笔记 -- V0W (2020)

[9] Hiding Wookiees in HTTP - HTTP smuggling is a thing we should know better and care about. -- regilero (2016)

[10] Security: HTTP Smuggling, Apache Traffic Server -- RBleug (2019)

[11] Smuggling HTTP headers through reverse proxies -- dtcert (2020)

[12] HTTP Desync Attacks: what happened next -- James Kettle (2019)

[13] Security: HTTP Smuggling, Apsis Pound load balancer -- RBleug (2018)

[14] HTTP Request Smuggling in 2020 – New Variants, New Defenses and New Challenges, white paper -- Amit Klein (2020)

[15] Smuggling HTTP requests over fake WebSocket connection -- 0ang3el (2019)

[16] h2c Smuggling: Request Smuggling Via HTTP/2 Cleartext (h2c) -- Jake Miller (2020)

[17] HTTP/2: The Sequel is Always Worse -- James Kettle (2021)

[18] http2smugl: HTTP2 request smuggling security testing tool -- wallarm (2021)

[19] HTTP Request Smuggling via higher HTTP versions -- neexemil (2021)

‼️键处理不一致

经常会遇到键值对方式传递数据，此时对于键的处理(重复值，大小写等)不一致就会造成一些漏洞： 1. 在HTTP参数里，如出现同名参数时，处理出错可能造成HTTP参数污染[0] 2. 在Json里，绕过一些检查[1] 3. 在HTTP头里，对重复头处理不一致，或对键进行一些变换(-与_转换，空格等无效字符处理等)会导致漏洞[2] 4. 在Cookie里，不同过程检查不同的键也可能造成漏洞 5. ...

参考

[0] HTTP Parameter Pollution

[1] An Exploration of JSON Interoperability Vulnerabilities -- Jake Miller (2021)

[2] Smuggling HTTP headers through reverse proxies -- Robin Verton (2020)

‼️编码不一致

编码解析问题经常被用于绕过各种限制

参考

[0] x-up-devcap-post-charset Header in ASP.NET to Bypass WAFs Again! -- Soroush Dalili (2019)

[1] WAF Bypass Techniques - Using HTTP Standard and Web Servers’ Behaviour -- Soroush Dalili (2018)

[2] Rare ASP.NET request validation bypass using request encoding -- Soroush Dalili (2017)

[3] Attacking "Modern" Web Technologies -- Frans Rosén (2018)

[4] A Forgotten HTTP Invisibility Cloak -- Soroush Dalili (2017)

[5] Request encoding to bypass web application firewalls -- Soroush Dalili (2017)

DNS重绑定

它是时间上的不一致，即TOCTOU/DoubleFetch，通过指定一个攻击者可控的域名，导致第一次获取到的值与第二次获取到的值不一致，从而绕过一些限制或实现特殊的攻击...

参考

[0] DNS Rebinding Attack: How Malicious Websites Exploit Private Networks -- Zhanhao Chen (2021)

[1] (somewhat) breaking the same-origin policy by undermining dns-pinning -- Maddin (2006)

[2] Circumventing DNS Pinning for XSS -- ha.ckers (2006)

[3] DNS Rebinding Headless Browsers -- W/Labs (2018)

‼️URL解析不一致

在存在URL解析验证的时，可考虑解析不一致问题，即验证时解析结果与使用时不一致（业务代码中，web服务器中）

参考

[0] Breaking Parser Logic! Take Your Path Normalization Off and Pop 0days Out -- Orange (2018)

[1] A New Era of SSRF - Exploiting URL Parser in Trending Programming Languages! -- Orange (2017)

[2] EXPLOITING URL PARSERS: THE GOOD, BAD, AND INCONSISTENT -- Noam, Sharon, Raul, Kirill (2021)

[3] Weird proxies/2 and a bit of magic -- greendog (2018)

缓存投毒(CP)

要有缓存的，研究下缓存的键是啥，再去构造同键不同值的情况污染缓存

参考

[0] Practical Web Cache Poisoning

[1] Web Cache Deception Attack

依赖不一致

这是一种思路，可以看[0]这个例子，软件经常使用包管理工具，当开发者开发一个内部包而没有上传到公共仓库时，如果包管理工具处理依赖的顺序是公共仓库优先于本地仓库则攻击者可以往公共仓库上传恶意包来实施攻击。

参考

[0] 例:Dependency Confusion: How I Hacked Into Apple, Microsoft and Dozens of Other Companies -- Alex Birsan (2021)

js语法解析不一致

参考

[0] LEXSS: Bypassing Lexical Parsing Security Controls -- Chris Davis (2021)

其他

长度处理不一致：截断问题，如前端视作超长串而后端会裁切导致绕过限制

特殊字符不一致：如后端使用C不安全函数，而前端不特殊对待\0

参考

[0] 例:Filling in the Blanks: Exploiting Null Byte Buffer Overflow for a $40,000 Bounty -- samwcyo (2019)

其他类

服务端请求伪造(SSRF)

SSRF在设备上太好用了，也是重点关注的对象，审计时就是找发请求的api，根据语言来找，如python的socket/urllib/requests等，这个必须根据具体环境去找，若它的参数来自用户且使用了过滤则很可能有问题，因为过滤很难防御(如IP的编码，域名绕过[7]等)，若只是IP一般是将其转换为数字再起匹配而不是使用正则，另外还有个点就是跟随重定向，通过这可以绕过一些限制，配合黑盒时可参考[0]找危险点... 当存在SSRF漏洞时，需要研究函数的功能，如它支持哪些特性，哪些伪协议，是否可重定向等，这可能可实现一些绕过，命令执行，发送任意数据等...

SSRF通常发生在HTTP请求上，而能控制的点可能也比较少，此时可利用一些解析上的问题[9]或DNS重绑定[8]等方式去扩大攻击面...

参考

[0] SSRF漏洞的挖掘经验 -- he1renyagao (2015)

[1] Server-Side Browsing Considered Harmful

[2] SSRF VS. BUSINESS-‐CRITICAL APPLICATIONS. -- Alexander, Dmitry, Alexey (2012)

[3] SSRF VS. BUSINESS-CRITICAL APPLICATIONS -- Alexander (2012)

[4] Blind SSRF exploitation -- bo0om (2020)

[5] OWNING THE CLOUT THROUGH SSRF AND PDF GENERATORS -- Ben , Cody

[6] SSRF bible. Cheatsheet -- Wallarm ,d0znpp (2017)

[7] https://nip.io/, http://xip.io/

[8] TLS-poison -- imdx (2020)

[9] A New Era of SSRF - Exploiting URL Parser in Trending Programming Languages! -- Orange (2017)

任意重定向

开放重定向通常需要配合其他漏洞使用以绕过一些限制。通常是在正常的URL带异常的尾巴，去那些容易出现重定向的位置，如登录页找，有代码直接根据重定向函数找，看是否过滤的好。这里记录一些常见的参数：url,site,host,redirect,domain,target,link,jump_to,returnURL...

Websocket问题

跨站Websocket劫持(CSWSH)：在目标使用cookie进行websocket的鉴权时，若没有验证Origin或CSRF token(或SameSite=None)则存在CSRF漏洞，由于攻击者可以完全控制websocket client的代码，因此可以完全的交互[0]。

注：由于现在浏览器已经支持抗CSRF了，因此这个在现实中并不好用，只能去骗洞。

一般websocket利用时需要自己写代码，推荐socket.io库

参考

[0] Cross-Site WebSocket Hijacking (CSWSH) -- Christian Schneider

[1] https://speakerdeck.com/0ang3el/whats-wrong-with-websocket-apis-unveiling-vulnerabilities-in-websocket-apis

正则表达式Dos (REDoS)

当用户能控制正则表达式的模式语句时，若使用的表达式引擎使用回溯方式，则存在REDoS[0]。这通常出现在搜索等位置，发现可控模式串时可通过如下片段检测RE引擎是否存在问题：

pattern: ^(a+)+$
str: aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa!

参考

[0] Revisiting ReDoS: A Rough Idea of Data Exfiltration by ReDoS and Side-channel Techniques -- Takashi Yoneuchi (2020)

密码学相关误用

密码学相关的漏洞，一般就关注如下点：

随机数/种子强度如何，是否是密码学安全的，是否能通过某些数据推测种子(包括通过生成的随机数逆推种子)...
Hash是否强度够，是否有碰撞影响，是否受hash长度扩展攻击影响[1]
密钥是否硬编码，能否通过各种方式得到
在填充时是否受PaddingOracle的影响
加密/签名方案是否有问题，是否有误用
是否受时间攻击[0]，一些比较功能不会对输入进行处理就逐个比较，此时时间上的差异“可能”能被利用

参考

[0] Timing Attack - 從入門到發現沒時間了 -- Allen Chou (2022)

[1] Understanding MD5 Length Extension Attack -- aullik5 (2012)

信息泄漏

和黑盒关注的点不同，此处关注代码本身会泄漏信息，如它是否会产生或存在一些路径可预测可访问的文件，某些请求获取携带敏感数据的响应等...

不完全的审计

包括与日志相关的：在某些点需要记录日志但没有记录，或能绕过，或能污染日志与访问限制相关的：有些点没有或可绕过访问限制，如登陆尝试次数等

逻辑漏洞

竞争条件

若使用共享对象未加锁就会有条件竞争，如打开某文件，读取内容修改并写回若无锁则会有问题... 还有有时会生成临时文件，抓住它的存活间隙可根据功能造成一些危害，如临时文件在/tmp下，session也在tmp下且路径可知可控导致绕过授权...

越权

分为横向越权与纵向越权，就看某操作获取的参数所需权限是否与身份相关，若是则分析此处是否有授权验证，是否未验证身份，是否直接使用了请求传递的身份，是否逻辑上可绕过某些验证(如双因素)等...

其实主要是找关键逻辑，如登录逻辑，购买流程，修改流程，看是否会有逻辑上的问题导致漏洞...

错误后未中止

看在出现错误或期待结束的位置，是否实现了正确的终止，如某些校验错误，鉴权失败后没有调用exit等终止导致后续逻辑被执行，或初始化接口检测到已初始化还继续执行...

需要交互类

不会真有人会挖这玩意儿吧！在审计内部产品时可能还真得有,特别是产品专门做了相关的防护时更得检查是否可以绕过。

跨站脚本(XSS)

只要看到客户的输入被返回到客户页(DOM型不会经过服务端)了就要小心，特别注意一些输入框的后台逻辑，审查方式就是看所有的输入点是否会被直接或间接(如先存入数据库再在其他接口取出)输出，有的话再看是否有验证或净化，如果它用的是过滤的话看看能不能绕，如果是某种牛批的转义就选择放弃吧，反正也没啥用。。。

BUT，如果存在客户端应用就要留意了，例如基于JS的客户端，它的沙箱相对较弱因此XSS可能造成严重的危害！

客户端请求伪造(CSRF)

一般认为需要交互的都是垃圾洞，但是没有其他漏洞时，存在CSRF时利用钓鱼等(如1)方式成功率还是不低的，因此无奈之下可以研究下，先看看防护方式：

检查Referer
带随机Token
重输入关键信息
使用SameSite=Strict/Lax修饰Cookie[0] (当前浏览器基本都支持了，且大多默认为lax)，注意它限制的是同站而非同源，因此同站下还有机会。

现在一般token用的最多，一般审计的点就是token是否可预测(例如通过某硬编码密钥去生成与校验，还有一个token可以被别人用的，可多次使用)，token检查是否覆盖全了(有些关键位置的关键方法被漏了)，是否可以让token失效

参考

[0] SameSite cookie 的说明 -- Rowan Merewood (2020)

相对路径覆盖(RPO)

用的是相对路径时，可能存在这问题，在按数量算钱/KPI时可以用来骗洞，原理就是在前后端解析请求路径时存在不一致，导致用户访问攻击者提供的URL时获取到错误的CSS，攻击者通过控制CSS的内容来窃取一些信息，emmm确实没啥用的玩意儿...

参考

[0] RPO Gadgets

[1] RPO

[2] detecting-and-exploiting-path-relative-stylesheet-import-prssi-vulnerabilities

PostMessage未验证来源

直接浏览器F12看有没有注册message事件，如果有看它的逻辑有没有验证origin或source，如果没有那么其他窗口可向该窗口发送该事件[0]，具体危害依赖于message事件实现的功能，例子可见[1]。

参考

[0] MDN Web API接口参考 PostMessage

[1] 例: Hacking Slack using postMessage and WebSocket-reconnect to steal your precious token -- Frans Rosén(2017)