1

The main technology behind any web application is HTTP (HyperText Transfer Protocol). HTTP uses a message-based model, in which a client sends an HTTP request and the server sends back an HTTP response. HTTP by itself is stateless, in the sense that it doesnot require the server to maintain a state over multiple requests. However, web applications that are on top of HTTP maintain their state both at the server side (e.g., by means of session variables) and at the client side (e.g., by means of cookies).

2

The core security problem of web application (like all the types of applications) is thatusers can submit arbitrary input. However, in web applications this is particularlydifficult to address, since the possible inputs are many. In practice, all the content of an HTTP request is tainted: the requested URL, the parameters, the HTTP headers, the request body, etc. In addition, requests can arrive in any sequence, thus we cannotassume a particular order in the page requests, for example the order given by the linksin the HTML code. This is true also in a non-adversarial situation, because honestclients can press the back button, or bookmark URLs to access them directly, etc.Another assumption that we have to make is that attackers may not use (only) browsers to attack our web application. There are many tools available that permitattackers to change anything in the HTTP request, read anything in the HTTP response(for example cookies, hidden fields, and HTTP headers) and perform requests in quantity and rates impossible with normal browsers.

3

Imagine on online-shopping website in which users can select products from a catalog and buy them by giving credit card and shipping information. The order placing functionality follows these steps: (1) The user browses the product catalog, and adds some items to the shopping basket by clicking “Add” buttons. The content of the shopping basket is stored on a cookie, in such a way that server’s database does not have to maintain all the costumers’ shopping baskets. (2) If the user adds some particular combinations of items to the shopping basket, then a special item that represents a 25% discount is automatically added. (3) The user clicks on a “Finalize order” button, which stores the shopping basket on server and leads the user to a page where (s)he can insert credit card information (number, expiration date, etc.). (4) The user clicks on a “Buy” button, which stores the credit card information on server and leads to a page where the user can insert shipping information (name, address, etc.). (5) Finally, the user clicks on a “Ship order” button, which stores the shipping information on server, places the order on server, and leads back to the product catalog page.

4

A first vulnerability comes from the fact that the user can remove items from their shopping basket by simply manipulating the cookies. A malicious user wanting to save money for an item “A” could add to the basket the combination of items to trigger the 25% discount, and then manually remove all the items except the item “A” and the discount item. In such a way, the user obtains a non-authorized 25% discount on the item “A”. In general, saving a security-critical state (in this case, the right of a 25% discount) with a non-protected client-side variable (a cookie) probably leads to vulnerabilities in the application logic. Security-critical states have to be saved at the server side, which is trusted.

5

A second vulnerability comes from the fact that the user can perform HTTP requests in any sequence, possibly different to the one driven by the links. A malicious user could skip the request that sends the credit card information to the server-side database, and perform directly the request that sends the shipping information. In this way, the user could place an order finalized for shipping but that had not actually been paid for. In general, no assumptions should be made on the sequence of user’s request. In web applications there is not such a thing as a “control flow” through successive HTTP requests. Every request must be processed by taking into account that the user could have come from any other request, and it could have any state. Thus, in multi-step procedures, every step must first check the precedent steps to have been performed correctly.

6

7

This PHP code performs a simple login procedure by matching a user identifier and a (hashed) password provided by the client as HTTP POST parameters on a database of users. If the user-provided identifier $name and the hashed password $pwdHash do not match any tuple in the ‘users’ table, then an authentication error will be raised. Otherwise, a personalized welcome message will be printed and a new active session will be registered. The query is built by inserting the values of $name and $pwdHash in a skeleton query string.

8

The code works normally if the inputs are those expected, but the behavior is unexpected if the input contains SQL symbols. Consider an attacker that sends the above malicious user ID, which contains SQL symbols that are interpreted as code by the victim system. The “’” character closes the string literal in the query string, and the “-- “ (with the trailing space) symbol makes the SQL interpreter to ignore the successive query, thus bypassing the password check. The attacker gains access to the system with the privileges of the user “admin”. This is an example of SQL injection attack. Despite such an attack is quite simple, it represents one of the most common and devastating attacks in the web.

9

Despite its simplicity, this is one of the most common and devastating attacks of the web according to OWASP. This slide shows the OWASP Top 10 Web Application Security Risks of 2017, which is a list of the currently most dangerous web vulnerabilities in terms of prevalence (how much the vulnerability is widespread), exploitability, and technical impact. Bypassing authentication is not the only possible impact of a SQL injection. Other effects include escalating privileges, stealing data, adding or modifying data, partially or totally deleting a database.

10

The aforementioned problem is not specific of SQL, but of all the interpretedlanguages, for example LDAP, XPath, etc. Such languages are very prevalent in web applications, especially for interfacing back-end components like databases. In a typicalweb application, user-supplied data is received, manipulated, and then acted on possibly by means of some interpreter. In this case, the interpreter will processinstructions of the web programmer mixed to user-supplied data. If this mix betweeninstructions and tainted data is not done properly, an attacker can send crafted input that breaks out of the data context, usually by injecting some syntax that has a meaning in the interpreted language. As a result, part of the attacker’s input isinterpreted as code (code injection) and executed as legitimate code written by the programmer.

