Chad Myers' Blog

# re: Predictable IDs exposed considered harmful

Hey Chad- the deal with "discoverable" URLs is for the end-user. There are many times when you don't want that to happen (like the Delete example) and it's (as always) up to the dev to make sure this kind of thing isn't exposed.

The good part is that following a REST principle - the URLs are supposed to be discoverable (right down to the format of the data).

Furthermore, by hiding the extensions of the requests, you actually have one extra layer of protection since the user doesn't necessarily know the platform. 10/10/2007 12:44 AM | Rob Conery

# re: Predictable IDs exposed considered harmful

Chad, I disagree. Obscurity is no substitute for security. 10/10/2007 1:09 AM | Mike Moore

# re: Predictable IDs exposed considered harmful

@Rob: Oh, I LOVE the new, clean URLs. I just don't see why you need the specific database primary key as the ID. I think you should use something else as the key. For example: /Employee/Details/SamJorgenson or /Employee/Details/A43928-C2 where A43928 is the employee number and not the database ID. Employee number may be a repeatable number in which case you may not want to use that either unless it's truly an intranet application

@Mike: I'm not sure what you're saying. I wasn't suggesting that you shouldn't do all the other stuff.

But it's generally best practices to do things like: a.) not show full error messages to end users b.) mask password fields c.) not make configuration files with passwords publicly available, etc

Likewise, I think it's a bad idea to have ID's just hanging out there, ESPECIALLY in the URL. 10/10/2007 1:21 AM | Chad Myers

# re: Predictable IDs exposed considered harmful

But if the masked keys get too outrageous, say map a GUID to a PK, then they URL is "ugly" again. Which defeats the whole purpose. 10/10/2007 3:40 PM | Scott

# re: Predictable IDs exposed considered harmful

What is the argument for having ID's in the URL again?

Look at how .TEXT/SubText handle the blog URLs. They have some semblance of the title in the URL. While not extremely useful, I bet you could work out a way where that would be useful and still serve to protect the DB ID.

In the /Product/Detail/15 case, maybe you could use the SKU, or the product name as the URL? For example, /Product/Detail/Farting_Nun_Dolls which seems more user-friendly (and book-markable) than does /15 10/10/2007 3:44 PM | Chad Myers

# re: Predictable IDs exposed considered harmful

"new, clean URLs" - I don't know what is so "new" about this idea, these are RESTful principles that have been known and in use for many many years. It is largely new to those whose only understanding of it comes when Microsoft vomits up something "new" that illustrates an already-well-known use of technology, and these Microsoft fanboys think Microsoft invented the idea (I am NOT implying you are such a person!); URL re-writing has been around for quite a while.

