Introduction
Those of us in the cyber security community strongly counsel for the inclusion of security considerations throughout the product and application development lifecycle; for instance, by adopting secure coding practices. Despite such good advice, many firms ignore security issues until the last minute. Sometimes we end up assisting these firms in securing their applications—or attempting to do so, at least—late in the product's development lifecycle. Even when under the restrictions imposed by going live soon, we can still take steps to ensure the security of the web application. Using a case study, this article illustrates some last-minute steps that are available to improve security measures, even at the eleventh hour.
Call for Help
Via email over a social networking site, we were contacted by a firm that was looking for a company to perform external attack and penetration testing. We responded by indicating that we did that type of work, and we would be happy to assist in any way. In a subsequent conference call, we learned that this firm had developed a web application that was going live within two weeks, and that they wanted to ensure that all security issues were addressed before going live.
In general, we would suggest performing a vulnerability analysis and secure code review against the source code and hosting environment, to identify both software and hardware vulnerabilities that may allow an external agent to compromise the application, access and inappropriately edit user profiles, and/or alter the application's functionality. We also would suggest an external penetration test to verify the vulnerabilities discovered and to identify process and business practices that may be susceptible to compromise.
In this case, however, the closeness of the announced launch date limited our options in assessing the application's security posture. The overall security assessment process would have to be completed in less than ideal time, which meant that we likely would have to limit time spent on researching the application and identifying vulnerabilities. Time for a true security code review was also insufficient. Further, extra caution would be needed for any penetration testing, to ensure that it would be nondestructive. In nine out of ten cases, pen tests are nondestructive; however, as the application was going live within two weeks, there really was no recourse for harming the code, breaking the system, or in any way altering the functionality of the application, so extra caution was warranted on that front as well.
Testing Plan
Given these restrictions, we suggested performing a comprehensive and automated vulnerability scan, along with an external penetration test against the hosted web application and the supporting network infrastructure. While this solution wasn't perfect, it would provide solid information on the security posture of the environment and actionable recommendations on additional measures (as appropriate) that could augment the existing level of security.
Our efforts would certainly include scanning for the Open Web Application Security Project (OWASP) Top Ten security vulnerabilities, including SQL injection, cross-site scripting (XSS), and cross-site request forgery (CSRF), as well as typical network-based vulnerabilities including open ports and insecure services.
The information we require from the web application is the public IP address and/or address range to target. Given the short timeframe for testing, we received additional information about the application that wasn't strictly required, but could help focus our investigation into the application and the search for vulnerabilities—such as the supporting operating system, database, hardware, and programming language used. This additional information saved some time that we would normally spend in the vulnerability analysis, footprinting, and research stages. We also selected a mutually convenient time and asked the client to inform their staff as well as their hosting provider of the scheduled time for the penetration test.
Testing and Findings
We performed the testing after work hours as specified. Over the following weekend, we held a conference call with the client to convey our findings and recommendations. We did this over the weekend and by phone because of the time crunch. There's no problem with reporting results in this fashion, but we usually prefer to complete at least a brief written report when sharing results with clients.
Our main findings were as follows:
- Cross-site scripting and SQL injection vulnerabilities. Both XSS and SQL injection vulnerabilities were identified, even though the client claimed to have followed secure coding practices and performed a security code review on the application source code. Indeed, they probably did do what they claimed; however, these vulnerabilities have become almost ubiquitous in today's computing environments, and the fact that they pop up even after a secure coding effort is not surprising or even uncommon.
- Lack of an intrusion-detection and/or intrusion-prevention system (IDS/IPS). This is the hosting provider's responsibility, according to information we received from the client. In other words, the client expected that the hosting provider would deploy an IDS to secure the servers hosting their web application.
Recommendations
To address the identified vulnerabilities, our recommendations included the following steps:
- Implement an intrusion-detection system with rules to identify XSS and SQL injection.
- Perform a code review.
- Perform log analysis.
Let's look at these steps in detail.
Step 1: Implement an Intrusion-Detection System
Given that the client's go-live date was in a matter of days, with clearly no time (or management interest) in delaying launch in order to complete a more thorough code review, we suggested taking measures to detect and filter such attacks by deploying an intrusion detection/prevention system, such as the Snort IDS/IPS, with specific regular expressions (regex) designed to identify these attacks.
For example, the Snort regex for a simple XSS attack is as follows:
/((\%3C) <)((\%2F) \/)*[a-z0-9\%]+((\%3E) >)/ix
This can be added into a Snort rule as follows:
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"NII Cross-Site Scripting attempt";flow:to_server,established; pcre:"/((\%3C) <)((\%2F) \/)*[a-z0-9\%]+((\%3E) >)/i"; classtype:Web-application-attack;sid:9000; rev:5;)
A paranoid regex for XSS attacks:
/((\%3C) <)[^\n]+((\%3E) >)/I
This signature identifies for the opening HTML tag (or its hex equivalent) followed by one or more characters other than the new line, and then followed by the closing tag (or hex equivalent). While in some cases the expression has been seen to produce a small number of false positives, it is virtually assured of identifying a cross-site scripting attack.
The Snort IDS can also be used to identify SQL injection attacks through a collection of regular expressions and Snort rules, including but not limited to the following:
Regex for detection of SQL meta-characters:
/(\%27) (\') (\-\-) (\%23) (#)/ix
It's added into a Snort rule as follows:
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"SQL Injection - Paranoid"; flow:to_server,established;uricontent:".pl";pcre:"/(\%27) (\') (\-\-) (%23) (#)/i"; classtype:Web-application-attack; sid:9099; rev:5;)
Regex for detecting SQL injection attacks on a Microsoft SQL server:
/exec(\s \+)+(s x)p\w+/ix
Regex for typical SQL injection attacks:
/\w*((\%27) (\'))((\%6F) o (\%4F))((\%72) r (\%52))/ix
Regex for detecting SQL injection with the UNION keyword:
/((\%27) (\'))union/ix (\%27) (\')
Additional expressions can be written for other SQL queries, including SELECT, INSERT, UPDATE, DELETE, DROP, and so on.
Installing the IDS with these rules will help to identify attempted cross-site scripting and SQL injection attacks, adding a layer of defense against these vulnerabilities. This possibility also presents an additional issue we haven't discussed thus far: When hosting your application and your data in the cloud with a hosting provider, it's often overlooked that suddenly your security practices and policies must be implemented and followed by at least two parties—both you and the vendor.
This level of coordination can be difficult to achieve and hard to verify on an ongoing basis. By asking the vendor to deploy certain IDS rules (as opposed to simply asking the vendor to deploy an IDS), you're implicitly asking the vendor to follow and adopt your security practices. Further, making a request this detailed and specific increases the likelihood that it will be followed.
Step 2: Perform a Code Review
The next recommendation involved actually performing the security code review. While there wasn't time to do it before going live, this step was strongly recommended for any web-based application at least once per year, and whenever changes to the application source code are made.
A code review to identify and change all instances of XSS and SQL injection is the primary means to remove these vulnerabilities. In addition to detecting the vulnerability through an IDS, we recommended a full security code review in the near term, such as within six months and/or prior to releasing any version upgrade of the software.
Specifically, the code review ensures the proper filtration and validation of all user-supplied data, as well as the encoding of all user-supplied data to prevent inserted scripts from being sent to end users in an executable format.
Input validation checks must include more than the default ASP.NET validation controls. The validation of user-supplied data involves verifying that input matches the strictest definition of valid allowable input. (It also implies that the universe of valid user-supplied inputs must be tightly defined.) User-supplied input should be limited to alphanumeric characters and, where necessary, support only a small set of identified HTML tags (such as boldfacing, italicizing, underlining), and only if strictly necessary.
Step 3: Perform Log Analysis
Checking the database access logs, server access logs, and transaction logs on a regular basis, such as monthly, will help you to understand the normal behavior of the network. Having a log analysis tool also allows you to keep up with the pace of log generation, scanning the logs on an ongoing basis while focusing on the truly critical events that need to be examined. This is another recommendation that may not be implementable in the short term; however, it should be strongly considered within the first six months.
Conclusion
In this example, the hosting provider had informed the application developer that the provider would implement the Snort IDS; however, the provider had not done so by the time of the security review—which was just before the go-live date. If it wasn't in place by then, there was a very good chance that it wouldn't have been in place when the application went live. The moral is that, while we'd like to believe what hosting providers tell us, "the proof is in the pudding," as my tenth-grade English teacher used to say. We need to push our providers on these points, ensuring that hosting providers deploy the security measures they promise.
Even if you have just a little time left before deployment, you can still take steps to improve security. This approach isn't ideal—security should be built in from the beginning—but conducting a security assessment at any point offers some value. In this instance, the client was able to push the hosting provider to install an intrusion-detection system with specific rules meeting the client's needs, as another layer of defense against the identified vulnerabilities.
One final comment on security: To become accepted and integrated, cyber security cannot remain an obstacle to business operations. It needs to be a means of enabling the operations of a business. It's security's role—and the role of the security officer—to find a way to allow operations to go forward, and even to streamline operations in a way that allows them to be safe.