Today, it’s imperative we improve the security of all our systems. There are more people with knowledge of hacking techniques, so there is a bigger need to search for vulnerabilities in our systems.
The objective of this blog is to explain some of the most common security vulnerabilities related to the Front End.
What is a Security Vulnerability?
A security vulnerability is a software code flaw or a system misconfiguration through which attackers can directly gain unauthorized access to a system. Once inside, the attacker can leverage authorizations and privileges to compromise systems and assets.
Only a small percentage of known vulnerabilities will be used to hack into a system. Vulnerabilities that pose the highest risk are those that have a higher chance of being exploited, and therefore we should prioritize and solve them first.
For many companies, it’s not until a security breach has occurred that security becomes a priority. But an effective approach to IT security must be proactive and defensive.
So let’s focus on common techniques attackers will use to provoke a breach. This will give us important knowledge when writing code.
Cross-Site Scripting (XSS)
Cross-site scripting (XSS) is an attack where an attacker injects malicious executable scripts into the code of a website.
There are 3 XSS approaches:
Stored XSS: This takes place when the malicious payload is stored in a database. It renders to other users when data is requested if there is no output encoding or sanitization. The idea is to use some comments section or something where the website gives the opportunity to store into the server.
Reflected XSS: This occurs when a web application sends attacker-provided strings to a victim’s browser so the browser executes part of the string as code. The payload echoes back in response since it doesn’t have any server-side output encoding.
DOM-based XSS: This takes place when an attacker injects a script into a response. The attacker can read and manipulate the document object model (DOM) data to craft a malicious URL. The attacker uses this URL to trick a user into clicking it. If the user clicks the link, the attacker can steal the user’s active session information, keystrokes and so on. Unlike stored XSS and reflected XSS, the entire DOM-based XSS attack happens on the client browser (i.e., nothing goes back to the server).
Example of a XSS Attack:
- Let’s say a website allows us to make posts or comments — some kind of data that will be stored in the database.
- The attacker will populate the input fields; in one of them, the information to store will be a JavaScript code.
- The attacker’s idea is, generally, to steal as much information from the browser as possible; the common information to steal is the cookie.
Another approach is to use an IMG tag taking advantage of the “onerror” attribute. In this case, the attribute SRC of the image contains something that will fire the “onerror” event of the IMG tag.
Prevent
Input validation is the default primary step to prevent these attacks. Proper input validation controls must be performed at every application tier to ensure it only accepts trusted user input.
Enforce a Strong Content Security Policy (CSP). All modern browsers support CSPs, which developers use to instruct browsers on the allowed sources to load JavaScript and other resources. Since stored XSS attacks rely on the attacker to include malicious inline <script> tags within the page’s <html> tag, CSPs prevent attacks by implementing the same-origin policy. The content security policy is set as a <meta> tag within the page’s <head> element.
The last technique is to “Escape Dynamic Content.” Stored XSS attacks take advantage of flaws in the delivery of dynamic content persisted within the application’s backend. First, it is essential to keep registered users from submitting raw HTML in input forms. Additionally, any dynamic content and special characters should be escaped so that the browser does not treat them as raw HTML source code, but as the contents of HTML tags.
SQL Injection Vulnerabilities (SQLi)
SQL injection is a code injection technique used to attack applications that have a database, in which malicious SQL statements are inserted into an input field for execution. It takes advantage of a vulnerability in the code of an application where user input is not filtered correctly.
This vulnerability allows attackers to perform, read, insert, modify and delete actions on the database, as well as execute administration operations on it, such as granting permissions. And in some cases, you can even issue commands to the machine’s operating system.
There are lots of SQL injection vulnerabilities, attacks and techniques that occur in different situations. Some common SQL injection examples include:
- Retrieving hidden data, where you can modify a SQL query to return additional results.
- Subverting application logic, where you can change a query to interfere with the application’s logic.
- UNION attacks, where you can retrieve data from different database tables.
- Blind SQL injection, where the results of a query you control are not returned to the application’s responses.
Example of a SQLi Attack
A common target by attackers is the login section. They choose this section because if they bypass the login, they will have access to the entire system.
Attackers can add SQL sentences into the fields to try to force the login to respond successfully.
A common SQL to validate a user/password follows a structure like “ SELECT * FROM Datatable.USERS WHERE ( username = Datatable .USERS.username AND password = Datatable .USERS.password);” they take advantage of his SQL knowledge to force the “username” and “password” fields to send SQL code that contains the OR logical operator.
Adding the OR “1 = 1” to force the make the logic sentence in TRUE.
Prevent
A common technique to prevent this flaw is to use a standard security measure, the input sanitization. It is the process of checking and filtering input data to ensure it’s free of characters or strings that could inject malicious code into the system.
This security measure must be performed on both sides of the Client/Server architecture. Attackers will use the browser the first time; if they can’t detect the vulnerability, the next step will be to use some application to intercept the request between Front End and Back End so they can modify the parameter values.
Conclusion
In these times, we need to take in consideration all possible ways attackers will use to penetrate our websites. Regardless of our website’s size, we need to keep both sides (Front End and Back End) of the architecture as clean and safe as we can and use all existing techniques to block attackers.
