During the code review process for an ASP.NET web application that we built for a client, a cross-site scripting (XSS) security scanner was used to check whether the application was secure enough to survive during XSS attacks. Fortunately, the application was well designed and coded leaving no chance for the scanner to inject even a single line of script for XSS attack. Alright, I will be honest with you – we did found a couple issues during the scan, but we were able to fix them before the application was delivered to our customer. So, here are the two notes I would like to share:
- Watch out for those non-ASP.NET components. Actually, all ASP.NET components were designed very well and the scanner was not able to inject any script on any page. The only problem we found was on the error page which accepts some parameters in the query string and displays part of the information on the error page which is a fairly common implementation. Because it is simply an HTML page and does not contain server-side code, it was overlooked for XSS attack. The scanner was able to embed scripts in the query string, and had them executed when the error page tried to render them on the page. Although the error page cannot post any data back to the ASP.NET application itself or insert any data to the database, it is still a security risk. You never know what hackers can do with this small hole in your site.
- DO NOT perform the scan on production database. We performed the scan on our QA environment assuming it would not do any harm to our database because it was only for XSS scan. However, we have found that it entered thousands of records in a table in our database through a page which only requires one field for data entering. As a result, the scanner tried all possible injection scripts on that page, and entered them all into the table in the database. Now, we have a list of scripts we can try on other sites to have some fun. : ) So, I guess we shouldn’t have done this in the QA environment which points to our production database. Even if we had to do so for whatever reason, we probably should have pointed the application to a test database for the duration of the scan.
