Input Validation Testing

source: freepik.com

In this article I will discuss Input Validation Testing in OWASP, each control point will be discussed what it is, examples, and the application of testing according to OWASP.

The tests carried out will use a lot of web applications that are designed to be used as training platforms and web application security testing, namely OWASP Mutillidae II, PortSwigger, and PentesterLab.

1. Testing for Reflected Cross Site Scripting

What is Reflected Cross Site Scripting?

Reflected Cross Site Scripting (XSS) is a type of web security attack that utilizes a gap in a web application that allows an attacker to inject a malicious script into a request and send it to the server, then the response from the server containing the script is reflected back to the web page and executed on the victim’s browser.

Reflected Cross Site Scripting Example

When a user enters unauthorized data into a form, the data will be stored in the URL as parameters. If the parameter is not properly validated by the web application, an attacker can manipulate it to inject a malicious script that will be reflected back to the web page and executed by the user’s browser.

Target URL: http://example.com/search?q=<script>alert('Hello XSS’);</script>

The injected script: <script>alert(‘Hello XSS’);</script>

In the URL above, the q parameter is used to search for content on the example.com site. However, in this example, the q parameter is filled with an insecure JavaScript script, namely <script>alert(‘Hello XSS’);</script>. If the script is executed by the browser, a dialog box will appear with the message “Hello XSS”. This can be utilized by attackers to perform attacks on users who open the URL.

Testing for Reflected Cross Site Scripting

Test Objectives:

• Identify variables that are reflected in responses.
• Assess the input they accept and the encoding that gets applied on return (if any).

Testing is done by trying to inject the script <script>alert(‘Hello XSS’);</script> in the Message field, the result is that the web application does not validate the input and the browser reflects the injected script.

2. Testing for Stored Cross Site Scripting

What is Stored Cross Site Scripting?

Stored Cross Site Scripting (XSS) is a type of XSS attack that involves storing a malicious script in a database or other storage system, then the script is executed when the web page is accessed by the targeted user. The storage of malicious scripts generally occurs through forms that allow users to enter data that is then saved to the server.

Stored Cross Site Scripting Example

An example of stored XSS is when an attacker inserts a malicious script into a comment box on a web page that allows users to leave comments, then the script is stored in the database and accessed by other users when they open the same web page.

Here is an example of a stored XSS payload inserted into a comment box on a web page:

<script>
alert("Hello, I am a stored XSS payload!");
</script>

When the webpage is accessed, the malicious script will be executed and a pop-up message will appear.

Testing for Stored Cross Site Scripting

Test Objectives:

• Identify stored input that is reflected on the client-side.
• Assess the input they accept and the encoding that gets applied on return (if any).

Testing is done by trying to inject the script <script>alert(“Hello, I am a stored XSS payload!”);</script> in the Blog column, the result is that the web application does not validate the input and the script is stored in the database or file system on the server, as a result when a user accesses the web application, the script will be executed.

As long as the script is stored in the web application system, when a user accesses the web application, the script will continue to be executed. That’s the difference with reflected XSS where the script is only executed once.

3. Testing for HTTP Verb Tampering

What is HTTP Verb Tampering?

HTTP Verb Tampering is an attack technique performed by changing the HTTP method (HTTP verb) used in HTTP requests. In an HTTP Verb Tampering attack, the attacker attempts to manipulate the HTTP method sent by the client to manipulate access to the requested web resource.

HTTP Verb Tampering Example

If a web application has an “edit profile” page that can only be accessed with the HTTP POST method, then an attacker may try to change the HTTP request to the GET method. That way, the page will open and user data can be manipulated in an unwanted way.

Testing for HTTP Verb Tampering

In OWASP this test has been merged into Test HTTP Methods.

In the example below, the web application has an “edit profile” page which should be accessed by the HTTP POST method but changed to the GET method and the web server gives a 200 response which means that the web application allows editing profiles with the GET method, this is certainly dangerous because it can be exploited by hackers, besides that HTTP Verb Tempering testing can also be done by changing the HTTP method to another one, don’t just stick to the GET and POST methods.

