3 ms·
I once found this in live code which was -- irony alert -- checking Authorization headers. Something of the flavor: "select user.* from users where TO_BASE64(
by patio11 15y ago
I once found this in live code which was -- irony alert -- checking Authorization headers. Something of the flavor:
"select user.* from users where TO_BASE64(email + ':'+ password) = '" + headers["Authorization"] + "' limit 1";
(Can't quite remember -- that base 64 bit might have been pre-calculated in a column. It has been a few years.)
One would hope that in addition to fixing the SQL injection they fixed the use of HTTP basic auth over a non-encrypted connection but, well, some stories are probably better left untold.
- Ralith 15y agoNot to mention storing passwords with a trivially reversible transform...
- vidarh 15y agoI once worked in a company where another team were responsible for the company flagship services which - after you'd logged in - stored your customer id in a cookie. That was the only authentication for subsequent requests. And the ids were sequential. After I demonstrated to them that I could get the CEOs personal details, as well as trivially brute force all other personal details in the system with a bash script calling curl, not to mention run up massive bills (the system allowed setting up phone conferences with up to 30 participants and let you use the web interface to call out to participants worldwide), they thanked me and told me they'd fix it. Next day they'd released an updated version which they said encrypted the customer id. Two problems: No nonce or anything, so if you sniffed it once, you could still trivially use it to "log in" and continue as before. Secondly, their "encryption" turned out to be base64. I sent them a new script that showed them how to get the customer id's still. They were amazed that I'd "cracked their encryption".