urllib库进行网络请求后返回的HTTPResponse对象的用法总结

Nov 8, 2023

urllib库进行网络请求后返回的HTTPResponse对象的用法总结

本文转自「已注销」并作补充

不管是使用urllib.request.urlopen()方法，还是使用opener.open()方法，都返回同样类型的HTTPResponse对象，用法总结如下:

# !/usr/bin/env python
# -*- coding:utf-8 -*-
 
from urllib import request
from urllib import response
 
URL="http://www.baidu.com/"
 
# 构造请求头信息
# 反反爬虫:设置User-Agent
request_headers={
    "User-Agent":"Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.108 Safari/537.36"
}
 
# 构造请求对象,并添加请求头
req=request.Request(URL,headers=request_headers)
# 发起请求
resp=request.urlopen(req)
 
 
print(type(resp))   # <class 'http.client.HTTPResponse'>
# 获取HTTP协议版本号(10 for HTTP/1.0, 11 for HTTP/1.1)
print(resp.version)
 
# 获取响应码
print(resp.status)
print(resp.getcode())
 
# 获取响应描述字符串
print(resp.reason)
 
# 获取实际请求的页面url(防止重定向用)
print(resp.geturl())
 
# 获取特定响应头信息
print(resp.getheader(name="Content-Type"))
# 获取响应头信息,返回二元元组列表
print(resp.getheaders())
# 获取响应头信息,返回字符串
print(resp.info())
 
# 读取响应体
print(resp.readline().decode('utf-8'))
print(resp.read().decode('utf-8'))

HTTP Python Reprint

HTTP请求走私漏洞

Jun 27, 2023

HTTP请求走私漏洞

本文转自Atkxor 并作补充

简介

HTTP请求走私是一种干扰网站处理从一个或多个用户接收的HTTP请求序列的方式的技术。请求走私漏洞本质上通常很关键，它使攻击者可以绕过安全控制，未经授权访问敏感数据并直接危害其他应用程序用户。

利用Content-Length字段来判定请求体的内容长度

利用Transfer-Encoding字段来判定请求体的结束位置

基础知识

Content-Length

Content-Length即为实体长度。浏览器可以通过 Content-Length 的长度信息，判断出响应实体已结束。通常如果 Content-Length 比实际长度短，会造成内容被截断；如果比实体内容长，会造成 pending。

Transfer-Encoding

历史上 Transfer-Encoding 可以有多种取值，但最新的 HTTP 规范里，只定义了一种传输编码：分块编码（chunked）。
分块编码相当简单，在头部加入 Transfer-Encoding: chunked 之后，就代表这个报文采用了分块编码。这时，报文中的实体需要改为用一系列分块来传输。每个分块包含十六进制的长度值和数据，长度值独占一行，长度不包括它结尾的 CRLF（\r\n），也不包括分块数据结尾的 CRLF。最后一个分块长度值必须为 0，对应的分块数据没有内容，表示实体结束。

CL与TE解析优先级顺序

CL表示Content-Length，TE表示Transfer-Encoding。优先级顺序详见 RFC7230 section 3.3.3

If a message is received with both a Transfer-Encoding and a
Content-Length header field, the Transfer-Encoding overrides the
Content-Length. Such a message might indicate an attempt to perform
request smuggling (Section 9.5) or response splitting (Section 9.4)
and ought to be handled as an error. A sender MUST remove the received Content-Length field prior to forwarding such a message downstream.

TE 优先于 CL ，但可以通过一些方式绕过

请求走私分类

请求走私攻击包括将Content-Length标头和Transfer-Encoding 标头都放入单个HTTP请求中并进行处理，以便前端服务器和后端服务器以不同的方式处理请求。完成此操作的确切方式取决于两个服务器的行为：

CL不为0:前端代理服务器允许请求携带请求体，而后端服务器不允许请求携带请求体。

CL-CL：前端服务器使用Transfer-Encoding头，而后端服务器使用Content-Length头。

