diff options
Diffstat (limited to 'Client-side URL redirection/Resources/notes.md')
| -rw-r--r-- | Client-side URL redirection/Resources/notes.md | 12 |
1 files changed, 12 insertions, 0 deletions
diff --git a/Client-side URL redirection/Resources/notes.md b/Client-side URL redirection/Resources/notes.md new file mode 100644 index 0000000..06ee7a4 --- /dev/null +++ b/Client-side URL redirection/Resources/notes.md @@ -0,0 +1,12 @@ +## Exploit + +1. In the wesite `<footer>` there are links to social medias that can be manipulated client-side. +1. Change the `site` parameter of the `href=index.php?page=redirect&site=…` to any other value to get the flag. + +## Fix + +[https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/11-Client-side_Testing/04-Testing_for_Client-side_URL_Redirect]() + +The problem here is that an attacker can craft an URL and use it to redirect a user to a website and the original site will appear as the referrer. In other words, an attacker can use the domain as a trusted relay to send victims to a malicious site. The primary risk is phishing. An attacker could redirect the user to a page resembling the original website to steal its credentials. + +Applications must not allow arbitrary redirect targets. The site uses references (`site=twitter`/`site=instagram`/`site=facebook`) but even then there should be a strict whitelist. This may not constitute a vulnerability if the `site` parameter is strictly used as a reference and mapped server-side to predefined URLs, provided the mapping logic does not allow any user-controlled input to influence the redirect target. |