There are so many issues here that you can't simply state "this is bad" or "this is good;" like most things, "it depends." Obviously, if IDs are not something you want known, you shouldn't be using them (e.g. maybe an employee, editing his own data on an intranet app, sees the following in the URL: "/Edit/MedicalHistory/Employee/12" - it would be bad if he could then simply change the 12 to a 13 and then a 14, etc. and get edit other employees' info each time, implying the use of auto-incrementing PK values) and I would venture to say the same if you were running a website that was public-facing and sold products, you would want to avoid the IDs because, as mentioned in previous comments, it isn't very indicative of what you may be bookmarking or sending to a friend, etc.

Many of these so-called "problems" are null and void when you use decent security; in the example I mention above where an employee is editing their own data at a URL that contains "/Edit/MedicalHistory/Employee/12", it really isn't a big deal if you have additional security that checks to see if the ID being requested matches that of the user or the user is in a role that allows them to see it.

Like Rob said in his comment, "the URLs are supposed to be discoverable (right down to the format of the data)." But, I would have to agree that providing any obvious reference to an auto-increment PK value is somewhat useless. I mean, it would be pointless to have a URL read, in part, "/Edit/MedicalHistory/Employee/12" if the PK value of the employee record really was 12, because what is the point of showing that to the user?! They are not going to simply "know" who employees number 13 and 14 are, so it isn't giving us anything useful. Now if those really were employee IDs, let's say something like JB_4324, it might be more useful.

Anyway, totally rambling now - thanks for the post; it is a good thing to think about.
11/21/2007 10:01 PM | Jason Bunting

# re: Predictable IDs exposed considered harmful

Wow Jason... you should blog about this rather than having a lengthy comment. Seriously. Anything over a few paragraphs should be a blog post. That way it's not buried in some backwater blog comment thread like this :)

I have been shielded by the Microsoft world. I wouldn't call myself a fanboy, but the rest of what you said is mostly true about me. I'm starting to come out of that shell now, but it's hard.

As far as ID's in querystrings, this is not a new problem whether you're using REST, URL rewriting, etc. When I saw this, I though "Oh crap, not this shit again."

A big problem in the NIH world of software development is that, in our constant re-invention, we also keep re-inventing security issues.

I firmly state that database ID's in querystrings are bad, bad, bad.

You're right about having proper security, but ask ANY information security expert and they'll tell you that simply *knowing* a key piece of information (like a user name, an ID of any kind, a table name revealed in an exception stack trace displayed to a user, etc) is half of the battle.

*ANYTHING* you can do to prevent users from seeing (even if it involves digging, no matter how deep down it is), is a good thing.

Just because the average user won't do anything with a '12', doesn't mean a determined hacker won't start banging away and discover all sorts of things about how your system is built and, most likely, discover a vulnerability.

People who bash Microsoft should know full well that you should *NEVER* trade security for ease-of-use. That's how MSFT got into their situation in the first place and why everyone laughs at them now that they're turning everything around 180 and trying to secure everything doing it the 'right' way. 11/21/2007 10:16 PM | Chad Myers

# re: Predictable IDs exposed considered harmful

Yeah, sometimes I think I should blog things, but right now my blog is in limbo - I am moving it from host to host trying to find the right spot for it (I was hosting it on my server at home, but I don't want to do that any longer).

Don't worry to much about being shielded - it happens to everyone to some extent, and at leasst you are starting to see beyond their marketing. I remember when I first learned about O/R mapping back in 2004 - by then, the Java world had been doing it for quite a while. I thought I was behind the times and then I ran into opposition from nearly every Microsoft-platform developer I came across. Now you see more and more people realizing it is worth while and I just wonder what took them so long.

Sure, I hear ya - I understand the need to avoid exposing data that might betray possibly-exploitable implementation details. And while I agree with you that it is "bad, bad, bad" I also recognize that few of my clients want to pay for the time it takes to do it right. Heaven knows why, because you can bet they would hold your feet to the fire if there were ever a problem that could be traced back to an implementation decision.

The hard thing is "View Source" - basically, if you are going to take this line of thinking through to the end, you would then need to provide "fake" identifiers for EVERYTHING on a page - oh, your drop-down list uses DB PK values for each item in the list? Need some fake ones! So, it could get unwieldy if you REALLY want to take it to the end. Any hacker knows there is more to a page than the URL and would simply view source and learn all sorts of things that might help them attack your site. The use of "Ajax" is one of the areas I believe has opened up more opportunities for attacks. People are so excited by the technology that they forget security in their rush to implement it (I am sure I am guilty here!).

11/22/2007 12:03 AM | Jason Bunting

# re: Predictable IDs exposed considered harmful

I disagree with you.
As a general rule, if you application is secured, you shouldn't be afraid of hackers knowing some id's. Converserly if simply changing a parameter (be it id or whatever) makes your application vulnerable, you have more important things to worry about than just some exposed id's.
12/18/2007 11:11 AM | alberto

# re: Predictable IDs exposed considered harmful

@alberto: We agree, I'm not arguing that you should secure through obscurity.

I'm saying that, as an added level of security, you should not reveal true database ID's to the users. No matter how secure your system is, there WILL be a vulnerability SOMEWHERE and the less info you give to a would-be hacker, the less likely he/she is going to be able to compromise your system.

It's the same reason why it's not good to show full exception stack traces when you have an error on your web application. Why? It's best practice! Why is it best practice to not show full exception messages and stack traces? Because it's just more clues to a would-be attacker.
12/18/2007 11:57 AM | Chad Myers