Writing secure web applications - Part I
Tags : Application Security, application access, validation, Web Security
Why, you ask, do you need me to go on and on about considering security implications of every design and development decision you make. “I am smart”, you say, “I know if I do not secure my environment I will be susceptible to attacks ranging from data compromise to content defacing. I will get a firewall or even two if necessary. I will also get a system administrator who has commanded the biggest and most diverse of systems. To top it all up, I shall lock my servers in a cell and feed the administrator through a hole in the door never allowing him to see the light of day.”
Fine, I understand physical security is important and so is restricting and controlling traffic that passes through your networks. Most organizations, which I have worked with, hire competent system administrators and enforce firewall policies stringently. I can hear you say, “Come to the point man”. Well if you haven’t got it already, I am talking about web application security. As Hamlet said: “Aha web apps, therein lies the rub”. It is the little window in your castled network that allows outsiders to talk to the database and the application servers. It is through this window, if unguarded, that the intruder shall enter (welcomed by your web app in fact which will also be courteous and smart enough to wish a happy new year if it happens to be the first week of January). After that, the system is at the mercy of the intruder depending on how competently the attack (for the lack of a better word) was carried out.
What prompted me to write this article is the regularity with which organizations will deploy vulnerable web applications while sticking most stringently to network security policies. We, at Imfinity, also regularly come across vulnerable web applications developed by people who seem to have significant experience. We hope this article will be useful to new developers who have never heard of things like SQL injection (yes you can safely go on and blame your University which taught you how to implement AES but never mentioned SQL injection) and also to experienced developers who can make sure that their applications are not vulnerable to things listed here. More importantly, we hope it helps managers evaluating third party software.
Web applications are the toughest to secure because most of the time their usability depends on access over the internet. The only way to completely secure an application would certainly render it unusable! What we will try here over the course of three articles is to make the intruder’s job more and more difficult. We will ignore firewalls, server updates, patches, physical security etc. and focus on the web application. We will, of course, assume your app accepts user input (if it does not then you should be ashamed of calling it a web application). It will also connect to a database of your choice though I will mention some issues specific to certain databases.
The application we will create is very simple. Let us call it the To-Do Master. The feature set looks like this:
1. It’s a system that lets you maintain a To-Do list. So users can add/edit/delete To-Do
items (belonging to the user, we wouldn’t want Mary to edit Lucy’s To-Do list).
2. If a user has administrator access then he/she can add/edit/delete users.
3. The users need to login to access the system.
4. The users can update their passwords.
We will use a database with two tables:
That describes our, not very innovative and horribly named but satisfactory enough, application.
The issues we will address are the usual suspects:
1. Futility of client-side only validation
2. SQL Injection
3. Cross Site scripting
4. Database privileges for the application
5. System privileges for the DBMS
I might digress and discuss certain other aspects of security.
The article is three-part but each of the parts should be helpful in itself. Part 1, as you read, started with a rant about the lack of importance placed on web app security and a description of a small application that we will use to illustrate the points mentioned above.
Futility of client-side only validation
JavaScript offers a fantastic way of enriching client experience. It is perfectly all right to check the user input before you send it to the server. It is faster and saves a round trip to the server. The problem occurs when we trust the input that comes from the browser.
For example: the login page for To-Do Master has a form. When we submit the form we check using JavaScript that the login contains only alphanumeric values, if not we prompt the user with an error and refuse to submit the form. On the server we assume that the input arriving from the client is only alphanumeric. What we are forgetting here is that the application can be fooled in several ways:
1. User can create a form and post us the values
2. JavaScript might be disabled on the browser
3. If our web application does not differentiate between GET/POST input then the user might simply append the parameters to the URL:
http://todomaster.com/login?login=invalid’’input&password=&*^%^%
I have met several developers who distrust any text input coming from the client but will trust input from an “HTML <select> element”. It is very easy to save the form and add more “options” to the select tag so beware of this practice. It does not matter if you use GET or POST. A client can always send the data he/she wants. Any input that you might be validating on the client should be re-validated on the server.
Come on, repeat with me and make your developer repeat it with you:
“I don’t trust client input, I don’t trust client input, I don’t trust client input”.
Great, do that for five minutes every morning for five days.
I think the article is getting close to scary lengths. So I will end it with an introduction for the next two parts:
To-Do Master was not scared of intruders. It had decided that it will follow web application security guidelines and was already looking at all client side validation with distrust. But was that all? Isn’t there anything more it can do to protect itself? What about SQL Injection and Cross Site scripting? Logon, same place and same time and take a plunge with us into this break neck roller-coaster ride of securing web applications!
Well, if you think the writer of this article deserves a compliment or two (or if you think he should be abused, vilified and never allowed to write a single line of code again) then don’t just sit there. Voice your opinion. Direct your comments, suggestions, corrections (especially), anecdotes, taunts, abuses, compliments and remarks to Tarun.
