To sanitize user input (remember, query strings are also a type of user input) before using it in a SQL query, you can apply sanitization functions and bind the variables in the query using parameters or prepared statements. For examples and more detail please refer back to Chapter 14.

From a security perspective, you should never trust a user input enough to use it directly in a query, no matter how many HTML5 or JavaScript prevalidation techniques you use. Remember that at the end of the day, your server responds to HTTP requests, and a hacker could easily circumvent your JavaScript and HTML5 prevalidation and post directly to your server.

Despite the sanitization of user input, there is always a risk that users could somehow execute a SQL query they are not entitled to. A properly secured system only assigns users and applications the privileges they need to complete their work, but no more.

For instance, in a typical web application, one could define three types of database user for that web application: one with read-only privileges, one with write privileges, and finally an administrator with the ability to add, drop, and truncate tables. The read-only user is used with all queries by nonauthenticated users. The other two users are used for authenticated users and privileged users, respectively.

In such a situation, the SQL injection example would not have worked, even if the query executed since the read-only account does not have the TRUNCATE privilege.

Reflected XSS (also known as nonpersistent XSS) are attacks that send malicious content to the server, so that in the server response, the malicious content is embedded.

For the sake of simplicity, consider a login page that outputs a welcome message to the user, based on a GET parameter. For the URL index.php?User=eve, the page might output Welcome eve! as shown in in Figure 16.29.

Figure 16.29 Illustration of a Reflection XSS attack

A malicious user could try to put JavaScript into the page by typing the URL:

index.php?User=<script>alert("bad");<script>

What is the goal behind such an attack? The malicious user is trying to discover if the site is vulnerable, so they can craft a more complex script to do more damage. For instance, the attacker could send known users of the site an email including a link containing the JavaScript payload, so that users that click the link will be exposed to a version of the site with the XSS script embedded inside as illustrated in in Figure 16.29. Since the domain is correct, they may even be logged in automatically, and start transmitting personal data (including, for instance, cookie data) to the malicious party.

Stored XSS (also known as persistent XSS) is even more dangerous, because the attack can impact every user that visits the site. After the attack is installed, it is transmitted to clients as part of the response to their HTTP requests. These attacks are embedded into the content of a website (i.e., in the site’s database) and can persist forever or until detected!

To illustrate the problem, consider a blogging site, where users can add comments to existing blog posts. A malicious user could enter a comment that includes malicious JavaScript, as shown in Figure 16.30. Since comments are saved to the database, the script now may be potentially displayed to other users that view this comment. This could happen by using a PHP echo to output the content, but it also might happen in JavaScript by setting the an element’s innerHtml property to this content. The next time another logged-in user views this comment their session cookie will be transmitted to the malicious site as an innocent-looking image request. The malicious user can now use that secret session value in their server logs and gain access to the site as though they were an administrator simply by using that cookie with a browser plug-in that allows cookie modification.

Figure 16.30 Illustration of a stored XSS attack in action

As you can see, XSS relies extensively on unsanitized user inputs to operate; preventing XSS attacks, therefore, requires even more user input sanitization, just as SQL injection defenses did. It is important to remember that query string parameters, URLs, and cookie values are also forms of user input.

Obviously, sanitizing user input is crucial to preventing XSS attacks, but as you will see, filtering out dangerous characters is a tricky matter. It’s rather easy to write PHP sanitization scripts to strip out dangerous HTML tags like <script>. For example, the PHP function strip_tags() removes all the HTML tags from the passed-in string. Although passing the user input through such a function prevents the simple script attack, attackers have gone far beyond using HTML script tags, and commonly employ subtle tactics including embedded attributes and character encoding.

• Embedded attributes use the attribute of a tag, rather than a <script> block, for instance:

  <a onmouseover="alert(document.cookie)">some link text</a>

• Hexadecimal/HTML encoding embeds an escaped set of characters such as:

  %3C%73%63%72%69%70%74%3E%61%6C%65%72%74%28%22%68%65%6C%6C%6F%22%29%3B%3C%2F%73%63%72%69%70%74%3E

  instead of <script>alert("hello");</script>.

This technique actually has many forms, including hexadecimal codes, HTML entities, and UTF-8 codes.

Given that there are at least 80 subtle variations of these types of filter evasions, most developers rely on third-party filters to remove dangerous scripts rather than develop their own from scratch. Most significant frameworks such as React or EJS provide built-in sanitization when outputting content. A library such as the open-source HTMLPurifier from http://htmlpurifier.org/ or HTML sanitizer from Google²¹ allows you to easily remove a wide range of dangerous characters from user input that could be used as part of an XSS attack. Using the downloadable HTMLPurifier.php, you can replace the usage of strip_tags() with the more advanced purifier, as follows:

$user= $_POST['uname'];
$purifier = new HTMLPurifier();
$clean_user = $purifier->purify($user);

Even if malicious content makes its way into your database, there are still techniques to prevent an attack from being successful. Escaping content is a great way to make sure that user content is never executed, even if a malicious script was uploaded. This technique relies on the fact that browsers don’t execute escaped content as JavaScript, but rather interpret it as text. Ironically, it uses one of the techniques the hackers employ to get past filters.

