Stop putting AUTO_INCREMENT ids in URLs(blogs.perl.org)
blogs.perl.org
Stop putting AUTO_INCREMENT ids in URLs
http://blogs.perl.org/users/ovid/2014/11/stop-putting-auto-increment-ids-in-urls.html
6 comments
It's also an excellent way to check for security problems, for pages which should be generated just for you. Increment/decrement the number - get someone else's information. I have reported countless instances of this with varying rewards and success; you can count on someone, somewhere making this mistake regularly.
Yeah, makes me think of the owasp top ten, though this site's problem isnt really insecure direct object references (as all the postings are public) more like "making it easy to infer information about the target."
https://www.owasp.org/index.php/Top_10_2013-Top_10
https://www.owasp.org/index.php/Top_10_2013-Top_10
I agree with the sentiment of the article, but not with the majority of the points the author makes.
Most of the time, information catalogued and then URL-ised by AUTO_INCREMENT are public information that could easily be spidered another way. As the article noted it's not hard to look back at previous job postings (using the article's example).
So most of the time AUTO_INCREMENT is just used as an arbitrary counter / identifier which is just as guessable with other arbitrarily chosen identifiers. The linked blog uses /CCYY/MM/ URL to order the articles, then a natural string to specify a specific record, and that method could just as easily work for the record ID in the same way /AUTO_INCREMENT/NATURAL_STRING. But the question of whether you'd want to hide (or make it harder to guess) URLs for articles published to the public still remains.
Where AUTO_INCREMENT really causes problems is when you have information you don't want public. Such as session IDs. But in those instances, it would be rare to URL-ise them in the first place (bar maybe some AJAX calls). And as far as I'm aware, nobody uses AUTO_INCREMENT for session IDs anyway (they'd have to be pretty useless developers if they did).
There might be some argument against AUTO_INCREMENT for some user-submitted / community services such as PasteBin and URL shorteners. But even here, if the information isn't intended to be public then it either a) be hidden behind some level of authentication or b) shouldn't have been published online to begin with.
Security aside, the other point he raised was with SEO. However even that's not really an issue for the same reason his /CCYY/MM/ URL isn't an issue: sites that need search engine optimised will support a human readable string as part of the URL.
So I don't think his "Stop Putting AUTO_INCREMENT IDs in URLs" is really tackling the real problems and I think his example is very misleading. The real issue is people who use predictable (which includes guessable hashes) row ID's as identifiers for non-public data AND the issue with developers who choose to hide non-public data behind obscurity[1] instead of secure authentication. None of which has much to do with URLs in the first place (since incrementing session ID's are just as bad regardless of whether they're encoded in a URL, HTTP "POST" body, a cookie, or whatever)
[1] https://en.wikipedia.org/wiki/Security_through_obscurity
Most of the time, information catalogued and then URL-ised by AUTO_INCREMENT are public information that could easily be spidered another way. As the article noted it's not hard to look back at previous job postings (using the article's example).
So most of the time AUTO_INCREMENT is just used as an arbitrary counter / identifier which is just as guessable with other arbitrarily chosen identifiers. The linked blog uses /CCYY/MM/ URL to order the articles, then a natural string to specify a specific record, and that method could just as easily work for the record ID in the same way /AUTO_INCREMENT/NATURAL_STRING. But the question of whether you'd want to hide (or make it harder to guess) URLs for articles published to the public still remains.
Where AUTO_INCREMENT really causes problems is when you have information you don't want public. Such as session IDs. But in those instances, it would be rare to URL-ise them in the first place (bar maybe some AJAX calls). And as far as I'm aware, nobody uses AUTO_INCREMENT for session IDs anyway (they'd have to be pretty useless developers if they did).
There might be some argument against AUTO_INCREMENT for some user-submitted / community services such as PasteBin and URL shorteners. But even here, if the information isn't intended to be public then it either a) be hidden behind some level of authentication or b) shouldn't have been published online to begin with.
Security aside, the other point he raised was with SEO. However even that's not really an issue for the same reason his /CCYY/MM/ URL isn't an issue: sites that need search engine optimised will support a human readable string as part of the URL.
So I don't think his "Stop Putting AUTO_INCREMENT IDs in URLs" is really tackling the real problems and I think his example is very misleading. The real issue is people who use predictable (which includes guessable hashes) row ID's as identifiers for non-public data AND the issue with developers who choose to hide non-public data behind obscurity[1] instead of secure authentication. None of which has much to do with URLs in the first place (since incrementing session ID's are just as bad regardless of whether they're encoded in a URL, HTTP "POST" body, a cookie, or whatever)
[1] https://en.wikipedia.org/wiki/Security_through_obscurity
You conflate several things and construct a problem where there is none:
* yes, auto-incrementing session IDs are bad and downright stupid. Noone ever does this (right?).
* information leakage about the number of jobs per month or similar is not a problem unless you're trying to maintain some sort of illusion about your company / web page, which hopefully most people/companies won't do (they have no good reason, unless they're crooks). Nowdays archive.org will take many snapshots of web pages, so will Google and any visitor can do it, so why try to hide something obvious?
In general, it's not an anti-pattern: it's fine for products in online shops, properties on real estate platforms, blog entries, etc.. To avoid it there would simply mean to make URLs longer and uglier with no good reason.
* yes, auto-incrementing session IDs are bad and downright stupid. Noone ever does this (right?).
* information leakage about the number of jobs per month or similar is not a problem unless you're trying to maintain some sort of illusion about your company / web page, which hopefully most people/companies won't do (they have no good reason, unless they're crooks). Nowdays archive.org will take many snapshots of web pages, so will Google and any visitor can do it, so why try to hide something obvious?
In general, it's not an anti-pattern: it's fine for products in online shops, properties on real estate platforms, blog entries, etc.. To avoid it there would simply mean to make URLs longer and uglier with no good reason.
I am not sure what you guys mean by “session id”—an identifier for the session, or an authentication mechanism? I have used systems where the session id was auto incremented, but there was a separate signature (in the cookie) verifying that the user “owned” that session.
on the other hand, I'm currently using quite random IDs (firebase), and the URLs are just ugly: /jobs/-J_wBsKY4Rn1WgMPB7-_/operations/-J_wBsKf4-WYh9ohK7j8
You don't have to have a massive random number - just one long enough to fulfil your goal. You then ensure uniqueness using your database. If your goal is just to allow sufficient addressability, then the random number needs to have enough bits to cover the maximum number of items you can ever conceive of creating. If your goal is to prevent people from typing in a random number and getting a valid page, you need to multiply your address space by 1/(acceptable probability of guessing).
Having two levels of random number is unnecessary - you should be able to access a job/operation combination with a single identifier.
Having two levels of random number is unnecessary - you should be able to access a job/operation combination with a single identifier.
In this case, there is also distributed ID generation.
Big title. Definitely not "anti-pattern"
Big title