{'fraction_non_alphanumeric': 0.038926174496644296, 'fraction_numerical': 0.011586012009890498, 'mean_word_length': 5.133448873483536, 'pattern_counts': {'":': 0, '<': 2, '<?xml version=': 0, '>': 2, 'https://': 2, 'lorem ipsum': 0, 'www.': 2, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
A Review of Common Web Application Breaching Techniques (SQLi, XSS, CSRF)

Regarded as one of the most popular platforms for digital services and content delivery over the internet, web application has been transforming our society for the better. However, with an increasing amount of critical services built upon web applications across government and private sectors, web applications have become a clear target for adversaries driven by financial or political motives. Although security standards such as the OWASP ASVS are being actively developed by security researchers to counteract the attacks on web applications, the concept of secure coding remains hostile for many developers, resulting in developed systems with various underlying vulnerabilities. This paper aims to provide an overview of the most common web application breaching techniques, with explanations to their working principles, proof of concept examples as well as applicable countermeasures.


INTRODUCTION
Web applications provide a competitive advantage and added convenience for enterprises of all sorts. Remote accessibility, scalability, cross-platform compatibility, rapid development are several factors pushing a business to develop its web application. From a standpoint of small business owners, having an established web application means an additional platform to conduct business, one that would allow a business to grow at an exponential rate [20][21][22][23][24].
As the demand for an interactive and feature-rich web application is growing, more client-side technologies are being used. To accommodate, the number of JavaScript libraries kept on growing, of which many were found to have a varying degree of vulnerabilities. Among the 5000 randomly chosen scan targets by Acunetix in 2020, around 25% were identified to use such vulnerable libraries [4]. Other factors such as orphaned web applications, legacy applications, short time to market also cause the security aspect of web applications to become second priority [25][26][27][28][29].
Based on the key findings from the investigation reports published by Akamai, Verizon, Acunetix, ENISA, F5 Labs, we have found that SQL Injection (SQLi), Cross-Site Scripting (XSS) and Cross-Site Request Forgery (CSRF) are amongst the most prevalent types of attacks conducted on web applications [4,5,7,8,19]. Although the reports we have referenced are prepared by different organizations, each with its unique dataset and analysis methodology, three of the said techniques have consistently made up for the majority of web application attack vectors (Verizon -48.63%, Akamai -69.60%, Acunetix -69.36%, ENISA -71.79%, F5 Labs -50.99%). And thus in this paper, these attacks, their types and prevalence in industrial trends, proof-of-concept examples, as well as their possible prevention methods are explained.

SQL Injection
Trend: Being one of the most famous and oldest attack techniques, SQL injection dates back to a 1998 article published in Phrack Magazine. Fast forward to the present, we have observed SQLi makes up 65.1% of web application attack vectors in 17 months (Nov 2017 -Mar 2019), according to the dataset analyzed by Akamai [5]. In late November 2018, over 35 million SQLi attacks were observed daily, the spike in attacks was most likely due to the holiday shopping season [5].
Mechanism: SQLi begins with an attacker embedding SQL keywords and operators within the user input, with intention of manipulating the SQL query structure to reveal, add, remove entries or even entire tables. Depending on the logic exploited, SQLi can be divided into the following categories [2]: Union-based SQLi -A union-based SQLi is an SQLi technique that takes advantage of the "UNION" SQL operator, allowing outputs of multiple "SELECT" statements to be fused into a single result, which is then returned as part of the HTTP response [9].
Error-based SQLi -An error-based SQLi leverages error messages returned by the database server to gather information about the structure of the database. Through improperly handled error messages, an attacker could obtain hostnames, IP addresses, usernames, and system information such as database version, which would be useful for extensive planning of an attack [6].
Blind SQLi -Unlike the previously mentioned SQLi techniques, blind SQLi does not rely on data returned from the server. Instead, it observes the HTTP response returned by an SQL statement (boolean-based), or the time taken to execute an SQL statement (time-based) [12]. For example, an attacker enumerates the desired piece of data, one letter at a time with the following logic, "If the first letter of the first database's name is an 'A', wait for 5 seconds". Although the process would be very time-consuming to be done manually. In reality, however, an attacker would develop tools such as SQLMap to automate the repetitive process. Impact: Successful SQLi could mean authentication bypass, information disclosure, the devastation of the entire database.

Cross-Site Scripting (XSS)
Trend: In 2020, Acunetix has found that out of the 5,000 randomly selected scan targets, 25% of them are vulnerable to at least one variant of XSS [4]. While interactive scripting has improved the web browsing experience for end-users, it also makes cross-site scripting possible.
Mechanism: Cross-site scripting begins with an attacker injecting malicious scripts (most often in Javascript) into a webpage. When a victim unknowingly opens the affected webpage, the maliciously injected script (often referred to as payload) was executed. The script injection can be achieved via a variety of methods, which classifies them into the following categories: Stored XSS -For stored XSS, the attacker attempts to leverage user input without proper data sanitization to save the malicious script permanently on the target server, message forum, comment field, etc. The stored payload is then "echoed" back to any victim who visits the page. Due to its freeloading nature, the payload could propagate through countless systems, collecting an enormous amount of information before getting detected [3,18].
Reflected XSS -A reflected XSS is carried out when a web server reflects the attacker's payload to an unknowing victim. The payload can be reflected in forms of alert popup, error message, search result, or any other response that includes part of or all of the attacker's input. The payload is typically included as part of the URI, and when embedded into a hyperlink, can be very effective in phishing attempts or social engineering attacks [3,18].
DOM-based XSS -DOM-based XSS relies on modifying the Document Object Model (DOM) in a victim's browser with the malicious payload. Unlike reflected XSS, the payload for DOM-XSS is located in the URI fragment (preceded by hash, #) and never sent to the server, it is stored as part of the DOM and executed when the browser reads from the DOM [16]. DOM-based XSS is hard to be detected because the malicious payload never leaves the victim's browser [10], unlike stored XSS and reflected XSS, in which the payload is stored in and reflected off the webserver.
Impact: Execution of the payload could lead to actions such as session, cookie stealing, keylogging, etc., of which the information could then be used to impersonate the victim.

Cross-Site Request Forgery (CSRF)
Trend Among the 5,000 randomly selected scan targets by Acunetix in 2020, 36% were found vulnerable to CSRF attacks. Under normal circumstances, when a user performs actions in a web application, the browser associates relevant cookies (of the same origin) with the HTTP request. While this has provided users with a seamless browsing experience, it also makes CSRF attacks possible.
Mechanism: In a CSRF attack, the victim is tricked to execute unwanted actions unknowingly to web applications which they are currently authenticated (i.e. not logged out of), in an attacker-controlled website [1]. CSRF attack usually begins with luring a victim into a malicious, attacker-controlled website. The malicious website then proceeds to forge a valid HTTP request to the target web application server, with the session cookie obtained from the authenticated session. From the web server's perspective, since the HTTP request is associated with valid session cookies or credentials, the request will be considered legitimate, even though the victim would be unaware of the whole process.
Impact: Successful CSRF attacks could mean statechanging operations on the server, such as changing the victim's email or password, transferring funds, goods or service purchases, sending a message, etc., with the victim's identity, but without the victim's consent [13].

Cross Site Scripting (Stored XSS)
Step Screenshot

Cross-Site Scripting (Stored XSS)
Step Screenshot

1
The CSRF demonstration is conducted on DVWA, with the security level set to low. The goal is to alter a user's password through an HTTP request forged with a malicious website.

2
By observing a legitimate password change request, it is found that the browser automatically associates parameters along with relevant cookies in an HTTP GET request. 3 The CSRF attack is carried out in an attacker-controlled site. The site comprised a line of text and a hidden image, the latter of which makes the password changing request.

4
When a victim visits the malicious site (referrer header). A password changing request with predefined parameters is initiated, while the browser associates the relevant cookie with the illegitimate request. Thereafter, the password of the victim has been changed successfully.

4.1.SQL Injection
SQL injection occurs due to insufficient input validation. In other words, it is caused by the mixing of code and data. One of the preventative measures is to practice prepared statements with parameterized queries [17], as it allows developers to predefine all SQL codes. Hence, the database can differentiate between code and data portions. For example, a username input of "sam' or '1'='1" will cause the database to match username based on the entire "sam' or '1'='1" string, instead of granting unauthorized access. Proper implementation of prepared statement would effectively nullify most SQL injection attempts

Cross-Site Scripting
In the attack analysis section, we have discussed the fundamental difference between stored and reflected XSS when compared to DOM-based XSS. The key takeaway is that, stored and reflected XSS relies on server-side HTTP request mishandling to dynamically inject payloads into the HTML, whereas most DOM XSS payloads are never sent to the server but directly injected into the client application during runtime [10]. As such, they will have different prevention methods. For stored and reflected XSS, the following preventative measures are strongly recommended: Contextual Output Encoding -Untrusted data should be encoded before being dynamically added to HTML. The type of encoding (e.g., HTML Entity/Attribute Encoding, JavaScript Encoding, URL Encoding, etc.) should vary based on the destination of the data where it is stored or displayed [14]. Consider the following example, if a user were to include the infamous XSS payload of "<script>alert(1)</script>" in a forum post, without proper output encoding, the HTML interpreter interprets it as active content, thereby executing it. With encoding, however, the payload would be translated into "&lt;script&gt; alert(1)&lt;/script&gt;", a form that is no longer dangerous to the HTML interpreter and will be handled as inactive text content.
Input Validation -User input should be validated strictly upon arriving at the server. For example, the input should be of the expected type, length or size, numeric range, free of dangerous characters before being accepted for further processing, or stored into the database. For DOM-based XSS, the following preventative measure is strongly recommended: Use safe methods -Untrusted data should be treated as displayable text, printed with methods such as document.innerText and document.innertextContent [15]. HTML rendering methods for example, element.innerHTML, element.outerHTML, document.write(), document.writeIn() should be avoided to handle untrusted data. If user input is to be expected, the input data should be sanitized on the clientside, including escaping and filtering before being used in scripts.

Cross-Site Request Forgery
A successful CSRF attack relies on the lack of identifier between legitimate and forged requests, browsers automatically associate session cookies with outbound requests. As such, CSRF attacks can be effectively prevented through the inclusion of CSRF tokens with each user request [1]. The implementation details of CSRF tokens are available in the following Figure 1.

CONCLUSIONS
This paper has focused on providing a review of the most common web application breaching techniques. From the various threat intelligence reports we have referred to, we observed a steady increase in the number of attack attempts on web applications, which can be attributed to the growing collection of scripts and automation tools available to the public, lowering the technical barrier to pull off attacks.
The ever-evolving web frameworks have enabled small businesses to offer a wide array of web applications, essentially behave like one of the larger. However, due to the lack of dedicated security staff, they are more than twice as likely to be affected by incidents with confirmed data disclosure, compared to large organizations [19]. As such, user-friendly security solutions for smaller organizations remains an unanswered question for security researchers. ents/state-of-the-internet/soti-security-web-attacksand-gaming-abuse-report-2019.pdf [6] Amorim, F. Exploring errors to reveal unauthorized information. Available from: https://www.redgate.com/simple-talk/sql/databaseadministration/exploring-errors-to-revealunauthorized-information/ [7] ENISA Threat Landscape 2020 -Web application attacks. Available from: https://www.enisa.europa.eu/publications/webapplication-attacks [8] F5 Labs 2018 Application Protection Report.