4. Testing for HTTP Parameter Pollution

What is HTTP Parameter Pollution?

HTTP Parameter Pollution (HPP) is an attack technique carried out by manipulating HTTP parameters sent by the client to the server. This technique aims to add or change the value of HTTP parameters used by the server in processing requests.

HTTP Parameter Pollution Example

A web application has a feature to retrieve user data based on the parameters given in the URL. For example, the web application has an endpoint “/user?id=123” to retrieve data of users with ID 123. However, an attacker can manipulate the URL by adding duplicate or multiple parameters with different values, such as “/user?id=123&id=456”.

In the above example, duplicate “id” parameters with different values have been added to the URL. When such HTTP requests are sent to the server, the server may process the wrong values or even process different values depending on how the web application processes the parameters.

Testing for HTTP Parameter Pollution

Test Objectives:

• Identify the backend and the parsing method used.
• Assess injection points and try bypassing input filters using HPP.

Initially we have an account with the name test and the uid value that can be seen in the parameters is uid=24, then by testing HTTP parameter pollution added uid=23, the result is that the web server gives a 200 response and we can enter the uid=23 account with the name ed without the need to authenticate.

before

after

5. Testing for SQL Injection

What is SQL Injection?

SQL Injection is an attack technique on web applications that aims to manipulate user input sent to the server and cause the server to generate unwanted or even malicious SQL execution. This technique is done by manipulating user input on a web application to inject SQL code in the database query executed by the server.

SQL Injection Example

An attacker can insert single quotes (‘) in user input to break the SQL syntax executed by the server. If the server does not sanitize the input correctly, it can execute the SQL code entered by the attacker, even allowing the attacker to manipulate, retrieve, or delete data from the database.

Another example, aweb application has a login form that validates the user with the following SQL query:

SELECT * FROM users WHERE username = '$username' AND password = '$password'

In the above query, the values $username and $password are taken from the user input on the login form. However, if the web application does not properly validate the user input, an attacker can manipulate the user input by entering unauthorized or unwanted SQL syntax.

For example, an attacker may enter the following user input on the login form:

' OR '1'='1

The above input can manipulate the SQL query executed by the server, so that the executed SQL query becomes:

SELECT * FROM users WHERE username = '' OR '1'='1' AND password = '' OR '1'='1'

In the example above, the SQL query has been manipulated so that all user data will be selected by the server, without checking the actual username and password.

Testing for SQL Injection

Test Objectives:

• Identify SQL injection points.
• Assess the severity of the injection and the level of access that can be achieved through it.

By injecting the payload ‘ OR ‘1’=’1 on the login form we can log in as admin.

6. Testing for LDAP Injection

What is LDAP Injection?

LDAP Injection is a security attack on web applications that takes advantage of vulnerabilities in Lightweight Directory Access Protocol (LDAP) directory servers used for user authentication and authorization. This attack is carried out by manipulating user input in web applications that contain LDAP filters so that the LDAP server performs unwanted or even malicious queries. The LDAP Injection technique is similar to the SQL Injection technique, but is performed on an LDAP server.

LDAP Injection Example

Suppose there is a web application that uses an LDAP server to authenticate users with the following LDAP filters:

(&(objectClass=user)(sAMAccountName=$username)(userPassword=$password))

In the LDAP filter above, the values $username and $password are taken from the user input on the login form. If the web application does not properly validate the user input, an attacker can manipulate the user input by entering unauthorized or unwanted LDAP syntax.

For example, an attacker could enter the following user input on the login form:

*)(uid=*))(|(uid=*

The above input can manipulate the LDAP filter executed by the server, so that the executed LDAP filter becomes:

(&(objectClass=user)(sAMAccountName=*)(uid=*))(|(uid=*))(userPassword=$password))

In the example above, the LDAP filter has been manipulated so that all user data will be selected by the server, without checking the actual username and password.

Testing for LDAP Injection

Test Objectives:

• Identify LDAP injection points.
• Assess the severity of the injection.

PentesterLab provides a lab for LDAP testing. We have an account with a hacker name and hacker password.

Testing was done by changing the password but the result was unauthenticated.

Testing was done by changing the password but the result was unauthenticated.

Then testing is done by injecting the LDAP payload into the name even though the password entered is wrong but the login process can still be authenticated.

7. Testing for XML Injection

What is XML Injection?

XML Injection is a security attack that exploits vulnerabilities in web applications that use XML for data exchange. This attack is performed by inserting input that is intended to change the structure or content of an XML document processed by the web application. XML Injection techniques are similar to SQL Injection and LDAP Injection techniques, but are performed on XML documents.

Suppose there is a web application that uses XML to store configuration and perform user input validation. The application has a function that allows users to upload XML files for validation. When the user uploads the XML file, the application reads the file and performs input validation.

XML Injection Example

A user uploads the following XML file:

The XML file above contains an entity definition with the name xxe, which retrieves the contents of the /etc/passwd file from the server. Then, the xxe entity is inserted into the foo element using the &xxe; syntax.

If the web application does not properly validate the XML file, it may execute or process the XML element inserted by the user. In the above example, when the XML file is uploaded and processed by the web application, entity xxe will be executed, so the contents of the /etc/passwd file will be displayed on the web page or stored in the application database.

Testing for XML Injection Example

Test Objectives:

• Identify XML injection points.
• Assess the types of exploits that can be attained and their severities.

The test was conducted by trying to exploit a vulnerability in XML by inserting the following payload:

This payload attempts to load the contents of the /etc/passwd file on the server and insert it into the <body> element of the XML document. If the application processes the XML document without sanitizing it properly, this payload can be successfully executed by the attacker, resulting in confidential information such as a list of users on the server as below.

8. Testing for SSI Injection

What is SSI Injection?

Server-Side Includes (SSI) Injection is a security attack that exploits vulnerabilities in web applications that use SSI to incorporate dynamic content into web pages. SSI is a feature on web servers that allows the addition of dynamic content into web pages by using special syntax such as <! — #include file=”file.html” →.

SSI Injection attacks are performed by inserting input intended to manipulate the SSI syntax and executing commands on the web server. The goal is to manipulate information displayed or processed by the web application, such as user information or application configuration.

SSI Injection Example

Let’s say there is a web application that uses SSI to include headers and footers on web pages. The header and footer are stored in separate files and included on the web page with the following SSI syntax:

<!--#include virtual="/header.html" -->

The user then enters input intended to manipulate the SSI syntax on the web page. For example, the user enters the following input:

<!--#exec cmd="ls -la" -->

The input is entered on the input form on the web page. When the form is submitted, the web application will process the user input and include the SSI syntax entered on the web page. In the example above, the SSI syntax will execute the “ls -la” command on the web server.

Testing for SSI Injection

Test Objectives:

• Identify SSI injection points.
• Assess the severity of the injection.

9. Testing for XPath Injection

What is XPath Injection?

XPath Injection is a security attack that exploits vulnerabilities in web applications that use XPath (XML Path Language) to process user input. XPath is used to retrieve information from XML documents, such as data stored in web applications.

XPath Injection attacks are performed by entering input that is intended to manipulate XPath expressions processed by the web application. The goal is to manipulate information displayed or processed by the web application, such as user information or application configuration.

XPath Injection Example

Suppose there is a web application that uses XPath to retrieve user information from an XML database. The web application has a user search function based on user name. This function can be accessed through a URL like the following:

https://example.com/search?username=<username>

The user then enters the following input on the “username” parameter:

The input is intended to manipulate XPath expressions in web applications. In the example above, the input will result in the following XPath expression:

The XPath expression will retrieve all user data from the XML database because the XPath expression always returns true. By manipulating XPath expressions in web applications, XPath Injection attacks can retrieve sensitive information or retrieve data from XML databases that are not allowed.

Testing for XPath Injection

Test Objectives:

• Identify XPATH injection points.

By injecting the payload as below, the web application opens all existing user data from the XML database.

10. Testing for IMAP SMTP Injection

What is IMAP SMTP Injection?

IMAP SMTP Injection is a security attack on email applications that exploits vulnerabilities in the IMAP (Internet Message Access Protocol) and SMTP (Simple Mail Transfer Protocol) protocols. This attack is carried out by inserting malicious input in the email header processed by the email server.

In the IMAP protocol, IMAP Injection attacks can be carried out by inserting malicious input in the IMAP command sent to the email server. This attack can allow attackers to access user emails, change or delete emails, or gain access to the email server itself.

While on the SMTP protocol, SMTP Injection attacks can be carried out by entering malicious input in email headers such as From, To, Subject, and others. This attack can allow the attacker to spoof the user’s email, send email spam, or gain access to the user’s email server.

IMAP SMTP Injection Example

An attacker can manipulate email headers in an email application using IMAP SMTP Injection. For example, an attacker can insert malicious input in email headers such as “From” or “To” in emails sent by users.

For example, an attacker can insert the following input in the “From” header of an email:

"From: attacker@example.com\r\nBcc: victim@example.com\r\n"

The input is intended to manipulate the email header and add the victim’s email address to the Bcc (Blind Carbon Copy). This way, the victim will receive a copy of the email without the knowledge of the sender or primary recipient.

Testing for IMAP SMTP Injection

Test Objectives:

• Identify IMAP/SMTP injection points.
• Understand the data flow and deployment structure of the system.
• Assess the injection impacts.

11. Testing for Code Injection

What is Code Injection?

Code injection is an application security attack that allows an attacker to insert malicious code into a running application. This attack is usually done by exploiting vulnerabilities in inputs that are not properly validated.

During a code injection attack, an attacker can insert malicious code into inputs provided by the application such as form inputs, URL parameters, or cookies. This malicious code will then be executed by the application by mistake, resulting in damage to the application or even the server running the application.

Code injection attacks can be of various types, such as SQL injection, LDAP injection, XPath injection, or SSI injection. These attacks can be very dangerous as the attacker can gain access to the system or sensitive data stored by the application.

Code Injection Example

An example of a code injection attack using SQL injection, suppose a web application has a login feature that requests a username and password from the user to verify their identity. The login form then sends the data to the server using the POST method and the server performs an SQL query to verify the existence of the username and password in the database.

Example of PHP code used by the server:

<?php
$uname = $_POST['username'];
$pass = $_POST['password'];
$sql = "SELECT * FROM users WHERE username='$uname' AND password='$pass'";
$result = mysqli_query($con,$sql);
if(mysqli_num_rows($result) == 1) {
    // login berhasil
} else {
    // login gagal
}
?>

In the code above, the use of the $uname and $pass parameters in the SQL query is not properly validated. An attacker can manipulate the input on the login form by entering a malicious SQL string in the username input, as follows:

' OR '1'='1

The string is intended to manipulate the SQL query into the following:

SELECT * FROM users WHERE username='' OR '1'='1' AND password='$pass'

In this example, the attacker successfully manipulates the SQL query and logs into the application without needing to know the correct password. This attack is particularly dangerous because the attacker can gain access to sensitive data stored by the application, such as user data or credit card information.

Testing for Code Injection

Test Objectives:

• Identify injection points where you can inject code into the application.
• Assess the injection severity.

Code injection testing is the same as SQL injection testing above.

12. Testing for Command Injection

What is Command Injection?

Command injection is an application security attack that allows an attacker to insert malicious operating system commands (commands) into the input of an application that is run on a shell or command prompt. This attack is usually done by exploiting vulnerabilities in inputs that are not properly validated.

During a command injection attack, an attacker can insert a malicious operating system command into input provided by the application such as form input, URL parameters, or cookies. These commands will then be executed by the operating system by mistake, resulting in damage to the operating system or even the server running the application.

An example of a command injection attack that utilizes input on a web application running on a Linux operating system. Suppose a web application has a feature to ping an IP address entered by a user. The application receives an IP address input from the user and sends a ping command to that address using the shell.

Example of PHP code used by the server:

<?php
$ip = $_GET['ip'];
$pingresult = shell_exec("ping -c 4 $ip");
echo "<pre>$pingresult</pre>";
?>

In the above code, the shell_exec() command is used to execute the ping command in the shell. Input from the user $ip is entered into the ping command without any validation and sanitization.

An attacker can manipulate the input to the application by entering a malicious shell command on the ip parameter, as follows:

127.0.0.1; ls -la

The string is intended to manipulate the ping command into the following:

ping -c 4 127.0.0.1; ls -la

In this example, the attacker successfully inserted the shell command ls -la into the ping command executed in the shell. The ls -la command will be executed in the shell working directory being used by the server, and the results will be displayed on the web page as the output of the ping command.

Testing for Command Injection

Test Objectives:

• Identify and assess the command injection points.

Using the paylod example above 127.0.0.1; ls -la, the web application will execute the ls -la command.

13. Testing for Format String Injection

What is Format String Injection?

Format string injection is a security attack on applications that exploits weaknesses in string formatting. In this attack, the attacker manipulates the format string used by the application to print text, thereby obtaining sensitive information from the application or even taking control of the program.

This attack occurs when the application allows the user to control the format string used in the output without carefully validating the input. By manipulating the format string, the attacker can read or write data to memory addresses that should not be allowed.

Format string injection typically occurs in applications written in the C or C++ programming languages, where string and format manipulation is often done directly at the bit and byte level.

Example of format string injection attack in C programming language.

#include <stdio.h>

int main(int argc, char **argv) {
    char buffer[100];
    sprintf(buffer, argv[1]);
    printf(buffer);
    return 0;
}

In the code example above, the C program accepts an input from the user and prints the input to the screen using the printf() function. However, the input is copied into the buffer without any validation or sanitization.

If the attacker enters input containing format string characters, such as %s or %n, then the printf() function will print the values on the stack above the buffer. This can reveal sensitive information such as the value of local variables or memory addresses.

An example of input that manipulates the format string in the above program:

./formatstring %x.%x.%x.%x

The resulting output prints out memory addresses and values on the stack, which can be manipulated by the attacker to find sensitive values or even take control of the program.

Testing for Format String Injection

Test Objectives:

• Assess whether injecting format string conversion specifiers into user-controlled fields causes undesired behaviour from the application.

14. Testing for Incubated Vulnerability

What is Incubated Vulnerability?

Incubated vulnerabilities are security vulnerabilities that exist in an application or system, but have not yet been discovered or reported by security researchers or hackers. These vulnerabilities can arise due to errors in system design or implementation, or due to changes in the environment being used.

Here are some common examples of incubation vulnerabilities:

• Vulnerabilities that arise as a result of system or application updates that are not thoroughly tested, leaving security holes undetected.
• Vulnerabilities in web applications that are not detected by firewalls or intrusion detection systems, allowing SQL injection or cross-site scripting (XSS) attacks.
• Vulnerabilities in the system caused by misconfiguration or insecure default settings.
• Vulnerabilities that arise from the interaction between multiple complex systems or applications, allowing for undetected security holes.
• Vulnerabilities in applications or systems that result from the addition of new features or design changes, allowing attackers to exploit new loopholes that have not yet been detected.

Testing for Incubated Vulnerability

Test Objectives:

• Identify injections that are stored and require a recall step to the stored injection.
• Understand how a recall step could occur.
• Set listeners or activate the recall step if possible.

15. Testing for HTTP Splitting Smuggling

What is HTTP Splitting?

HTTP Splitting is an attack technique that manipulates user input to insert newline or carriage return characters in HTTP requests. This technique aims to split the HTTP request into two parts, namely the header and the body, thus allowing the attacker to modify the header content received by the server. This attack can allow the attacker to perform various actions, such as changing the location or content of web pages generated by the server, accessing sensitive data, and performing other actions that are not authorized by the server.

HTTP Splitting payload example:

GET /index.html HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Cookie: sessionid=1234567890%0D%0ASet-Cookie:%20maliciousCookie%3Dtrue
Connection: close

In the example above, the attacker inserted %0D%0A (newline) in the Cookies section, which allowed them to insert an additional Set-Cookie header that the server should not have allowed. The Set-Cookie header inserted by the attacker can then be used to perform other attacks such as session hijacking.

What is HTTP Smuggling?

HTTP smuggling is a type of security attack that utilizes loopholes in the implementation of the HTTP protocol. This attack occurs when there is a difference in interpretation of the HTTP header between the proxy server and the backend server, allowing firewall bypass, filtering, or network traffic manipulation attacks. HTTP smuggling is usually done by sending invalid requests or hidden payloads over the HTTP protocol, thus exploiting loopholes in the parsing or buffering mechanisms within the web application or server. This attack can adversely affect the confidentiality, integrity, and availability of data.

Here is an example of an HTTP Smuggling payload:

POST / HTTP/1.1
Content-Length: 3
Transfer-Encoding: chunked

8
0\r\n
GET /hidden_content HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:58.0) Gecko/20100101 Firefox/58.0
Content-Length: 0
Transfer-Encoding: chunked