CL-TE：前端服务器使用Content-Length标头，而后端服务器使用Transfer- Encoding标头。

TE-TE：前端服务器和后端服务器都支持Transfer-Encoding标头，但是可以通过某种方式混淆标头来诱导其中一台服务器不对其进行处理。

TE-CL：前端服务器使用Transfer-Encoding头，而后端服务器使用Content-Length头。

CL不为0

所有不携带请求体的HTTP请求都有可能受此影响,这里以GET请求为例。
当前端服务器允许GET请求携带请求体，而后端服务器不允许GET请求携带请求体，它会直接忽略掉GET请求中的Content-Length头，不进行处理。这就有可能导致请求走私。
比如构造请求：

GET / HTTP/1.1\r\n
Host: demo.com\r\n
Content-Length: 44\r\n
\r\n
GET /secret HTTP/1.1\r\n
Host: demo.com\r\n
\r\n

注：\r\n表示 CRLF即换行

前端服务器处理了Content-Length，而后端服务器没有处理 Content-Length ，基于pipeline机制认为这是两个独立的请求：
第一个请求：

1 2	GET / HTTP/1.1\r\n Host: demo.com\r\n

第二个请求：

1 2	GET /secret HTTP/1.1\r\n Host: demo.com\r\n

CL-CL漏洞

RFC7230规范：在RFC7230的第3.3.3节中的第四条中，规定当服务器收到的请求中包含两个Content-Length，而且两者的值不同时，需要返回400错误。
构造请求：

POST / HTTP/1.1\r\n
Host: demo.com\r\n
Content-Length: 5\r\n
Content-Length: 6\r\n
\r\n
12345\r\n
a

得到响应，返回400 Bad Request

触发过程：但是总有服务器不会严格的实现该规范，假设中间的代理服务器和后端的源站服务器在收到类似的请求时，都不会返回400错误，但是中间代理服务器按照第一个Content-Length的值对请求进行处理，而后端源站服务器按照第二个Content-Length的值进行处理。

CL-TE漏洞

CL-TE，就是当收到存在两个请求头的请求包时，前端代理服务器只处理Content-Length请求头，而后端服务器会遵守RFC2616的规定，忽略掉Content-Length，处理Transfer-Encoding请求头。
CL.TE实验环境

TE-TE漏洞

在这里，前端服务器和后端服务器都支持Transfer-Encoding标头，但是可以通过对标头进行某种方式的混淆来诱导其中一台服务器不对其进行处理。
详见 RFC7230 section 3.3.3.3

If a Transfer-Encoding header field is present in a response and
the chunked transfer coding is not the final encoding, the
message body length is determined by reading the connection until
it is closed by the server.  If a Transfer-Encoding header field
is present in a request and the chunked transfer coding is not
the final encoding, the message body length cannot be determined
reliably; the server MUST respond with the 400 (Bad Request)
status code and then close the connection.

这里列出七种混淆方式:

Transfer-Encoding: xchunked

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.CL实验环境

TE-CL漏洞

所谓TE-CL，就是当收到存在两个请求头的请求包时，前端代理服务器处理Transfer-Encoding这一请求头，而后端服务器处理Content-Length请求头。
TE.CL验环境

绕过前端服务器安全控制

利用CL-TE漏洞绕过

CL.TE实验环境

利用TE-CL漏洞绕过

TE.CL实验环境

漏洞防御

在前端服务器通过同一网络连接将多个请求转发到后端服务器的情况下，会出现HTTP请求走私漏洞，并且后端连接所使用的协议会带来两个服务器不同意边界的风险。要求。防止HTTP请求走私漏洞的一些通用方法如下：

禁用后端连接的重用，以便每个后端请求通过单独的网络连接发送。

使用HTTP / 2进行后端连接，因为此协议可防止对请求之间的边界产生歧义。

