Interactive Application Security Testing (IAST) Tools

The security industry started on security testing automation journey almost a decade ago! First there were Static Analysis Security Testing (SAST) Tools and then there were Dynamic Analysis Security Testing (DAST) tools. Neither tools lived up to the expectations for various reasons, but primarily due to the large number of False Positives in SAST tools and difficulty automating DAST tools that require manual intervention needed to train the tool and triage results. Contrast Security was one of the early pioneers in a new space called Interactive Application Security Testing (IAST) to fill this gap! In this post we will discuss IAST tools and what they bring to the table.

Effectiveness of IAST Tools Over SAST/DAST Tools

IAST tools look to combine the best of what SAST tools and DAST tools offer, but with out the baggage these tools bring with them. The basic principle of IAST tools is that you configure your application with an IAST agent that can track the request from its “source” to the “sink” and determine is there is a vulnerability in the path due to a missing Sanitizer or an Encoder.

The agent is configured at the Runtime and has better context of the execution than a SAST tool and this allows IAST to provide better results with lower false positives compared to a SAST tool. Unlike DAST tools ISAT tools do not drive the application, but depend upon automated functional test cases or manual testing to drive the application and the agent runs in the background identifying vulnerabilities in the execution path. However, this is also a drawback of the IAST tools, in the sense that if you do not have sufficient test coverage either through automated testing or manual testing the effectiveness of IAST would be limited as the agent can only see the code that is executed. The agent does some analysis at startup, but the results you get there are comparable to what SAST tool provides. So, if you are planning to get an IAST tool, make sure that you have sufficient test coverage for your application either through automated or manual functional testing.

Does IAST eliminate manual pen testing?

This is a frequently asked question from senior management when you recommend big investment on any security tool including IAST. Although IAST offers significant improvements over traditional SAST or DAST tools, the tooling is not there at the moment to completely eliminate manual pen testing. Yes, the tools are much better now at identifying certain category of application security vulnerabilities such as XSS vulns, Injection vulns, Open Source Software vulns etc., but the tools are not able to identify vulnerabilities in business logic, back doors in the code, privilege escalation type of attacks etc. The way to look at the tools is to help you catch low hanging fruit so that you can free up pen testers to focus on more complex attacks on your applications! You need to augment security testing tools with robust code reviews and focused pen testing to fortify your application security!

Commercial IAST Tools

  1. Contrast Security is the leader in this space! Contrast has been on this journey longer than others and have improved their capabilities, language/framework coverage over the years. Contrast Security seems to check off on most of the capabilities you look for in a security testing tool! Contrast does a good job of identifying vulns in the Open Source Software (OSS) you use in your application. In addition to identifying OSS vulns, the tool would identify if you are using that component in your application. About 80% of the Open Source Software you include in your application is dead weight and is never used! So, having tool that would help you identify if you are using a vulnerable OSS component is a big win for prioritizing fixes for your OSS components!
  2. Seeker from Synposys is another IAST tool for you to consider! Seeker differentiates itself in this space by not only identifying a vulnerability, but also actively tries to exploit the vulnerability thus eliminating any false positives reported by the tool. The advantage with Seeker is that it is part of Synopsys that offers broad range of security testing tools: Coverity for SAST, BlackDuck for OSS scanning, Seeker for IAST. As Synopsys integrates these products and matures the platform, you will have single pane of glass for vulnerabilities reported across SAST, DAST, OSS, and IAST tools. Isn’t that an appealing proposition?
  3. Veracode and Checkmarx are on the early stages of building out IAST capabilities on their platforms. Watch out for updates from these vendors. The competition will only make the products better and will be win-win for the Consumers!

Trust, but verify your IAST Tools!

IAST is a Runtime tool, so you must verify that the agent is compatible for the languages, frameworks and libraries that you use including the specific versions that you use. Unlike a SAST tool where you may get partial coverage depending on how much code you throw at the SAST tool, IAST tool may be “all” or “nothing” if the tool is not able to detect “sources” and “sinks” in the versions of languages/frameworks that you use. So, it is imperative to evaluate the tool within your environment!

In Conclusion

If you budget for only one testing tool Test, I would strongly encourage you to consider IAST! But also be aware of the pitfalls of IAST:

  • Verify the tools in your enviroment for the languages/frameworks and the versions you use
  • Make sure you have effective test coverage in your organization via automated or manual pen testing. IAST is only as good as the test coverage!

 

Advertisements

Automated Security Test Cases

A paradigm shift in security testing

