Break Builds: Getting Devs to take action !

As your organization matures DevSecOps, enabling Developers to release features faster, as a security professional you are trying to assure that the code is free of security defects. As part of you Security team, you incorporated automated security tools in to the build pipeline such as Static Code Analysis Tools, Dynamic Code Analysis, Security Test Cases etc. But, you can only bring the horse to the water, but can you make it drink the water? In other words, how do you get your development teams to consume results reported by the security tools? That is the million dollar question.

There is an aspirational goal that no security defects should ever leak in to production. There is an ask from clients to prevent code with security defects from getting deployed to production. Why don’t you break the build and force the developers to take action and fix the defects reported by the security tools before any code is deployed to production?

The challenge is multi-fold.

  1. The error ratio, ration of false positives to false negatives is significantly high for security tools. This is especially true for Application Security, you have better results with Infrastructure Security. Some of the tools reports results that run in to literally 1000s of pages long that a Developer needs to triage to identify true positives that they can take action and fix. The tools lack the Business Context to alert if an issue is High or Low for a given attack vector. This is especially challenging if you are focused on Application Security. Would lack of Input validation indicate or out out escaping result in an exploitable vulnerability depends up on whether the data can be exploited by the attacker to compromise your system.
  2. The criterion you use to break a build gives you a false sense of security. Given the limitations of tools, there are whole bunch of false negatives that leak in to production giving the organization a false sense of security. The Developers can always point back and say the Build went through, hence there must be no security defects in the code.
  3. Given the negative testing involved with uncovering security defects, the current generation of tools are not capable of identifying all possible attack vectors and assuring defenses against the attacks. I would think AI plays a role in being able to identify security weaknesses in code that are exploitable.

One of the tools that is used to measure code quality, SonarQube has removed the capability that supports breaking builds based on criterion such as severity level of the issues, number of issues, etc. The team recommends that the better approach is for teams to look at the dashboard of issues, triage and identify real issues that are applicable to your code to be fixed. This did not go well with security minded folks, but in reality that is a pragmatic approach until the security tools mature and are able to report security issues that are exploitable as opposed simply identifying security code syntax that may or may not lead to a vulnerability.

Until then, there is no easy button for assuring application security in the DevOps pipeline. Security organizations would have to continuously tune security tools, follow-up with Developers to look at the results, add exploitable defects to the Backlog for the Devs to work on to have success at assuring application security in DevOps Pipeline.

I would like to hear from you. Please share what you have done to assure security in DevOps Build Pipelines. What kind of automated tools do you run? How do you make Developers take action on them? Were you successful in implementing automated enforcement gates that prevents Developers from deploying code with vulnerabilities identified by security tools in the DevOps Pipeline?

 

 

 

Advertisements

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 !

 

OWASP (Open Web Application Security Project)

I recently came across this Blog on AppSec related topics at https://appsecfordevs.com. I found the articles to be very pertinent and helpful to me. Please take a look at this Blog is you are in the Application Security domain.

AppSec For Devs

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…

View original post 229 more words

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 !

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.

AppSec Blogs (Current & Future)

Please vote (by way of comments) for the topic that is of interest to you.

  1. Securing REST APIs/Micro Services
    1. Security vs Speed and Flexibility: A Conundrum
    2. Authentication
    3. Authorizations
    4. Input Validations & Output Encoding
    5. CSRF Defense
    6. Authorize Direct Object References
    7. Error handling/Information Disclosure
    8. API Gateway: Why you need it?
    9. CORS Demystified!
  2. Amazon Web Services
    1. How do you know if your AMIs are secure?
  3. Dynamic testing using a Proxy
    1. Burp
    2. Zap
  4. OWASP (Open Web Application Security Project)
    1. Newest OWASP Top 10 Release Candidate List is Out
    2. OWASP Mobile Top 10: A Critique
  5. DevSecOps: Shifting Security to the Left/Automating Security in DevOps Pipelines
    1. Static code analysis for security vulnerabilities
    2. Dynamic Application Security Testing (SAST) tools
    3. Interactive Application Security Testing (IAST) Tools
    4. Open Source Software (OSS) Vulnerability Scanning Tools
    5. Automated Security Test Cases
    6. Bamboo APIs – Love ’em
    7. Break Builds: Getting Devs to take action !
    8. Just In Time (JIT) Training
  6. Setting up Security Assurance Program
    1. Security Architecture
    2. Security Assessments
    3. Vulnerability Management
    4. Security Training
  7. Security Learning Resources
    1. Conferences
    2. Training
    3. Webinars/Webcasts
  8. Miscellaneous
    1. Do you know what your attacks are?
  9. Professional Success
    1. How to make effective presentations?  A Survival Guide for Techies

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