0

In this example, the attacker exploits a weakness in the header parsing implementation that causes the server to consider the two requests as one valid request. The first request (POST) is sent with a Transfer-Encoding: chunked header and contains 8 characters. In the next section, there is a second request (GET) that is included in the chunked encoding with a size of 0.

When the server or proxy receives the request, they will process it as one valid request and then perform a GET request on the target desired by the attacker (example.com/hidden_content). In this case, the attacker can access hidden content that cannot be accessed by other users.

Testing for HTTP Splitting Smuggling

Test Objectives:

• Assess if the application is vulnerable to splitting, identifying what possible attacks are achievable.
• Assess if the chain of communication is vulnerable to smuggling, identifying what possible attacks are achievable.

16. Testing for HTTP Incoming Requests

What is HTTP Incoming Request?

HTTP Incoming Requests are requests sent by a client (such as a web browser) to a web server via the HTTP protocol to request information or resources from the server. This request consists of several elements, including method, URI, header, body (optional), and protocol version.

HTTP Incoming Requests example on the GET request for the main page of the website:

GET / HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive

Testing for HTTP Incoming Request

Test Objectives:

• Monitor all incoming and outgoing HTTP requests to the Web Server to inspect any suspicious requests.
• Monitor HTTP traffic without changes of end user Browser proxy or client-side application.

