A zero-day vulnerability is announced for one of the Web applications that you run. You rush to test and install a patch and all seems fine; problem solved, crisis averted and the boss is smiling again.
But I'd put money on the fact that you only tested that the Web application patch did what it was meant to do: fix the zero-day vulnerability. You most likely didn't test to see if it did anything it shouldn't have. Perhaps you checked that the Web app was running correctly, yes, but nothing more. Likewise with application upgrades, you may test the new features, but may not bother checking that the existing features still work securely. And that's how security holes can start to appear in websites that were initially secured.
Your initial Web application hardening and configuration is based on the known vulnerabilities and best practices at the time of setup. So whenever updates are made to an application or the operating system that it's running on, or the business logic in an application changes, it's important to repeat your security assessment in order to evaluate the impacts of any changes on the application's security.
In fact, a reassessment is such an important aspect of maintaining application security that the Payment Card Industry (PCI) Data Security Standard (DSS) Requirement 11.3 requires you perform external and internal penetration testing, including network- and application-layer penetration tests, at least once a year as well as after
Continue Reading This Article
Enjoy this article as well as all of our content, including E-Guides, news, tips and more.
The rate of change in Web application code is normally quite high, and the new code rapidly reduces the relevance of existing security assessments. The recent revelation that the search box on the MI5 website was vulnerable to both cross-site scripting (XSS) and to IFrame injection, for example, may well be the result of a lack of thorough testing when part of the application was upgraded or even when the Google search engine functionality was added.
Cross-site scripting attacks inject malicious code into webpages and can be used to steal data, take control of a user's session, and run malicious code. They are often used in phishing attacks and, according to a report from Symantec Corp., XSS is the most popular form of attack on Web applications. Like many application-layer threats, cross-site scripting works by passing data designed to masquerade as legitimate application code through normal request channels, such as URLs or form data. It is important to check for the most common vulnerabilities that make Web applications susceptible to XSS attacks:
- Failure to constrain and validate input.
- Failure to encode output.
- Trust of data retrieved from a user, database or cookie.
A simple test to see if your website is vulnerable to a cross-site scripting attack is to enter the following code snippet into a form field and submit the form:
<script>alert("Vulnerable to XSS");</script>
If an alert window pops up with the "Vulnerable to XSS" message when the form data is processed and displayed, then the application accepts tags and is at risk because the input data has not been validated either before being processed or being published.
However, this type of test is not practical for large sites which have many input paths. Here you should look at using automatic source code scanning tools and Web vulnerability scanners. A good Web vulnerability scanner will spot common technical vulnerabilities, such as cross-site scripting vulnerabilities, SQL injection flaws, parameter tampering, hidden field manipulation, backdoors, debug options and buffer overflows.
When choosing a scanner, a good place to start is the Web Application Security Scanner Evaluation Criteria, a set of guidelines to help evaluate Web application security scanners on their ability to identify Web application vulnerabilities.
In my next few articles, I will be covering XSS and other injection-based attacks in more detail. We'll look at how they work, what damage they can do and, of course, how you can prevent them with better application design, construction and maintenance.
This was first published in October 2009