ANÁLISIS COMPARATIVO DE LAS ÁREAS EVALUADAS

Just as a little SMTP knowledge aids understanding of email-security issues, a little background on HTTP and URLs improves knowledge of web security.

Every exchange between a web client and server is defined by the Hypertext Transfer Protocol (HTTP). HTTP 1.0 was the first widely used version, but it had some shortcomings. Most of these were addressed with HTTP 1.1, the current version that is almost universal. HTTP 1.1 is defined in RFC 2616

(http://www.w3.org/Protocols/rfc2616/rfc2616.html). The web client makes HTTP requests, and the web server responds. Web browsers hide much of the data exchange, such as MIME types, cache settings, content negotiation, timestamps, and other details. Other clients (such as a web spider, wget, or curl) offer much more control over the exchange.

An HTTP request contains an initial request line: Method URI HTTP-Version \r\n

Methods include OPTIONS, GET, HEAD, POST, PUT, TRACE, DELETE, and CONNECT. Some methods have a corresponding URL format.

This line may be followed by request header lines containing information about the client, the host, authorization, and other things. These lines may be followed by a message body. The web server returns a header and an optional body, depending on the request.

There are security implications with the type of URLs you use. Since the protocol is text, it’s easy to forge headers and bodies (although attackers have successfully forged binary data for years). You can’t trust what you’re being told, whether you’re a web server or a client. See section 15 of RFC 2616 for other warnings. The following are the most common methods and some security implications.

8.4.1.1 HEAD method

Do you want to know what web server someone is running? It’s easy. Let’s look at the HEAD data for the home page at http://www.apache.org:

$ telnet www.apache.org 80 Trying 63.251.56.142... Connected to daedalus.apache.org (63.251.56.142). Escape character is ’^]’. HEAD / HTTP/1.1 Host: www.apache.org HTTP/1.1 200 OK

Date: Sat, 13 Apr 2002 03:48:58 GMT Server: Apache/2.0.35 (Unix)

Cache-Control: max-age=86400

Expires: Sun, 14 Apr 2002 03:48:58 GMT Accept-Ranges: bytes

Content-Length: 7790 Content-Type: text/html

Connection closed by foreign host. $

(A handy alternative to this manual approach is the curl client, available from http://www.haxx.se.) The actual responses vary by web server and site. Some don’t return a Server: response header, or say they’re something else, to protect against attacks aided by port 80 fingerprinting. The default value returned by Apache includes the identity of many modules. To return only a Server: Apache response, specify: ServerTokens ProductOnly

8.4.1.2 OPTIONS method

If OPTIONS is supported, it tells us more about the web server: $ telnet www.apache.org 80 Trying 63.251.56.142... Connected to daedalus.apache.org (63.251.56.142). Escape character is ’^]’. OPTIONS * HTTP/1.1 Host: www.apache.org HTTP/1.1 200 OK

Date: Sat, 13 Apr 2002 03:57:10 GMT Server: Apache/2.0.35 (Unix)

Cache-Control: max-age=86400

Expires: Sun, 14 Apr 2002 03:57:10 GMT Allow: GET,HEAD,POST,OPTIONS,TRACE Content-Length: 0

Content-Type: text/plain

Connection closed by foreign host. $

The OPTIONS method is not a security concern, but you might like to try it on your own servers to see what it returns.

8.4.1.3 GET method

GET is the standard method for retrieving data from a web server. A URL for the GET method may be simple, like this call for a home page:

http://www.hackenbush.com/

A GET URL may be extended with a ? and name=value arguments. Each instance of name and value is URL encoded, and pairs are separated by an &:

http://www.hackenbush.com/cgi-bin/groucho.pl?day=jan%2006&user=zeppo An HTTP GET request contains a header but no body. Apache handles the request directly, assigning everything after the ? to the QUERY_STRING environment variable. Since all the information is in the URL itself, a GET URL can be bookmarked, or repeated from the browser, without resubmitting a form. It can also be generated easily by client-side or server-side scripting languages.

Although you may see some very long and complex GET URLs, web servers may have size limits that would snip your URL unceremoniously (ouch). Apache guards against GET buffer overflow attacks, but some other web servers and web cache servers have not.

Since all the parameters are in the URL, they also appear in the web-server logs. If there is any sensitive data in the form, a POST URL should be used.

The question mark and /cgi-bin advertise that this URL calls a CGI script called groucho.pl. You may want the benefits of a GET URL without letting everyone know that this is a CGI script. If an attacker knows you’re using Perl scripts on Apache, for instance, he can target his attack more effectively. Another reason involves making the URL more search-engine friendly. Many web search engines skip URLs that look like CGI scripts. One technique uses the PATH_INFO environment variable and Apache rewriting rules. You can define a CGI directory with a name that looks like a regular directory:

ScriptAlias /fakedir/ "/usr/local/apache/real_cgi_bin/"

Within this directory you could have a CGI script called whyaduck. When this URL is received: http://www.hackenbush.com/fakedir/whyaduck/day/jan%2006/user/zeppo Apache will execute the CGI script /var/www/real-cgi-bin/whyaduck and pass it the

environment variable PATH_INFO with the value /day/jan 06/user/zeppo. Your script can parse the components with any method you like (use split in Perl or explode in PHP to split on the slashes). Since GET requests are part of the URL, they may be immortalized in server logs, bookmarks, and referrals. This may expose confidential information. If this is an issue, use POST rather than GET. If you don’t specify the method attribute for a <form> tag in HTML, it uses GET.

8.4.1.4 POST method

POST is used to send data to a CGI program on the web server. A URL for the POST method appears bare, with no ? or encoded arguments. URL-encoded data is sent in the HTTP body to Apache, then from Apache to the standard input of the CGI program.

A user must resubmit her original form and data to refresh the output page, since the recipient has no way of knowing if the data may have changed. (With a GET URL, everything’s in the URL.) The data size is not as limited as with GET. Normally POST data is not logged, although you can configure Apache to do so. A POST URL cannot be bookmarked, and it cannot be automatically submitted from a browser without using client-side JavaScript (other clients like wget and curl can submit POST requests directly). You need to have a button or other link with a JavaScript URL that submits a form that is somewhere on your page. 8.4.1.5 PUT method

This was the original HTTP upload mechanism. Specify a CGI script to handle a PUT request, as you would for a POST request. PUT seems to have been superceded by WebDAV and other methods, which are described in Section 8.5.5.