[bungie4]

Programmer (not me!) manually iterates over user file (passwords plain text natch). If he finds a matching username (format is enforced so dead easy to guess). He sets the auth cookie. THEN he goes looking for the password. You don't have to enter any password. At that point, just hit the back button a couple of times and refresh and BING! You can impersonate anybody on the system. Including the admin because guess what the admin's username is.

This guy is notorious for writing crap like this. But according to the powers that be, he's a 'god'.

The funnier bit? This site is RSA protected.

[BinaryIdiot]

I used to work at a life insurance company that had a sessions page for the developers that wasn't locked down at all. If you could get someone's id you could go directly to this page and set your user id to that. Done.

They also had a contest for their agents and the database they used to store all of the entries and information was an access database that happened to be sitting in the public directory for the website to simply serve to anyone who knew to request the database.

Seeing so much "security" makes me realize that a large majority of sites out there are a complete shit show, especially if the companies I worked for / with couldn't get it right and they actually had some money to their name.

[cookiecaper]

Yes, most medium-or-smaller sized companies, including ones in fields that should take security seriously like insurance and lending, will have tons of stuff like this. It shouldn't surprise anyone at this point.

[BinaryIdiot]

Even large companies depending on how you want to classify one as "large". Back when Palm announced their new phone, the Palm Pre, I was given early developer access on their developer portal. I reported to them multiple security vulnerabilities including one that allowed anyone to change a simple integer in the URL and instantly see everyone's SSN / TIN, payment information, etc. It took them 3 months to fully resolve, too (their first fix was simply changing a GET call to a POST, sigh). They never even disclosed it to anyone despite my pleas (I should have but was still sorta green back then and didn't think it through).

[Sami_Lehtinen]

Been there done that. The only thing you didn't mention was that if you do give a wrong password, it calls the logout function. So all tests do work. You can't login with wrong password.

[bungie4]

Nope. Just refreshes back to the same page. Sorry, forgot to mention that the logout button doesn't actually DO anything except redirect to the Login page. Auth cookies are still intact.

This guy is special.

[jjnoakes]

Blow the whistle anonymously. Let people know which site it is.

[gruez]

>The funnier bit? This site is RSA protected

What does that even mean?

[ivanbakel]

You send them your public key in a GET request, and the payload you get back is the encrypted HTML page. Make sure to pick a big enough key size, or you might not see the whole thing...

[bungie4]

No, in this case it's RSA SecureID

https://en.wikipedia.org/wiki/RSA_SecurID

A one time, time based hash as 2FA. Despite using this 2FA, the bad code completely circumvents it.