Yesterday I explained the basic #1 rule of security when building a website – "Never Trust the User." Today I’m going to show you why and how a malicious user can attack your website.
Form Spoofing
When writing HTML, it’s normal to provide restriction on field lengths and choices:
-
Firstname: <input type="text" name="fname" maxlength="100" /><br />
-
Title: <select name="title">
-
<option value="Dr">Dr.</option>
-
<option value="Mr">Mr.</option>
-
<option value="Ms">Ms.</option>
-
</select>
-
</form>
This code simply creates a simple form that POSTs to save.php. The first name field is limited to 100 characters and the title is limited to those few options. This is useful in "restricting" the client to these basic limits. However, since the HTML code is now in their hands and there is nothing to stop them from changing maxlength=100 to maxlength=1000. They can even change what choices are in the title. It’s important to know that no matter what you send to the client, they can change it. So no matter what, always check your incoming data on the server side. Check for max length, data types, possible choices, etc.
Now I’m sure you’re probably thinking that it’s useless to put these client restrictions in, but it’s not. They help restrict the normal users’ input before it reaches the server side restrictions.
Cross-Site Scripting (XSS)
This is one of the most common and dangerous attacks for any website. The short version of this is basically that a malicious user crafts his own code which gets displayed on the targeted website. This kind of attack can execute commands on other user’s browsers. Simple things include: stealing sessions, grabbing cookie data, redirecting to alternate websites, and even installing viruses.
This is usually done by submitting HTML code through any posting system. Like on Facebook, if you were to post on someone’s wall and provide this as the text:
-
<script>
-
document.location = 'http://www.stjohnjohnson.com/';
-
</script>
This would redirect anyone who browsed that person’s wall to my website. Luckily, Facebook prevents against such attacks by filtering their input (as mentioned yesterday).
Cross-Site Request Forgeries (XSRF)
This attack is based on the idea of having a user perform an unrequested action on another website that they are logged in on. Here is an example (interpreted from the book):
- User logs into shopping website with personal credentials.
- Selects an item for purchase, goes to checkout, and hits the buy button (loading checkout.php)
- The final purchasing url for that item ends up being checkout.php?item_id[]=1233&qnt[]=1
- The malicious user then adds the following code to his OWN website:
-
<img src="http://www.example.com/checkout.php?item_id[]=1233&qnt[]=1" width="1" height="1" />
-
- Any user that visits the malicious site and is still logged into the shopping website now makes an unauthorized purchase without their knowledge.
This can be prevented by requiring POST data instead of GET data and adding in a uniquly generated TOKEN every time the checkout page is loaded.
Tomorrow I’ll be talking about some Database Security (SQL Injection), Session Hijacking, and Filesystem Security.