11

The tautology technique consists in injecting a condition wich always evaluates to true(e.g., 1=1) in a WHERE clause in order to bypass it somehow. Imagine that the WHERE condition of the previous example had the password and the username checksappearing in a different order, like shown in the above slide. In this case, the simplecommenting technique cannot be applied. However, the attacker can bypass authentication anyway with the tautology technique, by injecting the following input:$name = admin' OR 'a'='aSince the WHERE clause is always true, then the query will return all the tuples of the ‘users’ table. Thus the attacker can bypass the authentication. Note that here we didnot use a trailing comment symbol (--) but a more «elegant» quote balancingtechnique, which consists in injecting an even number of quotation marks in such a way all string literals are «closed» in the resulting query, thus avoiding syntax errors. The final effect is the same as using the comment symbol, but quote balancing works evenin the case the comment symbol is sanitized by the application.The clause commenting and the tautology techniques can also be used to steal data. For example, a webpage that displays some information of the current user can be forced to display information of all the users by making the WHERE clause evaluatealways to true.

12

Whitelisting inputs and rejecting them if they contain invalid symbols is always a goodpractice, but it may be insufficient for SQL injection. Indeed, many SQL symbols appearin legitimate field values (e.g., the name «Randy O'Brian» contains the operator «and» and the symbol «'»). If we accept the «'» symbol, then the system will be vulnerable. Ifwe reject it, then the system will reject legitimate names (false positive). Anotherapproach is input escaping, which consists in substituting characters interpreted as SQL symbols (e.g., «'») with corresponding sequences interpreted as string symbols (e.g., «\'» in MySQL), which are thus safe to be concatenated to form string literals.

A more definitive solution are prepared statements, which is a technique by which the query is built in two separate stages: SQL code first and then input parameters. Prepared statements were originally introduced for improving the performance of executing many times the same query with different parameters. As a secondary effect, prepared statements also make SQL injection attacks infeasible.

13

This code snippet shows how to escape inputs with the mysql_real_escape_string() PHP function. Note that we escaped also the $pwdHash variable, even though there isnot an evident way to exploit such a variable to inject SQL code. In principle, everytainted data should be escaped before being concatenated in the query. This makes thissanitization method quite error-prone, since a single missing escaping could lead to a vulnerability.

14

A more definitive solution are prepared statements, which is a technique by which the query is built in two separate stages: SQL code first and then input parameters. Prepared statements were originally introduced for improving the performance of executing many times the same query with different parameters. As a secondary effect, prepared statements also make SQL injection attacks infeasible. Prepared statementsare available only from PHP 5.0, as part of the «improved» MySQL APIs (mysqli_*()).This code snippet shows an example of prepared statement in PHP language with MySQL. The function mysqli_prepare() prepares a SQL query defined up to twoparameters, indicated by two «?» symbols in the query string. The parameters are inserted in the prepared query afterwards, with the functionmysqli_stmt_bind_param(), where 'ss‘ stands for «two parameters, both of stringtype». The mysqli_stmt_bind_param() function correctly escapes the parameters in such a way that no SQL injection attack is possible. The followingmysql_stmt_execute(), mysqli_stmt_get_result(), and mysqli_stmt_close() functionsrespectively executes the query, retrieves the result, and deallocates the preparedstatement.

15

16

Cross-site scripting (XSS) is an attack by which an attacker injects some malicious client-side code (e.g., Javascript code) in a web page provided by a legitimate server. Suchmalicious code is then executed by the victim client.In the example above, the server shows an input field where the user can input a credit card number. The default value of such a field is provided by the client through an HTTP GET parameter.

17

However, such a parameter could contain HTML code, so that an attacker can inject a <script> tag containing some malicious Javascript code.

18

The attack follows the above schema. The adversary deceives a victim into following a particular link to a honest server, which contains the injected code as an HTTP GET parameter. The honest server then forms a web page containing the malicious code, which is finally executed by the victim. The malicious code can do various things. Typically, it sends somehow to the attacker the session ID that the victim user hasestablished with the honest server, in such a way the attacker can do operations (e.g., money transferts) on behalf of the victim user (session hijacking). Cross-site scripting isparticularly dangerous because the client browser trusts the honest server, so it couldbe configured the execute scripts sent by the server without any protection.

19

The previous example shows the reflected XSS technique. Another, more devastating, technique is the stored XSS. In the stored XSS, the attacker makes the server store the injected malicious code, so that the server builds web pages containing it to manyclients.

20

A general countermeasure is escaping all the untrusted inputs before including them in the HTML code. A way to do that in the PHP language is to use the htmlspecialchars() function. Such a function translates the «'» character into «&#x27», the «>» characterinto «&gt», etc. so that the untrusted input is totally interpreted as data.

21