Feb
14

Basic application security considerations

14 Feb 2010 by tonie in General, Design

A very interesting discussion inspired me to write about some basic rules you have to understand before you publish your web application live. We were arguing on whether to clean up data before saving it to the DB or before displaying it to the user. So here are some basic security principles, every web developer should be aware of.

Database injections

One of the two most common ways to get cracked is by a database injection. There are tons of exploits out there for every possible web development environment. A MySQL injection, for example, is an external modification of a particular query to the DBMS in order to get access to a portion of data. This type of evil code is usually inserted as a value of some sort of user input. The way to prevent such attacks is to make sure you have escaped all user input properly before proceeding to query the database with it. If you are not using some sort of database abstraction layer, which already provides this functionality on the low level, you should add it yourself.

Cross-site request forgery (XSRF) and Cross-site scripting (XSS)

My favourite. Unlike SQL injections, this type of attack does not aim to harm your database or get access to a protected area of your application by directly inserting SQL statements. Instead, these try to insert code which will hopefully be displayed somewhere in your web site and vary from just layout-breaking code to much more dangerous hijacking scripts. For example, suppose that you have a forum app. One of your admin pages is thread.php and does three actions – adds, edits and deletes threads. In order to be able to delete a thread from your administration panel, you would use the following request: thread.php?action=delete&id=15. The script checks whether you are authenticated with the system and if you are, then it deletes thread #15. Now, let’s suppose that an evil hacker creates a reply to any of your threads, containing the following code:

<img src="http://yourdomain.com/admin/thread.php?action=delete&id=10" />

If you have allowed HTML in your posts, then every time someone reads this reply there will be a malicious request sent to your server. Now, since users are not allowed to delete your posts, this action will never be completed. However, the second you read the evil hacker’s reply and you have authenticated as admin, thread #10 will be deleted and you could even not notice it.

Protect yourself

Always be careful to escape SQL statements properly, so you don’t end up SQL injected. For protecting your app against XSRF you can approach with two different solutions. Clean up HTML code when you save data to the DB or you can worry about cleaning when you display this data on your web page. Either way, be sure to do it at some point.

Pro’s and Con’s

You execute your cleaning function only once before you save to the database. Then you don’t need to worry about displaying data. This will save you resources, but it will be very difficult to see the original code if you want to examine it. On the other hand, if you clean your HTML every time you display it, you’ll waste processor time and/or memory, but you will have the original code in your database, so it will be easier to examine it later on.

Conclusion

The best practice, I think, is to save both cleaned up data and non-cleaned up data simultaneously. This will eat up double hard drive space, but you will not have to escape your data every time you display it. It will also allow you to see the original code in case you want to see what it does and improve you application security.

Cheers,
Tony

xsrf, xss, security, mysql, injection

Speak your mind ( 0 Comments)

If you liked the article and want to contribute to it, please feel free to leave your comment. HTML tags are not allowed, but you can use the following BBCode to enhance your message: [url] [quote] [code] [b] [i] [u] [color].