Question

I recently landed on old web application which is full of old school tricks

1. GET param : user info in URL parameters
2. Session informations
3. Hidden elements used for storing information
4. HTML/JS/CSS dumped in the page. Without proper encoding. etc.
5. Window.open to show popups.
6. XSS issues etc.
7. Concatenated SQL string good for blind SQL attacks.

and just many more…

to make things work. Looks like application is old over past 5-7 years (ASP.NET 1.1) and looks like the application code has failed to keep pace with better security practices.

Thankfully it looks like over period browsers and security testing tools evolved very well. Helping people/customer to report so many security issues every now and then. Keeping them happy and system secure has become pain.

Can someone please let me know in case you have faced something similar and help me get to some case study or something for how to addressed this ? test tools which are “freely” available which can be used to test web sites for security on developer environment ? What strategies should be used to deal with this situation ? How to progress.

Answer 1

Let me start by saying this: While there are open-source and free security scanner tools, none will be perfect. And in my experience (with PHP at least) they tend to return enough false-positives that it’s barely worth running them (but that could have gotten better since I last used them). If you want to use one to try to help identify issues, by all means do so. But don’t trust the output either way (from a false-positive and a false-negative perspective).

As far as how to tackle it, I would suggest a step-by-step approach. Pick one type of vulnerability, and eliminate it across the entire application. Then go to the next vulnerability type. So a potential game-plan might be (ordered by severity and ease of fixing):

1. Fix all SQL Injection vulnerabilities.

   Go through the code, find all places where it does SQL queries, and make sure they are using prepared statements and that nothing can get in.

2. Fix all XSS vulnerabilities

   Find all places where local information (user-submitted or otherwise) is properly sanitized and escaped (depending on the use-case).

3. Fix all CSRF vulnerabilites

   Go through the site and make sure that all the form submissions are properly using a CSRF token system to protect them from fraudulent requests.

4. Fix any and all authentication and session fixation vulnerabilities

   Make sure the authentication and session systems are secure from abuse. This involves making sure your cookies are clean and that any session identifiers are rotated often. And make sure you’re storing passwords correctly…

5. Fix and information injection vulnerabilities

   You state that there is user information in URLs and hidden form elements. Go through all of them and change it so that the user cannot inject values where they shouldn’t be able to. If this means storing the data into a session object, do so.

6. Fix all information disclosure vulnerabilities

   This is related to the former point, but slightly different. If you use a username in the URL, but can’t do anything by changing it, then it’s not an injection vulnerability, it’s just a disclosure issue. Mop these up, but they are not nearly as critical (depending on what’s disclosed of course).

7. Fix the output

   Fix the encoding issues and any method that might generate invalid output. Make sure that everything is sane when it’s outputted.

The important thing to note is that anything that you fix will make the application safer. If it’s a live application right now, don’t wait! Don’t try to do everything, test and release. Pick a reasonable sized target (2 to 4 days of work max), complete the target, test and release. Then rinse and repeat. By iterating through the problems in this manor, you’re making the site safer and safer as you go along. It will seem like less work to you because there is always an end in sight.

Now, if the application is severe enough, it may warrant a full rewrite. If that’s the case, I’d still suggest cleaning up at least the big ticket items in the existing application prior to starting the rewrite. Clean up the SQL Injection, XSS and CSRF vulnerabilities at a bare minimum prior to doing anything else.

It’s not an easy thing to do. But taken a small bite at a time, you can make significant progress while staying above water… Any little bit will help, so treat the journey as a series of steps rather than a whole. You’ll be better off in the end…