Website hacking, the dark side – Part 1

What’s the solution to this problem?

For this particular hack there are a couple solutions for you and for little Zaphod – or anyone who thinks that script is k3\/\/1 (cool).

1. Encode data in hidden fields. If they can’t read it they can’t use it, and they’ll go find another site that’s simpler to hack. When you do encode, please don’t use ROT13 or some other common character substitution mechanism. There are scripts available to encode/decode ROT13 too ya know…
2. Don’t put any more data in a form than is required. Not only does it consume more bandwidth to put more data in the client, but it exposes more for someone to look at and figure out how your site works.
3. Don’t assume that hidden fields are current. Session IDs should have an encoded timeout value.

There are some general tips to avoid hacks too.

1. Validate data on every connection. Data needs to be checked to ensure that it’s consistent with the rest of the user activity. What if you get a transaction where the Session ID is valid but there are 100 line items for a total shopping cart value of zero?
2. Don’t just check the data, make use of headers that are provided to the web server on every connection. This includes client IP address, browser type, CPU type, Operating System, and other data. (Yes, you provide this data to a server every time you load a web page.) Some of it is invalid, but some of it can be used to uniquely identify any given client who is re-connecting to your system as part of a session. Think about it: Will a user change browsers from one form to another? Will they change IP addresses? CPU? Operating System? If the data looks fine by the operating system of the end-user has changed, something is up.
3. Be aware of your own vulnerabilities. Indulge yourself and think like a "bad guy" hacker. Hack your own site, look at the source code coming from your server. If you can recognize secure data then someone else can too – and they might want to change it.
4. Don’t trust obvious first lines of defense like when someone disables the View Source browser feature. First, that’s easy to subvert. Second, "real" hackers don’t always use browsers. There are programs like cURL and wget that don’t pay attention to scripts that inhibit HTML browsers from viewing source.
5. When you’re confident that your site is safe, ask someone else to hack it for you and to tell you whatever they can about the site.

So put on your white hat and have a look at your own site. If you find something that needs to be fixed based on what you’ve read here, then I’m glad this helped.

I’ll post another article on this topic sometime soon. There’s another hack that can be used against sites hosted with any DBMS platform – and you MV guys aren’t as immune as you might think. If you’d like a review of your environment to check for vulnerabilities, just let me know. I’m not a security guy and not trying to position as an authority in this area, but I can spot the issues mentioned here and help to fix them.