Let me propose a radical new idea: Implement security test cases to test security controls in your application similar to how you test functional requirements. Yeah, I know there is nothing radical about it and this is not a new concept. But, lot of organizations have accepted Test Driven Development (TDD) practice and are extremely good at automating testing of functional requirements, but when it comes to security testing, it is still being offloaded as a point in time assessment to the security teams. Lets try to make automated security testing as common as implementing test cases for functional testing! Are you with me on this?

Benefits of implementing security test cases

  1. Build secure coding practice in the Development teams and makes them aware of security vulnerabilities and their remediation.
  2. Over a period of time, you build a strong suite of security test cases that get executed continuously in a pipeline providing continuous security assurance as opposed to point in time assessments.
  3. Security tools can’t detect logic and functional security vulnerabilities such as what roles are required to execute a capability, if there are authorizations based on dollar amounts, user registration flows etc.
  4. Most importantly this is “free” as in there is no licensing costs for expensive application security testing tools out on the market that at the most provide partial coverage and effectiveness compared to manual security assessments. I put “free” in quotes because you still need to expend time to implement security test cases.

What are common security test cases to implement?

Please see below for some examples of automated security test cases to implement across various categories.

Authentication test cases

  1. Verify that you are not able to login with invalid credentials
  2. Verify that you are not able to bypass multi factor authentication steps
  3. Verify that account is locked after 3 tries
  4. Is access to secure end points limited to authenticated users?
  5. Is the timeouts of authentication tokens working as expected?
  6. Is logout working as expected?

Authorization test cases

  1. Is access limited to users that have certain Role?
  2. Authorizations based on thresholds, verify is access is limited based on business logic rules
  3. Can the user assume a Role that they are not assigned to by sending a role on the request?
  4. Is the user authorized to access the object referenced in the URL? This is significant for REST end points where as best practice, IDs are specified in the URL. For e.g. if you have REST end point to retrieve account information, /rs/account/123456789, verify that the authenticated user is authorized to access account 123456789 as the end user can easily manipulate the account number to somebody else’s account number. This is called Direct Object Reference Vulnerability.

Input Validation and Output Encoding test cases

  1. Does the system reject invalid or malicious inputs?
  2. Is the system encoding user inputs before persisting to a sink? For e.g., sending in data containing SQL Injection pay load.

CSRF Protection test cases

  1. Verify that you are not able to perform state changing operations with out a CSRF token in the request

Miscellaneous test cases

  1. Verify is data is encrypted in transit with the use of https protocol
  2. Verify that TLS Certificate is valid
  3. Verify if “secure” flag and “http only” flag is set on cookies that contain sensitive data

How to implement security test cases?

Now that you are convinced to implement security test cases, how do you go about implementing them? There is no secret sauce to security test cases, Developers can use commonly available Open Source testing frameworks such as Selenium, Cucumber, JUnit, Mockito, Jersey Test Framework etc. for implementing security test cases. There are some open source projects such as Gauntlt that can give you a head start in implementing security test cases. In a future blog, I can provide some sample Cucumber test cases to demonstrate how easy it is to incorporate security testing in to your applications!

SAST: Static Code Analysis to identify Security Vulnerabilities

What is SAST?

SAST stands for Static Application Security Testing. Before ShiftLeft became fashionable, security companies were thinking wouldn’t it be better to identify security vulnerabilities while the Developer is writing the code as opposed to later in the process. What a futuristic thought?

Static Application Security Testing (SAST) tools analyze source code or compiled code to identify security vulnerabilities. The intent of SAST tools is to Shift Security Testing to the left and allow Developers to scan code, identify and fix vulnerabilities during the software development process. SAST solutions have been available in the industry for 10+ years. Fortify, AppScan, Checkmarx, Veracode are some of the leading commercial SAST providers. There are mature Open Source tools and frameworks such as SonarQube, FindSecurityBugs, PMD, that have plugins/rules to scan for security vulnerabilities and the tools allow you to implement custom rules applicable for the software languages and frameworks used in your organization.

How do SAST tools analyze the code?

SAST tools are very effective at identifying the use of insecure APIs.  For e.g.,

  1. Use of Dynamic SQL that could lead to SQL Injection vulnerabilities
  2. Insecure use of Encryption & Hashing APIs such as the use of weak encryption and hashing algorithms
  3. Information disclosure with logs and stack traces emitted to stdout, stderr
  4. Use of deprecated APIs that are vulnerable

The commercial SAST tools provide deeper analysis by building Data Flow Analysis wherein the tools build a model of untrusted inputs from Source (say HTML Form) to a Sink (say a Database). SAST tools than analyze the Data Flow models to identify if the untrusted input is properly sanitized with input validations and output encoding to defend against Injection and XSS type of attacks. The tools allow you to customize the sanitizers to account for your custom libraries to whittle down false positives.

The SAST tools either consume raw source code or Binary code for analyzing the code.

