Most Common Web Security Vulnerabilities and How to Patch Them

Common Web Security Vulnerabilities and How to Patch Them

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. 

an example image of an application that prompts the user to enter their name and fetches information based on the input 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.

: image providing an example of a vulnerable application where SQL injection can be used to compromise the application

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.

image of SQL injection ‘OR’1’=’1 being used instead of name to gain private information

Patch:

  1. We can use prepared statements or stored procedures as they do not include any unsafe dynamic SQL query.
  2. 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.

image of application asking for name and using it in subsequent response

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. 

 image of XSS being executed as <script>alert(1)</script> command

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.

image of page being fetched using page parameters

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.

 image of an error message appearing when page parameter was changed to fetch standard file

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.

 image of the use of dot dot forward slash notations followed by etc/passwd to fetch the file from the root directory of the application

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.

 image of the screen with the option for uploading an 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.

image of test file being successfully uploaded showing that all the valid conditions have been met

 image showing the file path for the uploaded test file

Let’s use a PHP web shell to take advantage of the file upload.

 image of file upload being done of file with PHP web shell

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.

file being successfully uploaded and command being executed successfully

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.

Leave a Reply

Your email address will not be published. Required fields are marked *