We suffered a nasty hack earlier this year. Basically, it was an SQL injection hack to our “resend my password” page, a page which I knew was woefully out of date but hadn’t gotten around to updating.No matter how much of a tech geek you are, getting hacked can happen to you.
We suffered a nasty hack earlier this year. Basically, it was an SQL injection hack to our “resend my password” page, a page which I knew was woefully out of date but hadn’t gotten around to updating. The hacker in question got my password (since I’m user_id 1, doing a “select * from users” gives me first… something which I should also fix). Fortunately, they seemed mostly interested in looking at free porn and didn’t mess with our admin pages or do any really nasty stuff like “drop table users” which they could have.
The only reason I even learned of the hack was that we got a bunch of bounced “here’s your password” emails that were being sent to email addresses like, “create table fool insert into fool select top 1 * from users select name + ‘/’ + password from fool drop table fool” (yes, I got dissed by the hacker on top of everything!)
The hacker was coming from an IP address registered to the Pan Pacific Hotel in Singapore. Odds are it was a compromised system there, and if not, it was someone in a room or something so we have little hope of tracking down the bastard and inflicting appropriate retribution.
None of this is new, but I’m going to reiterate common best practices here:
1. Log everything.
I’m glad our admin pages log user ID, date, time, and admin action so I know that the hacker didn’t set up other accounts or give admin access to other accounts, etc.
2. If you’re using SQL, never, ever submit text queries.
If you’re on MS SQL, use command objects with the parameters collection. I’m sure that other databases have comparable objects you can use to avoid any chance of a SQL injection attack. There is no excuse for using browser submitted data in a text SQL query… eventually someone will find the weakness.
3. If you know that a page is out of date and using old coding standards, take a look at it even if you don’t fix it right away.
I’d been putting off fixing this page because it seemed like drudgery to update a rarely used page. Taught me a lesson.
4. Pay special attention to pages that are anonymously viewable.
Not many hackers will pay to try to hack your site, so odds are that 99% of hack attempts will be on the 2-8 pages that are viewable by anyone without paying, namely main page, tours, resend, etc.
5. If you’re running an SQL DB, the web server SQL user should absolutely not have rights to create, alter, or drop tables or stored procedures.
6. Likewise, the web server SQL user should not have any direct select/update/delete rights to tables.
All data access should be through stored procedures.
7. If you’re SQL based, do frequent backups (like daily), plus very frequent transaction log backups (like 5 or 10 minutes).
That way, if you are hacked by someone malicious, you can restore to within five minutes or so of when the hack happened.
I knew all of this stuff, and 99.9% of our code complied with it… but it goes to show you, that 0.1% can kill you. Fortunately, we escaped relatively unscathed because the hacker wanted to get free porn rather than damage our site. I’m definitely not counting on that happening twice.
Aiken is the co-owner and founder of Bondage.com, a Website dedicated to the Bondage, Domination and Sado-Masochism (BDSM) community since 1995. Aiken is also a Tech Chat Board Moderator here at YNOTMASTERS. Aiken can be reached via email at aiken@bondage.com.
