Secure Programming of Web Applications: Open Redirection

Added at 12/01/2020 by Frank Hissen

We can read about numerous successful attacks on well-known web applications on a weekly basis. Reason enough to study the background of "Web Application Security" of custom-made / self-developed applications - no matter if these are used only internally or with public access.

This is an excerpt from the book "Secure Programming of Web Applications: Web Application Security for Software Developers and Project Managers", also available as eBook
A corresponding online (video) training course exists: Online Course 'Web Application Security', also available on Udemy, and on request as HTML5/SCORM/Audio comment version

Description

Web applications often include a redirecting feature for triggering HTTP redirects. This can be helpful, e.g., to return to the own web shop after completing a payment through an external payment provider. If the redirect is not restricted to intended use, it can be exploited by attackers.

Example including Security Vulnerability:

Vulnerable redirect URLs often look similar to this:

or worse like

If the processing of the parameter which includes the redirect destination is vulnerable, an attacker is able to implant a malicious page as destination:

Links of this nature look harmless because they are coming from a genuine web application.

By forwarding users to malicious sites this way, an attacker can achieve almost anything. Aside from redirecting users to pages that simply trigger browser exploits, for instance a forgery of the original destination is possible to gain access to user data etc.

To foist malicious links to legit users of the original web application, the attacker could use central, public forums or tertiary channels like phishing e-mails (compare chapter "Hacking Anatomy").

Secure Programming:

Redirects have to be static as far as possible.

Especially, no user-based, changeable input data must be used for creating redirects.

1) Local Redirects

A local redirect is a forwarding to a resource within the own URL.

a)

The best way would be not needing a parameter at all which looks like this:

b)

Another way is to use tabularized, dedicated redirection destinations. That means, the redirection is set on the server-side through the parameter, the destination list is fix and read from, e.g., a database:

The corresponding URL could, for instance, look like this:

c)

In case static programming is not possible but rather an open parameter has to be used, whitelist filtering has to be applied to make sure that

• only valid, local paths are used
• no functional characters (e.g., header injection) are included in the parameter

2) External Redirects

If the web application is supposed to implement external redirects - forwarding its users to other domains - this has to be done using static programming (compare to 1b) or whitelisting! The list of URLs that will be redirected to has to be explicitly defined and approved.

An open interface which attackers can use to include their own domains must not be used.

Keywords

Secure Programming, Web Applications, Open Redirect, Open Redirection, Web Application Security, Software Developing, Secure Code/Coding, Java, PHP, C#, Security Awareness

Categories: IT Security Background articles Development/Java

---

Comments

Post your comment

Share

If you like this page, it would be a great thing if you share it with others:

reddit Digg StumbleUpon XING
WhatsApp Telegram