17. Testing for Host Header Injection

What is Host Header Injection?

Host Header Injection is a security attack on web applications that exploits a vulnerability in the way the server interprets the Host header in HTTP requests. In general, the Host header is used to specify the address of the destination domain when a client makes an HTTP request to the server. However, by using Host Header Injection, an attacker can insert a manipulated Host header value that can redirect the request to a different site or server than intended.

For example, a website receives the following HTTP request from a client:

GET /login.php HTTP/1.1
Host: www.example.com

However, an attacker can manipulate the Host header by sending the following HTTP request:

GET /login.php HTTP/1.1
Host: www.attacker.com

In this example, the server would perceive that the request came from www.attacker.com instead of www.example.com, which could allow an attacker to conduct a phishing attack or redirect users to a fake site that looks the same as the real one.

Testing for Header Injection

Test Objectives:

• Assess if the Host header is being parsed dynamically in the application.
• Bypass security controls that rely on the header.

18. Testing for Server-side Template Injection

What is Server-side Template Injection?

Server-side Template Injection (SSTI) is an attack that exploits vulnerabilities in web applications that use template engines to build dynamic web content. In an SSTI attack, an attacker exploits weaknesses in the template engine used by the web application to insert and execute insecure code, such as JavaScript code or other scripting languages.

In an SSTI attack, an attacker can insert malicious code into a web application input, such as a search box or contact form, which is then executed by the template engine. This can lead to the execution of malicious code on the server or the disclosure of sensitive information.

