Blog post id enumeration can lead to unwanted information disclosure
jeffgeerling.com
jeffgeerling.com
Remember "The URL is the new command line?"
That was back in the the early days of Web 2.0, back when people used that term with a straight face and even a bit of optimism, and where you might also use the term "Mashup" in the same sentence. Having consistent URL formats for Posts, Users, Dishwasher Models and everything else made it so that you could pull information out of web pages quickly and easily without the need for a formal API.
It was a pretty cool time to be writing software because you could quickly suck in data from tons of places in ways that they hadn't specifically anticipated. But it died just as fast as it rose because of SEO.
Over the span of a single year, everybody had to change their urls to look like http://site.org/blog/learn-rails-in-20-minutes and suddenly you couldn't do anything useful with them again.
Shame.
But yeah, at least whatever edge case this author talks about isn't there anymore. To mitigate that, I'd recommend Jason's Law of the Internet: "Try to avoid putting things on the Internet that you don't want to be on the Internet. That way there won't be anything you put on the Internet that you didn't want to be there."
We also built the entire thing basically as an API that just happened to by default pass through a processing step to render HTML. If you gave the right argument, you'd get the page back as our own XML markup [1], RSS or ATOM instead. We didn't go full HATEOAS [1] (didn't exist yet), but we there was a decent amount of descriptive links etc. pointing the way in the XML/RSS/ATOM versions.
[1] That was actually what the web app generated; it was converted server side using XSL, but if you "flipped the right switch" it'd serve up the XML with an XSL stylesheet and it mostly worked fine that way in most browsers, though we never invested the resources in making it flawless (but it was a great debugging tool to get the raw XML served up straight to the browser... everyone came out hating XSL though, for good reasons)
Many people, when faced with "unwanted information disclosure" via ID enumeration, will look to encryption to solve this problem. Please don't; it's the wrong tool for the job.
https://paragonie.com/blog/2015/09/comprehensive-guide-url-p...
Use a random lookup instead of encryption. (You'll notice that https://paragonie.com/b/oMFJhGJ0aSgCaZq0 takes you to the same URL.)
Use application logic (and access controls) instead of random lookups, where it makes sense to do so.
If you absolutely must use encryption (i.e. you don't have a place to store state), make sure you use an AEAD mode.
Is there a general name for this pattern? I'd like to find some of the other libraries for doing the same thing.
Alternatively, if you have 64-bit sequences as IDs (e.g. autoincremented ids in SQL database), you can encrypt then using a real 64-bit block cipher, such as Blowfish or XTEA, with a secret key known only to server. This can give you unsigned 64-bit numbers, which are usable in existing systems (except in JavaScript, where maximum integer has 53 bits), for example:
1 -> 3491820675944448233
2 -> 9264994595240464886
>Compared to Base64, the following similar-looking letters are omitted: 0 (zero), O (capital o), I (capital i) and l (lower case L) as well as the non-alphanumeric characters + (plus) and / (slash).
Not super secure, but good enough for this purpose.
Unless you have a long ID people can always simply try every ID, no matter what format you use. So fancy encryption on the ID isn't all that useful.
If security is important then generate a random 64bit number and store that, rather than let the database auto-generate a number.
XOR has a trivial known-plaintext attack, and you don't even need to determine the entire key to get something useful. If you can create a few posts in order and obtain a series of sequential items, you can obtain the low-order bits of the number XORed in, at which point you can easily browse around for adjacent items from any post.
I haven't tried it with WordPress, but I did do something similar on a custom CMS.
That said, there are better approaches. You can use a plugin to set publish dates in the future, and before that the page will return a 404 (unless you're logged in).
Or even better: For information security, just don't put information that you don't want to publicly disclose on a public web site. (Or if you do, at least make it accessible only to logged-in users with the proper credentials.)
But in this case, the post seems to be unpublished ("accessible only to logged-in users with the proper credentials"), but the SEO redirect plugin the blog is using is likely hitting it's 302 redirect prior to Wordpress checking it's access on the post ID in question, leading to this URL information disclosure.
Modern non-enterprise CMSes make this very hard. Wordpress and Drupal mix configuration and content all over their databases, and there's no "sync this content from stage to prod" that works reliably (i.e. they fail as soon as there is a single non-standard plugin loaded).
I haven't evaluated Drupal 8 yet, but I'm not counting my hopes too high.
It's a lot easier in 8 since it has an API-driven design for content entities.
EDIT: I realize UUIDs are not "secure random" tokens and this isn't sufficient for real security, it's just a nice to have encumbrance if I screw up something I should've made secure in the first place. It's no substitute for doing your job right in the first place. :)
I support UUIDs instead of nearly any other id space. They solve collision problems completely. Its time to stop managing ids.
Not if they are RFC 4122 UUIDs (more accurately, they are insufficiently cryptographically secure): even the random ones are only 122 bits, which only provide 61 bits of security.
UUIDs are still really, really useful. I don't recommend not using them unless one understands why and when not to.
Why would that be? You can fork your PRNG as many times as you have threads in initialization, so there's no need for IO. And secure ones do spend many times more CPU than the cheapest PRNG available, both would be a rounding error on the performance on nearly all real world work-loads.
I'd support removing non-secure random functions from every standard library out there.
~ $ python -m timeit -s 'import uuid' 'uuid.uuid4()'
100000 loops, best of 3: 14.2 usec per loop
Ah, Java...
The library you are using for creating those UUIDs must have some bug. My guess is they share the same generator for all threads on each machine.
It is a cryptographically secure PRNG, but during a small time in system start up, it may not be correctly seeded.
If you need long term keys, it may be better to get some 256 bits from /dev/random before using /dev/urandom.
http://sockpuppet.org/blog/2014/02/25/safely-generate-random...
I don't understand. What is it spoiling?
There are other ways unpublished urls may leak in - for example via sitemaps. Trying to lock them all down is lousy engineering. Instead just password protect the unpublished content and you're done.