DEV Community: Prakhar Chauhan

5 Common Reactjs Security Vulnerabilities

Prakhar Chauhan — Sat, 16 Oct 2021 18:28:09 +0000

Data is the new gold according to many scholars. It becomes much important to secure data on internet from the unauthorized users.

Reactjs is one the popular library of Javascript used to make SPA's and Mpa's. As is provides ease for developer to work over front-end development , its side effects are also huge.
It’s also true that React web apps may face certain security pitfalls. But it’s nothing discouraging, every framework has its own pitfalls. What matters is how you deal with React security vulnerabilities and protect your application against possible attacks.

[Link]https://www.simform.com/blog/react-security-vulnerabilities-solutions/

React Security Vulnerabilities and How to Prevent Them

Cross-Site Scripting (XSS) XSS is an injection of a malicious script into the code of a web application. The browser picks up this script and interprets it as legitimate. After that, the malicious code is executed as a part of an app.

Prevention:

APIs like createElement() help in automatic detection of injection attacks

The power of JSX can be leveraged in order to secure the application via its auto-escaping functionality

Third-party libraries like dangerouslySetInnerHTML can be used to set HTML directly from React instead of using innetHTML that is vulnerable to XSS

2.SQL Injection
Another common React security vulnerability is SQL injection (SQLi). It’s a trick hackers use to inject your database with random SQL code. By doing this, they are able to receive, edit, or delete data irrespective of user permissions.

Hackers are able to pull off SQLi by faking or creating new credentials. They manage to access data on the server by getting the admin credentials. Such a security attack can be very dangerous as hackers can modify this data or even destroy it.

Error based SQLi, time-based SQLi, and logical-error-based SQLi are three common types of SQL injections.

Broadly, a React application is vulnerable to this security pitfall because of improper coding of the app. Some developers may accidentally make it possible for SQL statements to enter through entry fields and move to the database directly.

Prevention

In no case should you allow your React app to connect to any database that may have admin privileges.

Broken Authentication Invalid authentication processes, improper implementation, and failure of authentication functions lead to compromise or exploitation of credential data in your web app. In some cases, authentication failure leads to credential stuffing and even automated brute force attacks.

Here’s a quick and dirty checklist you can follow to improve your authentication :

Implement multi-factor authentication
Initiate credential recovery
Incorporate API pathways
Use cloud native authentication for secure access (Example: amazon cognito)

Prevention

Employ multi-factor authentication wherever possible. It prevents attacks from credential stuffing and stolen credential re-use.

XML External Entities (XXE) In certain cases, XXE attacks are also considered a type of injection attack. XML parsers that are outdated in your React web application become the most vulnerable to get abused with injection attacks leading to DoS attacks. In such attacks, the perpetrator attempts to collect confidential data from the server.

In certain cases, XXE attacks fall under the category of injection attacks. Outdated XML parsers in your React web app are the most vulnerable to injection attacks that lead to DoS attacks.

Security Misconfiguration Needless to say, web applications developed using Reactjs do not follow security measures by default. It has to be incorporated during the development cycle to avoid any damage from occurring in the application framework. Often React security misconfigurations occur because of improperly built HTTP headers or incomplete configurations.

Scoping and the Scope Chain

Prakhar Chauhan — Sat, 16 Oct 2021 17:51:25 +0000

Scope and scoping is one the fundamental topics that every Javascript beginner makes mistake on.

Scoping basically answers the question “where can we access a certain variable or function?”

In JS, each function creates a scope - _this is the space or environment in which the variables that it defines are accessible. In other programming languages, scopes can also be created by if/why/for blocks, but that is not the case in JS. Here in JS, the only way to create a new scope is to write a new function - this is very important in JS.

JS uses lexical scoping - this means that a function that is lexically within another function (i.e. written inside another function) gets access to the scope of the outer function/parent function, and with that it gets access to the variables and functions that the parent function defines.

Consider the following code:

var a = 'Hello!';
first();
function first() {
var b = 'Hi!';
second();
function second() {
var c = 'Hey!';
console.log(a + b + c);
}
}

The whole code sits within the global scope and thus has access to the global VO. The code within the “first” function sits in the “first() scope” and has access to the variables and functions defined in the global VO and VO1 associated with the execution context of the first() function. Similarly, the function second() sits in the “second() scope” and has access to the functions and variables from VO2 (associated with the execution context of the “second” function, VO1 and the global VO) due to its lexical positioning within the context of “first” and the global context. This is why it can read the variables a and b despite their definitions being outside of its context.

So the global scope contains a, the “first() scope” contains a and b, and the “second() scope” contains a, b and c. This is what we refer to as the scope chain. When JS does not find a variable within its immediate execution context, it moves up the scope chain in search of the variable. We only return an error when JS does not find a variable anywhere.

