Insecure Direct Object References

We’ve spent a lot of time discussing SQL injection so far, and for good reason, given how widespread these vulnerabilities are and how damaging they can be when they’re exploited. But SQL injection is by no means the only form of remote attack against SQL databases. In this section, we’ll take a look at a completely different vulnerability known as the insecure direct object reference.

No Technical Knowledge Required

The term insecure direct object reference is the way OWASP describes a particular type of authorization flaw that leads to data compromise. To explain this vulnerability, let’s give our sales team management example application that we’ve been using a little more functionality, and have it keep records of all the salespeople’s salaries. When a sales manager logs in to the application to manage his team, he is presented with a list of his employees and links to their individual performance pages.

When he clicks the link, the application requests the details from the database based on the value specified by the user parameter in the link querystring.

As you can see, the application developers have securely coded the database access with parameterized queries, so no SQL injection attack is possible here. But in fact, it’s not even necessary. What’s to prevent the sales manager from entering a totally different value for salespersonID into his browser, such as an ID for another manager’s employee, or maybe even his own manager’s ID? Without any additional authorization checks—that is, ensuring that the user actually is the manager of the person he’s looking up—there’s nothing in this SQL command to prevent a data breach.

The insecure direct object reference attack is also remarkable for the complete lack of technical knowledge required to exploit it. With SQL injection, the attacker had to know at least a little bit of the SQL programming language in order to get any useful data out of the system. But here, an attacker can just randomly type numbers into his browser address bar and potentially gain access to sensitive data. It’s literally an attack that a four-year-old could pull off.

Insecure direct object reference vulnerabilities have even more serious consequences when they occur in multitenant environments—environments where multiple sets of customers share resources on the same server.

Note

Multitenancy is a key feature of Software-as-a-Service (SaaS) cloud applications.

An insecure direct object reference in a multitenant application could potentially reveal sensitive information of every organization that’s using the service. Competitors might be able to view each other’s private files: Coke could read Pepsi’s data; Ford could read Chevy’s data. This is one of the main reasons that corporate CIOs and CSOs are hesitant to move their data to the cloud, and why it’s so important to prevent this type of vulnerability in the first place.

Insecure direct object reference issues aren’t limited to just authenticated sites. You can see them in anonymous public web applications too, such as online shopping sites. Large retail shopping sites often get information from their suppliers on new products before they’re actually announced to the public. The Best Buy/Apple relationship is a good example of this: Apple provides Best Buy with specs and release dates for new iPads, iPhones, and MacBooks way before Steve Jobs gets up on stage to share the news with the rest of the world. But retail sites like Best Buy don’t wait until the day of the product release to create the catalog data for the new product; they start work on creating this data right away. Sometimes this data is actually published to the live web site ahead of time too, but it’s not advertised, and the new product catalog page isn’t linked to any other pages in the application. The intent is that only the site administrators should know about the new page until the official announcement date, at which time they can quickly link it to the site’s home page and start actively promoting the new product. However, users hungry for information on potential upcoming product releases will set up automated scanners to look for new pages added to the site.

http://retailsite.cxx/productDetails?productId=1

http://retailsite.cxx/productDetails?productId=2

http://retailsite.cxx/productDetails?productId=3

. . .

http://retailsite.cxx/productDetails?productId=9999999

. . .

It’s time-consuming, but the automated scanner takes care of the tedious grunt work, and the chance to be the first to find out when the new iPods are coming out is priceless.

Insecure Direct Object References and Confidentiality-Integrity-Availability

In terms of confidentiality-integrity-availability, insecure direct object reference attacks are primarily targeted at breaking the confidentiality of the application. The attacker’s goal is to gain access to data not normally available to him. However, in rare cases there may be some kind of RESTful web service or Model-View-Controller (MVC) architecture that allows integrity attacks through insecure direct object references. For example, the sales team management application might allow the sales manager to grant a bonus to an employee:

http://salesteam.cxx/grantbonus?salespersonID=11209003&amount=1000

Note

There are tons of security problems with this application design pattern aside from the insecure direct object reference, not least of which is the fact that the application is accepting an HTTP GET request for an action with persistent side effects. For a review of why this is so dangerous, refer back to the section “Cross-Site Request Forgery” in Chapter 6.

Solving the Problem: Pre- or Post-Request Authorization Checks

To prevent insecure direct object reference information leaks, you’ll need to enforce some kind of authorization checking in your application before it sends potentially confidential data to the user. There are two main strategies for doing this. First, you can check whether or not the user is allowed to see the resource he’s asking for right after he asks for it. Second, you can check which resources the user is allowed to see before he even asks for one, and only offer him those choices to begin with.

The first approach is pretty straightforward. If you keep the authorization data in the database itself, you can just change your query to directly include an authorization check. Let’s continue our retail site example. This application’s database has three tables: User, Product, and UserProduct (a table to list which users have rights to see which products):

The only user in the database who should have rights to see the upcoming product “myPhone5”—in fact, the only user who should even know that such a product exists—is the user SteveJ. All other users should only be able to see the previously released products “myPhone3” and “myPhone4.” We can ensure that the myPhone5 specs don’t leak ahead of schedule by changing the database query to join the Product and UserProduct tables on the ProductName column and filtering on the UserId:

Now if an unauthorized user tries to search for “myPhone5,” the database engine won’t return any rows from his query. It’ll be completely invisible to him, just as if he had searched for “myPad3” or some other nonexistent product.

The second insecure direct object reference defense approach we mentioned earlier is similar to this approach, but instead of checking for permissions after the user searches for an item, we’ll change the application code to check before. Then, instead of letting the user search by a product name, we’ll display all the valid choices in a list and just let them choose item 1 or item 2 or so on.

A side effect of this is that one person’s item 1 may not necessarily be the same as someone else’s item 1. For this product database example, that’s probably a bad thing: If I’m looking around on the site and I find something I think is cool, I might want to e-mail you a link so you can check it out too. But the page that http://retailsite.cxx/catalog/productIndex=123 links to for me might be a completely different page for you, which could lead to some misunderstandings (why are you sending me links for Justin Bieber CDs?).

However, there are situations where this is actually a good thing. Let’s say that the database stores credit card data for all of its users. There might be tens of thousands of cards stored in the database, but any particular user would only have authority to access one or two of these. In this case, it makes a lot more sense to say “use card 1” or “use card 2” rather than having to send the complete card number, and this isn’t information that you’d want to send around or share with anyone else.

Final Thoughts on Insecure Direct Object References

In truth, insecure direct object references are a wider class of vulnerabilities that affect more than just databases. The same type of vulnerability can happen when the application is retrieving potentially sensitive pages from the file system, or when it redirects users to other pages based on URL querystring parameters. We’ll cover the particulars of these attacks later in the book, but the defensive strategies will remain similar.

We’ve Covered

SQL Injection

SQL injection exploits and their effects

The dangers of detailed error messages

Blind SQL injection

Solving the problem: validating input

Solving the problem: escaping input

Setting database permissions

Revoking unnecessary privileges

Creating multiple database user roles

Stored procedures

Minimizing privilege attack surface

SQL-injectable stored procedures

Insecure direct object references

Pre- and post-request authorization checks