Entry Tags

Wednesday, January 01, 2025

Recording this for Austerity

(It's actually June 15, 2025)

Ooh wee mama! It's a little embarrasing, but I have to record this somewhere so are you ready? Yes? Here we go! ...

On 2021-08-11, I rewrote the login mechanism for this very site; I'm sure at the time I thought I was making it very robust and bulletproof, I can just imagine my smug expression as I FTP'd those last changes up to the web host.

Fast forward to 2025-06-15 08:14 AM CEST. I'm clearing out old bookmarks (so I can delay finishing my novel) and I come across an old link: https://shoppe.ca/phpAuth_login_history.txt. I had totally forgotten that I log all my logins and logout to file. And what do I see for January 11, 2023? HUNDREDS of lines of not login attempts, but people actually logging in as user "1" or as user: "1')) OR NOT 5431=7560-- ptIt" or as user "DROP table 'bob';". (Sadly I deleted the log thinking I had a backup only to remember that I don't backup logs.)

I figured, "There's no way!" and I plugged in: 1')) OR NOT 5431=7560-- ptIt as both user and pass and just as Robert is your father's brother, I was in! LOL Holy shit. LMFAO, etc.

Now, even though I haven't looked at that code in 4 years, I had a funny feeling, judging by that string above, that I kind of new how they were getting in. But that's not as interesting as me not having any clue in 2021 that it could be a possibility! What I did (didn't do actually was:

• I didn't sanitize my inputs, specifically _POST["username"] and _POST["password"]
• I didn't check the contents of the query result: auth_result. (I only checked if it was set!

So when someone wrecked the query by including say, an apostrophe, then the query would return:

Warning: SQLite3::querySingle(): Unable to prepare statement: 1, near ")": syntax error in /home/u370171204/domains/shoppe.ca/public_html/shoppeauth_login_engine.php on line 44

and so since auth_result is therefore set with that, the user would get in.

Wow, it's so bush league that I would expect Signiant to have it in their code. But on the bright side, it really shows how far I've come! And is also shows that I should definitely track logins on my other sites to make sure people there haven't figured out my login scheme on those sites.

Anyway, to fix, I made three changes:

I now sanitize the SHIT out of the _POST vars before passing them to the query.

I now run my querySingle with an @ in front (like, @auth_db->querySingle ... ). This suppresses error messages if the query is fucked. Sqlite3 will just return: false.

Since now, auth_result can only contain the id or false, I now check auth_result to make sure it's an integer.

Bonus: I also now log fail attempts and the password they used for my interest ... to a different log file: https://shoppe.ca/shoppeAuth_Login_History.txt

Of course, no one knowing this vulnerability has even logged in since January 2023, and once in there's not much to see except my excellent literary ramblins' ... but still, the fact that I had been breached at all, ever, meant I could delay finishing my novel for several hours today while I fixed things! Yay!

SIDE NOTE
I typed in "amateur programmer" into Duck Duck Go's image search to find a funny image for this post and it came back with 100% porn! Not a single image wasn't pornographic! Is this a bug in Duck Duck Go's image search, or have I been hacked, or (most likely) is DDG's AI-based image search correctly guessing my image preferences?

Ignore (for templates)