Open Source Tools are very good in identifying vulnerabilities in the first category but fall woefully short in doing complex Data Flow Analysis that span multiple modules.

Coverage and Effectiveness of SAST Tools

The advantage of using SAST tools is that they offer coverage across many categories and industry standards such as OWASP Top-10, SANS 25, PCI DSS, HIPAA, CWEs etc across many languages and frameworks. Some organizations use SAST as a mechanism to be compliant with regulatory requirements such as PCI DSS.

Most of the tools have coverage for Java, JavaScript, .NET, Mobile (iOS & Android), Python, Ruby etc. and the vendors keep adding support to new and upcoming languages such as Go.

You can think of SAST as offering coverage that is mile wide but only an inch deep! The tools are very noisy and produce false positives. Don’t be under the impression that you can drop these tools in your environment and run them on autopilot! This will only drive Developers away from adopting these tools and lose goodwill with them! You need to spend time and resources training the tools by creating customizations that apply for the languages, frameworks that are used in your organization! For e.g., if you have custom input validators, you need to train the tool to recognize these validators or else the tool would report false positives in injection vulnerabilities.

SAST Tools Evaluation Criteria

Given the number of commercial tool vendors, what are some of the considerations for evaluating and selecting a SAST tool? I would rate the tools based on the following criteria:

  1. Does the tool cover the languages and frameworks used in your organization?
  2. Does the tool cover industry vulnerabiltiy categories such as OWASP Top 10, SANS 25, PCI DSS etc?
  3. Is the tool customizable to limit false positives being reported?
  4. Does the tool provide mitigation guidance and is the guidance customizable?
  5. Does the tool integrate with Build Pipeline to automate static analysis during Build time and fail the build if based on preset policies?
  6. Does the scan performant? Especially, if the tool is integrated into the pipeline, the scans have to be performant. Does the tool allow incremental scans to speed up the scans?
  7. Does the tool have an IDE plugin that integrates with the Developer IDE and allows the Developer to scan code during Development and consume the scan results from your Build Pipeline scans?
  8. Is there a usable dashboard and reporting capability that allows your Security team to identify vulnerable applications and work with the application teams to mitigate the vulnerabilities?
  9. Does the vendor offer on-demand training or coaching is the Developer needs further assistance?
  10. Does the tool integrate with Bug tracking systems such as Jira and productivity tools such as Slack or ChatOps?
  11. Does the tool integrate with your Authentication and Authorization systems?

The vendors demonstrate their tools with readily available vulnerable applications such as WebGoat. OWASP Benchmark project also provided a suite of test cases and code to help evaluate these tools. The project also ranks open source SAST tools and commercial SAST tools although they do not call out the commercial tools due to licensing constraints.

In my opinion, the tools are highly tuned to work for test apps such as WebGoat and the best way to evaluate a tool is to throw a variety of applications that you have in your organization against the tool and see what you get!

In Conclusion

Given the coverage and effectiveness shortfall associated with SAST tools, is there a place for SAST tools in your Development process? I believe there is value in having SAST tools in your arsenal. But, instead of looking at SAST tools as the be all and end all, I would consider using SAST tools as guardrails that can help Developers avoid common security anti-patterns and adhere to secure coding practices!

If your organization does not currently use SAST tools, there is no reason for not adopting Open Source Tools that are free and make them available for your Developers today!

 

 

Newest OWASP Top 10 Release Candidate List is Out

OWASP Top 10 is updated every 3 years and the latest 2016 Release Candidate list of OWASP Top 10 Vulnerability Categories list is out. There two new categories of vulnerabilities that were added and that is the focus of this Blog Post.

OWASP Top 10 Project team added the following two new categories to the list:

  1. A7 – Insufficient Attack Protection
  2. A10 – Underprotected APIs

Lets talk about these two.

A7 – Insufficient Attack Protection

This category suggests that most applications have insufficient Preventive, Detective and Corrective Controls built in to the applications. Does your AppSec team provide common libraries, frameworks and services for Authentication, Authorization, Input Validations etc.? Do these frameworks log Security events if someone tries to circumvent these controls? Do you have actively monitor for these errors and respond if you receive alerts on these events? Are your applications self healing if they detect an attack in progress? These are some of the questions that this new category prods us to think.

As in most organizations, they rely upon Developers to implement sufficient Logging to be able to Detect malicious activity. But more often than not, the organization that does the monitoring is separate from Development Organizations and most likely are not aware that they need to monitor and respond to these Application Security Events. Most of the times, the monitoring and alerting is only at the Network and Infrastructure layers and not at the App layer. Hopefully, having this new category allows organizations to fortify SOC monitoring to include Application Security Alerts for monitoring.

