每日一题 – Sunset Jesus

2024/7/3

2024/7/2

2024/7/1

2024/6/30

2024/6/29

2024/6/28

2024/6/27

2024/6/26

2024/6/25

2024/6/24

2024/6/23

2024/6/22

2024/6/21

2024/6/20

2024/6/19

2024/6/18

2024/6/17

每日一题不出意外的断更了, 在断更的日子里，我就给大家整点活吧。

接下来每天更新一页某人的笔记本, 持续更新, 我会在被律师函之后删除所有的照片。即使没有收到律师函, 我也会在一定时间后删除所有内容。

2024/5/30

今天有一个弱智知识点, 做了三道题

Linux screen 命令

题目是三道青少年ctf的弱智题目

1. PHP的后门

题目提示我们看 PHP 版本, 是一个从来没见过的版本: PHP/8.1.0-dev , 上网一查就有一个逆天漏洞, 就是传 User-Agentt 头进去可以执行任意代码, 有一说一确实有后门那味了….

2. EasyMD5

和之前的 XYCTF 的 MD5 题解法一模一样, fastcoll 我的超人
然后上传上去只后 flag 会显示一秒消失, 拼个手速即可

3. Easy_SQLi

SQL 布尔盲注

好久没做注入题, 一开始我还小脑萎缩, 把 or 写成了 and ,但是运气特别好, 随手写的 username 恰好和题目数据库里的一模一样, 我还是在注入成功之后才发现我用 and 的…

我用的是 Burp 的 Intruder 模块注的, 想当年我刚刚接触网安的时候随便发个请求都要 import requests , 现在已经基本没用过 py 了, 令人感慨

这里的列名, 表名之类的都是我一位一位读出来的, 开始长度短还好, 后面 flag 将近 40 位真的读的有点怀疑人生, 本来正则一下就可以解决的问题, 但是我不会调教 Burp 的这个正则所以只能这么读…鉴定为用 Burp 用的, 真的有点目光呆滞了。

2024/5/28

感觉自己 Linux 学的好烂……接下来可能会更一段时间的 Linux , 对各位大佬来说可能都是基础中的基础, 对我来说则是初见。

Linux 中 sudo 和 su 的一些应用, 起因是不知道在哪里看到有人说一直用的 sudo -i , 然后我发现自己连sudo -i 都不知道。

sudo 使用当前用户的密码, 用于运行单个命令 ; su 使用转换用户的密码, 会开一个新的 shell 。

单纯的 su 在不加参数的情况下, 不会改变环境变量, 可以通过加 - 来改变。

sudo -i 不同于一般的 sudo 命令只能执行一次, sudo -i 可以让你一直用管理员权限去执行命令, 环境变量会改变, $ 会变为 # 。

sudo su 我没看懂有什么用。

然后我发现自己 root 密码没改……

改密码用的是 sudo passwd root 。

参考网站 :

https://cloud.tencent.com/developer/article/1701710

https://worktile.com/kb/ask/384929.html

2024/5/27

今天在看 SSRF 绕过的时候看到这个 :

试了一下真的可以, 于是很好奇这个所谓的 IDN 是怎么工作的

https://zh.wikipedia.org/wiki/%E5%9B%BD%E9%99%85%E5%8C%96%E5%9F%9F%E5%90%8D

https://zh.wikipedia.org/wiki/%E5%9B%BD%E9%99%85%E5%8C%96%E5%9F%9F%E5%90%8D%E7%BC%96%E7%A0%81

给一个常见的 example , 新华网.中国在输入浏览器的时候会被解析为 xn--xkrr14bows.xn--fiqs8s , 解析靠的是一个叫 Punycode 的方法 ,这个绕过技巧可以用来绕一些 waf , 也可以用来缩短 Payload 长度, 比如使用 ⑭.₨ ,就会比直接输入 URL 少了两位, 在一些情况下能起到作用。

参考的网站除了上面列的, 还有 https://websec.readthedocs.io/zh/latest/vuln/ssrf.html

2024/4/30

HTTP 请求走私

现在网络架构多数采用反代 + 多台后端服务器的形式实现, 用户将请求发送到反代服务器, 然后该服务器将请求转发到一台或多台后端服务器。当前端服务器将 HTTP 请求转发到后端服务器时, 它通常会通过同一后端网络连接发送多个请求, HTTP 请求被一个接一个地发送, 接收服务器必须确定一个请求在哪里结束以及下一个请求从哪里开始 :

那假如我们发送不明确的请求, 而前端和后端系统以不同的方式解释该请求, 就可能会导致导致其前端请求的一部分被后端服务器解释为下一个请求的开始, 也就是我们的请求的一部分被插入到了另一个请求的开头, 实现攻击。

