Skip to content

Protocols

Jump to bottom Edit New page
plokta edited this page Jun 28, 2019 · 1 revision

This page describes how the following supported protocols are determined by EsPReSSO, as defined.

OAuth-Family Protocols

OAuth

Figures for OAuth were taken from Chris­toph Ni­ckel - Si­cher­heits­ana­ly­se von OAuth 2.0 mit­tels Web An­grif­fen auf be­ste­hen­de Im­ple­men­tie­run­gen.

The message is checked at the beginning of the OAuth detection for the parameters redirect_uri, scope, client_id, client_secret and response_type. If one or more of the parameters is present the algorithm proceeds. The checks are then divided into three parts:

  1. Authorization Code Flow: If the parameters grant_type or response_type are present, the algorithm proceeds. If the previous message has status-code 302 and the current message contains the parameter response_type with the value code, the message is marked as OAuth ACG Request. If the parameter code exists, the message is classified as OAuth ACG Code. If the parameter grant_type exists with the value authorization_code, the message is marked as OAuth ACG Token Request.

code-grant-flow

  1. Implicit Flow: If the parameters access_token or response_type are present, the algorithm proceeds. If the previous message had the status-code 302 and the current message contains the parameter response_type with the value token, the message is marked as OAuth Implicit Grant Request. If the response of the message matches the regular expression Location:.*?#.*?access_token=.*?&?, the message is marked as OAuth Implicit Token, otherwise it is marked as OAuth (IF).

A depiction of the Implicit Flow is seen in the diagram below. implicit

  1. Other Flows: The parameter grant_type is evaluated for the following values and marked as:
    • OAuth Access Token Request with the value authorization_code.
    • OAuth Refresh Token Request with the value refresh_token.
    • OAuth Resource Owner Password Credentials Grant with the value password.
    • OAuth Client Credentials Grant with the value client_credentials.
    • OAuth Extension JWT Grant with the value urn:ietf:params:oauth:grant-type:jwtbearer.
    • OAuth Extension SAML Grant with the value urn:oasis:names:tc:SAML:2.0:cm:bearer.

OpenID Connect

Figures were taken from Julian Krautwald's Master's Thesis Single Sign-On – OpenID Connect(ing) people

The method for checking OpenID Connect is divided into two parts, which divides up the HTTP 302 and 200 messages, and looks for a number of parameters.

OpenID Connect Authorization Code Flow

oidc_code_flow

The messages are split up as follows:

  • If the parameter response_type contains the value code and the value id_token or token, the message is marked as OpenID Connect Hybrid Flow.

  • If the message has the HTTP status code 302 and the response location matches the regular expressions ^Location:.*?response_type=code.*?$ and ^Location:.*?&?scope=[a-zA-Z+]*?openid[a-zA-Z+]*?&?.*?$, the message is marked as OpenID Connect ACF Request. If the next message contains the parameter response_type=code and scope=openid, the message is also marked as OpenID Connect ACF Request.

OpenID Connect Implicit Flow

oidc_implicit

  • If the parameter response_type=id_token exists in a message with a 302 status-code, the message is marked as an OpenID Connect Implicit Flow Request. If the subsequent message has a parameter named id_token, it is marked as OpenID Connect Implicit Flow Response. If the following message contains the parameter access_token, the message is marked as the OpenID Connect Implicit Flow Access Token.

The other parameters are split and classified as follows:

  • If the regular expression "\\/\\.well-known\\/openid-configuration|\\/\\.well-known\\/webfinger" is found, the message is classified as an OpenID Connect Discovery Flow.

  • If the parameters code and/or state are present along with the parameter scope, the message is marked as OpenID Connect / OAuth. Additionally, if scope is set to openid, the message is only marked as OpenID Connect.

OpenID Connect Hybrid Flow

