Hack Your Own Site

lock

What's the best way to protect your site from hacking? To actually try it out, and hack your own site! It can be a great learning experience to test out some common exploits on your site, and fix all your vulnerabilities.

Plus, it's pretty fun to see the different ways that people can get into and cause problems with your site. This post focuses on a few of the most common ways that people can do this.

Today we are going to try out some examples of common exploits, and figure out how to solve them, keeping everything safe. We will focus on SQL injection and cross-site scripting for today.

Remember to only use these on your own site, I will not be held responsible if someone gets angry at you for trying these on their site. And don't be stupid and try these on your live site, have a private server setup for this.

SQL Injection

SQL injection attacks work by adding extra malicious commands into SQL queries. For example if we have a login form, our SQL query would look something like this:

SELECT * FROM 'users'
    WHERE 'username' = 'myuser'
    AND 'password' = 'mypassword'

And here is some code that someone could inject into the SQL query through the form:

Username: ' OR 1=1 /*
Password: */;--

This would change our SQL query into the following:

SELECT * FROM 'users'
    WHERE 'username' = '' OR 1=1 /*
    AND 'password' = '*/;--'

Because PHP simply sees the MySQL query as a string, the user can play around with the quotes inside it and add stuff to it. In this example, the OR operator is used to change the SQL query to check if either the username is equal to an empty string, or if 1 is equal to 1, which will always be true. And then the rest of the query is commented out, to avoid any errors.

For a login form, this will allow anyone access to the "protected" areas. You obviously don't want just anyone to get into a members only area, so we have to fix this problem.

The easiest way to solve this vulnerability is to escape your strings before using them in your queries. A function included in PHP is mysql_real_escape_string. However, there can be some problems with this, mainly because it is a blacklist of certain "dangerous" characters.

So, we're going to use prepared statements. This method is more secure because SQL logic from the data being used. Prepared statements are included in PHP, through the MySQLi class. It's basically used like this:

< ?php
// Create the mysqli object, replace parameters with the DB information
$db = new mysqli('localhost', 'username', 'password', 'database');
 
// Create statement object
$stmt = $db->stmt_init();
 
if($stmt->prepare('SELECT * FROM users WHERE \'username\' = ? AND \'password\' = ?')) {
    // Bind your variables and replace the ?s
    $stmt->bind_param('ss', $username, $password);
 
    // Set your variables
    $username = 'aldld';
    $password = md5('password'); // Assuming that passwords aren't stored in plaintext. Right?
 
    // Execute query
    $stmt->execute();
 
    // Close statement object
    $stmt->close();
}
?>

For more on using MySQL prepared statements with PHP, check out this awesome article at UltraMegaTech.

Cross-Site Scripting

Cross-site scripting (XSS) is another type of code injection technique, similar to SQL injection. Except this time, client-side scripts such as JavaScript are inserted into pages to be targeted to users, not to the site itself. This is often why search results in Google sometimes say "This site may harm your computer."

For example, let's say we have a comments form that allows HTML. XSS can be a problem here because a bad user can input the following:

<script type="text/javascript">
doBadStuff(); // Does bad things
</script>

Of course, this is the simplest possible example that exists, but even with more complex situations, for example if BBCode is used, someone determined to harm your users can find a way around it.

A simple way to prevent common types of XSS is to use the PHP htmlspecialchars function. It converts certain characters to HTML entities, like this:

echo htmlspecialchars('test <bad code> test', ENT_QUOTES);
// Output: test &lt;bad code&gt; test
</bad>

The only problem with this is that it means that HTML cannot be used by users at all. To work around this, you could try to use a "whitelist" of HTML tags that can be used, and be sure to do it very carefully.

For more information on basic protection against XSS, check out this post at Webmaster-Talk. It has an easy to understand example, with fixes that make sense.

Conclusion

These are just a couple of examples of common attacks on websites that can be prevented with some good security practices. What other security vulnerabilities would you like to learn to fix? Do you ever hack your site, to test for vulnerabilities? I'd love to hear what you think.

Stay Updated

Did you enjoy this post? Don't miss a single post by getting free updates!

9 Comments

  1. January 18, 2010

    Killer post. Thanks for giving examples. Most people tend to speak theoretically about how sites get hacked, which does very little good to those of us who actually understand this stuff and WANT details.

    • January 18, 2010

      Glad you liked it! That's partly what actually inspired me to write this post.

  2. January 20, 2010

    This is a great concept. I have tried to hack other peoples sites before (on a purely educational, non-malicious way. Sites like hackthissite.com and stuff like that lol), but I never thought to do my own. I guess that if you knew what you were doing, then you really could be effective at finding such vulnerabilities.

    Thanks for the thought provoker. :)

    • January 21, 2010

      Yeah, that's why I included that line saying to only use these techniques to evaluate your own site's security. I don't think someone would be too happy if you tested their site's security :P

  3. April 9, 2010

    alert('good article')

  4. June 28, 2010

    Awesome! great post.....
    Thanks a lot for sharing.

  5. August 17, 2010

    Being in the web security business, I attempt to hack my own site constantly.

    The last exploit I found was a CSRF, and before that it was a vulnerability in my captcha system that could allow a bypass.

    More people need to be aware of these threats so I can stop getting calls about XSS exploits in EVERYTHING.

Trackbacks/Pingbacks