Note that this does not work backwards. The global scope will not have access to the variables b or c unless they are returned from their functions. Locally scoped variables are not visible to their
parent scopes. The scope chain only works “upwards”. How this works is that in the creation phase of each execution context object, the object gets the exact scope chain, which is basically all of the variable objects that the execution context has access
to.

In our above example, in the second scope we have access to the variable objects of the second
function, the first function and the global variable object.

Here is a visual example of the difference between the execution stack and the scope chain. Note that we indent scopes to show which are contained in which “levels”. The third() scope here is contained within the global scope but since third() is not contained lexically within second() or first() then it does not have access to the scope of these functions - and thus doesn’t contain its variables, even though the third() function is called within the second() function.

Execution contexts store the scope chain of each function in the variable object, but they do not have an effect on the scope chain itself. These are inherently different concepts. Note that the second() function can still call the third() function because it has access to the global scope, even thought the third() function can not read the variables b and c which are defined outside
of its scope.

How Js works behind the browser

Prakhar Chauhan — Sat, 16 Oct 2021 17:20:24 +0000

In the era of computers, javascript is every where. With the use of Javascript, a developer can make a single page application to a native mobile application. Using different libraries and framework a single individual can easily put his ideas or thoughts to a application easily by the knowledge of Javascript.

Wait, Do you you know JavaScript was primarily a client-side language, meaning it runs on your computer within your browser. However, more recently the introduction of Node.js has allowed JavaScript to also execute code on servers.

Since its release, JavaScript has surpassed Java, Flash, and other languages because it is relatively easy to learn, has a free and open community, and, most importantly, is incredibly useful, allowing developers to quickly create apps with audiences in the millions.

Now comming to main topic How Js runs behind the Browser

All JS code needs to run in an environment and these environments are called execution contexts. An execution context is like a box/container which stores variables and in which a piece of our code is evaluated and executed. The default execution context is always the global context.

In the global execution context, all of the code that is not inside any function is executed. This is associated with the global object - which in the case of the browser, is the window object. Thus everything we declare in the global execution context is essentially a part of the window object. In this context, a variable lastName and window.lastName are the same thing, i.e. lastName becomes
like a property of the window object, which makes sense as properties are just variables attached to
objects. For code in functions: Each time we call a function, it gets its own brand new execution context.
Our variable assignments take place in the global execution context. Our function declarations are also stored/executed in our global context. However, when we call the function, we create a new context for the function which is placed “on top of our current context”, forming the EXECUTION STACK. Once we call the function, we switch to the Execution Context for the function and all variables within the function are stored/assigned within the Execution Context rather than the Global Context.

Multiple functions leads to multiple Execution Contexts in our Execution Stack. Once the function has completed, we say the function “returns” and the Execution Context leaves the top of
the Execution Stack.

“We see a lot of feature-driven product design in which the cost of features is not properly accounted. Features can have a negative value to customers because they make the products more difficult to understand and use. We are finding that people like products that just work. It turns out that designs that just work are much harder to produce that designs that assemble long lists of features.”
― Douglas Crockford, JavaScript: The Good Parts

Execution Contexts in Detail: Creation and Execution Phases and Hoisting.

How exactly does the creation of new execution contexts happen?

We can associate an execution context with an object - the Execution Context Object. This object has three properties:

Variable Object (VO), which will contain function arguments, inner variable declarations and functiondeclarations.
Scope chain, which contains the current variable object as well as the variable objects of all its
parents.
And the most confusing thing according to many developer:
“This” variable

When a function is called, a new execution context is put on top of the execution stack. This happens in two phases - the creation phase and the execution phase.

Creation phase. A) Creation of the Variable Object (VO). B) Creation of the scope chain. C) Determine value of the “this” variable.

The properties of the execution context are defined.

Execution phase. The code of the function that generated the current execution context is ran line by line and all the variables are defined. If it’s a global context, then it’s a global code that is executed. Creation of the Variable Object:
The argument object is created, containing all the arguments that were passed into the function.
Code is scanned for function declarations: for each function, a property is created in the VO, pointing to the function. This means that all of the functions will be stored inside of the variable object, even before the code starts executing.
Code is scanned for variable declarations, and for each variable, a property is created in the VO, and set to undefined. These last two points are what we refer to as “hoisting”: functions and variables are hoisted in JS, which means that they are available before the execution phase actually starts. They are hoisted in a different way though - functions are already defined before the execution phase starts, while variables are set to undefined and will only be defined in the execution phase. So each execution context has an object which stores a lot of important data that the function will use while it’s running, and this happens before the code is even executed.