Before a web page renders in a user's browser, a request is made to the application host server The server receives the request, processes it, and then sends a response to the browser In an attack scenario, cyber-criminals use simple server request …
Before a web page renders in a user’s browser, a request is made to the application host server. The server receives the request, processes it, and then sends a response to the browser. In an attack scenario, cyber-criminals use simple server request and response pairs to determine the architecture and infrastructure of the application. This can be used to launch targeted attacks on your application should you run outdated unpatched software.
Understanding Server Requests
When you type a URL into your web browser, it creates a request and sends it to the web server. There are two types of requests: GET and POST. A GET request is a simple “please send me the information based on the URL given.” In a POST request, data is submitted to the server for processing. POST requests are normally used in web forms and other input sent to the server. Attackers use both request types to discover vulnerabilities on the server, but a basic GET request is only required to view infrastructure information about the application and server software.
The following snippet is an example server request sent from your browser:
- GET / HTTP/1.1
- Host: yoursite.com
- Accept-Language: en-US
The above request is a simple request using GET targeting the root of the site yoursite.com. You can identify that the root (home page) of the web application is requested because only the slash (“/”) character is included in the first line where GET is specified. The “HTTP/1.1” section tells the server that this is an HTTP request using version 1.1. If a specific directory or application file is requested, it’s included in the GET request. The “Accept-Language” header provides the language understood by the user. The user’s language is configured in the browser installation and passed in your web requests.
The following request is another example:
- GET /mypage.htm HTTP/1.1
- User-Agent: Mozilla/5.0 (compatible; MSIE5.01; Windows NT)
- Host: yoursite.com
- Accept-Language: en-US
- Accept-Encoding: gzip, deflate
- Connection: Keep-Alive
In the above request, the GET request asks for a specific file named mypage.htm from the yoursite.com website. In this request, the “User-Agent” header is included. This header identifies the browser used by the user requesting content.
POST requests look somewhat differently, because these requests are used to send information to the server either from a form or possibly an uploaded file. The following snippet is an example of a POST request:
- POST /sendmessage HTTP/1.1
- User-Agent: Mozilla/5.0 (compatible; MSIE5.01; Windows NT)
- Host: yoursite.com
- Content-Type: application/x-www-form-urlencoded
- Content-Length: length
- Accept-Language: en-US
- Accept-Encoding: gzip, deflate
- Connection: Keep-Alive
- userid=myuser&message=hello
In the above the POST request sends the “userid” and “message” values to the application’s “/sendmessage” processing page. Attackers will send data to the web server to identify exploitable vulnerabilities, but a POST request is not necessary when researching servers to map out application architecture.
Understanding Server Response Headers
After the server receives a request, it processes it and sends a response back to the web browser. Server responses contain several more header values than a request. The following is an example of a server response:
- 200 OK
- Access-Control-Allow-Origin: *
- Connection: Keep-Alive
- Content-Encoding: gzip
- Content-Type: text/html; charset=utf-8
- Date: Mon, 11-Jan-2021 16:06:00 GMT
- Keep-Alive: timeout=5, max=997
- Last-Modified: Mon, 21 Dec 2020 02:36:04 GMT
- Server: Apache/2.4.9 (Unix)
- Set-Cookie: userid=3454332; expires=Mon, 11-Jan-2021 16:06:00 GMT; Max-Age=31449600; Path=/; secure
- Transfer-Encoding: chunked
- Vary: Cookie, Accept-Encoding
- X-Cache-Info: not cacheable; meta data too large
The important components in the server response for an attacker performing reconnaissance on your application are the first line (200 OK in this example) and the Server header value. A web application server could return several other header values, even custom ones created by server administrators and application developers.
The “200 OK” response means the request was processed successfully. An attacker may send various spoofed headers to the web server to identify if any vulnerabilities exists based on header information. For instance, the attacker might manipulate cookie values sent to the server to identify vulnerabilities or send malformed form input to identify if the server responds with an error. If an error occurs, the “200 OK” response would indicate an error such as a “500 general error.”
The other interesting component in the response is the Server header. The example response Server header value tells an attacker that the server runs Apache on a Unix operating system, most likely one of the Linux distributions. This information gives an attacker enough information to customize attacks on the server. If the server runs Windows, the headers will look like the following:
- 200 OK
- Access-Control-Allow-Origin: *
- Connection: Keep-Alive
- Content-Encoding: gzip
- Content-Type: text/html; charset=utf-8
- Date: Mon, 11-Jan-2021 16:06:00 GMT
- Keep-Alive: timeout=5, max=997
- Last-Modified: Mon, 21 Dec 2020 02:36:04 GMT
- Server: Microsoft-IIS/8.0
- Set-Cookie: userid=3454332; expires=Mon, 11-Jan-2021 16:06:00 GMT; Max-Age=31449600; Path=/; secure
- Transfer-Encoding: chunked
- Vary: Cookie, Accept-Encoding
- X-Cache-Info: not cacheable; meta data too large
Notice in the above example that the Server header returns Microsoft IIS, which is a Windows hosting service. In this scenario, the attacker might assume the application could be running .NET. In some cases, the server returns the application .NET framework information.
Server Headers and Targeted Attacks
It might seem harmless for anyone to know server operating system and framework information, but it’s useful information for targeted attacks. For instance, suppose Microsoft discloses a critical vulnerability affecting their Windows operating system. Attackers use disclosed vulnerabilities to craft attacks against servers where administrators have not patched its software. If the response headers define the software running on the server, an attacker knows that the server is vulnerable to exploits.
The severity of this risk can be seen in the Equifax attack, where millions of consumer records were disclosed to an attacker. Equifax administrators failed to patch critical web hosting software running on a publicly available server. Attackers were able to identify the outdated software and exploit the server. The result was one of the biggest data breaches to date.
Protecting Your Web Application from Targeted Server Attacks
To protect your server from targeted attacks, administrators should configure the web application server to leave the Server header value empty. Any web hosting software will allow this configuration including Apache, nginx, and Microsoft IIS. You can check out the hosting software documentation to find out how the header value can be removed.
With the Server header value removed, you make it one step harder for attackers to find vulnerabilities on your web application. It doesn’t fully protect your server from exploits, but it forces attackers to blindly script attacks rather than having the advantage of targeted attacks using known vulnerabilities and outdated unpatched software.
