Thinking and practice of front-end and back-end separation based on NodeJS (4) Solutions to security issues

Foreword

In the front-end and back-end separation development model, one of the most obvious changes in terms of development roles and functions is: in the past, front-end students who were only responsible for development in the browser environment needed to dabble in the server level. Write server-side code. A fundamental question facing us is how to ensure Web security?

This article, under the architecture of front-end and back-end separation mode, proposes solutions to the security problems encountered by the front-end in Web development, as well as countermeasures and precautions.

Defense against cross-site scripting attacks (XSS)

Problems and solutions

Cross-site scripting attack (XSS, Cross-site scripting) is the most common and basic method of attacking Web websites. An attacker can publish data containing offensive code on a web page, and when a viewer sees the web page, a specific script will be executed with the identity and permissions of the viewer's user. XSS can easily modify user data, steal user information, and cause other types of attacks, such as CSRF attacks.

The basic method to prevent XSS attacks is to ensure that any data output to an HTML page is escaped in HTML (HTML escape). For example, the following template code:

Copy code The code is as follows:

$description in this code is a template variable (the syntax of variables defined in different templates is different, here is just an illustration), the data submitted by the user, then the attacker can enter a piece of code containing "JavaScript", so that The result of the above template statement becomes the following result:

Copy code The code is as follows:

<br>
<script>alert('hello')'</script>

The above code, when rendered in the browser, will execute the JavaScript code and alert hello on the screen. Of course, this code is harmless, but an attacker can create a JavaScript to modify user information or steal cookie data.

The solution is very simple, which is to html escape the value of $description. The escaped output code is as follows

Copy code The code is as follows:

<br>
<script>alert("hello!")</script>

The above escaped HTML code is harmless.

Midway’s solution

Escape all user-output data in the page

There are several situations and methods to escape data:

1. Use the mechanism provided inside the template to escape

Midway uses KISSY xtemplate internally as the template language.

In the xtemplate implementation, two square brackets ({{val}}) are used to parse the template data grammatically. By default, the data is HTML escaped, so developers can write templates like this:

Copy code The code is as follows:

In xtemplate, if you do not want the output data to be escaped, you need to use three square brackets ({{{val}}}).

2. Explicitly call the escape function in Midway

Developers can directly call the HTML escaping method provided by Midway in the Node.js program or template to explicitly escape the data, as follows:

Method 1: HTML escape data in Node.js program

Copy code The code is as follows:

var Security= require('midway-security');

//data from server，eg {html:''，other:""}

data.html =Security.escapeHtml(data.html);

xtpl = xtpl.render(data);

Method 2: HTML escape the HTML data in the template

Copy code The code is as follows:

Note: Use Security.escapeHtml to escape only when the data is not escaped inside the template. Otherwise, double escapes will be superimposed inside the template and in the program, resulting in unexpected output.

Recommendation: If you use xtemplate, it is recommended to directly use the template's built-in {{}} to escape; if you use other templates, it is recommended to use Security.escapeHtml to escape.

Filter the rich text output by users in the page

You may be thinking: “Actually, I just want to output rich text. For example, some message boards and forums provide users with some simple font size, color, background and other functions. So how should I handle such rich text to prevent XSS? What? "

1. Use the richText function provided by Security in Midway

Midway provides the richText method, which is specially used to filter rich text and prevent vulnerabilities such as XSS, phishing, and cookie theft.

There is a message board, the template code may be as follows:

Copy code The code is as follows:

{{{message}}}

Because message is user input data, the content of the message board contains rich text information, so here in xtemplate, three curly brackets are used, and HTML escaping is not performed by default; then the data input by the user is as follows :

Copy code The code is as follows:

http://eval.com/eval.js"> style="color:red;font-size:20px;position:fixed ;">I am leaving a message

If the above rich text data is output directly to the page, it will inevitably cause the js of the eval.com site to be injected into the current page, causing an XSS attack. In order to prevent this vulnerability, we only need to call the Security.richText method in the template or program to process the rich text entered by the user.

The calling method is similar to escapeHtml, there are two ways as follows

Method 1: Call directly in the Node.js program

Copy code The code is as follows:

message =Security.richText(message);

var html = xtpl.render(message)

Method 2: Call

in the template

Copy code The code is as follows:

Security.richText({{{message}}})

After calling Security’s richText method, the final output is as follows:

Copy code The code is as follows:

I am leaving a message

It can be seen that first of all: the script tags that can cause XSS attacks are directly filtered; at the same time, the CSS attribute position:fixed; style in the style tag is also filtered. Finally output harmless HTML rich text

Learn about other possible avenues for XSS attacks

In addition to possible XSS attacks in page templates, there are several other ways in which web applications may be at risk.

1. Error page vulnerability

If a page cannot be found, the system may report a 404 Not Found error, for example: http://localhost/page/not/found

404 NotFound
Page /page/not/found does not exit
Obviously: an attacker can use this page to construct a connection like this, http://localhost/