JavaScript is one of the most widely used languages in the world.
It is not only the basic programming language that runs on the web, but also appears to have high demand as a server-side programming language since the advent of Nodejs.
However, how well do programs made with JavaScript, especially web services, protect their security?
We will learn about the basic security policies of JavaScript that must be observed regardless of programming skills.
XSS
XSS, or cross-site scripting, is a type of attack that injects malicious code into a web page. It can be classified into two main types reflected and stored.
Web browsers have a number of security policies in place, including one that invalidates script blocks inserted by the browser. This means that even if someone were to manipulate something like HTMLElement.innerHTML to inject a script block into a page, the script would not execute.
So what's the problem? The problem occurs when malicious scripts are downloaded from the server.
Reflected XSS
Reflected XSS is a vulnerability that occurs when user-supplied parameters are inserted into a page without validation.
For example, when showing search results based on the value of the query parameter q, if the value of q is inserted into the search bar directly, it can be used to create a URL that executes malicious scripts to a domain such as Dev.to.
One way to address this is to escape tag characters to make them strings.
Stored XSS
Stored XSS is a type of attack that works on the same principle as reflected XSS, but it stores malicious scripts on the server's database using functions such as a bulletin board.
It may seem that it can be dealt with in the same way as reflected XSS, but the thing to consider here is functions such as WYSIWYG.
To support WYSIWYG, only the function that executes scripts without invalidating HTML should be filtered.
The filtering targets are as follows.
<script>alert('Attack')</script>
<a href="javascript:alert('Attack')"></a>
<a href="javas	cript:alert('Attack')"></a>
<button onclick="alert('Attack')"></a>
<div onmousemove="alert('Attack')"
style="position:absolute; z-index: 12345;
left:-100vw; top:-100vh; width:200vw; height:200vh;">
</div>
Of course, script tags should be filtered, and href attributes with javascript or event handlers starting with on should also be filtered, even though they are executed when the user clicks.
Here, it is important to note that filtering can be bypassed using \	, or malicious scripts can be executed without clicking using onmousemove and some styles.
Unverified Redirection
If you use the URL sent by the user without validation in the redirection, it can be used to create URLs such as dev.to?redirectUrl=attacker.site, similar to reflected XSS.
SQL Injection
SQL injection is a vulnerability that allows an attacker to escape the string range using comments and manipulate SQL freely if the user's input is inserted into the query directly.
It is a vulnerability that can lead to fatal damage, such as the theft of all personal information on the server or the deletion of data, but if you use the Prepared Statement function, you can treat all user input as simple strings, so no problems occur.
SELECT * FROM user
FROM id = '{id}' AND pw = '{pw}'
// id = " ' OR 1 == 1 --"
SELECT * FROM user
FROM id = ' ' OR 1 == 1 --' AND pw = ''
Check permissions on the client side
Web apps are vulnerable to attacks because they allow users to freely execute JavaScript through features like the console, and attackers can intercept communications, send manipulated requests, or receive manipulated responses.
All validation logic should be handled on the server.
Client-side validation is almost useless except for reducing server traffic due to bad requests.
Conclusion
I have listed various security vulnerabilities and their solutions, but in fact, all of these methods are based on not trusting the user's request.
This also includes business logic processing.
Even when processing basic CRUD, use the data from the database rather than the user's input values.
Thank you.
Top comments (0)