Improving NodeJS Website Security: Web Server anti-hacker attack skills

Improving NodeJS Website Security: Web Server anti-hacker attack skills

Undoubtedly, Node. js is becoming increasingly mature. In this case, we have not yet formed many security rules.

In this article, I will share some tips on improving Node. js security.

Win Friends Without eval

You should not only avoid using eval-you should also avoid using eval in the following situations. They are equivalent to directly using eval;

setInterval(String, 2)setTimeout(String, 2)new Function(String)

Note * eval: directly convert the string into code for execution, such as: eval ('alert ("hi ")')

Why not use eval?

If you run eval on user input (do not design it like this), you may be vulnerable to injection attacks. And this running method is very slow.

Please use Strict Mode

Using this mode will restrict your variable declarations and always throw hidden errors. Below are several examples:

Attributes that cannot be deleted

'use strict';delete Object.prototype; // TypeError

The object property must be unique.

'use strict';  var obj = {      a: 1,     a: 2 }; // syntax error

Forbidden to use

var obj = { x: 17 };  with (obj) // !!! syntax error  {}

Static code analysis

Use JSLint, JSHint, or ESLint to statically analyze your code. Static code analysis allows you to capture potential bugs in the early stages.

Test

This is self-evident: Testing, testing and then testing.

More than just a unit test, you should perform a full test (test pyramid ).

Do not directly use: sudo node app. js

Many people use the superuser permission to run Node applications, aren't they? Because they want the application to listen to port 80 or port 443 directly (note * default ports for http and https)

This is wrong. Any errors/vulnerabilities in the process will cause the entire system to go down, and you will not be able to do anything.

Therefore, you should use an HTTP reverse proxy service to forward these requests. You can use nginx or Apache.

Avoid shell command Injection

What is the problem with the following code segment?

child_process.exec('ls', function (err, data) {      console.log(data);});

The child_process.exec command calls/bin/sh, which starts an interpreter rather than a program.

This is problematic. When this method is used to execute a user-input method, a new command may be injected by an attacker than the content in a backquotes or $.

To avoid this problem, you only need to use child_process.exe cFile.

Temporary Files

When creating a file, pay special attention to the process of uploading the file. These files can easily eat up all your disk space.

To solve this problem, you should use Streams.

Encrypt Your Web Application

Not only Node-all Web applications should be encrypted. (Note * https)

Cross-Site Scripting (Reflected Cross Site Scripting)

In this case, attackers inject an HTTP Response to executable code. An application is vulnerable to this type of attack. It executes unverified scripts on the client (mainly written in Javascript ). Attackers can steal cookies, clipboard content, or modify the page itself.

For example

http://example.com/index.php?user=<script>alert(123)</script>

If this user query is directly inserted into the DOM (HTML) without verification, it will be executed.

How to avoid

Never insert untrusted data into the DOM

Remove HTML before insertion

Prevent Cookie Theft

By default, cookies can be read in the same domain using Javascript. This may cause cross-site scripting attacks. They may also be read by third-party JavaScript libraries.

For example

var cookies = document.cookie.split('; ');

How to avoid

 

To prevent this, you can use HttpOnly on Cookies. This tag prevents JavaScript from reading this cookie. (Note * For example, the Cookie used by the server)

 

Content Encryption Policy

Content Security Policy (CSP) is an additional security layer that helps detect and mitigate certain types of attacks, including cross-site scripting (XSS) and Data injection attacks.

CSP can be enabled through Content-Security-Policy.

For example:

Content-Security-Policy: default-src 'self' *.mydomain.com

This header will only receive the content sent from the trusted domain name and its subdomain name.

Cross-Site Request Forgery)

CSRF forces end users to execute other actions in their authorized Web applications.

The problem may occur at this time, because cookies will also be sent to the requested website (which you are authorized to)-even when these requests come from different locations.

For example

<body onload="document.forms[0].submit()">    <form method="POST" action="http://yoursite.com/user/delete">    <input type="hidden" name="id" value="123555.">  </form></body>

 

This will directly cause the user information to be deleted.

How to stop

To prevent CSRF, you should implement the synchronous token mode-fortunately, the node community has already helped you. The following is how it works:

• When initiating a GET request, the server checks your CSRF token-if it does not exist, create
• When the user displays the input, make sure to add a hidden CSRF token value.
• When the Form is submitted, make sure that the value matches the content in the Form and Session.

•