HTTP RS and User ID & Password Mishandling

Below are a few snippets from our August 2007 WhiteHat Sentinel customer newsletter that thought people might find interesting.

---

HTTP Response Splitting results are in:

Many customers have asked us which Web servers are vulnerable to HTTP Response Splitting attacks. While we are still assembling aggregate totals, here is an initial list of server types we’ve observed to be vulnerable:

1. Apache/2.x
2. Apache/1.x
3. IBM_HTTP_SERVER
4. Jetty/5.1.11
5. Lotus-Domino
6. Microsoft-IIS/5.0
7. Microsoft-IIS/6.0 (commonly misconceived to be invulnerable.)
8. Netscape-Enterprise/4.1
9. Oracle-Application-Server-10g/Oracle-HTTP-Server
10. Resin/2.x
11. Websense Content Gateway (Traffic-Server/5.x)

Note that the problem of Response Splitting susceptibility is really with the application code. A common mistake is narrowly focusing on the server itself as the source of the issue, likely because a few servers have controls to strip this attack from HTTP GET requests. However, many of the HTTP RS attack vectors we’ve found use the HTTP POST verb as well.

The initial HTTP Response Splitting tests are not yet taking advantage of our more advanced testing engines that perform layered encoding attacks and malformed URI manipulations. Once this is fully incorporated, we expect to find even more variants than we do today.

Watch Out For...

User ID and Password mishandling: Using the user ID and password after logging the user in, as session or authorization identifiers, is a dangerous practice with many security implications. Not only does the presence of an XSS vulnerability indicate that you are giving up the user’s credentials very easily, but it often indicates weak session handling and leads to a variety of information-leakage issues, like passing the user ID and password off-domain via the HTTP Referer field or non-SSL encrypted parts of the website.

So, don’t use the user ID and password as identifiers.

While enhancing our authentication and automation tests, we have been observing more and more Web applications that pass the user ID and the password around in things like hidden form fields or cookies. Sometimes credentials are encoded, sometimes encrypted, and sometimes they are en claire (in plain sight).

While the actual security implications of this are contextual to the specific application, this design pattern usually indicates the presence of one or more weaknesses.

WhiteHat Website Vulnerability Management Practice Tips

Q. What do I do if I see a user ID and password being passed around one of my applications?

A. First off – you need to identify why the credentials are being passed around in the application. If there is no reason, you can simply have your developers remove it.

Barring that, a common weakness we observe is the user ID and password being used as a form of session-token to maintain state in the application. This is a really bad idea on many levels. In addition to information leakage issues with the user credentials, this will introduce:

Session Fixation Weaknesses: The “session token” is predictable, fixed, and unchanging. This makes it a trivial task for an attacker to reverse-engineer and take over a “session.”

A Vast Attack Surface: In general, there is no notion of a “session.” You cannot log a user “in” or “out” handling sessions in this fashion, since in this case, there is only “one” session for all eternity, making the attack surface very large once an attacker figures that out. Everything from XSS to CSRF becomes far, far worse if this weakness is present - not to mention the attacker can impersonate the user directly and at will.

Multiple other issues from the WASC Threat Classification list

Another common use is when credentials are checked before making security decisions such as verifying whether or not a transaction is really authorized by the user. Unfortunately, if the credentials are not entered by the user, but rather provided automatically via a hidden form field or cookies – the attacker can also force the user to submit these automatically.