6

Can I safely use user data when redirecting to an url on my own domain?

Assume that I own example.com. If normal usage of my app would require me to redirect users to urls like this at times, is this ok? 

https://example.com/ + userData

Is there anyway this can be used to do an exploit, and run javascript for example? or redirect to some completely different domain?

For the purposes of this discussion, I'd like to:

  • ignore directory traversal attacks
  • only consider attacks that affect the browser (not the example.com server)

You can assume I'm doing no encoding of the parameter I received from the user at all.

EDIT: Clarification - the userData isn't added to the page in anyway - it only resides in the url itself.

Brad Parks
  • 66,836
  • 64
  • 257
  • 336
  • 3
    Apart from a URL _starting_ with the pseudo protocol `javascript:`, I don’t know of any other way one could get JavaScript code to execute directly from the address bar. – 04FS Mar 05 '19 at 13:02
  • I agree, and have not seen any way this could happen myself. I ask the question because I was talking the other day with a very smart security guy, and he thought this was a possible exploit point for javascript, but I never got specifics, and thought I'd try and ask here to find out more. Hopefully there's no exploit here! – Brad Parks Mar 05 '19 at 13:40

3 Answers3

6

As mentioned in the comments this scenario doesn't seem to be exploitable with the javascript: (or data:, which can also be used to execute JavaScript) pseudo protocol. However, it may be possible to perform a reflected XSS attack, if example.com outputs userData on a custom 404 page. Lets assume that this page displays an error message: 

<h1>Page 'userData' not found.</h1>

In this case, if an attacker submits a JavaScript payload (eg: <script>alert('xss');</script>), it will be rendered on the page, 

<h1>Page '<script>alert('xss');</script>' not found.</h1>

and the code may be executed by a visitor. This attack can be prevented by filtering the user data - user input should always be sanitized anyway.

An open redirect exploit does not seem very likely because the user input is appended to the domain, and exploit attempts should result in a 404 response. Of course, if there are other local pages that allow any redirects, then an attacker could use them in their payload, eg: 

vulnerable/page?url=http://attacker.com

Note that just because I can't confirm an exploit that doesn't mean that the code isn't vulnerable, depending on the server configuration. We can prevent open redirect exploits by filtering user data based on a list of valid and trusted locations. This may also help with several other attacks targeting the server, such as directory traversal, file inclusion and server side request forgery attacks.

Brad Parks
  • 66,836
  • 64
  • 257
  • 336
t.m.adam
  • 15,106
  • 3
  • 32
  • 52
  • thanks for the feedback - you're correct in that the content, if rendered to the page, would be open to injection attacks, but it's not actually being used in the page at all - I'll clarify this in an edit above. As for a redirect, there's no where in our app that we allow redirects from query string params, but it's stuff like `https://example.com/http://www.badsite.com` or `https://example.com/javascript:alert(1)` that concern me - though I too don't believe this can be used to do an exploit, i wonder if there are scenarios this plays out in that i'm not aware of. – Brad Parks Mar 07 '19 at 14:02
  • 1
    I don't see a way to expolit this either, but that doesn't mean it's not exploitable by hackers with more experience or information. You could test with the items in [this list](https://github.com/cujanovic/Open-Redirect-Payloads/blob/master/Open-Redirect-payloads.txt) to eliminate the most common Open Redirect payloads. – t.m.adam Mar 07 '19 at 14:50
  • Hi @ t.m.adam, this is the [latest post](https://stackoverflow.com/questions/60307297/cant-send-a-post-requests-filling-in-the-value-of-g-recaptcha-response-within-p) that I've created to look for any solution. Thanks. – MITHU Feb 19 '20 at 19:01
2
  1. This may be point for phishing attack

Attacker may send email pretending to be mail from your site and inject the link alike (I assume “jumper.php” is a page that has single url parameter with target url, that may contain user data):

To verify your account please follow this link: http://example.com/jumper.php?url=http%3A%2F%2Fexample-my.com

In that case, user will see in the mail link started with http://example.com and may assume that this is valid link to your site, but actually he will be redirected to http://example-my.com that may be controlled by attacker (and looks much like your site).

  1. In some cases, people are using javascript for redirection

If page contains code like this (php example):

<script>location.replace(<?= json_encode($userData) ?>);</script>

Then, even variable is properly sanitized, attacker may execute arbitrary javascript code in context of http://example.com with redirection to javascript:.... For example:

To verify your account please follow this link: http://example.com/jumper.php?url=javascript%3Aalert%28document.cookie%29

In that case, redirection will transform to 

<script>location.replace("javascript:alert(document.cookie)");</script>

and code javascript:alert(document.cookie) (as example) will be executed in context of http://example.com. Sure, attacker may do much more poverfull things with injection arbitrary javascript code code.

Serge Ageyev
  • 437
  • 3
  • 8
  • I think the only way this would work would be if my server, `http://example.com` redirected to whatever it has after the domain, correct? on the server, i mean? If so, I'm not open to this exploit, as we don't support redirects like this.... – Brad Parks Mar 11 '19 at 15:50
  • It depends on how redirection is done. If it is something alike (php example): `header("Location: ".$userData);` the site are open to exploit listed as point #1 (as `userData` may contain absolute URL). – Serge Ageyev Mar 11 '19 at 16:30
  • understood - but our redirects do ensure that nothing absolute is allowed, so no `http` or no `javascript` or `://` at the beginning of the `userData` parameter. When I said assume we dont encode, I didnt mean we don't sanitize/sanity check though... good point – Brad Parks Mar 11 '19 at 16:39
2

Let assume that the redirection code is done via adding looks like this (php example): header("Location: http://example.com/".$userData);

Since $userData is not encoded in any way, in fact attacker may obtain access to http response generated by the server. For example $userData may contain something alike:

"somepage.php\r\nattacker-header:some value\r\n\r\nattacker page body with JavaScript"

While most of http libraries (including php starting from 5.1.4 AFAIK) prevents this kind of header injection attack and will generate error, some old instruments may be vulnerable.

Serge Ageyev
  • 437
  • 3
  • 8