There are a few critiques of this new category, especially, as this category proposes including a RASP (Realtime Application Security Protection) in your application stack that can detect and protect in real time as the exploit is in progress. The reason being the this category proposal came from Jeff Williams, the co-founder of Contrast Security, that offers RASP capability. Is there a conflict of interest? May be. But, does that stop me from exploring this new category and looking at ways to get better at application security? Definitely not.

I am not endorsing the criticism, but here is one such post to learn about the controversy on A7 – Insufficient Attack Protection. But, who does not like some drama in their chosen field?

http://www.skeletonscribe.net/2017/04/abusing-owasp.html

A10 – Underprotected APIs

If you do not have APIs in your organization, you must be hiding under a Rock or accidentally hitched on to the Mars Rover looking for Alien life. APIs are every where. Every company worth its salt is embracing micro-services architecture. So what is the problem?

All the OWASP Top 10 vulnerabilities typically associated with Web Applications apply to APIs as well. All APIs need to be Authenticated, Authorized, etc. etc. But, one area that we see vulnerabilities is Insecure Direct Object References, where Resource Ids are exposed in the URIs and an attacker can change the Resource Id to see if they are able to get to Resources that they are not authorized for. For e.g., if you have an API to retrieve your bank account information and the API is, /rs/account/{id}, an attacker will enumerate this API with different Account Ids to see if they accidentally get access to someone else’s account information. This is Insecure Direct Object Reference. Does the Authenticated user has access to the Resource being requested, in this Account information referred to by the Account Id, is Business Logic and it is very hard to verify outside of the context of your application.

How do mitigate this vulnerability?

API Developers needs to implement what we can call Data Level Authorization checks in the application code. Does the authenticated user has access to Account Id “xyz” check needs to be implemented before any Account information is sent back to the user. This check may vary based on the Resources and APIs that you deal with and needs to be built with in the context of the application.

Please share your thoughts on what you are seeing as your organization adopt APIs and Micro-Services architecture.

Authorizing Access to Data Embedded in REST APIs

Is your REST API vulnerable to Direct Object Reference Attacks?

Designing Client applications using HTML/JavaScript/CSS that call REST APIs to retrieve data is an architecture pattern that lot of companies are adopting these days. In the blog post, I will address a common security vulnerability that the developers expose their applications while implementing the REST APIs.

Lets say you have are building a REST API for your Banking and implement the following REST APIs:

  1. API to retrieve account balances – http://api.yourbank.com/rs/account/{account_id}/balance
  2. API to transfer money – http://api.yourbank.com/rs/transfer/from/{from_account_id}/to/{to_account_id}/amount/{amount}

Although it seems simple enough, the Developers do not verify that the authenticated user (the user logged on) has authorization to operate on the accounts being specified in the API calls. There could be different reasons for this missing security control:

  • Under the covers the API is using legacy code to implement the functionality and the security checks were done in legacy UI that was calling the legacy mid-tier. So, when the Developer is implementing REST API, they are not accounting for the authorization check and are relying upon the UI to enforce the check.
  • The Developers might be under the impression that the user can not change the data in the URL as there is no input from that allows them to control the data as it is displayed as an HTML link on the page. This line of thinking applies to other inputs that could be submitted on the payload such as Cookies, Headers, Query Params, Hidden Inputs, Path Params etc.

In Security, this is called Direct Object References and directly conflicts with REST Design principles to have Unique Ids for Resources. Hence, it is a must that REST API Developers must implement authorization checks on any Ids that appear on the APIs to ensure that the authenticated user (Logged on user) has authorization to access data embedded in the REST APIS.

How to mitigate this vulnerability?

The solution is custom for the API that you are implementing as this is data specific to your use case. The authorization checks could be done at the entry point to your APIs or with in each API to verify that the authenticated user does have access to each data element embedded in the API. For e.g. in the above API calls, verify that the logged on user has access to the Account Id specified in the API call.

Frameworks such as Spring Security, makes this very easy by applying authorization annotations on your REST end points.

The code implementing “Get Balances” REST API could have authorization annotations such as:

@PreAuthorize("hasPermission(#account_id, 'view_account')")
  public Double getBalance(@PathParam("account_id:) Double account_id);

TBD: Reference application that shows implementation details is soon to follow. Please say tuned.

Please suggest frameworks for other languages that you are familiar with.

Verification

Implement test cases to verify that the controls is working as expected and is preventing unautjhorized access to resources specified in the API/URI.

TBD: Reference application that shows implementation details is soon to follow. Please say tuned.

Additional Resources

https://www.owasp.org/index.php/Top_10_2013-A4-Insecure_Direct_Object_References