You may recall that HTML escape codes allow characters to be encoded as a code, preceded by &, and ending with a semicolon (e.g., < can be encoded as <). That means even if the malicious script did get stored, you would escape it before sending it out to users, so they would receive the following:

<script>alert("hello");</script>

The browsers seeing the encoded characters would translate them back for display, but will not execute the script! Instead your code would appear on the page as text. The Enterprise Security API (ESAPI), maintained by the Open Web Application Security Project, is a library that can be used in PHP, ASP, JAVA, and many other server languages to escape dangerous content in HTML, CSS, and JavaScript²² for more than just HTML codes.

The trick is not to escape everything, or your own scripts will be disabled! Only escape output that originated as user input since that could be a potential XSS attack vector (normally, that’s the content pulled from the database). Combined with user input filtering, you should be well prepared for the most common, well-known XSS attacks.

XSS is a rapidly changing area, with HTML5 implementations providing even more potential attack vectors. What works today will not work forever, meaning this threat is an ongoing one.

Header set Content-Security-Policy default-src 'self';

<meta http-equiv="Content-Security-Policy" content="default-src 'self'; img-src https://res.cloudinary.com; font-src fonts.gstatic.com; style-src 'self' fonts.googleapis.com">

The challenge of DDoS is that the requests are coming in from multiple machines, often as part of a bot army of infected machines under the control of a single organization or user. Such a scenario is often indistinguishable from a surge of legitimate traffic from being featured on a popular blog like reddit or slashdot. Unlike a DoS attack, you cannot block the IP address of every machine making requests, since some of those requests are legitimate and it’s difficult to distinguish between them.

Interestingly, defense against this type of attack is similar to preparation for a huge surge of traffic, that is, caching dynamic pages whenever possible, and ensuring you have the bandwidth needed to respond. Unfortunately, these attacks are very difficult to counter, as illustrated by a recent attack on the spamhaus servers, which generated 300 Gbps worth of requests!²³ Due to the complexity of identifying and defending against this attack, many cloud providers sell variations of a DDOS service as part of a hosting package so you don't have to (see Chapter 19).

Most softwares are regularly updated with new versions that add features and fix bugs. Sometimes these updates are not applied, either out of laziness/incompetence or because they conflict with other software that is running on the system that is not compatible with the new version.

From the OS and services, all the way to updates for your plug-ins in Wordpress, out-of-date software puts your system at risk by potentially leaving well-known (and fixed) vulnerabilities exposed.

The solution is straightforward: update your software as quickly as possible. The best practice is to have identical mirror images of the production system in a preproduction setting. Test all updates on that system before updating the live server.

An open mail relay refers to any mail server that allows someone to route email through without authentication. While email protocols (SMTP, POP) are not technically web protocols, they offer many threats the web developer should be aware of. Open relays are troublesome since spammers can use your server to send their messages rather than use their own servers. This means that the spam messages are sent as if the originating IP address was your own web server! If that spam is flagged at a spam agency like spamhaus, your mail server’s IP address will be blacklisted, and then many mail providers will block legitimate email from you.

A proper closed email server configuration will allow sending from a locally trusted computer (like your web server) and authenticated external users. Even when properly configured from an SMTP (Simple Mail Transfer Protocol) perspective, there can still be a risk of spammers abusing your server if your forms are not correctly designed, since they can piggyback on the web server’s permission to route email and send their own messages.

Although SQL injection is one type of unsanitized user input that could put your site at risk, there are other risks to allowing user input to control systems. Input coupled control refers to the potential vulnerability that occurs when the users, through their HTTP requests, transmit a variety of strings and data that are directly used by the server without sanitation. Two examples you will learn about are the virtual open mail relay and arbitrary program execution.

Consider, for example, that most websites use an HTML form to allow users to contact the website administrator or other users. If the form allows users to select the recipient from a dropdown, then what is being transmitted is crucial since it could expose your mail server as a virtual open mail relay as illustrated in Figure 16.33.

Figure 16.33 Illustrated virtual open relay exploit

By transmitting the email address of the recipient, the contact form is at risk of abuse since an attacker could send to any email they want. Instead, you should transmit an integer that corresponds to an ID in the user table, thereby requiring the database lookup of a valid recipient.

Another potential attack with user-coupled control relates to running commands in Unix through a PHP script. Functions like exec(), system(), and passthru() allow the server to run a process as though they were a logged-in user.

Consider the script illustrated in Figure 16.34, which allows a user to input an IP address (or domain name) and then runs the ping command on the server using that input. Unfortunately, a malicious user could input data other than an IP address in an effort to break out of the ping command and execute another command. These attackers normally use | or > characters to execute the malicious program as part of a chain of commands. In this case, the attacker appends a directory listing command (ls), and as a result sees all the files on the server in that directory! With access to any command, the impact could be much worse. To prevent this major class of attack, be sure to sanitize input, with escapeshellarg() and be mindful of how user input is being passed to the shell.

Figure 16.34 Illustrated exploit of a command-line pass-through of user input

Applying least possible privileges will also help mitigate this attack. That is, if your web server is running as root, you are potentially allowing arbitrary commands to be run as root, versus running as the Apache user, which has fewer privileges.