Web Exploitation

Websites all around the world are programmed using various programming languages.
While there are specific vulnerabilities in each programming language that the developer
should be aware of, there are issues fundamental to the internet that can show up regardless
of the chosen language or framework.

These vulnerabilities often show up in CTFs as web security challenges where the user
needs to exploit a bug to gain some kind of higher level privilege.

Common vulnerabilities to see in CTF challenges:

● SQL Injection
● Cross Site Request Forgery
● Cross Site Scripting(XSS)
● Server Side Request Forgery
● HTTP DoS ATTACK

At the end of this document, you will find some practice problems to help reinforce
your understanding of these concepts.
SQL Injection

SQL injection enables an attacker to manipulate the queries that an application sends to its
database. This manipulation grants the attacker unauthorised access to view data within the
database.

Furthermore, SQL injection can escalate to remote code execution, potentially granting the
attacker control over the web server where the application is hosted.

Despite being an older vulnerability, SQL injection remains prevalent in various forms,
largely due to improper sanitization of user inputs, which allows them to be directly
inserted into SQL queries. It allows the attacker to create, read, update, alter, or delete data
stored in the backend database.

How does SQL injection work?

Imagine a website that authenticates users based on username and password. The URL
looks like this:

https://www.example.com/auth/username=user&password=mypassword

The vulnerable code on the server looks like this:

<?php
$username = $_GET['username'];
$password = $_GET['password'];
$result = mysql_query("SELECT * FROM users WHERE username='$username' AND
password=’$password");
?>

When this request is reached at server, if the username and password are placed in an SQL
query directly without any filtering or sanitization, it will look like this:

SELECT * FROM users WHERE username='user' AND password='mypassword'

It retrieves all columns where username is user and password is mypassword.

Now if we change the URL like the following:

https://www.example.com/auth/username='&password=mypassword

The resultant query would be like this:

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

We closed the string where the username was supposed to be there.

Now if we make the URL as

https://www.example.com/auth/username=' OR 1==1 -- &password=mypassword

The Resultant query would look like:

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

What does the ‘ OR 1==1 -- payload mean and do?

The ' closes the string literal in the query where the actual username is supposed to come.
The OR operator checks whether either of the condition results is true.

The 1==1 condition is always true. So the whole where clause returns true.

The -- comments out the rest of the query.

Now what happens when the query is executed in the database?

It retrieves all columns(*) from table users where the username is TRUE (because 1==1 is
always true) and comments out the rest of the query.

This way we can essentially bypass the authentication method of websites.

Cross Site Request Forgery (CSRF)
A Cross Site Request Forgery or CSRF Attack, pronounced see surf, is an attack on an
authenticated user which uses a state session in order to perform state changing attacks like
a purchase, a transfer of funds, or a change of email address.

The entire premise of CSRF is based on session hijacking, usually by injecting malicious
elements within a webpage through an <img> tag or an <iframe> where references to
external resources are unverified.

Using CSRF
GET requests are often used by websites to get user input. Say a user signs in to an banking
site which assigns their browser a cookie which keeps them logged in. If they transfer some
money, the URL that is sent to the server might have the pattern:

http://securibank.com/transfer.do?acct=[RECEPIENT]&amount=[DOLLARS]

Knowing this format, an attacker can send an email with a hyperlink to be clicked on or
they can include an image tag of 0 by 0 pixels which will automatically be requested by the
browser such as:

<img src="http://securibank.com/transfer.do?acct=[RECEPIENT]&amount=[DOLLARS]"
width="0" height="0" border="
Cross Site Scripting (XSS)
Cross Site Scripting or XSS is a vulnerability where on user of an application can send
JavaScript that is executed by the browser of another user of the same application.

This is a vulnerability because JavaScript has a high degree of control over a user's web
browser.

For example JavaScript has the ability to:

● Modify the page (called the DOM)

● Send more HTTP requests
● Access cookies
By combining all of these abilities, XSS can maliciously use JavaScript to extract user's
cookies and send them to an attacker controlled server. XSS can also modify the DOM to
phish users for their passwords. This only scratches the surface of what XSS can be used to
do.

XSS is typically broken down into three categories:

● Reflected XSS
● Stored XSS
● DOM XSS

Reflected XSS
Reflected XSS is when an XSS exploit is provided through a URL parameter.

For example:
https://ctf101.org?data=<script>alert(1)</script>
You can see the XSS exploit provided in the data GET parameter. If the application is
vulnerable to reflected XSS, the application will take this data parameter value and inject it
into the DOM.
For example:

<html>
<body>
<script>alert(1)</script>
</body>
</html>

Depending on where the exploit gets injected, it may need to be constructed differently.

Also, the exploit payload can change to fit whatever the attacker needs it to do. Whether
that is to extract cookies and submit it to an external server, or to simply modify the page to
deface it.

One of the deficiencies of reflected XSS however is that it requires the victim to access the
vulnerable page from an attacker controlled resource. Notice that if the data parameter,
wasn't provided the exploit wouldn't work.

In many situations, reflected XSS is detected by the browser because it is very simple for a
browser to detect malicious XSS payloads in URLs.

Stored XSS
Stored XSS is different from reflected XSS in one key way. In reflected XSS, the exploit is
provided through a GET parameter. But in stored XSS, the exploit is provided from the
website itself.

Imagine a website that allows users to post comments. If a user can submit an XSS payload
as a comment, and then have others view that malicious comment, it would be an example
of stored XSS.
The reason being that the web site itself is serving up the XSS payload to other users. This
makes it very difficult to detect from the browser's perspective and no browser is capable of
generically preventing stored XSS from exploiting a user.

DOM XSS
DOM XSS is XSS that is due to the browser itself injecting an XSS payload into the DOM.
While the server itself may properly prevent XSS, it's possible that the client side scripts
may accidentally take a payload and insert it into the DOM and cause the payload to trigger.

The server itself is not to blame, but the client side JavaScript files are causing the issue.
Server Side Request Forgery (SSRF)
Server Side Request Forgery or SSRF is where an attacker is able to cause a web application
to send a request that the attacker defines.

For example, say there is a website that lets you take a screenshot of any site on the internet.

Under normal usage a user might ask it to take a screenshot of a page like Google, or The
New York Times. But what if a user does something more nefarious? What if they asked the
site to take a picture of http://localhost ? Or perhaps tries to access something more useful
like http://localhost/server-status ?

Depending on what the response from the site is the attacker may be able to gain additional
information about what's running on the computer itself.

In addition, the requests originating from the server would come from the server's IP not
the attackers IP. Because of that, it is possible that the attacker might be able to access
internal resources that he wouldn't normally be able to access.

Another usage for SSRF is to create a simple port scanner to scan the internal network
looking for internal services.
HTTP DoS ATTACK

An HTTP DoS attack operates at Layer 7, as opposed to a network-layer-based denial of

service attack. In this form of attack, the website is crawled programmatically to obtain a list
of pages to be viewed, while the attacker also records the amount of time the server takes to
process each page. The pages that take the longest to process are chosen, and numerous
HTTP requests are issued to the Web server, each requesting one of the chosen pages.

The Web server begins to consume resources in order to fulfil each request. It finally gives
up and stops responding when its resource constraints are reached. To carry off this attack,
attackers are known to utilise simple scripts to generate a flood of HTTP GET requests. If
the website contains only simple static HTML pages, this attack does not work very well.
However, this attack can wreak considerable damage if dynamic pages pull data from a
backend database server.
PREVENTING WEB EXPLOITATION

Preventing and disabling superfluous services, as well as shutting ports other than the Web
service port, is strongly advised. It's critical to set up a well-configured firewall or
intrusion-detection system. As previously stated, a basic firewall is insufficient; hence, a
a content-filtering firewall with Web-layer attack detection is necessary.

Securing Web portals isn't only about the Web server; it also includes database servers, Web
services, and other components. Allowing IP access to the database solely via front-end
Web servers is a smart approach from a network security standpoint. To avoid hacking
efforts, rootkit detectors, anti-virus software, and log analyzers must be run on a regular
basis.

A better authentication method should be in place between the middleware and the Web
server for increased security. Stronger encryption techniques should be used to encrypt
cookies, and SSL should be used.

As we learned previously, it is critical to employ safe programming approaches and to

follow best security practices, such as code reviews and penetration testing, when it comes
to coding. Additional processes such as input code validation and server and database-side
validation are recommended too.
Practice Problems

https://play.picoctf.org/practice/challenge/46
https://play.picoctf.org/practice/challenge/161