It's a Security Issue! Practical Tips for Common Web Application Security Vulnerabilities.

This is a guest post from our partner and service provider, Cigital.

Cigital has been conducting vulnerability scans of applications using the QuickBooks API for the past few years. Though these applications are coming from different companies, we are observing the same set of issues repeatedly. This blog post points to the top HIGH severity issues we observe repeatedly in the vulnerability scans, the impact from each of these issues, and how best to prevent these issues. The top HIGH severity issues are:

1. Cross-site scripting
2. Unencrypted login request
3. SQL injection
4. Phishing through URL redirection.

Let’s now look at each of the above and understand what the impact would be from these vulnerabilities if not mitigated:

1. Cross-site scripting: Some issues are identified more than others during our reviews. One of the most commonly occurring security issues of web applications is cross-site scripting (XSS). As many of you might know, XSS is when malicious users’ input is inserted into the HTML source of the application. This might happen if the developer echoes back a URL parameter (GET) or a form parameter (POST) or some other parameter that can be controlled by the user. A malicious user can abuse this to set a parameter value to ‘<script>alert(0)</script>’ to get JavaScript running on your domain (e.g. www.example.com). The idea is to send or redirect the victim to a specially crafted URL running the attacker’s JavaScript.

   Now, what malicious things can one do with JavaScript? Great question. First, JavaScript allows one to insert/modify any of the UI elements on the web page. An attacker can fake a credential pop-up to trick a user into ‘re-authenticating’. Second, one can submit web requests with JavaScript. If we’re talking about a banking website that is vulnerable to XSS, the attacker can set values for ‘transfer to’ and ‘amount’ fields (along with whatever other parameters are required for the request to go through) and submit that to the server. Finally, JavaScript can be used to read the HTTP response from any page or resource hosted in that domain. So, if there is a sensitive document accessible only by the victim hosted at the URL (www.example.com/mySecrets.txt), an XSS vulnerability in www.example.com/anyPage can be used to steal their document. XSS can be destructive depending on what functionality is available on that domain.

   We recommend output encoding (escaping special characters) or white-list validation on the server side as a remediation for cross-site scripting.  Usually this is all that needs to be done; however, it depends ultimately on the context of the application.  Perhaps there is so much vulnerable code that it would be practical to deploy a web application firewall to temporarily fix the issue across the site while fixes are being developed. Perhaps you need to support user-generated HTML content.  Perhaps you want to allow JavaScript (in which case, it should only be allowed on a test domain with no other functionality or sensitive documents).

   We won’t talk about the other findings in detail here, but we do want to mention what the impact may be.

2. Unencrypted login request: Sending user credentials unencrypted can allow a man-in-the-middle to steal user credentials. Programs such as Wireshark can be used to sniff unencrypted packets that contain the account credentials.
3. SQL injection: An attacker can perform database operations, such as deleting tables or retrieving sensitive data stored in the database.
4. Phishing through URL redirection: If users see a URL that starts with a trusted domain, they will be likely to click on that link.  Phishing scammers will use URLs of pages that have redirection functionality to trick users into visiting a phishing site.

Now that we know the security impact from the above vulnerabilities, and understand that the cost to fix these at the deployment stage is very high compared to earlier in the SDLC cycle, the next step is to understand on how best to prevent these from occurring in the first place, and/or catching them earlier in the SDLC process.

We can have reasonable success in prevention through a combination of developer training on security as well as through technology deployed in the developer’s IDE at a minimal cost.

1. Technology plugin in the developer’s IDE: In this case, the technology would have flagged 60% of the HIGH severity issues during the code development stage with appropriate remediation guidance for the developer to fix the issues while coding. Security needs to be introduced into the SDLC as early as possible. Cigital’s SecureAssist (CSA) is an IDE plugin that provides guidance to developers  as they develop code. For instance, a developer may be writing a SQL query by concatenating user input. CSA provides a description regarding the issues introduced by concatenating user input to queries, and also provides language-specific guidance on how to remediate it using code samples.
2. Training: Training the development group is essential. Introducing the developer to industry best practices and providing them training is a key step towards developing secure code. Developing code using best practices will prevent vulnerabilities to be introduced during development. Cigital’s Instructor-led trainings and BuildSecure eLibrary provide a comprehensive set of online company-wide training, covering various languages and platforms. 
3. Our services are designed to meet the varying needs of our clients. We do understand that there are cases where the standard remediation guidance may not apply, or the developers may need to discuss an issue or remediation in detail. Cigital’s on-demand secure remediation helpdesk service provides to developers the ability to discuss individual issues with the security experts on a need basis. Once the request ticket is submitted, Cigital consultants follow up with the requester to discuss specific details and provide detailed guidance.

Pooja Garg
Senior Security Consultant, Cigital Inc.
http://www.cigital.com
Software Confidence Achieved.