Is the problem of injections in JavaScript relevant?

In the old days, when web development was based on the fact that server applications sent queries to relational databases and issued HTML output, there was often a code like this:
 
 
//WARNING: Bad example!
function popup (msg: string): string {
return " " + msg + " ";
}

 
or such:
 
 
//WARNING: Bad example!
function getName (login: string): string {
return "SELECT name FROM users WHERE login =" "+ login +" "";
}

 
Since then, we have learned to use safer approaches.
 
 
Widely used tools such as templating and binding parameters. Today, you can rarely find dangerous string concatenation.
 
 
In this article, I would like to share my thoughts on attacks by introducing code. Apparently, they still represent a threat in jаvascript.
 
 
Is the problem of injections in JavaScript relevant?
 

 
To understand why, we will break one of the unfortunate examples into simpler fragments. Here so:
 
 
function f (userInput: A): A {
const firstCommand: A = ;
const secondCommand: A = ;
return firstCommand.concat (userInput.concat (secondCommand));
}

 
It is obvious that The root cause of attacks through the introduction of code is related to the fact that for the computer there is no difference between the command and input of information by the user! Therefore, an attacker can enter data that will later be treated as a code.
 
 
Naturally, as I said, there are well-known means of protection against such attacks. Instead of this one:
 
 
"SELECT name FROM users WHERE login =" "+ login +" ""
 
it's better to write something like this:
 
 
query ("SELECT name FROM users WHERE login =: login", {login})
 
Thus the command is SELECT name FROM users WHERE login =: login is distinctly separated from the data. {login} . At the same time, internal mechanisms ensure that the data will be prepared for use in the SQL query. Screening quotes and introducing malicious code will not work.
 
 
However, the development of web applications is rapidly developing. Increasingly, not only this:
 
 
    {
paramA: "the value of the A parameter",
paramB: "the value of the A parameter",
}

 
but also this:
 
 
    {
paramA: "the value of the A parameter",
paramB: {$ in:[
"the value of the B parameter",
"the value of the C parameter",
]},
}

 
A significant difference between the two options is that the value of the parameter is an object that includes the command!
 
 
Let's assume the values ​​are read from userInput :
 
 
    {
paramA: userInput.paramA,
paramB: {$ in:[
userInput.paramB[0],
userInput.paramB[1],
]},
}

 
Do not worry about the user providing a malicious line. Everything will be processed in a safe manner.
 
 
The problem is that the parameter values ​​can be not only simple values ​​like the value of the A parameter , but also commands, for example {$ in:["B", "C"]} . The user can send a request in different ways, after decryption of the object (form, JSON or XML), and therefore the code can be attacked by injection.
 
 
Suppose that userInput.paramA is equal to {$ empty: false} . Then the query looks like this:
 
 
    {
paramA: {$ empty: false},
paramB: {$ in:[
userInput.paramB[0],
userInput.paramB[1],
]},
}

 
Again, it turns out that for a computer, reliable commands are indistinguishable from unreliable user input. Only now we are not talking about reliable and unreliable lines, but about reliable and unreliable objects.
 
 
To avoid this problem, you must always write commands so that they can not be received from the user. This can be realized, among other things, using the approach used in React and Snabbdom-Signature (this is a small library for protection against injection into a virtual DOM), namely, to mark each object of the command Symbol so that it can not be sent over the network.
 
 
I admit, I myself often thought that if there is no SQL database or if I use a virtual DOM, I am not threatened by the introduction of the code. How could I be wrong!
 
 

 
LOOKING.HOUSE - the project collected more than 150 points looking glass in 40 countries. You can quickly execute the host, ping, traceroute, and mtr commands.
 
 

 
+ 0 -

Add comment