Building an app integration with QuickBooks® comes with serious responsibility to protect the data and privacy of QuickBooks customers. If your app is popular (more than 500 QuickBooks customers are attached) or is listed on the QuickBooks app store, Intuit® will conduct its own security scan of your app, annually. We asked our friends at Synopsys, the company that manages the security review process for us, to provide some advice and tips on how to best prepare your app to comply with security requirements.
The following is a guest post by Tom Stripling, managing principal at Synopsys Software Integrity Group.
As the company that has managed hundreds of vulnerability scans over many years, we have extensive knowledge working with applications that use the QuickBooks API. Even though applications come from different companies and provide different functionality, we observe many of the same issues repeatedly, some of which pose a high risk to the applications and their data.
Here are the top high severity issues we come across:
- Stored Cross-Site Scripting (XSS)
- Cross-Site Request Forgery (CSRF)
- HTTPS Not Enabled
- Verbose Error Messages
Let’s examine the impact of each of these vulnerabilities.
Cross-Site Scripting (XSS)
The most commonly identified issue we come across is Cross-Site Scripting. XSS, which occurs when a malicious user is able to cause JavaScript or other active content to be executed by another user. This can take two forms:
- Reflected XSS occurs when the application echoes back a URL parameter (GET) or a form parameter (POST) that comes from user data. An attacker can craft a URL or POST request that contains malicious data in this parameter, causing JavaScript to be executed when the user follows a link (POST-based attacks require an extra step but are still possible).
- Stored XSS, on the other hand, is stored in the application database and executed whenever the data is displayed. So, an attacker could potentially poison one parameter and have the attack executed multiple times by many victims as they view the poisoned data.
Once malicious JavaScript is running in the victim’s browser, all bets are off. JavaScript is very versatile and can do many things. It could attempt to capture the user’s login credentials by popping up a window asking users to re-enter them. It could also retrieve pages and submit forms on behalf of a user. In fact, any sensitive data the user can view is up for grabs. Likewise, any changes the user can make, such as sending money in a banking application, are possible via JavaScript unless other protections are in place.
Cross-Site Scripting is possible when applications don’t properly sanitize data before returning it to the user. Sanitization takes two forms: input validation and output encoding:
- Input validation is the process of validating assumptions about data before using it. If something is supposed to be a first name, I shouldn’t be able to put <script> tags into it.
- Output encoding, arguably the more important of the two, is the process of replacing dangerous characters with safe values. So <script> might be turned into <script>. The correct form of output encoding depends on the context in which the data is being used; often HTML encoding or URL encoding is appropriate.
Cross-Site Request Forgery (CSRF)
Cross-Site Request Forgery is another common finding. CSRF forces a user of the application to execute unwanted actions on a web application to which they’re currently authenticated. If an attacker can get a user to follow a specially crafted link, they can trick victims into performing actions of the attacker’s choosing. For most users, this means things like changing email addresses or (again) sending money in a banking application. For administrators, the results are often far more severe.
The difference between CSRF and XSS is that in CSRF, encoding your data won’t help you. The attack exists because the application is accepting input from a user without verifying where that data came from. The typical fix for this is to require a two-step process for sensitive forms. In the first step, when the form is displayed, a secret token is added. In step two, when the data is processed, the secret token is checked. This prevents attackers from skipping step one and crafting malicious URLs that take users directly to step 2 and change data.
HTTPS Not Enabled
Some sites still don’t require HTTPS. While this is fine for static sites, any application with a login or that provides sensitive data should require HTTPS on all pages. Without encryption, any attacker on the same local network as a user could read data between the user and the application. Anything sensitive the user sees, so does the attacker.
Verbose Error Messages
Error messages that provide too much information are a great way for attackers to perform reconnaissance against the application. Stack traces in particular provide a wealth of information for potential attackers by revealing how your application is architected. This type of information is valuable for attackers seeking to craft custom exploits against your application. It’s important to ensure that all application exceptions are caught and properly handled.
These vulnerabilities can be addressed by using the remediation actions above, but organizations can also take proactive steps to prevent them from occurring in the first place. Some of these are listed below:
Training: Providing training to the development group decreases the number of security bugs that are introduced by raising the bar of security knowledge. More security-aware developers are more aware of the existence and impact of security issues and thus are less likely to write them into their code. Synopsys’ Instructor-Led Training (PDF download) and eLearning Library provide comprehensive, role-based curricula that provide not only a security baseline for all employees, but include learning plans for each employee to pursue additional education based on their individual roles and interests.
Static Analysis (SAST): Static analysis can detect many potential vulnerabilities in the development process before the code goes live. Synposys’ Coverity is a fast, accurate, and highly scalable static analysis solution that helps development and security teams address security and quality defects early in the software development lifecycle, track, and manage risks across the application portfolio, and ensure compliance with security and coding standards.
Services: Outsourced security services can include tasks such as penetration testing, source code review, open source security review, and others that are vital to the creation of secure software. Synopsys Application Security Services provide all of these and more. If you’re not already performing these tasks internally, using external security services is a great way to fill the gaps in your secure SLDC. Third-party testing can also provide a measure of confidence in your product or service due to the assurance of having an external partner validate your security profile.
Editor’s note: We hope this information is useful to you and helps you in development. As always, contact us if you have any questions.