Web 2.0 Entrepreneur

Securing your Web Application

• Posted by Tengku Zahasman on July 9th, 2007 filed in Web App Development, Security


• 3 Comments »
• (407 Views)

Apart from ensuring code performance, there’s something quite bothering when you’re developing a web application and that is to constantly ensure (while writing the application) that your codes are hack-proof to the black hats out there. As a person who works full-time in the Internet security industry, I analyze the security of our client’s web application almost on a daily basis. I study the structure of their application, identify any obvious or hidden vulnerabilities, and then try to poke into them and see if I can hack their web application. This is called a Web Application Testing.. and depending on how deep I am allowed to dig in, it’s sometimes also considered as Penetration Testing.

In most cases, the security holes are obvious. Most of the problem lies on the carelessness (or laziness) of the web developer in developing the application or maybe they just don’t care so much about their application security due to tight deadlines for completing the web app. However, having your web app to be compromised is not something you’d like to see in the long run so it is always a good idea to make sure your application is practising good security measures from the day it is being developed.

There are a few obvious web attacks that you need to be aware of such as SQL Injection, Session hijacking, Bruteforce attack, Buffer Overflows, Cross-site Scripting (XSS) and Cross-site Request Forgery (CSRF). We’ll discuss about those in detail some other time. For the time being it is important to realise that 80% of the time the problem lies on the failure to sanitize or filter out user input from URLs, hidden fields and forms. Sanitizing/filtering user input means processing the user input first instead of using them straight away in the system. This way you can make sure that the input you’re passing around your application is not malicious to the system. If you don’t process the user input first, hackers can easily inject codes into your system and do bad things.

So where do we need to be extra careful about security when writing your code?

1. Forms - Any forms. Search forms. Login forms. Registration forms. Subscription forms. All of them accepts user inputs, and that means they are open doors for hackers to inject malicious codes or SQL statements. Escape any unwanted inputs like quotes (”) or convert them into HTML-equivalent strings (eg: ” to &quot;). Strip any HTML tags like <script> and ensure that the stripping algorithm is good enough to disallow hackers to get around it. Don’t just validate the user input on the client side, process it as well on the server side. Never trust that your users are following the rules.

2. Dynamic URLs - The same rules apply when you accept inputs on the URL. Always strip and escape unwanted inputs (”escape” means adding slashes to the malicious character; like ” to \”). If a user puts in weird characters, make sure your application knows how to handle it and display the appropriate errors instead of spitting out database errors or code errors.

3. File Uploads - Be extra careful on this function if you provide one. If your application can’t properly filter out unwanted files, hackers can easily upload malicious scripts and run it on your web server. It is pretty easy for people to gain control over your web application if they’re allowed to upload dangerous scripts or “backdoored” files into your web server.

There are of course many other ways for hackers to compromise your web application, but I’d like to be general for this time.

Studying CakePHP 1.2 so far…

• Posted by Tengku Zahasman on July 5th, 2007 filed in CakePHP


• 1 Comment »
• (675 Views)

I have made some intensive self-study on the CakePHP 1.2 framework for the past few weeks. The learning curve that I had to go through has been quite tiring and troublesome, in an interesting way that is, since CakePHP 1.2 is still undergoing development and there are too little documentation on this version if compared to the stable version 1.1.

Cake 1.2 doesn’t have any practical manual (yet) like version 1.1. So learning this version means having to dig deep through their source files and reading the description headers for functions, going back and forth with their API documentation, browsing through the Bakery, hanging around in their official IRC channel to ask for guidance and posting quick questions, and then lots and lots of Googling around too. Yes. I find out that learning a new framework is not all easy. It takes time. Because I found out that learning a framework is almost like learning a new programming language altogether even though you already use PHP as your mother tongue. Frameworks have their own built-in functions to memorize, their own naming conventions to follow, their own unique approaches to methods and classes to get used to which are mostly way different than the usual way we write applications. But even though learning a framework is not a snap, the benefits you get after mastering it is just priceless.

There are many differences I could see in Cake 1.2 if compared to 1.1. More components added in (Auth component for doing authentications is now included! And helpers for Pagination, RSS & XML too! Oh life is getting so much easier~ )… file structures have slightly changed… tremendous change in their Model validation technique (will discuss this in later posts)… and some other changes which you can view them all here.