What is Web Exploitation?
Web exploitation involves taking advantage of flaws or weaknesses that are present in a web application. When an application uses data inputs that are not sanitized or validated, a hacker can easily exploit it and compromize the security of the web application.
What parts of a web application are susceptible to attack? A web application usually has a web server, an application server and a database. Any of these components can be exploited if they are not secure. With websites handling sensitive data regarding users across the world, it is important to recognize vulnerabilities in the setup and guard against them.
There are several different web exploitation techniques. Here, we take a look at SQL injection and cross site scripting labs, and methods of guarding against these attacks.
SQL Injection
SQL Injection is a common web vulnerability that occurs when an application makes a modifiable and insecure query to its database. This allows attackers to view data which they should typically be unable to access.
SQL Injection - Portswigger Lab
Let’s take a look at the above lab to get a better understanding of SQL injection.
Note: You’ll need a Portswigger account in order to solve the lab. Burpsuite is another helpful tool that you can use to scan web applications for vulnerabilities.
The goal here is to obtain the details of all released and unreleased products. Navigate to the proxy tab on Burpsuite, and open Burp’s browser. Once you access the lab using the above link, turn on the ‘intercept’ option in Burpsuite. This will intercept the HTTP request to the server, and allow you to examine the manner in which requests and data are handled.
Now that intercept is on, try choosing one of the categories from the different options listed(shown here):
The request is intercepted by Burpsuite, and you can now view the details of the request – the first line mentions the category. Notice that the data is not validated in any way. Is it possible to insert something here that would return details of unreleased items too?
1=1 is a condition that always evaluates to true. We can include that along with the category option using the OR operator in SQL. Now, the query is modified to select all items, as even if the category is different, the expression returns true since we have appended the ‘1=1’ condition. [The hyphens (–) that you see in the screenshot are a comment indicator in SQL, which comments out the remainder of the query.]
Forward this request to the server, and navigate back to the browser. You’ll notice that all the products are listed, and the lab is solved!
Another option is to directly modify the URL parameter from
https://ac461ff61fdf9067c04e58b1007e0038.web-security-academy.net/filter?category=Corporate+gifts
to that given below:
https://ac461ff61fdf9067c04e58b1007e0038.web-security-academy.net/filter?category=Corporate+gifts%27+OR+1=1–
Preventing SQL Injection Attacks
SQL injection is very common, due to the fact that it targets the database - where most sensitive information is stored. There are a few simple methods to avoid SQL injection attacks in your application:
Stored Procedures
Stored procedures are codes that can be stored and used many times. The SQL statements are automatically parameterized, and the procedure is called instead of writing the same query over and over.
Parameterized Queries
In this method, the SQL statements are precompiled and the user input is supplied as parameters. With parameterized queries, the entire user input is quoted, so that the intent or behaviour of the SQL statement cannot be changed.
Cross Site Scripting (XSS)
XSS attacks exploit vulnerable websites by injecting malicious scripts into responses to web requests. An attacker sends malicious code or scripts along with seemingly benign data requests.
There are two main types of XSS attacks: reflected and stored.
Reflected XSS
Reflected XSS is non-persistent, and one of the simplest types. It arises when an application accepts data through a request, and immediately uses the data (without validation) in the response to the user.
On to the next lab: Reflected XSS - Portswigger Lab
This lab requires us to perform an XSS attack that calls the alert function. When we access the lab, we find that there are only a few articles, and a search bar. The immediate approach is to enter data by searching the blog. Enter some random text (for example, hello), and observe how the request is handled in the URL. This is what we see:
https://ac601fcb1e00eb94c0642475006600b7.web-security-academy.net/?search=hello
Interesting. The data we provide is directly passed to the request without validation. Maybe we can embed javascript using script tags in the search box. On entering the text as shown:
it executes an alert – and we’ve solved this lab.
Here, the alert() function is fairly harmless, and used without malicious intent. If an attacker found this vulnerability in a web application and performed an XSS attack, it could change the behaviour of the application entirely.
Stored XSS
Stored XSS is a persistent form of attack. Stored attacks occur when the web application receive data from requests, and include this data in responses later on.
Let’s try another lab, based on stored XSS: Stored XSS - Portswigger Lab
The instructions say to submit a comment, which executes an alert whenever the blog is viewed. This tells us that it is a form of stored XSS, because the contents are stored once submitted and loaded each time.
Each time the blog is viewed, the comments are also loaded. Select any of the blogs listed, and submit a comment. However, instead of plaintext, let us provide an alert() function within script tags:
Post your comment, and the lab is solved. When you click on “Back to Blog”, your alert is executed and a pop-up appears:
Preventing XSS Attacks
To prevent XSS attacks, try to make sure that dynamic content can’t be used to inject Javascript in the application.
Whitelisting values
If some item has only a handful of valid values, make a list of the known ‘safe’ values, and deny permission to all other input. One example is asking the user to select their country from a drop-down menu, rather than allowing them to enter it in a text field.
Escaping Dynamic Content
Usually, an application does not need to obtain raw HTML input from its users. In order to treat user input as contents of an HTML tag rather than raw HTML, we need to escape all the dynamic content provided. This process consists of replacing some important characters with the respective HTML entity encoding, for example:
” to "
; to ;
These are only a few types of web exploitation that can occur. There are many other methods of exploiting web vulnerabilities, such as denial-of-service (DoS), client-side request forgery(CSRF), and server-side request forgery(SSRF), to name a few.
References
