Scotland's oldest newspaper exposes readers' smalls in public
URL manipulation snafu gives access to other users
Regcast training : Hyper-V 3.0, VM high availability and disaster recovery
Updated Scottish newspaper The Aberdeen Press and Journal inadvertently made it easy to harvest sensitive information about registered users from its site as a result of a basic information security mistake.
Registered users are presented with stories an a URL along the lines of
http://www.pressandjournal.co.uk/Article.aspx/815191?UserKey=xxxx
By altering the UserKey number it was possible with only one further click of a mouse button to see the name, home address, email address and telephone number of registered users.
Granite City reader details exposed
Only registered users can make comments on stories or enter competitions. Registration also gives readers the ability to search through job and car adverts on affiliated sites, or to track online responses to ads.
The Aberdeen Press and Journal is the main local paper for Scotland's third city, and was first published in January 1748. Judging by the UserKey numbers its site has more than 80,000 registered users.
Parent firm Aberdeen Journals Limited maintains a privacy policy that states that "protecting the privacy and personal data of individuals is an important aspect" of how the firm is run. By allowing access to sensitive details via simple URL manipulation the paper has clearly fallen short of this policy.
The paper got its developers to fix the problem promptly, only hours after we relayed the concerns of Reg readers on Monday. "Apparently, the bug was introduced two or three weeks ago during an upgrade to part of the site," a representative of Aberdeen Journals explained.
Aberdeen Journals is far from alone in making a security slip-up that created a URL manipulation risk. Coding errors in O2's Bluebook application, discovered and repaired in February 2008, made it briefly possible to see SMS messages sent through the service by other registered users simply by changing the message ID number. Customers' call records of 02's business customers were left open by the same type of coding snafu in August 2006.
URL manipulation also cleared the way to viewing application forms submitted to oil giant Shell in 2003. More seriously still, Powergen fell foul of basic URL manipulation in July 2000, with the result that credit card payment details were exposed.
In reporting on previous instances of URL mainipulation we've been told that using the HTTP Post method of encoding a database query would mean that a requested page comes with a URL that looks like gibberish, reducing the problem of URL manipulation. Judging from your feedback, this is no longer best practice, if it ever was. ®
Bootnote
Thanks to Reg reader Frazer for first alerting us about the problem with the Aberdeen Journals site.
COMMENTS
Oh someone has to explain the post business
post is meant to be used when the server state changes.
get is used to retrieve a URL based on parameters.
Both can be affected by a lone cracker, get is arguably simpler as you can mainpulate directly in the browser, but of course a cracker can create a program to send crafetd post requests.
In an earlier infomercial, the art of self defense in the browser I think it was called, the author said a problem with a certain site was that a call to a url could be embedded in an external page causing the external site to change account information.
Now, those calls tend to have to be get requests, post requests are not sent automatically via the browsers to another domain. So, in that instance requiring a post would have helped (not made secure but helped).
See, they could have made you fill in a form or cloaked a form as a button, but less chance of an exploit then as it would require user interaction. And of course there is the possibility of using an iframe and an auto submission, could work, would be more obvious though, and would be considered a security hole, therefore a candidate to be patched. Whereas, accessing a url via get should be harmless, because it is not meant to change server state, see how all this works.
But in this instance, post or get it doesn't matter.
Browser security is really based on what does the user allow, that's why the confirm boxes are not really customizable so people cannot switch the ok and cancel around. And that's also why the mouse cursor cannot be moved all round the browser anymore :) Well maybe IE still allows that.
I have lost count of the bozos who think mixing post and get requests is a good idea. Break the model if you like, it is breakable but of course people base security around the model.
Anyhow, the golden rule is never trust the information sent, and verify the place it is sent from, if the system is open to abuse. Amazon one click is an example of something that could be quite easy to abuse or not depending upon how they verify the request.
And whilst we are on the subject, if you are using javascript, then it makes verification simpler and more robust, states can be changed depending upon page exit and tab currently being viewed, so it does amuse me that people advise noscript because in some instances they are lowering their security potential.
@ a@b.com
... techncally, I do ... where a = [username] and b = [hotmail]
Local papers
and what about the Dundee Courier whitch until fairly recently did not have Front Page news the Front Page was all adverts
IT infrastructure monitoring strategies
Agentless Backup is Not a Myth
Top 10 SIEM implementer’s checklist
Steps to Take Before Choosing a Business Continuity Partner
Requirements Checklist for Choosing a Cloud Backup and Recovery Service Provider
