HTTP协议

第二章HTTP协议1WEB应用安全课程大纲一切从URL开始HTTP协议HTML语言层叠样式表浏览器端脚本非HTML类型文档浏览器插件产生的内容浏览器安全特性浏览器安全机制的未来趋势HTTP协议HTTP基本语法HTTP请求类型服务器响应代码持续会话分段数据传输缓存机制HTTPCookie语义HTTP认证协议级别的加密和客户端证书2.1HTTP基本语法初始版本的HTTP/0.9协议完全没有为客户端和服务器提供任何额外的元数据交换空间。它的客户端请求仅有一行，以GET开头，后面跟着URL路径和查询字符串，然后以一个CRLF换行符结束（对应的ASCII码为0x0D0x0A；按照规范如果结尾处只有一个LF字符，服务器也会接受）。一个HTTP/0.9请求样例如下：GET/fuzzy_bunnies.txt服务器对这条请求的回应，是立刻返回它需要的HTML数据（按照规范，服务器应该按每行80个字符换行的方式来返回响应的内容，但基本上没人遵守该条建议）。2.1HTTP基本语法HTTP/1.0和HTTP/1.1的格式就略有变化了：请求的第一行包含具体的版本信息，后面则跟着零到多条以“名称:值”（name:value）格式组成的数据行（也叫头域，Headers），每行为一个头域。常见的请求头包括：User-Agent（浏览器版本信息）、Host（URL主机名称）、Accept（支持的MIME文件类型）、Accept-Language（支持的语言编码）和Referer（这个字其实拼错了，它的含义是，如果有的话，显示发起当前请求的原始页面）。2.1HTTP基本语法服务器对这个请求的响应是，第一行包含支持的协议版本和一个数字格式的状态码（用以显示出错状况和其他特殊情况），还有可选的易于理解的状态信息描述。紧随其后的是若干一看自明的响应头，响应头部分以一个空行结束。响应数据的最后再跟着请求资源的具体内容。RFC2616还规定，除非客户端明确地发过来一个Accept-Encoding头，在里面设定了能接受的传输压缩方式，否则服务器端可以在以下三种压缩方式里（gzip、compress和deflate）任选其一，用于传输响应数据。2.1.1支持HTTP/0.9的恶果因为SMTP服务器不理解这个请求是什么意思，它很可能这么回应：如果服务器example.com的25端口有上运行着一个不做任何检查的SMTP服务，浏览器向这个端口发送了HTTP/1.1请求会有什么效果：只要是遵守RFC协议的浏览器，都会被迫接受返回的信息，认为这些就是有效的HTTP/0.9响应内容，并把返回的文档按HTML格式解析。所以浏览器会把上面那些由攻击者控制，出现在返回错误信息里的代码，解析为example.com网站返回的合法网页内容。与浏览器安全模型的深层交互会在后面再详加讨论，总之，后果可以很严重。2.1.2换行处理带来的混乱对IE浏览器来说，这个响应看起来类似：开发人员在处理HTTP头域里任何攻击者控制内容时，不仅要过滤LF字符，其实还要过滤CR字符。要说清楚这个问题，以下面这个服务器响应为例，其中加粗部分就是出现在响应头里未经足够过滤的用户提供内容：这类在HTTP头域里夹带换行符的漏洞，不管是因为数据解析的不一致性还是由于没有正确过滤各种类型换行符而产生，都实在是太常见了，所以这类攻击还有专门的名字：头域注入（HeaderInjection）或者响应拆分（ResponseSplitting)。2.1.3经过代理的HTTP请求使用代理的原因可能是为了提高性能（先把某些服务器的响应缓存到就近的系统）、或强制应用某些网络访问策略（如禁止访问某些色情站点）或需要以代理方式实现某些独立网络环境的监控和需要授权的接入。要使用代理方式来获取一个HTTP资源，浏览器通常需要发送如下请求：上述例子和普通的HTTP请求最大的语法差异，就是请求内容里的第一行，这时候是一个完整的URL（），通过这项信息代理服务器才知道用户要连接的目标服务器在哪里。这项信息实际上有点多余，因为在Host请求头里也标识了主机名称；这种重复是因为这两套机制其实是相互独立发展起来的。为了避免客户端和服务器串通一气，如果Host请求头的信息与请求行里的URL不匹配时，代理服务器应以请求行里的URL为准，或者用特定的“URL-Host”数据对和缓存内容关联起来，而不能只根据其中一项信息做出判断。GET:Bunny-Browser/1.7Host:对重复或有冲突的头域的解析对一个符合要求的解析器要怎么解析请求或响应数据里含糊和有冲突的数据，RFC并没有做更详细的描述。因为规范里没有给出建议，大约一半的浏览器会以HTTP头域里第一次出现的值为准，而另一半则以最后一次为准，这使得每种和头域相关的注入漏洞，不管怎么限制，总有另一部分的用户会遭殃。而在服务器端，也是一样地随机：Apache认可第一个Host头的值，而IIS则完全不接受多个Host头的情况。与之类似的情况，相关的RFC文档也没有明确规定要禁止可能有冲突的HTTP/1.0和HTTP/1.1请求头，也没有要求HTTP/1.0版本的服务器或客户端程序必须忽略所有HTTP/1.1的语法。因为这种设计，很难预料如果同时具有HTTP/1.0和HTTP/1.1两个版本的不同名称但一样功能的头域时，会产生什么后果，例如Expires和Cache-Control。最后，要如何解析某些较为罕见的头域冲突，在规范里的描述反而非常清楚，但为什么要允许这些奇怪的冲突也令人费解。2.1.5以分号作为分隔符的头域值有一些HTTP头域，例如Cache-Control或Content-Disposition，使用分号来分隔在同一行里的几对独立的“名称=值”数据组。允许使用这种嵌套式语法的原因，人们可能认为这种方式更有效率或者更直观一些，否则就要用到好几个独立的HTTP头域了。RFC2616规定在某些使用场景里，这种数据组对里等号右边的参数值可以使用Quoted-String格式。Quoted-String指的是用双引号作为分隔符，由任意可打印字符组成，两边用双引号括起来的字符串。当然了，缺点是引号本身不能包括在字符串里，但好处是支持分号和空格，使得某些不加引号可能会有问题的字符串仍能保持原样传输。IE浏览器对Quoted-String的语法支持得不是很好，直接导致这种编码策略完全派不上用场。在微软的实现里，文件名会在有分号的地方被截断，导致文件最后被存为evil_file.exe。应用程序在处理这样的文件名时，必须要专门检查整个字符串中的双引号和换行符，否则仅仅去检测后缀名是否“安全”或人为添加一个“安全”的后缀名，都避免不了风险隐患。2.1.6Referer头域的表现本章早前提到，HTTP请求里可以包含Referer（来源）头域。这个头域里包含的是哪个URL地址触发了对当前页面的访问。Referer头域对某些纠错处理颇有帮助，还可以通过这个头域，强化网页之间的引用关系，有助于Web的发展壮大。HTTP协议HTTP基本语法HTTP请求类型服务器响应代码持续会话分段数据传输缓存机制HTTPCookie语义HTTP认证协议级别的加密和客户端证书2.2HTTP请求类型大多数实验性的构想都在HTTP/1.1里被抛弃了，HTTP/1.1中只有8种方法：GETPOSTHEADOPTIONSPUTDELETETRACECONNECT其他HTTP方法2.2HTTP请求类型2.2.1GETGET方法对信息的获取至关重要。实际上，所有常规浏览会话在“客户端–服务器”交互时都在使用GET方法。一般来说GET请求不会携带从浏览器端提交的Payload数据，尽管这也并非绝对禁止的。根据RFC的规定，GET请求“除了索取信息之外，不应该承担其他的重要功能”（也就是说，它们应该不能永久性地改变应用的状态）。这个需求在现在的Web应用里已经越来越没有意义了，因为现在甚至服务器端也没法决定应用的状态了；因此，这个建议也越来越为开发人员所忽略。2.2.2POSTPOST方法原来的目标是把客户端提交的信息（主要是HTML表单数据）传递给服务器端。因为POST动作更有可能带来持久性的副作用，很多浏览器在重新加载包含POST方式的数据时，浏览器都会谨慎地向用户再确认一次，但大多数情况下，GET和POST的交互机制是比较相近的。POST请求通常都会带有表单数据，这段数据的长度要明确地设置在Content-Length请求头里。在HTML格式的情况下，这些提交的数据通常是经过URL编码或MIME编码的表单数据，但要再说一遍，在HTTP协议里对这些数据的语法格式其实并没有具体的限制。2.2HTTP请求类型2.2.3HEADHEAD是一种很少用到的方法，在本质上HEAD近似于GET方法，但它只返回响应头域的部分，不包含具体的数据，即响应内容的部分。一般来说无法通过浏览器直接发出HEAD请求，但有时候搜索引擎的爬虫或其他自动化测试工具会用到这个方法，例如探测文件是否存在或检查它的最后修改时间。2.2.4OPTIONSOPTIONS是一种元数据请求（metarequest），服务器会根据客户端请求的URL地址（如果URL设置为“*”，则泛指整个服务器范围内），在一个响应头里返回其所能支持的全部方法列表。除了用于服务器信息检测，OPTIONS方法在实际中几乎从来不会用到；而即使用于这个目的，由于返回的值过于有限，所以最后的信息也不会精确。2.2HTTP请求类型2.2.5PUTPUT请求用来向服务器特定目标URL上传文件。但因为浏览器并不支持PUT方法，常规的文件上传功能一般是用POST方法提交给服务器端脚本来实现的，而不会用这个理论上更优雅的做法。当然也有某些非浏览器的HTTP客户端和服务器出于某种考虑允许使用PUT。有趣的是，由于某些Web服务器上的配置错误，可能导致这些服务器支持PUT请求，从而产生明显的安全漏洞。2.2.6DELETEDELETE这个方法看字面就知道它的意思了，其他方面和PUT类似2.2.7TRACETRACE是一种“ping”形式的请求，服务器会返回HTTP请求经过所有代理后的每一跳信息，并且把原始HTTP请求内容再回显出来。TRACE请求不能由浏览器发出，也很少用于合法用途。TRACE主要用在安全测试里，用于揭示远程网络的内部架构里一些有趣的细节。因为这个缘故，服务器管理员一般都会把这个功能禁掉。2.2.8CONNECTCONNECT方法是通过HTTP代理服务器建立非HTTP类型连接时使用的。Connect指令是不能直接发送给目标服务器的。如果特定服务器上不小心设置了支持CONNECT方法，就可能导致安全风险，使攻击者获得了一条访问受保护网络的TCP通道。HTTP协议HTTP基本语法HTTP请求类型服务器响应代码持续会话分段数据传输缓存机制HTTPCookie语义HTTP认证协议级别的加密和客户端证书2.3服务器响应代码服务器在返回响应时会返回响应代码，有些代码是值得记住的，因为确实常用或者具有特殊的意义，描述如下：200~299：成功200，OK：对成功的GET或者POST请求的正常响应300~399：重定向和其他状态信息400~499：客户端错误400，BadResquest:服务器因为某些特定原因，不能或者不愿意处理该请求403，Forbidden:禁止访问404，NotFound:文件找不到500~599：服务器端错误500，InternalServerError:内部服务器错误HTTP协议HTTP基本语法HTTP请求类型服务器响应代码持续会话分段数据传输缓存机制HTTPC