For example, a website uses the Jinja2 template engine to build a dynamic web interface. In this case, a search box on the website allows users to search for articles with certain keywords. However, an SSTI attack can be carried out by inserting malicious code into the search box, such as:

{{ 7*'7' }}

In this example, the attacker exploited a flaw in the Jinja2 template engine to execute Python code on the server, which would result in a ‘49’ output. Thus, the attacker can use SSTI techniques to execute malicious code on the server.

Testing for Server-side Template Injection

Test Objectives:

• Detect template injection vulnerability points.
• Identify the templating engine.
• Build the exploit.

The SSTI test below uses the lab from PortSwigger.

• In the example below the GET request uses the message parameter to render “Unfortunately this product is out of stock” on the home page.

• We have an ERB template syntax which is <%=7*7 %> which if URL-encoded becomes <%25%3d+7*7+%25>, if the payload is successful then the value 49 will appear. This indicates that we may have a server-side template injection vulnerability.

• Then testing was done by finding the system() method from the Ruby documentation to execute an arbitrary operating system command to delete the carlos file.
• Payload to delete Carlos’s file as follows:

<%= system("rm /home/carlos/morale.txt") %>

• The result of the URL-encoded payload above is:

<%25+system("rm+/home/carlos/morale.txt")+%25>

• Then the above payload is injected into the message parameters and the SSTI test is successfully performed.

