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 !

How to make effective presentations – A Survival Guide for Techies

Practical advice.. Like this very much !

AppSec For Devs

Lot of folks in the security field, would rather be in front of a computer instead of people. But, in order to grow professional and become a leader in any field, one needs to be comfortable talking, presenting, teaching in various settings and group sizes. I am not a natural public speaker. I envy people who jump in front of a group and speak eloquently and give effective presentations. But, I would like to get better at this skill. I teach course on Defensive Security for Developers and them on implementing & verifying security controls in their code to mitigate OWASP Top 10 vulnerabilities. I will blog about teaching techniques in another post. Recently, I had to get in front of the CTO, Managers and other Lead architects in the organization. This is a situation where if you do well, it will be a “no op”, you may get a…

View original post 503 more words

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