MEAN stack brings full stack development under purview of a single programming language, JavaScript. Alongside bringing the best of the frontend and backend technologies under a single basket, MEAN stack inherits security vulnerabilities each of these technologies are susceptible to. Some of the security threats augment when these technologies play together inside the framework. If those vulnerabilities are not subsided by the MEAN stack developers at the time of writing code, they will put the entire organization using those applications at jeopardy.
For example, MongoDB is a NoSQL database and an integral part of the MEAN stack. A common myth is NoSQL means no injections. In reality, MongoDB has a concept of query selector operators. These operators start with a dollar sign: $gt means greater than, $ne means not equal to, $not for negation, etc. If an attacker can inject these queries selector operators into the query, he can alter the logic of that query.
Here the presence of Express.js in MEAN stack makes the situation worse; it acts as a catalyst to NoSQL Injections. When Express sees nested URL encoded parameters in an input, it’s going to automatically parse them. This allows a person to inject a query operator into hid statement and alter the logic of this operation. And that’s only a part of the problem with MongoDB and there are three more technologies with their own share of risks and vulnerabilities.
Let’s take a look at the all the technologies inside MEAN stack and what are the potential security risks they can expose your application to.
As I said, MongoDB is immune to SQL injections but not every type of injections. In fact, MongoDB are more susceptible to something called Query Selector Injections or NoSQL Injections than MySQL is to SQL injections. The JSON documents with some neat, little tricks can be altered to achieve some malicious results. This as I mentioned above involve built-in logic operators to alter queries.
Another problem with MongoDB is this that it doesn’t force authentication that means that five year old hacker living next door can query the database with little to no difficulty. The icing on the cake is MongoDB’s optional HTTP and REST interface, which not only puts the database and the sensitive information inside it on the public domain but also the underlying file system.
To make sure, your database is not accessible to anybody make sure you disable HTTP and REST interface. You can configure /etc/mongodb.conf file’s bind_ip, auth,httpinterface, and rest options to contain access to the database and, thus, secure the MongoDB instance as demonstrated below.
Ransom-wares targeting the insecure default conf file on these servers exploited more than forty thousand instances of MongoDB by January 2017.
Node.js facilitates the development of web applications with broad backend capabilities:server and networking capabilities. It makes way for real-time bidirectional communications back and forth from server and client. Node.js is a standalone package of Google’s V8 JavaScript engine and; thus, works outside of a web browser.
Developers love Node.js as it allows creating HTTP web servers while building the web applications. The very reason MEAN stack exists; Node.js isn’t without its share of security vulnerabilities. In fact, it inherits all security flaws JavaScript suffers from. In addition, the ability to execute at the server exposes it to a new set of attack vectors. Nevertheless, the CVE database compiles an up-to-date list of Node.JS vulnerabilities.
In a nutshell, full stack development may be the epitome of DevOps; nevertheless it necessitates stringent adherence to protected application development practices. The MEAN stack, and any stack for that matter—be it LAMP, .NET, or MEAN—needs apt controls to make sure that security is baked into an application since the initial phases of development. In the MEAN stack, complete vulnerability assessment and monitoring for web applications, databases, and servers is required.
A minimal, flexible web application framework built around Node.js, Express hasmany features that simplify web and mobile application development. Express.js is to Node what Ruby-on-Rails or Sinatra is to the Ruby language.
Unluckily, the framework is susceptible to numerous injection and cross-site attacks and is vulnerable to all of Node.js’s core vulnerabilities.
For example, in MEAN stack, session state client-side stored in JSON Web Token (JWT) is encrypted. Thus, persistent session data server-side makes the application scalable when deployed in clustered servers. However, this handiness comes at a cost, explicitly the incapability to nullify a user’s session. Of course, you can expire the cookie afteryet the server will accept a replayed cookie even when you purged the cookie.
This issue can be moderated by keeping an inner expiration value within the session cookie.
Another problem with Express is this that the Csurf plugin is omitted from GET, HEAD, and OPTIONS methods. Csurf plugin protects web application from cross-site request forgery (CSRF). That is, an application with GET routes will not be protected from CSRF attacks.
That means the below code and the resulting app is vulnerable to CRSF because of the GET part.
To mitigate this, developers should do one of the following:
Angular has inherent Strict Contextual Escaping service ($sce) by default. This service secure Angular from malicious HTML tags (e.g., <script>, etc.), attributes (e.g., onmouseover, onerror, etc.), and URI protocols (e.g., javascript) from data rendered as HTML with the ng-bind-html directive.
The problem is Strict Contextual Escaping service ($sce) can turned off by sceProvider.enabled() method globally while $sce.trustAs methods turn it off per-instance. In short, Angular is quite vulnerable to cross-site scripting (XSS) attacks when binding insecure data as HTML.
The easiest method around this vulnerabilities is to enable $sce service for untrusted bound to the ng-bind-html directive. Removing the $sceProvider.enabled(false) method from the excerpt above means the malicious onerror attribute will be sanitized appropriately.
Another security risk with Angular and thus MEAN stack applications is expression injection. An attacker can enter a curly bracket to Angular template to modify expressions. Aforementioned functions do not take in account expression injection using curly brackets.
To mitigate the risk, sanitize curly brackets from insecure input or by prevent the input from being written inside an Angular template by reducing the scope of the ng-app directive.
MEAN stack development is the epitome of DevOps that forbids insecure development practices. Besides, this approach entails sufficient controls to make sure that security is an integral part of every stage of development.
Tags