oidc_hybrid_flow

  • Hybrid Flow is comparable to the flows before, but its hybrid (OAuth + OIDC).
    • response_type=code id_token token
    • response_type=code token
    • response_type=code id_token
    • Maybe the order of the values can vary.
  • Identify OpenID Connect Hybrid Flow:
    • response_type must contain code AND (either id_token or token or both).

OpenID Connect Discovery Flow

oidc_discovery

Facebook Connect

The message host must contain facebook.com and if found, the URL is then checked for /ping?. If both of these elements are found, the message is marked as a Facebook Connect Ping Request.

To determine additional information regarding the message, the message is then checked for the following parameters: app_id, domain, origin, and/or sdk. If one of these parameters is found, the message will be marked as Facebook Connect.

If the signed_request parameters is found, the message is marked as a Facebook Connect Authentication Response.

If the parameter response_type contains the value signed request, the message is marked as a Facebook Connect Authentication Request.

Below is an depiction of the protocol taken from Jacek Rzeniewicz - Log Me In with Facebook: Security Analysis of Facebook Connect. fb1 fb2 fb3

Microsoft Account

The message must contain live.com, live.net, or contoso.com.

If the scope parameter is present in the message and contains the values wl.basic, wl.offline_access, or wl.signin, the message is identified as Microsoft Account with OAuth. If the scope contains the openid and is assigned with a value, the message is marked as a Microsoft Account.

If any of the previous elements have not yet allowed the EsPReSSO scanner to identify the message, the parameter wa is looked for by the scanner. If it present and set to wsignin1.0, the message is marked as Microsoft Account WS-Federation.

Non-OAuth Protocols

SAML

To determine SAML messages, the messages must contain the parameter SAMLRequest for the request and SAMLResponse for the responses. EsPReSSO decodes the messages in reverse order of the standard SAML Encoding.

The DTD-Attacker sends the SAMLRequests using the encoding shown below. If the tester makes any changes to the ´SAMLRequest´, the standard encoding needs to be taken into consideration.

SAMLRequest

Encoding:

  • GET : SAMLRequest=URL-Encoding(Base64-Encode(deflate((XML)))
  • POST : SAMLRequest=Base64-Encoding(deflate((XML))

Decoding:

  • GET : SAMLRequest=URL-Decode(Base64-Decode(inflate(XML)))
  • POST : SAMLRequest=Base64-Decode(inflate(XML))

OpenID

If the parameter openid.mode contains the values checkid_setup for the OpenID Request or id_res, it is classified as an OpenID message.

If the openid.mode parameter contains the value associate, the message is assigned as an OpenID Association message.

The OpenID 2.0 Token is determined by the parameters openid.sig and openid.claimed_id. If openid.claimed_id is not present, the message is marked as an OpenID 1.0 Token.

BrowserID

Figures for BrowserID were taken from Hen­ning Thiel - Prak­ti­sche Si­cher­heits­ana­ly­se des Mo­zil­la Sin­gle Sign-on Pro­to­kolls Brow­ser­ID.

persona1 persona2 persona3

For BrowserID to be recognized, the following attributes must be met:

  • The message must contain persona.org.
  • Cookie with value browserid_state is set.

OR

  • GET or POST parameter with name assertion is set.
    • assertion contains a JWT that must be decoded.
  • POST JSON object with the following content: {"pubkey":"{\"algorithm\":\"DS\",\"y\":\"6dd39e08cbecbab...\",\"p\":\"ff600483db6abfc5b...\",\"q\":\"e21e04f911d1ed799...\",\"g\":\"c52a4a0ff3b7e61...\"}","duration":3600,"email":"ssoanonym2@gmail.com"}:
  • POST JSON object with the following content: {"assertion":"eyJhbGciOiJSUzI1NiJ9.eyJwdWJsaWMta2V5I....eyJleHAiOjE0NDA0OTI3Nj....F69xoO8wAv2LOW...","ephemeral":true,"csrf":"siVxypVsfcdJZAZCMxhwHQ: ="}
Add a custom footer
Clone this wiki locally