Where to insert the correction?

It is hard for an automated tool to decide where to apply a correction in the code of a web application. Some variants of XSS and SQLi can be corrected by using a sanitization function to make the input safe to include in the HTML or a SQL query, respectively. However, even in this case, it is often difficult to determine where to place the sanitization function call without breaking the application logic.

1 <?php

2 $a = $_GET["v"];

3 echo "<div>" . $a . "</div>";

Listing 3.1: Example of a reflected XSS vulnerability in PHP.

Taking as an example the program program of Listing 3.1, the htmlentities func- tion could be used to prevent the exploitation of the XSS vulnerability, by replacing line 2 with $a = htmlentities($_GET["v"], ENT_QUOTES);.

This would in fact remove the bug, but the htmlentities function might modify the length of the input string if it has to replace some characters with their HTML en- tity equivalents. If this program contained some additional logic based on the length of

that string, this modification could cause the application to behave erroneously. List- ing 3.2 contains an example of a program in this situation. Assume that the call to htmlentitiesmade in line 2 was added by an automated tool. Considering the in- put string <script>alert(1)</script>, the program’s control flow should enter the ”then branch” of the if statement because the input is exactly 25 characters in length. However, the call to htmlentities converts the input into it’s representation in HTML entities (&lt;script&gt;alert(1)&lt;/script&gt;), a string that is 37 char- acters in length. This causes the if statement’s condition to evaluate to false, leading to a change in the program’s behavior.

1 <?php

2 $a = htmlentities($_GET["v"], ENT_QUOTES); 3 if (strlen($a) <= 25) {

4 echo $a . " is a short string"; 5 } else {

6 echo $a . " is a long string"; 7 }

Listing 3.2: Example of a PHP program with logic based on the length of the input.

For this reason, an automated tool can not fix every application by applying the sani- tization function to the entry point. However, adding the correction closer to the sensitive sink is more difficult than it seems because there are no guarantees that the source code’s formatting will be easy to process by the tool. This can be a problem especially if the source code contains instructions that span over multiple lines or multiple instructions per line. In Listing 3.3, there is an example of a program containing an echo statement that spans over multiple lines. This makes the program hard to fix for an automated tool because adding a call to a sanitization function directly on the echo requires that func- tion call to span over multiple lines as well. On the other hand, adding a new line to the program containing a function call requires the tool to obtain the whole of the array’s key, which also spans over multiple lines.

1 $prefix = "pre"; 2 $suffix = "suf"; 3 echo $_GET[$prefix

4 .

5 $suffix];

Listing 3.3: Example of a PHP program with an instruction spanning over multiple lines.

1 <div>Welcome</div>

2 <?php $a = $_GET["v"]; ?>

3 <?php $q = "SELECT * FROM T WHERE id = " . $a; ?>

4 <div>Query results:</p>

5 <?php $result = mysqli_query($con, $q); ?>

6 <?php print_r($result); ?>

Another example can be observed by considering the program in Listing 3.4, where the vulnerability could be fixed by replacing the PHP instruction on line 4 with

$q = "SELECT * FROM T WHERE id = " . intval($a);

It is important that the remainder of line 4 is not modified because, if so, it will cause the program to become syntactically invalid by modifying a PHP tag. Although this seems easy to the human eye, it is non-trivial for an automated tool to reason about what parts of a line of code it can modify safely.

This problem becomes even more complicated if the required correction requires more than the addition of a simple sanitization function. Such cases include for instance the use of prepared statements to correct SQLi vulnerabilities. In order to add a prepared statement to an existing program, the automated tool has to ensure that the statement (and it’s multiple function calls) is added after the program’s connection to the database is open, otherwise the application will completely stop working.

In order to solve this challenge, we decided to ensure that all corrections inserted by our approach consist solely of adding lines of code, instead of modifying existing ones. This will help us minimize the chances of making a program syntactically invalid. We also decided that our solution would always insert corrections that do not require the inclusion of new files in the application. To avoid breaking the application’s logic by modifying the input string too early in the program, we decided to insert the correction for a given variable on the line of code immediately before the sensitive sink, if possible. This may not be possible in every program because some variables can not be sanitized in their entirety (for example, a variable that contains some developer-provided HTML can not be converted to HTML entities because that would produce an output different from what the developer intended). When a tainted variable V can not be sanitized on the line of code before the sensitive sink, we will sanitize the variable(s) that caused V to become tainted, in the line(s) of code immediately before that happened. We also propose that our approach would need to simulate the execution of the variable operations contained in the program. This would allow us to know the approximate value of a variable when it reaches a sensitive sink, thus knowing whether we can correct the variable in it’s entirety.