那具体什么是不明确的请求呢?是因为在HTTP/1中,提供了两种不同的方式来指定请求的结束位置 : Content-Length 标头和 Transfer-Encoding 标头。

Content-Length 头很简单：它指定消息正文的长度（以字节为单位）。例如：

POST /search HTTP/1.1
Host: normal-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 11

q=smuggling

Transfer-Encoding 头可用于指定消息正文使用分块编码。这意味着消息正文包含一个或多个数据块。每个块由块大小 ( 以字节为单位 ) ( 以十六进制表示 ) 组成, 后跟换行符, 然后是块内容。消息以大小为零的块终止。例如 ( b是16进制的11 ) ：

POST /search HTTP/1.1
Host: normal-website.com
Content-Type: application/x-www-form-urlencoded
Transfer-Encoding: chunked

b
q=smuggling
0

那为什么我们平时很少看到这种格式的请求呢？主要是因为浏览器段很少会用这种分块编码, 通常是服务器的响应中看到, 而一般来说浏览器为了可读性会将这种分块请求自动转化为正常格式的请求。

因为存在两种表示长度的方式, 就有可能产生冲突, 一旦我们的反代服务器和实际的后端采用的判断长度的方式不一样就有可能产生上述攻击。

为了利用这一点，我们可以充分利用HTTP1给我们提供的 Transfer-Encoding ( TE ）和 Content-Lenth ( CC ) 。假如反代服务器使用 CL 判断长度而后端服务器使用 TE ，或者反代服务器使用 TE 而后段使用 CL , 都能造成歧义。或者利用相同的请求头进行一些修改从而造成歧义, 使前后端服务器对此解释不同, 也能达到攻击的效果。

下面, 我们将举例三种方式对应的 payload 。

1. CL-TE 漏洞
这里, 前端服务器使用 Content-Length 头, 后端服务器使用 Transfer-Encoding 标头。我们可以执行这样的HTTP 请求走私攻击, 如下所示 :

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 13
Transfer-Encoding: chunked

0

SMUGGLED

前端服务器处理 Content-Length ，确定请求体长度为 13 字节 ( 两个换行符算四个字节 ) , 直到 SMUGGLED 结束。该请求被转发到后端服务器。后端服务器处理标头, 因此将消息正文视为使用分块编码。它处理第一个块, 该块被声明为零长度, 因此被视为终止请求。而后端服务器会将剩下这些没有被处理的字节视为下一个请求的开始。

2. TE-CL 漏洞
这里，前端服务器使用 Transfer-Encoding ，后端服务器使用 Content-Length 。我们就可以实现这样的攻击 :

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 3
Transfer-Encoding: chunked

8
SMUGGLED
0

前端服务器处理标头，因此将消息正文视为使用分块编码。它处理第一个块，该块的长度为 8 个字节，直到后面的行的开头。它处理第二个块，该块被声明为零长度，因此被视为终止请求。该请求被转发到后端服务器。
后端服务器处理 Content-Length 并确定请求正文的长度为3 个字节, 直到后面的行的开头 8。以下字节 ( 以 SMUGGLED 开头的这些 ) 就没有被处理, 后端服务器会将这些字节视为序列中下一个请求的开始。

3. TE.TE 漏洞 : 混淆 TE 头

由于 Content-Length 一般不会导致歧义, 混淆一般存在于前后端服务器都使用 Tranfer-Encoding 的情况。这里, 前端和后端服务器都使用 Transfer-Encoding 标头来判断请求长度, 但是可以通过某种方式混淆标头来诱导其中一台服务器不处理它。
混淆标头的方法可能有无数种。例如:

Transfer-Encoding: xchunked

Transfer-Encoding : chunked

Transfer-Encoding: chunked
Transfer-Encoding: x

Transfer-Encoding:[tab]chunked

[space]Transfer-Encoding: chunked

X: X[\n]Transfer-Encoding: chunked

Transfer-Encoding
: chunked

这些技术中的每一种都与 HTTP 规范存在微妙的偏差。实现协议规范的现实代码很少都能够绝对准确的遵守这些规范, 并且不同的实现通常会容忍与规范的一些变化。要发现 TE.TE 漏洞, 需要找到 Transfer-Encoding 标头的某些变体, 以便只有前端或后端服务器之一处理它, 而另一台服务器忽略它。
根据是否可以诱导前端服务器或后端服务器不处理混淆 Transfer-Encoding 标头, 攻击的其余部分将采用与已经描述的 CL.TE 或 TE.CL 漏洞相同的形式。

如何防止 HTTP 请求走私

省流 : 换 HTTP/2

本文参考了 https://portswigger.net/web-security/request-smuggling

日更知识点;)