Difference between revisions of "GSoC2013 Ideas/OWASP ZAP SAML Support"

Revision as of 17:55, 1 July 2013

Introduction

The OWASP Zed Attack Proxy (ZAP) is an easy to use integrated penetration testing tool for finding vulnerabilities in web applications. It is open-source under Apache License 2.0 and widely used by the computer security community.

SAML is an XML-based federated single sign-on (FSSO) protocol that uses security tokens containing assertions to pass information about a principal between a SAML authority (an identity provider), and a SAML consumer (a service provider). It enables web-based authentication and authorization scenarios including cross-domain single sign-on (SSO).

The Objective of this project is to develop a component for ZAP that will detect and fuzz various elements and attributes of a SAML Assertion.

Project Goals, Scope and Deliverables

As listed in the OWASP GSoC 2013 ideas page and as per discussion with the possible mentor, following is the goal for this project.

Develop a component that enable ZAP to

• Understand SAML messages
• Detect SAML Assertions in HTTP requests and responses
• Decode SAML Assertions
• Fuzz various entities and attributes within a SAML assertion
• Re-encode the assertion and send it forward to the final destination

Scope and Constraints

The component will be developed only for HTTP POST and HTTP Redirect binding

Deliverables

The following deliverables are expected as the outcome of the project.

• A component integrated to ZAP that can achieve the goal described above.
• The source code for the component, committed to the ZAP project's code base
• The relevant documentation for the users and the developers who will be using this component

Implementation Plan

The requirements of this project are to identify a SAML request/Response, Decode the request/response and get the assertions, give the user the ability to fuzz the requests and re-encode the requests as SAML requests and sent to the desired endpoint. Here is a high level diagram to demonstrate the sequence.

Identifying SAML Request Response

This will be done as specified in the SAML 2.0 specification on SAML Binding. In the scope of the project this will be done as follows

• HTTP Redirect: SAML messages are deflated, base64 encoded and URL-encoded as the value of the parameter “SAMLRequest” or “SAMLResponse” based on whether it is a request or a response.
• HTTP POST: SAML messages are base64 encoded and submitted as the value of post parameter “SAMLRequest” or “SAMLResponse” based on whether it is a request or a response.

The identification will be done based on the above. If any request/ response has the above parameters set, they will be identified as a SAML request/response.

Detecting SAML Assertions

The SAML messages identified will be decoded and parsed to get the SAML assertions.

Modifying SAML Assertions

Automatically replacing values for SAML assertion attributes with user supplied values

After the identification and decoding of the SAML assertions, the values for certain attributes such as but not limited to Subject, Conditions etc. will be replaced by the values pre-defined by the user. This will guarantee a near real-time attacks like privilege escalation by changing the identifier of the subject, extending or re-use of an old assertion by changing the Conditions on the assertion etc.

Fuzzing the entities and Attributes of SAML message

After the identification and decoding of the SAML assertions the users will be given the ability to fuzz the entities and attributes of the SAML message. They may use the existing fuzzers or new fuzzers specific to SAML that may be implemented as necessary.

XSW Signature Exclusion Attack

After the identification and decoding of the SAML assertions, the signature element of the assertion will be removed from the assertion, re-encoded and sent forward to simulate XSW Signature Exclusion Attack

Re-encoding assertions

The SAML message with fuzzed attributes will be prepared as follows,

• HTTP Redirect – The SAML message will be rebuilt. Then it will be deflated and base64 encoded and will be added as a URL-encoded parameter value
• HTTP Post – The SAML message will be rebuilt. Then the message will be base64 encoded and added as a POST parameter value

Project Progress

Community bonding period (before 17th June)

Agreed to have video conference twice a week on Monday and Thursday to discuss the project progress and any issues that may occur.

• Clarification of project idea
• Read the SAML specs to get familiar with SAML standards and usages
• Identifying the use cases that need to be implemented
• Setting up the development environment.

Week 1 (17th June - 23rd June)

Week's progress

• Finalizing the use cases
• Setting up the Third party applications to generate SAML requests/responses
• Intercepting the SAML requests/responses from ZAP and get familiar with the parameters
• Studying on ZAP core and extensions to start the coding

Plans for next week

• Intercept the requests and responses and log them to console/file

Week 2 (24th June - 30th June)

Week's progress

• Created a project at GitHub for the development of the extension at https://github.com/pulasthi7/zap-saml-extension
• Created a passive scanner to intercept and log SAML requests/responses in their raw values
• Wrote a component that can decode the SAMLRequest/ SAMLResponse parameters in a HTTP request
• Updated the passive scanner to log the decoded SAML messages to the console
• Studied on the ZAP's extension API

Plans for next week

• Design the UI for the extension
• Provide ability to view SAML messages in a GUI in readable XML format