Think of a robber who wanders around a neighborhood looking for houses to break in. Can they try to disable your alarm? Sure! Can they climb that tree, get access to your roof, and go in through a bedroom window? Sure! Those methods, however, also take time and some work. The easiest target would be one whose downstairs door is unlocked.
Now think of your website as a home. Have you taken basic precautions to prevent users from breaking in? When your customers ask, are you able to tell them that you integrate security measures into your development methods to block out the “low hanging fruit” so to speak?
In Part 1 of this series, let’s take a look at one of the easy things you can do to help protect yourself…..
#1 - Error Handling:
Attackers can glean very valuable information just by trying to break your site. What types of information you might ask? Well as a Developer, think of the types of exceptions you’ve seen. Those exceptions give you insight into what happened in the application. It may point to what broke. It helps you to go to the source of the problem and fix it. What if an attacker finds it first though? What information could they get?
DATABASE ERROR: Duplicate entry ‘0-2’ for key PRIMARY
INSERT INTO ‘ot_term_relationships’ (‘term_taxonomy_id’, ‘object_id’) VALUES (‘2’, ‘0’)
This code was returned as part of a more recent Wordpress exploit. Take a look at the error message. As an attacker, this tells me a lot. Let’s take a look at what we know even if you think it’s obvious:
- I know there is a database
- I know that database is online
- I know there is table named ‘ot_term_relationships’
- I know that table has at least two columns called ‘term_taxonomy_id’ and ‘object_id’
- I know they both accept numbers
- I know there is already a record with a value of 2 in the ‘term_taxonomy_id’ and a 0 in ‘object_id’
I was able to get this all because of an error message. Now I know a little more about your site and how’s it organized.
Example #2 – Login Page:
What just happened there? Did you notice the difference in error handling? In the first case I typed in both an invalid username and invalid password. As an attacker, I try to create a baseline. I’ll type in something I’m almost sure won’t exist to see what the application does and what it gives me. In the first case, the application did what it should have. The error didn’t tell me what was invalid only that the complete package of the username and password didn’t work.
Now it’s time to get serious. Most applications have some type of root/admin account. Look what happened when I typed in the admin account. I got an error telling me I have an invalid password. Now I can infer that the account is valid, and I just need the right password. Now I can start enumerating this form looking for valid users because I know what the response should be.
Take a look at your login page and error handling. Does it give away too much? Don’t just look at the code returned, but look at the URI as well.
See you next time for part 2…
UPDATE: Check out the follow up article showing examples of error disclosures including a Government Site I came across. Link