Update: Microsoft is NOT at fault for this! There seems to be some confusion within the talkbacks on this subject about this being Microsoft's fault, and also some strange claims that development shops who do only .NET programming are more likely to program insecurely. This is just, in fact, completely without basis.
This particular issue is an issue created by poor development practices, and that is all. This same flaw could exist in ANY web application programming language, and in fact, no application programming language gives a developer a significant advantage to NOT create an issue like this.This issue is around lack of authorization control, and since these voter registrations can be accessed by index with no authorization check, I can view anyone's information. That is it. There is no flawed feature in a Microsoft product, no Visual Studio use that causes this to happen, etc., so let's get over the vendor bashing at this point.
There's even been some strange comments that say things like, .NET makes it more likely that these parameters will get sent in the URL, thus creating the vulnerability. The fact is, it wouldn't matter if these were sent in the query string, a Post request, within the cookies, I could still catch it as it leaves my browser, modify it and access someone else's data. Not to mention that most applications simply wrap their doGet method within their doPost method, so you can actually send a GET request (i.e. where the browser sends data in the query string of the URL) INSTEAD OF a POST request.
The fact is, I've performed hundreds of application security assessments and I've seen no basis to say that a Java language/framework is more secure than .NET.
Original post begin:
Ok security people, we've been talking about it for awhile now, and here it is! Do you remember when you first heard about online voting? Do you remember thinking, geez, that sounds like a really bad idea? Well, your fears are confirmed.
The state of Pennsylvania online voter registration page has a major flaw that was discovered and mentioned on digg, the text of which is posted below:
Online voter registration PDFs are left unsecured on the server for anyone to access. Simply change the request ID at the end of the URL. Valid IDs appear to be working from 50000 and up to 58500+ This was discovered after filling out a registration myself. Being a security conscious programmer, I decided to test. Very bad PA...very very bad!
The entire application has since been replaced with a message that says the site is temporarily offline, but the basis of the flaw was that an attacker could force the application to retrieve arbitrary PDF voter registration files of other voters by simply modifying a request parameter sent in a request to the PrintVoterApplication.aspx page.
This reminds me a lot of the work that Billy Rios has helped Google out with, as referenced here, here, and here. In these examples arbitrary user's documents could be stolen from the Google Docs application.
This particular example; however, seems to be quite a bit easier to exploit than the Google example, as you simply can increment or decrement the application id parameter, whereas Google had some form of randomness to the value. There's another thing to consider here, the Google issue was not so straightforward, and was therefore discovered, reported, and then Google's Security Team took care of it real fast cause they're a strong team. In this case, the State of Pennsylvania's site was up and running with the vulnerability fully reported on Digg... who knows how many user records could've been viewed during this time. Additionally, I'm not sure the issue has been addressed in terms of a fix, basically it just looks like the applications functionality has been turned off.
The details are very unclear (i.e. no screenshots that are currently posted), but it seems straightforward to exploit if the server was still accpeting requests. The request looks something like the following:
Where the ApplicationID parameter (which I've bolded and italicized) can be modified from your own application id to that of another user.
Perhaps it's only reasonable in my perfect, Utopian vision of how the world should be, but I'd love to think that the government of the country that I love is doing a bit more to enforce security of its citizen's data. One would think that this would've come up in an application security review if the reviewers had any skill at all.