I have the following open redirect vulnerability:

$redirectUrl = $_GET['url'];
header("Location: $redirectUrl");

This exploit sends user from your page to evil page:


How do I insert evil.com/sploitCode.php into the victim's page/URL?


3 Answers 3


Exactly as you are doing. The idea of open redirect vulnerabilities is to use the trust a user has in a specific website (the vulnerable site), and exploit it to get them to visit your website.

So you would send this link to a user: example.com/?url=evil.com/sploitCode.php. Because the website they see is example.com, and they trust them, they will click on it (in theory). On the other hand, if you would have send them evil.com, they would not click on it, because they do not know or trust it.

You can also obfuscate the url further example.com/some/nice/sounding/path/%2F..%2F..%2F..%2F..%2F/?url=evil.com/something-less-evil.php?some-unneded=parameters. Then you can also wrap it up in a nice a tag, so users will be less suspicious (then the main advantage is that hovering over the link will show them an innocent link at first glance) .

  • Can i also hack a user's session, in order to embed this code into the page he views on example.com ?
    – nik
    Commented Mar 29, 2015 at 13:39
  • @user2598085 Not really. You can highjack a session, or perform session fixation, and I guess theoretically this could enable an open redirect (eg if you change your example code to $redirectUrl = $_SESSION['url'];, and set $_SESSION['url'] in a different script) without the need to send the evil url, just the normal url, but this is a very contrived example, and if you can highjack/fixate a session, open redirect isn't the most interesting attack to perform.
    – tim
    Commented Mar 29, 2015 at 13:42
  • A redirect to any given domain is a security issue indeed. But what about a user input path only? An open redirect but only to any given path on the same domain.
    – Bell
    Commented Dec 4, 2016 at 21:22
  • 1
    @Bell If the filter is working correctly it's not an issue. Note though that eg filtering http:// and https:// is not enough, //google.com eg works as well. Note also that if the CSRF protection is a simple referer check and if the application has GET requests that change server state (or if a POST to GET downgrade is possible) this would enable CSRF attacks.
    – tim
    Commented Dec 4, 2016 at 21:35

Note that the URL that you give as example, can also be written as such:


The domain, evil.com, is no longer visible in the link. Nor that it's a redirect at all. It doesn't look exactly normal, but how often are there funny-looking links in emails that include some tracking code? The domain is perfectly legit.


Your question is somewhat unclear. Does the site already have Open Redirect vulnerability (https://www.owasp.org/index.php/Open_redirect)? If it does you proceed as tim already have said. If it doesn't and you are interested in general methods of getting your malicious code into its pages, then either you hack into the site ("getting shell"), or find some kind of Unrestricted File Upload vulnerability (https://www.owasp.org/index.php/Unrestricted_File_Upload), or bruteforce the password for ftp account with enough privileges to replace site's pages and then update the .php page your targets will frequently visit with your malicious code.

  • your answer doesn't make sense Commented Apr 29, 2020 at 10:48

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .