FirstBlood-#537 — The ref parameter is redirectable in the register.php path
This issue was discovered on FirstBlood v2

On 2021-10-26, axe Level 4 reported:

Summary

  1. Through the report disclosed by V1, I found an unpatched redirect vulnerability in v2.

  2. In reading other people's reports, I learned how they think about testing. I will expand on what I have learned!

Testing ideas

Open Redirect

  1. Do a test on the parameter, e.g. xxx.php?xx1="><xss. Do a fuzz on the xx1 parameter and then look at the response in burp. By the response we can see that this ref parameter is working.

  2. Visit /register.php?ref=/\/google.com

  3. Click Return to previous page. successfully redirected to google.

After testing you can also redirect via parameter pollution:

`/register.php?ref=google.com&ref=//google.com`

Available payloads

/\/google.com
//google.com
////google.com
//%2F/yoursite.com
\/\/yoururl.com
//[email protected]
...
...

Vulnerability for exploitation

Open Redirect to SSRF(Test Failure)

  1. I'm extending the application based on the redirect vulnerability. Change /\/google.com to n8w5dmbcdeg73bqwioriwy5p7gd61v.burpcollaborator.net

  2. But in the end it was not exploited successfully. It was not possible to get the internal address.

  3. I would very much like zseano to give me guidance advice.

Fixes

  1. Whitelisting of domains is the most effective way to deal with redirects in my opinion.

Reference study material.

  1. https://www.bugbountyhunter.com/vulnerability/?type=open_redirect

  2. https://book.hacktricks.xyz/pentesting-web/open-redirect

  3. https://blog.detectify.com/2019/05/16/the-real-impact-of-an-open-redirect/

P5 Informative

Endpoint: /register.php

Parameter: ref

Payload: /\/google.com

Even though this issue has been accepted as valid, no FirstBlood ID has been set for this report.

Report Feedback

@zseano

Creator & Administrator

Hi there, whilst you're correct that this parameter is vulnerable to open redirect, it is possible to redirect the user to javascript: which results in XSS which carries more impact. As such this is the intended solution/bug for this parameter. As open redirect was demonstrated in this report we won't reject but there wont be any ID assigned. With regards to the SSRF, this is just an open redirect which occurs client side, and not server side. For SSRF you need the server to initiate the request and to then follow the redirect :) Redirecting to your burp collaborator just means you are visiting it yourself (hence the request is received)