An open redirect vulnerability in the python package Flask-Security-Too <=5.3.2 allows attackers to redirect unsuspecting users to malicious sites via a crafted URL by abusing the ?next parameter on the /login and /register routes.
Flask-Security-Too contains logic to validate that the URL specified within the next parameter is either relative or has the same network location as the requesting URL in an attempt to prevent open redirections. Previously known examples that bypassed the validation logic such as https://example/login?next=\\\\\\github.com were patched in version 4.1.0
However, examples such as https://example/login?next=/\\github.com and https://example/login?next=\\/github.com were discovered due to how web browsers normalize slashes in URLs, which makes the package vulnerable through version <=5.3.2
Additionally, with Werkzeug >=2.1.0 the autocorrect_location_header configuration was changed to False - which means that location headers in redirects are relative by default. Thus, this issue may impact applications that were previously not impacted, if they are using Werkzeug >=2.1.0 as the WSGI layer.
References
jwag956 Analyst
brandon-t-elliott Analyst
An open redirect vulnerability in the python package Flask-Security-Too <=5.3.2 allows attackers to redirect unsuspecting users to malicious sites via a crafted URL by abusing the ?next parameter on the /login and /register routes.
Flask-Security-Too contains logic to validate that the URL specified within the next parameter is either relative or has the same network location as the requesting URL in an attempt to prevent open redirections. Previously known examples that bypassed the validation logic such as
https://example/login?next=\\\\\\github.comwere patched in version 4.1.0However, examples such as
https://example/login?next=/\\github.comandhttps://example/login?next=\\/github.comwere discovered due to how web browsers normalize slashes in URLs, which makes the package vulnerable through version <=5.3.2Additionally, with Werkzeug >=2.1.0 the autocorrect_location_header configuration was changed to False - which means that location headers in redirects are relative by default. Thus, this issue may impact applications that were previously not impacted, if they are using Werkzeug >=2.1.0 as the WSGI layer.
References