Introducing Proxy Enriched Sequence Diagrams (PESD)
14 Feb 2023 - Posted by Francesco LacerenzaPESD Exporter is now public!
We are releasing an internal tool to speed-up testing and reporting efforts in complex functional flows. We’re excited to announce that PESD Exporter is now available on Github.
Modern web platforms design involves integrations with other applications and cloud services to add functionalities, share data and enrich the user experience. The resulting functional flows are characterized by multiple state-changing steps with complex trust boundaries and responsibility separation among the involved actors.
In such situations, web security specialists have to manually model sequence diagrams if they want to support their analysis with visualizations of the whole functionality logic.
We all know that constructing sequence diagrams by hand is tedious, error-prone, time-consuming and sometimes even impractical (dealing with more than ten messages in a single flow).
Proxy Enriched Sequence Diagrams (PESD) is our internal Burp Suite extension to visualize web traffic in a way that facilitates the analysis and reporting in scenarios with complex functional flows.
Meet The Format
A Proxy Enriched Sequence Diagram (PESD) is a specific message syntax for sequence diagram models adapted to bring enriched information about the represented HTTP traffic. The MermaidJS sequence diagram syntax is used to render the final diagram.
While classic sequence diagrams for software engineering are meant for an abstract visualization and all the information is carried by the diagram itself. PESD is designed to include granular information related to the underlying HTTP traffic being represented in the form of metadata.
The Enriched part in the format name originates from the diagram-metadata linkability. In fact, the HTTP events in the diagram are marked with flags that can be used to access the specific information from the metadata.
As an example, URL query parameters will be found in the arrow events as UrlParams expandable with a click.
Some key characteristics of the format :
- visual-analysis, especially useful for complex application flows in multi-actor scenarios where the listed proxy-view is not suited to visualize the abstract logic
- tester-specific syntax to facilitate the analysis and overall readability
- parsed metadata from the web traffic to enable further automation of the analysis
- usable for reporting purposes like documentation of current implementations or Proof Of Concept diagrams
PESD Exporter - Burp Suite Extension
The extension handles Burp Suite traffic conversion to the PESD format and offers the possibility of executing templates that will enrich the resulting exports.
Once loaded, sending items to the extension will directly result in a export with all the active settings.
Currently, two modes of operation are supported:
- Domains as Actors - Each domain involved in the traffic is represented as an actor in the diagram. Suitable for
multi-domainflows analysis
- Endpoints as Actors - Each endpoint (path) involved in the traffic is represented as an actor in the diagram. Suitable for
single-domainflows analysis
Export Capabilities
-
Expandable Metadata. Underlined flags can be clicked to show the underlying metadata from the traffic in a scrollable popover
-
Masked Randoms in URL Paths. UUIDs and pseudorandom strings recognized inside path segments are mapped to variable names
<UUID_N>/<VAR_N>. The re-renderization will reshape the diagram to improve flow readability. Every occurrence with the same value maintains the same name -
Notes. Comments from Burp Suite are converted to notes in the resulting diagram. Use
<br>in Burp Suite comments to obtain multi-line notes in PESD exports -
Save as :
- Sequence Diagram in
SVGformat Markdownfile (MermaidJS syntax),- Traffic
metadatainJSONformat. Read about the metadata structure in the format definition page, “exports section”
- Sequence Diagram in
Extending the diagram, syntax and metadata with Templates
PESD Exporter supports syntax and metadata extension via templates execution. Currently supported templates are:
-
OAuth2 / OpenID Connect The template matches standard OAuth2/OpenID Connect flows and adds related flags + flow frame
-
SAML SSO The template matches Single-Sign-On flows with SAML V2.0 and adds related flags + flow frame
Template matching example for SAML SP-initiated SSO with redirect POST:
The template engine is also ensuring consistency in the case of crossing flows and bad implementations. The current check prevents nested flow-frames since they cannot be found in real-case scenarios. Nested or unclosed frames inside the resulting markdown are deleted and merged to allow MermaidJS renderization.
Note: Whenever the flow-frame is not displayed during an export involving the supported frameworks, a manual review is highly recommended. This behavior should be considered as a warning that the application is using a non-standard implementation.
Do you want to contribute by writing you own templates? Follow the template implementation guide.
Why PESD?
During Test Planning and Auditing
PESD exports allow visualizing the entirety of complex functionalities while still being able to access the core parts of its underlying logic. The role of each actor can be easily derived and used to build a test plan before diving in Burp Suite.
It can also be used to spot the differences with standard frameworks thanks to the HTTP messages syntax along with OAuth2/OpenID and SAML SSO templates.
In particular, templates enable the tester to identify uncommon implementations by matching standard flows in the resulting diagram. By doing so, custom variations can be spotted with a glance.
The following detailed examples are extracted from our testing activities:
- SAML Response Double Spending. The SAML Response was sent two times and one of the submissions happened out of the flow frame
- OIDC with subsequent OAuth2. In this case, CLIENT.com was the SP in the first flow with Microsoft (OIDC), then it was the IdP in the second flow (OAuth2) with the tenant subdomain.
During Reporting
The major benefit from the research output was the conjunction of the diagrams generated with PESD with the analysis of the vulnerability. The inclusion of PoC-specific exports in reports allows to describe the issue in a straightforward way.
The export enables the tester to refer to a request in the flow by specifying its ID in the diagram and link it in the description. The vulnerability description can be adapted to different testing approaches:
-
Black Box Testing - The description can refer to the interested sequence numbers in the flow along with the observed behavior and flaws;
-
White Box Testing - The description can refer directly to the endpoint’s handling function identified in the codebase. This result is particularly useful to help the reader in linking the code snippets with their position within the entire flow.
In that sense, PESD can positively affect the reporting style for vulnerabilities in complex functional flows.
The following basic example is extracted from one of our client engagements.
Report Example - Arbitrary User Access Via Unauthenticated Internal API Endpoint
An internal (Intranet) Web Application used by the super-admins allowed privileged users within the application to obtain temporary access to customers’ accounts in the web facing platform.
In order to restrict the access to the customers’ data, the support access must be granted by the tenant admin in the web-facing platform. In this way, the admins of the internal application had user access only to organizations via a valid grant.
The following sequence diagram represents the traffic intercepted during a user impersonation access in the internal application:
The handling function of the first request (1) checked the presence of an access grant for the requested user’s tenant. If there were valid grants, it returned the redirection URL for an internal API defined in AWS’s API Gateway. The API was exposed only within the internal network accessible via VPN.
The second request (3) pointed to the AWS’s API Gateway. The endpoint was handled with an AWS Lambda function taking as input the URL parameters containing : tenantId, user_id, and others. The returned output contained the authentication details for the requested impersonation session: access_token, refresh_token and user_id. It should be noted that the internal API Gateway endpoint did not enforce authentication and authorization of the caller.
In the third request (5), the authentication details obtained are submitted to the web-facing.platform.com and the session is set. After this step, the internal admin user is authenticated in the web-facing platform as the specified target user.
Within the described flow, the authentication and authorization checks (handling of request 1) were decoupled from the actual creation of the impersonated session (handling of request 3).
As a result, any employee with access to the internal network (VPN) was able to invoke the internal AWS API responsible for issuing impersonated sessions and obtain access to any user in the web facing platform. By doing so, the need of a valid super-admin access to the internal application (authentication) and a specific target-user access grant (authorization) were bypassed.
Stay tuned!
Updates are coming. We are looking forward to receiving new improvement ideas to enrich PESD even further.
Feel free to contribute with pull requests, bug reports or enhancements.
This project was made with love in the Doyensec Research island by Francesco Lacerenza . The extension was developed during his internship with 50% research time.