CS Web Application Attacks
These days, web applications are ubiquitous and are utilized to manage nearly every aspect of daily life. We will examine web application security and attacks in this part.
IDOR ("Insecure Direct Object Reference")
IDOR vulnerabilities occur when resource access permission criteria are not enforced by developers.
Eve can access Alice’s papers by just altering an identifier, such as the document Rest argument.
Attackers are able to enumerate values and test access to other data points when the web application does not enforce authorization between objects.
For instance, the pseudo-code below can be present but without displaying any authorization indicators:
$id = getInputFromUser();
$doc = getDocument($id);
return $doc;
The aforementioned code requests input from the user, runs without validation or sanitization, looks up the document directly using the getDocument function, and returns it.
Verifying the privileges would be a more effective implementation.
$id = getInputFromUser();
$user = findUsername();
$doc = "";
if (hasAccessToDocument($user, $id)) {
$doc = getDocument($id);
} else {
$doc = "Not authorized for this document";
}
return $doc;
These kinds of vulnerabilities are straightforward to identify because all you need to do is alter a single number to check if you can access another person’s data. This issue can be avoided by first confirming the user’s authorization.
Note: Code that looks like genuine code but may not function is called pseudo code. It’s employed to create a working code example.
Avoiding "Magic Numbers"
When referencing data, an application wants to stay away from using numerical sequences. The papers in the IDOR example had identifiers ranging from 1000 to 1002. These numbers are sometimes referred to as “Magic Numbers” because they can all be readily enumerated and they point straight to a server resource, such as a database. An attacker may, for instance, verify every document identification between 0 and 10,000 and log any results that grant access to data.
Use of GUID (“Globally Unique Identifier”) or UUID (“Universally Unique Identifier”) for data referencing is useful, even though authorization should be performed correctly. The randomness inherent in the number production process makes these identifiers globally unique and hard to count.
A GUID may appear like this:
- 3377d5a6-236e-4d68-be9c-e91b22afd216
Note: It is not simple to enumerate, as one would quickly discover if one were to examine the mathematics involved in estimating the number above. The GUID or UUID prevents this from happening. Enumeration is a technique that may be used to go through every potential choice of a value.
SQL Injection
A database is linked to numerous online apps. All of the data that the web application wants to save and use is stored in the database.
With the use of a technique called SQL Injection, an attacker can change the SQL (“Structured Query Language”) that the web application’s developer is utilizing. Usually, this occurs as a result of improper data sanitization. SQL is used regularly by developers to access database resources.
Eve enters the following value in the request shown in the preceding graphic: 1000′ OR ‘1’=’1
The database interprets this as the statement being always true, which leads to the resultant SQL Query returning every row in the table. Consider this: every time the database receives a request with a value that can be 1000 OR 1 is equal to 1, it will always return a value! This is only one example of the numerous SQL methods and operations available to us for manipulating syntax.
An example of pseudo-code with a SQL Injection vulnerability is shown below.
$username = getUserName();
$pw = getPassword();
$user = mysql_query("SELECT * FROM userTable WHERE username = $username AND password = $pw");
if ($user) {
$loggedIn = True;
} else {
$loggedIn = False;
}
It is evident that neither the username nor the password variables have been sanitized; rather, the SQL uses them directly, which creates the vulnerability. In the event that the query returns anything, the code permits the $loggedIn variable to be set.
An attacker might easily create a URL against the target domain that contains the attack in order to take advantage of this:
/login?username=admin&password=password' OR '1'='1
Even though we don’t know the password, the password variable is set to contain the SQL characters, which causes the resulting SQL string to return a record. The SQL query that would be produced is:
SELECT * FROM userTable WHERE username = 'admin' AND password = 'password' OR '1'='1'
It is advised to use parameterized queries to prevent SQL Injections. The developers take great effort to guarantee that every input to a parameterized query is declared as a particular value and type. Here is an illustration of what is regarded as a secure implementation of the code mentioned above:
$username = getUserName();
$pw = getPassword();
$parameterizedQuery = prepare_query("SELECT * FROM userTable where username = ? and password = ?");
$parameterizedQuery.setString(1, $username)
$parameterizedQuery.setString(2, $password)
$user = parameterizedQuery.execute();
if ($user) {
$loggedIn = True;
} else {
$loggedIn = False;
}
The developer has explicitly stated in the example above that parameter 1 should be a string that contains the username, and that parameter 2 should contain the password.
Note: SQL Injection allows an attacker to trick an application or database into executing unauthorized SQL code because developers fail to properly sanitize user input.
XSS ("Cross-Site Scripting")
XSS attacks users of the server by using it as a platform. The users are the target of the assault, not the server itself.
All that the server does is mirror the values of the attackers, which are usually in the form of JavaScript, against users who run the attackers’ data in their own browsers. In order to execute code that the attacker supplied when a visitor clicks a link containing the attacker’s values or visits a resource on the webpage that the attacker has utilized in their attack, the attacker must create input that the server does not clean and sanitize.
This is a graphic representation of Eve sending Alice a link that triggers the XSS attack:
This kind of attack, known as a Reflected XSS, starts with Eve identifying the vulnerability. She then sends an unsuspecting victim a link containing the attack, and she waits for them to click on it. When a victim clicks the link, the attack is contained in the link and is returned to them by the webserver.
This could have code that is as basic as this example of pseudo-code:
$nickname = etNickName();
echo "Greeting $nickname, nice to meet you!";
A Stored XSS attack is a different type of XSS. The attacker in a stored cross-site scripting (XSS) attack has the ability to save content on the website, which is displayed each time a user visits. It is not necessary for someone to click on a link.
This image explains how Eve can install malicious JavaScript that, upon visiting the resource, will cause any browser to run it:
XSS attacks can achieve a variety of goals, such as:
- Stealing cookies which can be used for authentication
- Defacing the website, presenting content which the webserver did not intend to
- Phishing users in leaving credentials in fake login forms
There are various best practices to adhere to in order to guard against XSS:
- Let the webserver return CSP (“Content Security Policy”) headers which strictly decides where and how JavaScript is executed from
- Safely encode the output the webserver returns to users, effectively turning HTML characters into encoded safe characters
HTML Encoding
The web application can safely return characters that are generally dangerous thanks to HTML encoding. The encoding of the following special characters, for instance, can result in their corresponding counterparts:
| Special Character | HTML Entity |
|---|---|
| < | < |
| > | > |
| “ | " |
| & | & |
| ‘ | ' |
This generates output that is safe to show. The HTML entities can then be safely converted to values by using client-side JavaScript.
CSP ("Content Security Policy")
What kind of JavaScript is permitted to run on the webpage can be managed by the webserver. While this increases defense in depth in the event of an unknown vulnerability, it does not eliminate vulnerabilities.
A typical and stringent CSP is to give the web application’s users a list of all authorized JavaScript source files.
Furthermore, it is common for CSP to block in-line JavaScript execution.
In order to facilitate the deployment and identification of ongoing attacks, CSP permits clients to report violations of the protocol to a URL that the server provides.
Web-Application Scanning
Web application scanners are widely available. These make it possible to check programs for flaws like XSS and SQL Injection. A web-application scanner, in contrast to a network vulnerability scanner, is usually based on heuristics rather than signatures and lists of known vulnerabilities.
When incorporated into development procedures like CD (“Continuous Delivery”) and CI (“Continuous Integration”), web application scanners are very helpful.
