POSTER TEMPLATE BY: Whitewater HTTP Vulnerabilities Nick Berry, Joe Joyce, & Kevin Vaccaro. Syntax & Routing Attempt to capture and modify HTTP traffic between a client and server on a closed network. It is assumed that HTTP is the only protocol in use and there are no other security measures currently implemented on the web server. Test Method: Capture client HTTP traffic via a proxy server on a LAN and attempt to read, edit, and forward the HTTP messages to the web server. Once the edited message has been received by the server, it will serve a resource that was not originally requested by the client. Conclusions: HTTP traffic was able to be captured and modified on all four web servers on each operating system. There is no mechanism for obfuscating HTTP traffic in any of the servers tested when exclusively using the HTTP protocol. Caching Project Summary Identify web servers more vulnerable to attack due to their implementation of recent changes to the HTTP protocol. The project team focused on five areas of HTTP to find scenarios in which servers are not secure. Range Requests Use the Range header to request byte ranges that overlap and are out of order with the goal of denying service to legitimate clients. Serving the resource in many parts uses much more time, memory, and bandwidth than a normal Range request. Test Method: Send HTTP requests with a ‘Range’ header requesting several overlapping and out of order byte ranges. Conclusions: IIS, Tomcat, and NGINX each served overlapping and out of order byte ranges, requiring much more data to be served. Apache, however, would aggregate the byte ranges, so no overlapping or out of order byte ranges would be served. The size of the served resource was significantly smaller than the resource served by the other three web servers. Authentication Semantics & Content Attempt to obtain confidential authentication credentials sent from a client requesting a resource that is within a protection realm on the HTTP server. Test Method: Capture client traffic via a proxy server and attempt to use the clients credentials to gain access to protected resources on the web server. Conclusions: All four web servers used a base-64 encoding to receive the authentication request. The IIS server performed differently in that it decoded the base-64 into a Windows-1252 charset instead of UTF-8. By intercepting the interaction between the client and the server, it is possible to intercept the encoded credentials, decode them, and use them to access protected resources. Although encoding is not encryption, it provides some method of obfuscation of the authentication credentials. Attempt to obtain product information through HTTP headers that disclose information about the sender’s system. Attackers may be able to use this data to more effectively attack the system. Testing Method: Capture HTTP requests between the server and client and try to obtain operating system and server data from the “Server” header. Conclusions: NGINX, Apache, and IIS responded with the name of the server, the version number, and the operating system on which the server was running. Only Tomcat sent a “Server” header that did not contain the operating system on the host machine. Attempt to obtain user authentication credential data from a server side cache via HTTP. Test Method: Send HTTP requests with the intent of obtaining data in the webserver authentication cache. Conclusions: Using strictly HTTP, none of the web servers would serve data from their authentication cache. Each server had a different method of caching authentication credentials, but none could be accessed via HTTP alone. Servers Tested: Operating Systems: Testing Tools: Security Rating Key Signifies some server functionality that mitigates vulnerabilities relating to a specific area of the HTTP protocol. - Signifies vulnerabilities that can be exploited by HTTP messages implementing the new functionality.