← Back to context

Comment by tyingq

5 years ago

Ah, so finally the detail. The site was apparently an ASP.NET site, and they were putting the whole SSN into the "VIEWSTATE" object.

Which looks something like this in the html:

<input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="BASE64STUFFHERE=">

There is a choice to encrypt it, but I'm skeptical how useful that is, or that it was enabled in this case.

So the "hack" was "view source" -> decode some base64 data sitting in plain sight.

Edit: A little bonus. This bizarre video from a PAC the governor started, still trying to call this "hacking": https://www.youtube.com/watch?v=9IBPeRa7U8E

Wow, great job piecing together the “View State” comment from the article.

The docs on how to encrypt[0] this information has an interesting example use case:

> View state data is stored in one or more hidden fields on the page and is encoded using base64 encoding. ... In some cases controls might use view state to store information that no users should have access to. If those identifiers contain sensitive data, such as social security numbers (emphasis added), you should encrypt the view-state data in addition or instead of sending over SSL.

[0]: https://docs.microsoft.com/en-us/previous-versions/dotnet/ne...

  • You can encrypt it, but then it's useless for anything other than keeping state on the server side, and only across form posts. In which case a session id would be simpler. It seems to be a holdover ASP.NET feature from when browser support was weak for things like cookies.

    In this case, they just really shouldn't have sent the SSN at all, as only the last 4 were ever displayed on the page.

It's always fun when someone thinks they are encrypting something when they Base64 "Encode" it. "Is it encrypted?" "Yes, it's encrypted using Base64!" Facepalm