Arbitrary URL Redirection in SAML Response
Description
Environment
None
Potential Workaround
None
blocks
is blocked by
Checklist
hideTestRail: Results
Activity
Show:

Craig McNally May 21, 2020 at 1:41 PMEdited
Created , , and for the implementation of a fix for this. Once those are complete, this can be unblocked and closed.

Craig McNally May 18, 2020 at 12:28 PMEdited
Done
Details
Assignee
Hongwei JiHongwei JiReporter
Jakub SkoczenJakub SkoczenPriority
P2Story Points
2Sprint
NoneDevelopment Team
Core: PlatformFix versions
TestRail: Cases
Open TestRail: CasesTestRail: Runs
Open TestRail: Runs
Details
Details
Assignee

Reporter

Priority
Story Points
2
Sprint
None
Development Team
Core: Platform
Fix versions
TestRail: Cases
Open TestRail: Cases
TestRail: Runs
Open TestRail: Runs
Created April 16, 2020 at 11:55 AM
Updated July 13, 2021 at 8:53 AM
Resolved May 27, 2021 at 1:06 PM
Impact
An attacker can use this vulnerability to aid in social engineering attacks. The most common use would be to create highly believable phishing attacks.
Description
The application will redirect users to an arbitrary URL specified by the RelayState query parameter. This is often used to bring users back to a previous page when they authenticate to an application or to pass single sign-on information to a third-party application. This value can be controlled by an attacker and the application will redirect a user to any value set for the parameter.
A typical attack would involve sending legitimate users an email requesting them to click a link related to the application. This link would embed the redirect URL and would ultimately take the victim to an attacker-controlled login page that looks similar to the application’s login page. The attacker could then harvest the victim’s credentials and silently authenticate them to the application without the victim realizing an attack occurred.
Furthermore, the application embeds the resulting JWT in the ssoToken query parameter. This sensitive information could be leaked to third-parties and attackers due to the arbitrary URL redirection vulnerability. For instance, an attacker can force an admin to initiate a SP- initiated login flow, providing an attacker-controlled server as the value of the RelayState. Since there’s no URL validation done on the FOLIO application, it then sends the final JWT to the attacker-controlled server. This can be potentially exploited to steal tokens from higher- privileged users of the application.
Repro steps
1. Log in with a user to the application via SSO.
2. Using a web-intercepting proxy tool such as Burp Suite, intercept the POST request to
the https://okapi-bugfest.folio.ebsco.com/_/invoke/tenant/fs00001000/saml/callback and
copy the value of SAMLResponse parameter.
3. Save the contents below to a local file with a .html extension, substituting the value of
SAMLResponse HTML element with the value copied from the previous step.
4. Open the file in a browser and click the submit button. Observe the redirection to ncc-
group.com domain.