Error Handling: Prevent Information Disclosure

Are your developers handling unexpected server side errors? If server side error handling is weak, attackers can gain insights in to the technology stack being used in your applications and use that information to exploit known vulnerabilities in the technology stack as reported on National Vulnerability Database (NVD).

Typically un-handled server side errors bubble up as stack-traces, default error pages disclosing web server/app server names, version numbers etc. If an attacker were to know that your application is using Apache Structs 2, the recent OS Command Injection vulnerability disclosed in Apache Structs2 provides an easy attack vector for an attacker to compromise your application. Why would you let anyone know that you are using Apache Struts with lax error handling?

What are the common techniques used for error handling in applications?

Exceptions can happen in any tier of your application – UI/Mid-tier/Data-tier. Typically any modern language offers try/catch/finally to handle exceptions. Also, the web tier offers configuration to handle any uncaught exception and display generic error messages when un-handled exceptions are raised in code. Although configuring the web tier to handle un-handled exceptions provides you the safety net, educate your developers to handle exceptions in all tiers of the code. In addition to helping prevent information disclosure, having  proper exception handling logic allows your application to gracefully fail and provide debug information in the logs to help you triage those stubborn issues that typically only happen sporadically in production environments.

OWASP also provides guidance on exception handling that is worth giving a quick read.

No body wants to see stack-traces reported on their web sites, which is a bad user experience, but on top of that you are providing valuable information to attackers. This is an easy one to fix with proper education to your Development teams !

 

Advertisements

CSRF Defense for REST API

What is CSRF?

CSRF stands for Cross Site Request Forgery. Let us say you are on your Bank Web Site, logged on and paying your bills. While the session is activity, your 5th Grader interrupts you with a Math question. Of course you need to google the answer as you have long forgotten 5th Grade Math Mr. Andy Ruport taught you. You end up on a site that is infected with Malware while you are still logged on to your Bank’s website. The malware on the site could issue a state changing operation such as Fund Transfer on your behalf to your Bank’s website. Since you are already logged on to your Bank Website, there is an active session cookie that get sent on the request to your Bank’s site. So, unbeknownst to you a Fund Transfer request to your Bank on your behalf. This in a nut shell is CSRF Attack.

Refer to the CSRF documentation on OWASP Website for additional information.

The defense for CSRF Attack in a traditional web application is to expect a  CSRF Token on every state changing request that the server validates with the token saved in the Session. Since APIs are supposed to be stateless, there is no CSRF Token that can be maintained across requests in REST API calls. Refer to the CSRF Prevention sheet sheet on OWASP website for additional details. CSRF Guard is a widely used library to implement CSRF Defense in traditional web applications.

The CSRF Defense in REST APIs is to expect a custom header such as X-XSRF-TOKEN by the API. By making the client set a custom header in the request, the attacker can not rely upon traditional CSRF Attach such as auto-submit of a HTML Form as the attacker can not set custom headers via that attack vector. If the attacker were to rely up on  sending an AJAX request using XMLHttpRequest (Level 2) than the CORS protection mechanism supported by all modern browsers would kick in and allow the REST API to accept or deny the request from the attacker controlled site.

This is a simple and elegant CSRF Defense that can be implemented for stateless REST APIs.

Do you know what your attacks are?

Do you know what your attacks are so that you can validate that the defensive controls that you are building are really helping keep your applications safe?

In most of the organizations, the attacks detected by SOC (Security Operations Center) never make it to the Development teams or even their counterparts in SSG (Software Security Group) that work with development teams to fortify their application defensive controls. In my opinion this leaves a big gap between the actual attacks and the defenses that SSG and Application teams are building. This leaves organizations susceptible as they may not be fortifying defenses where they need to. Does this sound like what happens in your organization?

In the absence of real information on the attacks seen by the organizations, the SSG teams rely upon OWASP Top 10 Categories to prioritize application defenses to build out. Although this better than nothing, the OWASP Top 10 are based on the vulnerabilities found in the applications based on the penetration testing done by security firms that participate in the OWASP Top 10 projects. For the most part, the Top 10 vulns seems like they align with High Value rewards the attackers go after. But, there is no validation or data supporting this that I could put my hands on.

So, why does the SOC team hesitant to share the attack patterns they detect and respond with the SSG and Development teams. If you work in SOC, I would like to hear from you. Please drop in a note.

