Eavesdropping is the easiest way to steal security tokens like cookies. SSL or other appropriate session confidentiality technologies should be used to protect against eavesdropping attacks.
In addition to on-the wire eavesdropping, be aware that there are a slew of security issues with commonly used web clients that may also expose your security tokens to malicious client-side malware or cross-site scripting manipulation (see Chapter 9 for more on this).
In general, the best approach is to use a session identifier provided by the application server. However, if you need to build your own, you should also design a token that can’t be predicted and can’t be practically attacked using brute-force methods. For example, use a random number generator of sufficient entropy to generate session identifiers. In addition, to prevent brute-force attacks, use a session identifier with a large enough key space (roughly 128 bits with current technology) that it can’t be attacked using brute-force. Keep in mind there are subtleties with pseudorandom number generators that you must consider when using them. For example, concatenating four randomly generated 32-bit integers to create a single 128-bit session identifier is not as secure as randomly generating a single 128-bit value using a cryptographically secure PRNG. By providing four samples to prevent brute-force attacks, you actually make session ID prediction easier.
You should also implement integrity checks across security tokens like cookies and session IDs to protect against tampering at the client or during transit. Tampering can be prevented by using hashed message authentication codes (HMACs) or by simply encrypting the entire cookie value.
In general, storing sensitive data in a client-side security token is not recommended, even if you implement strong confidentiality and integrity-protection mechanisms.
Cross-site Request Forgery
Cross-site request forgery (often abbreviated as XSRF or CSRF) is a web application attack that leverages the existing trust relationship between web applications and authenticated users to force those users to commit arbitrary sensitive transactions on the behalf of an attacker. In security literature, this attack is often classified as one manifestation of a confused deputy attack. The deputy in this case is the web application client browser
andconfused simply refers to the inability of the browser to properly distinguish between a legitimate and unauthorized request.
Despite the extremely dangerous nature of XSRF attacks, these attacks have received less attention than the more easily understood web application vulnerabilities such as XSS. As recently as 2006, XSRF attacks were referred to as a “sleeping giant,” and listing in the OWASP Top 10 project was not achieved until the year 2007. Even at the time of this writing, XSRF vulnerabilities are being actively reported against popular application web sites.
The reader might be wondering then, if XSRF vulnerabilities present such a significant risk, why, until now, have they received such little attention? While opinions certainly vary on this question, part of the reason undoubtedly has to do with how inherent this vulnerability is to the stateless nature of the HTTP specification that requires an authentication token (usually a combination of a session ID cookie and additional authorization tokens) be sent with every request. Common sense dictates that security vulnerabilities are generally caused by mistakes application developers make during design and development or administrators make in deployment. Contrary to this, XSRF vulnerabilities occur when developers simply omit an XSRF prevention mechanism from their application. In other words, if developers have not actively defended against this issue and their application supports sensitive authenticated transactions, then the application is usually vulnerable, by default, with a few exceptions.
So what constitutes an XSRF attack? The classic example is that of a banking application that permits users to transfer funds from one account to another using a simple HTTP GET request. Assume the transfer account action takes the following form:
http://xsrf.vulnerablebank.com/transferFunds.aspx? toaccount=12345&funds=1000.00¤cy=dollars
Continuing with the above example, assume an attacker creates a malicious HTML page on a system under her control containing the following JavaScript code:
<script type="text/javascript">
var i = document.createElement("image");
i.src = "http://xsrf.vulnerablebank.com/transferFunds.aspx?
toaccount=EVIL_ATTACKER_ACCNT_NUMBER&funds=1000.00¤cy=dollars"; </script>
The effect of this JavaScript code is to create a dynamic HTML image tag (<img ...>), and set the source to that of the funds transfer action on the vulnerable banking application. Client browsers of users authenticated with the banking web site that are lured into visiting the malicious page will execute the attacker’s JavaScript to create a background HTTP GET request for the source of the dynamic image, which, in this case, is the funds transfer action, and that action will be executed just as if the user had willingly performed it. The key to remember here is that whenever a browser makes a request to a resource on another domain, any cookies associated with that domain, port,
and path will automatically be attached to the HTTP header and sent along with the request. This includes, of course, session cookies used to identify the authenticated user to the application. The result is that the attacker has successfully forced a banking user to transfer funds from the user’s account to the attacker’s account.
While this example is somewhat contrived and serves to merely illustrate the fundamental issue, similar vulnerabilities have been reported against live systems that could result in heavy financial loss for the vulnerable organization. For example, in 2006, it was reported on the security mailing list Full Disclosure that Netflix was vulnerable to cross-site request forgery issues that, according to David Ferguson who originally disclosed the vulnerability, could result in the following:
• Adding movies to his rental queue
• Adding a movie to the top of his rental queue • Changing the name and address on the account • Enabling/disabling extra movie information
• Changing the e-mail address and password on the account • Cancelling the account (unconfi rmed/conjectured)
Fortunately, the Netflix vulnerability was disclosed before any real damage was inflicted. However, as can be seen from the list of actions this vulnerability made possible, the potential damage, both in terms of real financial loss and damage to Netflix’s brand, of a successful attack against the Netflix userbase simply cannot be understated.
It should be noted that while the example used to illustrate this issue was an HTTP
GET request, HTTP POST requests are also vulnerable. Some developers appear to be under the misapprehension that simply changing vulnerable GET requests to POST will be sufficient to remediate XSRF vulnerabilities. However, this only makes life for attackers slightly more difficult as now they have to construct JavaScript to construct and POST
the form automatically. In order to prevent the browser from automatically redirecting the victim user to the vulnerable application when the POST is submitted, the JavaScript can be embedded in a hidden iframe tag in the malicious page. As a general application design rule, any action with consequence should be constructed using a HTTP POST
request.