WebGoat靶场日记
sql注入
编写安全代码
sql绕过
（1）关键字内插入/**/
（2）大小写绕过
（3）双写绕过（删除关键字的情况）
（4）内联注释绕过（mysql）（把一些特有的仅在MYSQL上的语句放在 /*!...*/ 中，这样这些语句如果在其它数据库中是不会被执行，但在MYSQL中会执行）
（5）关键字内插入（有些网站为了防止xss可能过滤）
（6）and和or可以试试&&、||或者异或注入
爆破服务器ip
(CASE+WHEN(substring((SELECT+ip+FROM+servers+WHERE+hostname='webgoat-prd'),1,1)='§1§')+THEN+hostname+ELSE+ip+END)--+
XXE
XML 实体允许定义标记，这些标记将在解析 XML 文档时替换为内容。通常有三种类型的实体：
- internal entities（内部实体）
- external entities（外部实体）
- parameter entities（parameter 实体）
在 Java 应用程序中，XML 可用于将数据从客户端获取到服务器，我们都熟悉 JSON API，我们也可以使用 xml 来获取信息。大多数情况下，框架会根据 xml 结构自动填充 Java 对象。
XML 外部实体攻击是一种针对解析 XML 输入的应用程序的攻击。当包含对外部实体的引用的 XML 输入由配置较弱的 XML 解析器处理时，会发生此攻击。此攻击可能导致机密数据泄露、拒绝服务、服务器端请求伪造、从解析器所在计算机的角度进行端口扫描以及其他系统影响。
一般来说，我们可以区分以下类型的 XXE 攻击：
- Classic：在这种情况下，外部实体包含在本地 DTD 中
- Blind: 响应中不显示输出和/或错误
- Error: 尝试获取错误消息中资源的内容
一个例子：
]>
&root;
第7题：将Content-type改成xml，然后注入即可
第11题：将恶意dtd文件上传到webwoft 在webgoat评论修改xml调用恶意dtd，包含文件发送给webwoft
路径遍历
常用步骤：（1）../ （2）抓包改文件名
当然，这是一个非常简单的例子，在大多数情况下，这不会起作用，因为框架为此实现了控件，所以我们需要更有创意并开始编码../ 在请求发送到服务器之前。例如，如果我们 URL 编码 ../ 你会得到 %2e%2e%2f，接收此请求的 web 服务器会再次将其解码为 ../ 的。也可以使用双写绕过。
第5题
抓包发现其请求的参数会拼接一个后缀.jpg，因此构造文件名如直接传入参数id=../path-traversal-secret。服务器返回的响应中包含了 "非法字符" 的错误信息。为了绕过这个问题，可以尝试对参数进行编码，例如使用URL编码，将参数转换为 id=%2e%2e%2fpath-traversal-secret，以期成功绕过服务器对非法字符的检测和限制。这种方法可以帮助我们访问所需的资源而不触发服务器的安全机制。发现回应400，可能在上一层，继续遍历即可
第7题
上传.zip文件
mkdir -p /root/.webgoat-8.2.0/PathTraversal/root123
cd /root/.webgoat-8.2.0/PathTraversal/root123
curl -o root123 http://localhost:8080/WebGoat/images/cats/1.jpg
zip profile.zip ../../../../../../../../root/.webgoat-8.2.0/PathTraversal/root123/root123.jpg
JWT令牌
令牌采用 base64 编码，由三部分组成：
- header
- claims
- signature
第7题
base64编码 alg=none为不签名 修改权限
ewogICJhbGciOiAibm9uZSIKfQ.ewogICJpYXQiOiAxNTk0NzE1MDMyLAogICJhZG1pbiI6ICJ0cnVlIiwKICAidXNlciI6ICJUb20iCn0.
第8题
用hashcat -m 16500 jwt.txt -a 3 -w 3 20k.txt --force爆破secret，然后修改
编码得到eyJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJXZWJHb2F0IFRva2VuIEJ1aWxkZXIiLCJhdWQiOiJ3ZWJnb2F0Lm9yZyIsImlhdCI6MTc0MDgzNDc5MywiZXhwIjoxNzQwODM0ODUzLCJzdWIiOiJ0b21Ad2ViZ29hdC5vcmciLCJ1c2VybmFtZSI6IldlYmdvYXQiLCJFbWFpbCI6InRvbUB3ZWJnb2F0Lm9yZyIsIlJvbGUiOlsiTWFuYWdlciIsIlByb2plY3QgQWRtaW5pc3RyYXRvciJdfQ.XIEPGe2EN4zl2afnhlbMTxlojrhAx9O78ka4_15ZxD0
在token中还设置了token的生效时间，只有1分钟，所以在爆出available之后，可能时间就不够了，这时候手动修改一下这里的数字（该处使用的是unix时间戳，可以百度看现在的时间，然后修改）让现在的时间处于两者之间，再提交就能通过了
刷新令牌
通常有两种类型的令牌：访问令牌和刷新令牌。访问令牌用于对服务器进行 API 调用。访问令牌的生命周期有限，这就是刷新令牌的用武之地。一旦访问令牌不再有效，就可以向服务器发出请求，通过提供刷新令牌来获取新的访问令牌。刷新令牌可能会过期，但其生命周期要长得多。这解决了用户必须使用其凭证再次进行身份验证的问题。
第10题
将alg改成none，再修改时间戳得到eyJhbGciOiJOb25lIn0.eyJpYXQiOjE1MjYxMzE0MTEsImV4cCI6MTc0MDg0MDY3MiwiYWRtaW4iOiJmYWxzZSIsInVzZXIiOiJUb20ifQ.
最后一题臭杰瑞要删除汤姆的账户
查看源码发现在kid处存在sql注入，kid的作用是查找对称密钥，通过构造';select 'MQ==' from jwt_keys--语句使得返回值为1，然后修改时间戳得到令牌
payload：eyJ0eXAiOiJKV1QiLCJraWQiOiInO3NlbGVjdCAnTVE9PScgZnJvbSBqd3Rfa2V5cy0tIiwiYWxnIjoiSFMyNTYifQ.eyJpc3MiOiJXZWJHb2F0IFRva2VuIEJ1aWxkZXIiLCJpYXQiOjE1MjQyMTA5MDQsImV4cCI6MTc0MDg5OTIxNywiYXVkIjoid2ViZ29hdC5vcmciLCJzdWIiOiJqZXJyeUB3ZWJnb2F0LmNvbSIsInVzZXJuYW1lIjoiVG9tIiwiRW1haWwiOiJqZXJyeUB3ZWJnb2F0LmNvbSIsIlJvbGUiOlsiQ2F0Il19.rsweu6yB247GOCBAWZrCkhfHxlhlMhAn0aCMzCeSrJQ
CSRF
host表示请求的目的地，包括域名和端口号
origin表示请求是从哪发起的，包括协议、域名、端口号
referer表示当前页面的来源完整地址，包括协议、域名、查询参数
将referfer头去掉，得到flag
得到flag=61409
修改Referer为http://www.baidu.com
大多数框架现在都默认支持防止 CSRF。例如，在 Angular 中，拦截器默认从 cookie 中读取令牌 XSRF-TOKEN 并将其设置为 HTTP 标头 X-XSRF-TOKEN。由于只有在您的域上运行的代码才能读取 Cookie，因此后端可以确定 HTTP 请求来自您的客户端应用程序，而不是攻击者。
为此，后端服务器在 Cookie 中设置令牌。由于 cookie 的值应由 Angular （JavaScript） 读取，因此此 cookie 不应使用 http-only 标志进行标记。在对服务器的每个请求中，Angular 都会将令牌作为 HTTP 标头放入 X-XSRF-TOKEN 中。服务器可以验证这两个令牌是否匹配，这将确保请求所在的服务器在同一域上运行。
重要提示：定义单独的 COOKIE，不要重复使用会话 COOKIE
请记住，会话 cookie 应始终使用 http-only 标志定义。
Cookie：
- 是由服务器发送到客户端（浏览器）的一小段数据，存储在客户端。
- 每次请求时，浏览器会自动将 Cookie 附加到请求头中，发送给服务器。
- 通常用于会话管理、用户偏好设置等。
- 存储在客户端的浏览器中。可以通过 document.cookie（JavaScript）访问和操作。
- 支持 HttpOnly 和 Secure 标志：
-
- HttpOnly：防止 JavaScript 访问 Cookie，减少 XSS 攻击风险。
- Secure：仅通过 HTTPS 传输 Cookie，防止中间人攻击。
- 容易受到 CSRF（跨站请求伪造）攻击，需要额外防护（如 CSRF Token）。
- 适用于传统的 Web 应用（如服务器渲染的页面）。
Token：
- 是一个字符串，通常由服务器生成并发送给客户端。
- 客户端需要手动将 Token 附加到请求头或请求体中，发送给服务器。
- 通常用于无状态的身份验证（如 JWT）。
- 通常存储在客户端的 localStorage 或 sessionStorage 中。需要开发者手动管理。
- 容易受到 XSS 攻击。不受 CSRF 攻击影响，因为需要手动附加到请求中。通常使用加密算法（如 JWT 的签名）保证数据完整性。
- 适用于现代 Web 应用（如单页应用 SPA）和移动端应用。
许多 Web 应用程序没有实现对 CSRF 的保护，它们在某种程度上受到保护，因为它们只使用 application/json 作为内容类型（content-type）。从浏览器使用此内容类型发出请求的唯一方法是使用 XHR 请求。在浏览器可以发出此类请求之前，将向服务器发出预检请求（请记住，CSRF 请求将是跨域的）。如果预检响应不允许跨域请求，则浏览器将不会进行调用。简短地回答：这不是针对 CSRF 的有效保护。
window.onload = function() { document.getElementById("submit").click(); }
-