In the meantime, OWASP Top 10 is the best we have to prioritize defensive controls to fortify applications. So, long !

Open Source Software (OSS) – Do you know what you are vulnerable to?

Do you know what percent of software that runs in your application is Open Source libraries?

Do you know if your application is vulnerable because you are using a version of OSS library that is old and has known vulnerabilities?

Are you still writing custom software for your plumbing code instead of using OSS libraries?

If you answered “yes” to any of these questions, you have some work to do, my friend !

If you answered “yes” to the last question, you must be either working for Microsoft or wasting your organizations resources on something that you could get for free, and probably better software than what you could write yourself.

In any case, a large number of organizations: (a) use OSS libraries in their custom software development;  (b) have OSS libraries in their environment from commercial products they use

You can take the time to query CVE Database for the OSS libraries that are in your environment. This is obviously tedious with 1000’s of libraries and various versions that you need to keep track.

There are commercial vendors out there who offer products that solve this problem for a fee. Some of the well known vendors in this space are:

  1. Nexus Lifecycle from Sonatype
  2. Blackduck

OWASP has a free version “OWASP Dependency Track Project

Although the free version has limited capabilities, it is a pretty good start if you are constrained by resources. However, the commercial products provide extensive coverage of the OSS components you use in your organization across Licence management, Vulnerabilities and Architecture.

The capabilities provided by commercial tools and make case for your dollars are listed below:

  1. Scan for OSS components with know vulnerabilities during development or build pipeline with IDE Plugins and CI/CD integration plugins
  2. Set policies to fail builds in CI/CD if OSS components fail compliance against enterprise policies
  3. The products provide coverage for Licence compliance, Vulnerability checks, and compliance with Architecture policies
  4. The products allow automation of your OSS procurement process by blocking download of OSS components with know vulnerabilities and fail compliance against set policies
  5. Dashboard of your OSS vulnerability posture
  6. Integration with Bug tracking tools for resolution
  7. Real time updates if your apps are using OSS components that have zero day vulnerabilities

If your organization is using Sonatype products such as SonarQube, Nexus Pro, etc., OSS Scanning products from Sonatype: Nexus Lifecycle and Nexus Firewall provide efficiency of integration in to the echo system. The Developers can have better user experience with tool set and that is more than half the battle getting developers to consume findings from Security products.

Please share if your organization is using any of these products or others to keep a health check on the OSS libraries that you have exposure to in your organization.

OWASP (Open Web Application Security Project)

If you are new to Application Security domain, OWASP has a treasure trove of information on getting you started on path to a great career in application security as a Security Architect, Penetration Tester, Security Assurance Engineer etc. The OWASP Website is located @ https://www.owasp.org/index.php/Main_Page

Some of the main things that I learnt from the OWASP Website are:

  1. Top 10 Web Application Vulnerabilities that are published every 3 years. This list allows you to prioritize your dollars on what defenses you need to build for securing your web application assets. They have recently released the Release Candidate for 2016 OWASP Top 10. The additions to the 2016 list are: a) Automated detection and remediation of vulnerabilities. b) Lack of sufficient security controls in APIs (for e.g. REST APIs). I agree that most organizations that are re-architecting their sites using REST/CSA technologies are missing basic security controls such as authorizations, output escaping etc., making them susceptible to attacks.
  2. Cheatsheets that are provided explain the attack vector, defenses to mitigate the vulnerability and verification of the mitigation are very useful for any application developer. XSS Cheatsheet can be found here. Scroll to the bottom to find cheatsheets for other categories of vulnerabilities.
  3. Open Source tools and libraries such as ZAP Proxy, ESAPI, CSRF Guard, Anti-Samy have been invaluable to me. These tools and libraries have wide exposure and used by security professionals there by providing the assurance that they have been sufficiently vetted for security vulnerabilities. ESAPI has input validation, output escaping and decoding routines that come in handy for any developer.
  4. One of the most recent OWASP projects that I am interested in is OWASP Benchmark that evaluated and published Security Testing Tools for their efficacy, coverage, false positives to false negative ratios allowing you to compare various tools and services that are available in the market place.
  5. I have extensively used OWASP Webgoat for learning when I started on the career path as an Application Security professional. I used the app to evaluate various security testing tools and last but not least teach application security vulnerabilities and mitigations for Development teams.
  6. Last but not least, explore the full range of projects that the OWASP community has made available for helping you secure you web application assets.

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