From e39d9fc7df710dc5a761d7de301da526b078cc54 Mon Sep 17 00:00:00 2001
From: Thomas Vanbesien <tvanbesi@proton.me>
Date: Fri, 27 Mar 2026 12:59:12 +0100
Subject: Add client-side URL redirection solution

---
 Client-side URL redirection/Resources/notes.md | 12 ++++++++++++
 1 file changed, 12 insertions(+)
 create mode 100644 Client-side URL redirection/Resources/notes.md

(limited to 'Client-side URL redirection/Resources/notes.md')

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.
-- 
cgit v1.2.3