This article is also available as a TechRepublic download.
The fundamental weakness that can potentially make insecure direct object reference an attractive attack vector is a failure to properly secure directories and folders on site servers. Also known as directory traversal, insecure direct object reference vulnerabilities are exploited by simply adjusting URLs provided when users visit a site or provided within scripts delivered directly to the desktop. This vulnerability replaced Broken Access Controls, A2 in the 2004 OWASP Top 10 list.
Other articles in the series can be found using this tag.
The following is an example taken from a Web posting at Imperva's site. In Figure A, a request is being made to obtain the news file for March 20, 2003. Assuming this HTTP request was built with user supplied input, it's a prime target for an Insecure Direct Object Reference attack.
If the site's developer is not properly checking for and allowing only valid input, an attacker can input the character sequence "../" to jump out of the current directory into its parent directory. A series of these sequences can continue traversing up through the directory tree until arriving at the parent of the target directory. In Figure B, an attacker is attempting to traverse up four directories in order to access WINNT. If successful, she will receive the win.ini file instead of a news file.
|Traverse four directories|
Even if the attacker doesn't know the exact number of jumps necessary to arrive at the proper location in the directory tree, it isn't difficult to play with the character string input to figure it out.
Defending against a directory traversal or insecure direct object reference attack is pretty straightforward:
- Lock down all directories and folders on site servers. Under no circumstances should anyone accessing a server from the Internet have access to any directories other than those specifically intended to contain Web content.
- Second, validate all input. In the case of directory traversal, be particularly watchful for "../" or "..\". Input validation was covered in detail in Part 3 of this series.
- Keep private object references private.
Cross site request forgery (CSRF)
CSRF is very similar to cross site scripting (XSS), with one very important difference. XSS takes advantage of weaknesses on the client while CSRF takes advantage of weaknesses on the site server.
According to the OWASP, "A CSRF attack forces a logged-on victim's browser to send a request to a vulnerable Web application, which then performs the chosen action on behalf of the victim, to the benefit of the attackers" ("OWASP Top 10", 2007 (RC1), p. 19).
The key piece of this description is "forces a logged-on" victim to send requests. The attacker exploits the trust the site has for the targeted user. This means that if an attack is successful, the attacker can perform actions on behalf of the user, including,
- Make purchases
- Transfer funds
- Deposit malware and leave little or no trace to identify the real attacker
- Perform stock trades
- Subscribe to online services
CSRF isn't a small problem. According to rsnake, founder of ha.ckers.org, there are too many CSRF vulnerabilities on the Internet to count (Kelly Jackson Higgins, "CSRF Vulnerability: A 'Sleeping Giant'", darkReading, 17 Oct 2006). Jeremiah Grossman, founder of WhiteHat Security, provides some context for this position by saying that, "[CRSF] is not seen as a vulnerability because it works like the Web works" (ibid).
The exploit is delivered to the user in various ways. Attack vectors include e-mail and tricking users to click on a link at the attacker's site. Once the exploit is launched, it relies on an existing trusted session with the target site or the presence of an auto-logon cookie on the victim's PC. If a trusted session is available, the exploit commands are run on the site server within the victim's security context.
Defending against CSRF attacks is difficult, but not impossible. The best defense for users is to take the proper steps to ensure trusted sessions can't be used by cybercriminals.
- Be sure to log out of trusted sessions when finished.
- Be cautious when asking a site to remember your user and password on login. This may deposit login information on the client that can be exploited.
- Delete all cookies after a trusted session.
Site developers have a bigger challenge when attempting to write applications that are less susceptible to CSRF. The following is a list of countermeasures to consider:
- Set a short time period for trusted user sessions.
- Verify the user making the request each time a trust-based action is requested.
- Per-request nonces added to URLs and forms provide per request user verification beyond the basic session token.
- Eliminate all XSS vulnerabilities from applications. XSS can be used to obtain useful attack information. For example, an attacker could fake a form that prompts the user for identity information.
The final word
Vulnerabilities from Insecure direct object reference are easily preventable. Basic folder and directory access controls coupled with consistent input validation will block most if not all attacks.
CSRF is a much more difficult vulnerability against which to mount a defense. User awareness of the dangers it presents and how to protect themselves from exploits is a good first step. Developers must take a look at how they establish a trusted session and how they re-verify user identity when trusted activities are requested. Developing sites safe from CRSF requires a complete review of how Web applications are designed.
Tom is a security researcher for the InfoSec Institute and an IT professional with over 30 years of experience. He has written three books, Just Enough Security, Microsoft Virtualization, and Enterprise Security: A Practitioner's Guide (to be published in Q1/2013). Before joining the private sector, he served 10 years in the United States Army Military Police with four years as a military police investigator. He has an MBA and CISSP certification. He is also an online instructor for the University of Phoenix.