前端服务器和后端服务器使用完全相同的Web服务器软件，以便它们就请求之间的界限达成一致。
在某些情况下，可以通过使前端服务器规范歧义请求或使后端服务器拒绝歧义请求并关闭网络连接来避免漏洞。但是，这些方法比上面确定的通用缓解措施更容易出错。

参考文章

(https://paper.seebug.org/1048)
(https://portswigger.net/web-security/request-smuggling)
(https://portswigger.net/web-security/request-smuggling/exploiting)

Exploit HTTP Reprint

Slowhttptest Usage

Aug 25, 2022

Slowhttptest 对 Slow HTTP Dos 的误判

当场滑跪

前段时间在巡检公司项目的时候发现了HTTP慢速拒绝服务攻击（Slow HTTP Dos）
于是就下发让项目运维去修复了，但是反馈说明明配置了正确的参数，于是我当（zhi）场（jie）滑（dao）跪（qian） ORZ

发生了什么

所以是发生了什么？漏扫就那么垃圾和我过不去这么多误报？我还好好用 slowhttptest 去验证了，确实存在service available: NO的显示，图就不发了，拿阿B的给你们看看：

后来看得多了我发现（其实早就发现了），slowhttptest 的slowbody模式下很容易出现service available: NO，read和header就很容易通过测试
但是归根到底是否触发拒绝服务，肯定看：

网站载入延时

网站是否还可访问

在看了星球守护者的漏洞复现后我发现，用 slowhttptest 验证 Slow HTTP Dos 真实存在，需要注意：

1. slow HTTP test status on Xth second:		X 数字较小，即较早就开始拒绝服务
2. service available:   NO
3. Test ended on X+1th second
4. Exit status: Connection refused		这两点比较重要，真的拒绝服务了直接下一秒就停止测试了

不得不说

其实 Dos 类的漏洞你很不好说，因为访问量过大必然服务器承受不住，这个只能做缓解（流量分析、请求时限、扩容等等）
所以漏扫出来是否存在这个漏洞或者 slowhttptest 的service available: NO，有可能是看片面了（某些请求在开始或者后来被识别后被拒绝、中断，或者网页响应时间是否有某个范围内的增量变化等，尤其是这个增量变化，我曾经发现因为一个资产页面正常请求的数量会变化，时延直接从几百ms级变成几s级的）

好吧，okk

DOS Exploit HTTP Reprint

Slow HTTP Dos

Aug 8, 2022

HTTP慢速拒绝服务攻击（Slow HTTP Dos）

本文摘自春告鳥及libaisec

HTTP慢速拒绝服务攻击简介

HTTP慢速攻击是利用HTTP合法机制，以极低的速度往服务器发送HTTP请求，尽量长时间保持连接，不释放，若是达到了Web Server对于并发连接数的上限，同时恶意占用的连接没有被释放，那么服务器端将无法接受新的请求，导致拒绝服务。

HTTP慢速攻击原理（摘抄自倾旋师傅的博客:

既然是一个HTTP协议的缓慢攻击，这就要从HTTP协议说起了。

首先HTTP协议的报文都是一行一行的，类似于：

GET / HTTP/1.1\r\n
Host : payloads.online\r\n
Connection: keep-alive\r\n
Keep-Alive: 900\r\n
Content-Length: 100000000\r\n
Content_Type: application/x-www-form-urlencoded\r\n
Accept: *.*\r\n
\r\n

那么报文中的\r\n是什么？

\r\n代表一行报文的结束也被称为空行（CRLF），而\r\n\r\n代表整个报文的结束

从上面贴出的GET请求包可以看出，我们的客户端请求到服务器后，告知服务器这个连接需要保留。

通常我们知道HTTP协议采用“请求-应答”模式，当使用普通模式，即非KeepAlive模式时，每个请求/应答客户和服务器都要新建一个连接，完成之后立即断开连接（HTTP协议为无连接的协议）；当使用Keep-Alive模式（又称持久连接、连接重用）时，Keep-Alive功能使客户端到服务器端的连接持续有效，当出现对服务器的后继请求时，Keep-Alive功能避免了建立或者重新建立连接。

那么当我们客户端发送一个报文，不以CRLF结尾，而是10s发送一行报文，我们的报文需要80s才能发送完毕，这80s内，服务器需要一直等待客户端的CRLF，然后才能解析这个报文。

如果客户端使用更多的程序发送这样的报文，那么服务器端会给客户端留出更多的资源来处理、等待这迟迟不传完的报文。假设服务器端的客户端最大连接数是100个，我们使用测试程序先连接上100次服务器端，并且报文中启用Keep-Alive，那么其他正常用户101、102就无法正常访问网站了。

简单来说，就是我们每次只发一行，每次发送之间的间隔时间很长，这迟迟未发送结束的HTTP包会占用服务端的资源，当达到服务端处理请求的上限时，这时候再用户对网站正常请求，服务端也处理不了了，导致了拒绝服务。

HTTP慢速攻击分类

HTTP慢速攻击分为三类：

Slow headers

Slow body

Slow read

1，Slow headers

第一类是最经典的HTTP Slow慢速攻击，由rsnake发明的，原理在上面已介绍。

2，Slow body

第二类也叫做Slow HTTP POST

原理为在POST提交方式中，允许在HTTP的头中声明content-length，即POST内容的长度。

提交了恶意头之后，将需要传输的body缓慢进行发送，跟Slow headers类似，导致服务器端长时间等待需要传输的POST数据，当请求的数量变多后，达到了消耗服务器资源的效果，导致服务器宕机。

3，Slow Read attack

第三类攻击方式采用调整TCP协议中滑动窗口大小，来对服务器单次发送的数据大小进行控制，使得服务器需要对一个相应包分为很多个包来发送，想要使这种攻击效果明显，请求的资源要尽量大，这里很容易理解，当请求的资源越大，返回包才越大，这样才能分成更多的包让服务器发送，导致拒绝服务的产生。

也就是说，客户端以极低的速度来读取返回包，来消耗服务器的连接和内存资源。

HTTP慢速攻击实战

一般使用slowhttptest工具（安装方式很多，不再赘述）

工具简介

SlowHTTPTest是一个可配置的应用层拒绝服务攻击测试工具，它可以工作在Linux，OSX和Cygwin环境以及Windows命令行接口，可以帮助安全测试人员检验服务器对慢速攻击的处理能力。

这个工具可以模拟低带宽耗费下的DoS攻击，比如慢速攻击，慢速HTTP POST，通过并发连接池进行的慢速读攻击（基于TCP持久时间）等。慢速攻击基于HTTP协议，通过精心的设计和构造，这种特殊的请求包会造成服务器延时，而当服务器负载能力消耗过大即会导致拒绝服务。

使用参数介绍

测试模式:
-H                            slow header,slowloris默认采用此模式          
-B                            slow body
-R                            远程攻击又名Apache killer
-X                            slow read

报告选项：
-g                            生成具有套接字状态更改的统计信息（默认关闭）
-o file_prefix                将统计信息输出保存在file.html和file.csv中（需要-g）
-v level                      日志信息，详细级别0-4：致命，信息，错误，警告，调试

常规选项：
-c connections                连接目标连接数（50）
-i seconds                    后续数据之间的间隔（以秒为单位）（10）
-l seconds                    测试目标时间长度，以秒为单位（240）
-r rate                       每秒连接数（50）
-s                            如果需要，Content-Length标头的值（4096）
-t                            在请求中使用的动词，对于slow header和response，默认为GET；对于slow body，默认为POST
-u URL                        目标的绝对URL（http://localhost/）
-x                            在slowloris and Slow POST tests模式中，指定发送的最大数据长度
-f                            Content-Type标头的值（application/x-www-form-urlencoded）
-m                            接受(Accept)标头的值（text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5）

探测/代理选项：
-d host:port                  为所有连接指定代理
-e host:port                  为探测连接指定代理
-p seconds                    指定等待时间来确认DoS攻击已经成功

range attack特定选项：
-a                            标头中的起始位置
-b                            标头中的结束位置

slow read特定选项：
-k                            在连接中重复相同请求的次数。如果服务器支持永久连接，则用于成倍增加响应大小。
-n                            从recv缓冲区读取操作之间的时间间隔，以秒为单位（1）
-w                            slow read模式中指定tcp窗口范围下限
-y                            slow read模式中指定tcp窗口范围上限
-z                            在每次的read中，从buffer中读取数据量

对于三种类型的慢速攻击，分别给出payload：（摘抄的！）

Slow Header

1	slowhttptest -c 65500 -H -i 10 -r 200 -s 8192 -t SLOWHEADER -u http://vulurl.com

该攻击会像我们刚才讲的慢速传递HTTP报文，占用服务器资源让其等待我们最后的CRLF。

Slow Read

1	slowhttptest -c 65500 -X -r 1000 -w 10 -y 20 -t SLOWREAD -n 5 -z 32 -u http://vulurl.com

该攻击会在Web服务器响应内容传输回来的时候，我们客户端缓慢的读取响应报文，这样服务器端也会一直等待客户端来接收完毕。

Slow Post

1	slowhttptest -c 65500 -B -i 10 -r 200 -s 8192 -t SLOWBODY -u http://vulurl.com

该攻击会构造一个POST数据包，将数据缓慢传输，使服务器端一直等待接收报文。

找一个存在漏洞的网址进行检测：

使用Slow Post的payload：（漏洞网址已高码）

1	slowhttptest -c 65500 -B -i 10 -r 200 -s 8192 -t SLOWBODY -u https://xxxxxx

当显示为NO，则表示存在HTTP慢速攻击漏洞，可导致拒绝服务。

解决办法

针对不同的Server其对慢速http拒绝服务攻击防范方法也不同：

WebSphere

1、限制 HTTP 数据的大小

在WebSphere Application Server 中进行如下设置：

任何单个 HTTP 头的默认最大大小为 32768 字节。可以将它设置为不同的值。

HTTP 头的默认最大数量为 50。可以将它设置为不同的限制值。

另一种常见的 DOS 攻击是发送一个请求，这个请求会导致一个长期运行的 GET 请求。WebSphere Application Server Plug-in 中的 ServerIOTimeoutRetry 属性可限制任何请求的重试数量。这可以降低这种长期运行的请求的影响。

设置限制任何请求正文的最大大小。

2、设置keepalive参数

打开ibm http server安装目录，打开文件夹conf，打开文件httpd.conf,查找KeepAlive值，改ON为OFF,其默认为ON。

这个值说明是否保持客户与HTTP SERVER的连接，如果设置为ON，则请求数到达MaxKeepAliveRequests设定值时请求将排队，导致响应变慢。

详见参考链接

Weblogic

1、在配置管理界面中的协议->一般信息下设置完成消息超时时间小于200

2、在配置管理界面中的协议->HTTP下设置 POST 超时、持续时间、最大 POST 大小为安全值范围。

详见参考链接

Nginx

1、通过调整$request_method，配置服务器接受http包的操作限制；

2、在保证业务不受影响的前提下，调整

client_max_body_size
client_body_buffer_size
client_header_buffer_size
large_client_header_buffersclient_body_timeout
client_header_timeout

的值，必要时可以适当的增加；

3、对于会话或者相同的ip地址，可以使用HttpLimitReqModule and HttpLimitZoneModule参数去限制请求量或者并发连接数；

4、根据CPU和负载的大小，来配置worker_processes 和 worker_connections的值，公式是：max_clients = worker_processes * worker_connections。

Apache

建议使用mod_reqtimeout和mod_qos两个模块相互配合来防护。

1、mod_reqtimeout用于控制每个连接上请求发送的速率。配置例如：

#请求头部分，设置超时时间初始为10秒，并在收到客户端发送的数据后，每接收到500字节数据就将超时时间延长1秒，但最长不超过40秒。可以防护slowloris型的慢速攻击。

RequestReadTimeout header=10-40,minrate=500

#请求正文部分，设置超时时间初始为10秒，并在收到客户端发送的数据后，每接收到500字节数据就将超时时间延长1秒，但最长不超过40秒。可以防护slow message body型的慢速攻击。

RequestReadTimeout body=10-40,minrate=500

需注意，对于HTTPS站点，需要把初始超时时间上调，比如调整到20秒。
示例：

LoadModule reqtimeout_module modules/mod_reqtimeout.so
<IfModule reqtimeout_module>
        RequestReadTimeout header=10-40,minrate=500 body=10-40,minrate=500
</IfModule>

2、mod_qos用于控制并发连接数。配置例如：

当服务器并发连接数超过600时，关闭keepalive
QS_SrvMaxConnClose 600

限制每个源IP最大并发连接数为50
QS_SrvMaxConnPerIP 50
这两个数值可以根据服务器的性能调整。

更多关于qos_module配置参考
示例：

LoadModule qos_module modules/mod_qos.so
<IfModule qos_module>
QS_SrvMaxConnClose 600
QS_SrvMaxConnPerIP 50
</IfModule>

IHS服务器

请您先安装最新补丁包，然后启用mod_reqtimeout模块，在配置文件中加入：
LoadModule reqtimeout_module modules/mod_reqtimeout.so

为mod_reqtimeout模块添加配置：

1 2	<IfModule mod_reqtimeout.c> RequestReadTimeout header=10-40,MinRate=500 body=10-40,MinRate=500

对于HTTPS站点，建议header=20-40,MinRate=500。

参见

F5负载均衡

F5负载均衡设备有相应的防护模块，如无购买可参考附件中的详细配置过程。
关于F5的慢速攻击防护配置，请参考Page1,Page2

IIS服务器

IIS可配置相关网站的Web.config如下：

1、WebLimits设置：

<configuration>
    <system.applicationHost>
        <webLimits connectionTimeout="00:00:30"
        headerWaitTimeout="00:00:10"
        dynamicIdleThreshold="150"
        minBytesPerSecond="512"
    />
    </system.applicationHost>
</configuration>

参考以下链接

2、headerLimits设置：

<configuration>
 <system.webServer>
  <security>
   <requestFiltering>
    <requestLimits>
     <headerLimits>
     <add header="Content-type" sizeLimit="100" />
     </headerLimits>
    </requestLimits>
   </requestFiltering>
  </security>
 </system.webServer>
</configuration>

参考

参考链接：

https://payloads.online/archivers/2018-04-16/2

https://www.f4guo.top/2019/10/09/HTTP%E6%85%A2%E9%80%9F%E6%8B%92%E7%BB%9D%E6%9C%8D%E5%8A%A1%E6%94%BB%E5%87%BB/

https://www.cnblogs.com/xiaoliu66007/p/10174672.html

https://forum.huawei.com/enterprise/zh/thread-293945.html

DOS Exploit HTTP Reprint

HTTP.sys远程代码执行

Aug 3, 2022

【渗透整理】HTTP.sys远程代码执行

本文转自久违 °

漏洞介绍

HTTP.sys是Microsoft Windows处理HTTP请求的内核驱动程序，为了优化IIS服务器性能，从IIS6.0引入，IIS服务进程依赖HTTP.sys。HTTP.sys远程代码执行漏洞实质是HTTP.sys的整数溢出漏洞，当攻击者向受影响的Windows系统发送特殊设计的HTTP 请求，HTTP.sys 未正确分析时就会导致此漏洞，成功利用此漏洞的攻击者可以在系统帐户的上下文中执行任意代码。

影响环境：Windows+IIS的环境下，任何安装了微软IIS 6.0以上的Windows Server 2008 R2/Server 2012/Server 2012 R2以及Windows 7/8/8.1操作系统都受到这个漏洞的影响。

漏洞知识

说到HTTP.sys远程代码执行漏洞，不得不先介绍一下Range首部字段。

在“上古时代”，网络并不是很好，下载大型文件很不容易。下载途中如果网络中断，就得重头开始下。为了解决这个问题，HTTP/1.1引入了范围请求。

在请求报文的Range首部字段中指定资源的byte范围，告诉服务器，请求的是资源哪个范围的内容，让断点续传和并行下载得以实现。

如果服务器支持范围请求，响应包中就会存在Accept-Ranges字段(且值不为“none”，bytes为资源范围的单位)，并在Content-Length字段中告诉客户端资源的大小范围。

如果没有Accept-Ranges字段，则服务器可能不支持范围请求，有的服务器会明确将值设为“none”。

服务器面对范围请求，有三种响应：

请求成功：

响应206Partial Content请求范围越界：（范围超过资源的大小）

响应416Requested Range Not Satisfiable不支持范围请求：

响应200OK

而HTTP.sys远程代码执行漏洞正是利用Range字段注入恶意数据。该漏洞的检测，也是利用服务器面对范围请求时的响应特征来判断。

漏洞检测方法

1、先判断目标环境是否为Windows+IIS

2、然后构建Range字段进行检测即可

检测时，在请求包中添加Range字段，如下：

Range: bytes=0-18446744073709551615

【18446744073709551615的十六进制为0xFFFFFFFFFFFFFFFF(16个F)是64位无符号整数所能表达的最大整数，整数溢出和这个超大整数有关】

然后go给服务器

1
2
3

GET / HTTP/1.1
Host: stuff
Range: bytes=0-18446744073709551615

或者：

1	curl -v www.test.com -H "Host: irrelevant" -H "Range: bytes=0-18446744073709551615"

服务器响应 400，证明不存在HTTP.sys远程代码执行漏洞

HTTP Error 400. The request has an invalid header name.

服务器响应 416，则证明存在该漏洞

HTTP/1.1 416 Requested Range Not Satisfiable
Content-Type: text/html
Last-Modified: Thu, 22 Aug 2013 23:53:12 GMT
Accept-Ranges: bytes
ETag: "2edebc2929fce1:0"

漏洞修复建议：

升级安全补丁

Exploit HTTP RCE Reprint

- HTTP -

urllib库进行网络请求后返回的HTTPResponse对象的用法总结

urllib库进行网络请求后返回的HTTPResponse对象的用法总结

HTTP请求走私漏洞

HTTP请求走私漏洞

简介

基础知识

Content-Length

Transfer-Encoding

CL与TE解析优先级顺序

请求走私分类

CL不为0

CL-CL漏洞

CL-TE漏洞

TE-TE漏洞

TE-CL漏洞

绕过前端服务器安全控制

利用CL-TE漏洞绕过

利用TE-CL漏洞绕过

漏洞防御

参考文章

Slowhttptest Usage

Slowhttptest 对 Slow HTTP Dos 的误判

当场滑跪

发生了什么

不得不说

Slow HTTP Dos

HTTP慢速拒绝服务攻击（Slow HTTP Dos）

HTTP慢速拒绝服务攻击简介

HTTP慢速攻击原理（摘抄自倾旋师傅的博客:

HTTP慢速攻击分类

1，Slow headers

2，Slow body

3，Slow Read attack

HTTP慢速攻击实战

工具简介

使用参数介绍

Slow Header

Slow Read

Slow Post

解决办法

WebSphere

Weblogic

Nginx

Apache

IHS服务器

F5负载均衡

IIS服务器

参考链接：

HTTP.sys远程代码执行

【渗透整理】HTTP.sys远程代码执行

漏洞介绍

漏洞知识

漏洞检测方法

漏洞修复建议：