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.
Advertisements

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