A good framework must possess the capability to provide security for the application being developed and KeystoneJS is no exception. KeystoneJS has capability built into it to prevent malicious attacks such as CSRF, IP range-based access control, and iframe protection headers. Let us look how we can take advantage of these features.
7.9.1 Cross-Site Request Forgery
Cross-site request forgery, commonly known as CSRF is a type of attack where a malicious website will send a request to another web application where the user is already authenticated. This enables the attacker to manipulate functionality in the target web application via the victim’s authenticated browser. It is the responsibility of the affected web application to prevent such attacks, and neither the victim’s browser nor the site hosting the CSRF can do anything to prevent it.
The most common method to prevent CSRF attacks is to append CSRF tokens to each request and associate them with the user’s session (e.g., via cookies). Such tokens can be unique per session or per request. By including the token with each request, the developer can ensure that the request is valid and not coming from a source other than the user.
KeystoneJS’s middleware makes the above-mentioned very simple to implement.
In fact, it takes just three lines to implement CSRF protection automatically. Let us look at how to add CSRF protection to the reset password form we present to the user as an example.
The first step is to automatically generate a CSRF token and set it in the cookie. Use the KeystoneJS security middleware to do it on the GET route as below:
1 app.get('/resetpassword/:key', keystone.security.csrf.middleware.init, routes.vi\
2 ews.auth.resetpassword);
The next step is to set a hidden variable in the reset password form so that it can be posted back to the server along with the cookie behind the scenes. Add the following line to the template form:
1 <input type='hidden' name='_csrf' value='{{csrf_token_value}}'/>
When keystone.security.csrf.middleware.init is called, it automatically adds a property named csrf_token_value to the response. KeystoneJS expects the CSRF token to be named _csrf when it is posted back to the server for validation.
The next step is to request KeystoneJS to validate the token before we start to process the form contents to reset the password. We can accomplish this with the validate security middleware method as shown below.
1 app.post('/resetpassword', keystone.security.csrf.middleware.validate,
Adding the validate middleware method automatically checks for the validity of the incoming token. If the validation fails, KeystoneJS returns a response with a HTTP 500 status.
The CSRF token generation and validation can also be done manually, if we choose to. To generate the token, use the below methods and use in the template rendering:
1 var csrfTokenKey = keystone.security.csrf.TOKEN_KEY;
2 var csrfTokenValue = keystone.security.csrf.getToken(req, res);
To validate the token, use the validate methods:
1 if (keystone.security.csrf.validate(req)) { 2 // CSRF is valid
3 ...
4 } else {
5 // CSRF is not valid 6 ...
7 }
7.9.2 Cross-Site Scripting
Cross-site scripting, commonly known as XSS, is a form of attack where the intention is to execute a piece of JavaScript on the user’s browser when they are authenticated, in the hope of stealing cookies or session tokens. The most common way of performing such attacks is via unsanitized form inputs where the application accepts user input but does not sanitize it either before saving to the database or before rendering on the browser.
Avoiding such attacks is pretty easy. Swig, our rendering engine, will escape all output by default. There is no need to do any else! In case we want to render something that should not be escaped, then use the autoescape tag and set it to false.
1 {% autoescape false %}{{ somejs }}{% endautoescape %}
As a good practice, it is very important for us to sanitize the input from users. The Open Web Application Security Project (OWASP) has a list of rules that we can follow to mitigate XSS. More information is available at https://www.owasp.org/index.
php/XSS(CSite_Scripting)_Prevention_Cheat_Sheet (https://www.owasp.org/
index.php/XSS(Cross_Site_Scripting)_-Prevention_Cheat_Sheet)
7.9.3 Cookies
Sessions are persisted using an encrypted cookie storing the user’s ID using the cookie secret option for encryption. All cookies are automatically signed and encrypted, which means that if they are tampered with, KeystoneJS will automatically discard them and make it very difficult to be read on the client side using JavaScript.
7.10 Summary
In this chapter, we have learned how to use KeystoneJS’s built-in capability to add authentication features to our application quickly and also how to avoid common security problems.
Searching Site Data
A good navigation menu makes a site very usable. Add a fast search to it and it makes the site much better. People use search engines like Google to find relevant information and expect to be able to find relevant information quickly and easily on our site as well. A good search experience can make users return to the website for future queries. Writing a good search system from scratch is a tough task but node, express, and keystoneJS make it relatively easy.
In this chapter we will look at a quick way to present search results from our keystoneJS application using Mongo DB’s built-in full-text search capability.
8.1 MongoDB Full-Text Search
A good search system is indispensable to locating relevant online information on a website. To be able to provide precise search results in response to a query, the search system should not only cut down extra results but also use ranking and precision to organize the search results. A good search system will provide the most relevant results at the top. Beginning from version 2.4, MongoDB offered full-text search using Text indexes.
MongoDB full-text search allows us to define a text index on any field in the document whose value is either a string or an array of string elements. When we create a text index on a field, MongoDB tokenizes, eliminates stop words, and stems the indexed field’s content and adds it to the index. An important consideration is that a collection can contain only one text index. Hence it is very important for us to determine what we want fields to allow to be searched.
To create a text index, use the db.collection.createIndex() command against the MongoDB database.