Web application vulnerabilities refer to bugs or vulnerabilities in web-based software. They are caused by applications that do not validate or sanitize user inputs, logic flaws, or misconfigured web servers. These vulnerabilities can be exploited to compromise the security of the application. Let’s discuss some of the high severity vulnerabilities which exist in web applications.
1. SQL Injection
SQL Injection vulnerabilities occur when user-supplied inputs are used directly in SQL queries without being sanitized. This vulnerability allows an attacker to inject arbitrary SQL statements, by which an attacker can fetch sensitive information from the database. If successfully exploited, hackers can read/delete/update information in the database.
Exploitation: We have an application that prompts the user to enter his name and fetches the information based on the input he provided.
So, for initial testing of SQLi, I passed ‘ as the name and application displayed a different response than before. The application is vulnerable to SQLi as it is just taking the inputs and without sanitization and transferring them to the SQL query, which is used to fetch the details from the database.
So, to retrieve all of the data stored in the database, let’s try the classic SQLi payload, i.e.,‘ OR’1’=’1. Using this instead of a name displays all details saved in the database, including the administrator’s information.
Patch:
- We can use prepared statements or stored procedures as they do not include any unsafe dynamic SQL query.
- Always filter and sanitize the user input before passing them to the SQL queries.
2. Cross-Site Scripting/XSS
Cross-site scripting is a vulnerability that allows malicious scripts to be injected into legitimate websites.This occurs because the website does not filter or sanitize user inputs before including them in its later HTTP response in an unsafe way.
Types: XSS commonly have two types
- Stored XSS: In this type of XSS the injected malicious script or javascript payload gets saved in the database permanently and gets executed whenever any user visits on that page. There is no need to send a URL or manipulate the user to click on a URL from his side.
- Reflected XSS: This is the most common form of XSS; in this case, the attacker’s payload must be included in the request sent to the server. An attacker must send a URL containing the payload in order to target a user and should manipulate the user to click on it, so that the XSS can be exploited.
Exploitation: As you can see in the screenshot below, we have an application that asks for the user’s name and then includes it in subsequent responses.
Whatever value you pass in this parameter directly gets reflected in further responses. This implies that there is a possibility of XSS. So let’s start with a very basic payload to execute the XSS, i.e. “ <script>alert(1)</script>”. As the value of the name parameter must be included in the request going to the server, this is reflected in XSS. As soon as I inserted the JS payload it got executed.
Attackers can do a lot more with XSS, such as steal cookies, redirect users to malicious websites, and so on.
Patch:
a) Sanitize the user input before including it in further HTTP responses.
b) Use X-XSS protection header and set it to mode 1.
3. Local File Inclusion/Directory Traversal
Such a vulnerability allows an attacker to access confidential files from the server on which the application is running. This happens when the path used by the application to access files hasn’t been properly validated. As a result, attackers can gain control of the path and force the server to read sensitive data.or files. In Linux, there are a few regular files that attackers often attempt to obtain to demonstrate effective exploitation of a directory traversal vulnerability.
- /etc/passwd
- /etc/shadow
Example: This application fetches a page using page parameters and embeds the page’s content on the website.
When I changed the “page” parameter and attempted to fetch a standard file, an error message appeared, indicating that the application attempted to fetch the file but it did not exist.
Now, I used a few dot dot forward slash (../) notations to get myself out from the current directory and then fetch the /etc/passwd file from the root directory of the application. I was able to retrieve the /etc/passwd file using the LFI or directory traversal technique as soon as I passed the intended parameter.
Patch:.
a) Sanitize the user input path and do not allow absolute (../) path in the URL.
b) Implement whitelisting of accepted file paths.
4. File Upload
File upload is an extremely common functionality provided by web applications to their users. If uploaded files are not managed properly, they may pose a significant risk to the application—an attacker can upload a web shell or a malicious file and take control of the whole server.
Exploitation: This application allows us to upload the image file.
I uploaded a valid image file to get the overview of how the uploading process works.
After uploading, the file application actually shows us the file path that can be used to access the file. So all of the valid conditions are met here: we can upload a file and have access to it, and if we upload a web shell, we can execute the commands by accessing the file.
Let’s use a PHP web shell to take advantage of the file upload.
I failed to upload the PHP web shell because the program appears to be checking the file’s content and not allowing me to upload non-image files.
This time, let’s use a proxy to intercept the request to upload the file that is being sent to the server.
.
I modified the content type to “image/jpeg”. This time the file was uploaded successfully on the server and I was able to execute the commands.
Patch:
a) Implementing whitelisting of accepted file extensions.
b) Uploaded files should have to be validated and their mime type should have to be checked.