19. Testing for Server-Side Request Forgery

What is Server-Side Request Foregery?

Server-Side Request Forgery (SSRF) is an attack on web applications that allows an attacker to force the server to make requests to other network resources with the aim of retrieving information or executing unwanted actions. This attack is performed by manipulating HTTP requests made by the web application on the server.

An attacker can exploit the SSRF vulnerability by inserting the URL intended to be attacked into the HTTP request made by the web application. If the server accepts the request and takes the requested action, the attacker can gain access to network resources and perform unwanted actions, such as retrieving sensitive data or accessing other systems within the network.

For example, a web application that allows users to upload files to a server can be the target of an SSRF attack if it is not secure enough. In this case, an attacker can manipulate HTTP requests made by the web application to load files from the URL intended to be attacked, such as:

POST /upload HTTP/1.1
Host: example.com
Content-Type: application/octet-stream
Content-Length: 123

file content...

&redirect=http://attacker.com

In this example, the attacker has inserted the ‘redirect’ parameter with the value of the URL to attack into the HTTP request made by the web application. If the server does not validate the URL entered by the user, the HTTP request will be sent to the URL intended for attack and the attacker can take advantage of access to network resources to perform unwanted actions.

Testing for Server-Side Request Forgery

Test Objectives:

• Identify SSRF injection points.
• Test if the injection points are exploitable.
• Asses the severity of the vulnerability

The SSRF test below uses the lab provided by PortSwigger.

• Initially check stock points to the URL in stockApi.

• Then the SSRF attack is carried out by changing the URL in stockApi to the URL http://localhost/admin. The result is that the web server gives a 200 response which means that the SSRF attack can be carried out, and hackers can enter the admin page.

• Then the hacker can delete the user carlos.

References:

HTTP Host header attacks | Web Security Academy

Server-side template injection | Web Security Academy

What is SSRF (Server-side request forgery)? Tutorial & Examples | Web Security Academy