The Top 10 OWASP may not be unfamiliar to information security learners, but it will be essential knowledge for Web developers or those interested in security. In this article, I will generalize concepts, give examples as well as some ways to prevent each vulnerability. This content is quite long, so I will divide it into many parts. Link part 2 I will put at the end of this article (After I finish writing)
1. Injection
Speaking of injection, people will often think of SQL Injection. I also have had two posts talking about this type of attack
- What is SQL Injection? How many types of SQL Injection attacks are there?
- Using SQLMap to exploit SQL Injection (SQLi) vulnerabilities
In fact, we have many other types of Injection like NoSQL, OS or LDAP Injection. This vulnerability usually occurs when untrusted data (malicious code, payload, ..) is compiled through a program command or query. This allows attackers to execute unwanted commands or access data without going through authentication.
Most application source code has the potential to be injected, via environment variables, function parameters, web services, etc. Therefore injection is very common, they are often found in SQL, LDAP, XPaths, NoSQL queries, OS commands, XMP parsers, SMTP headers or ORM queries. Hackers can easily find injections by checking the application source code. Scanning and spying tools can help hackers in this regard
Injection can lead to loss, damage or disclosure of data, affecting the operation and reputation of the organization as well as the user. In the event that Hackers exploit the Admin’s account, it can lead to loss of control of the system.
Is your application susceptible to Injection?
A Web application would be a victim of Injection if:
- Data provided from users is submitted at will, not checked for validity, not filtered or “cleaned” first.
- Using dynamic queries, in which user-level data is connected to the original code to create complete queries, directly executed without control and processing mechanisms.
Prevention
The basic rule against injection is to separate the posted data from the direct execution statements and queries
- There is a mechanism to check and filter the input data such as size limit, remove special characters, ..
- Use Store procedures in the database. Temporarily it is to put SQL queries into the procedure (almost like the function in programming languages), the data is passed into the procedure through parameters -> separating data from the code
- Do not display Exception or error messages to avoid an attacker who can speculate on the result
- Set appropriate user rights
- Proactively use security vulnerability scanning tools
- Backup data regularly
2. Broken Authentication
This is a flaw related to user authentication, improperly deployed session management, weak management mechanism -> allowing hackers to crack paswords, keys, session tokens or take advantage of them. exploits other vulnerabilities to gain temporary or permanent user identities.
It is easy for an attacker to find hundreds of thousands of common usernames and passwords, a list of default admin accounts, automated brute force tools (scare attack), or dictionary attack kits. This is a prerequisite to carry out an attack against this vulnerability
With having access to several accounts, or just 1 admin account is enough for hackers to harm the whole system. Depending on the nature of the system, it allows hackers to commit many illegal acts such as money laundering, property theft, identity, disclosure of offensive information, …
So what kind of system would be at risk of dealing with this vulnerability?
- The application allows hackers to conduct exhaustive Brute Force attacks or other types of automated attacks.
You can simply understand that our Web application allows continuous requests for multiple APIs from the same IP or tries to access an account multiple times without a management mechanism such as locking that account. If such behavior occurs - Allows users to set weak, non-standard passwords. There is no forced default password change mechanism such as “Password1” or “admin / admin”.
- Password recovery mechanism (if the user forgets the password) is weak or insecure, such as the mechanism to answer questions you often see if using Yahoo 7-8 years ago, this is really a solution. France is very bad at the moment
- Store passwords in Plaintext format (plaintext) without encryption, or use encryption algorithms or simple hashes, easily cracked.
- Missing or inefficient 2-layer authentication mechanism
- Direct display of Session IDs or important parameters in Params of URLs
- There is no alternate mechanism for changing Session IDs after a successful login
- Session IDs lifetime settings are incorrect
Prevention
- Deploying two-factor authentication against automated attacks such as Brute Force
- Check the security of the Password, do not allow users to set too simple passwords such as all numbers or all words. You can also check the user passwords for the top 10000 worst passwords ( https://github.com/danielmiessler/SecLists/tree/master/Passwords ) and not allow them to be set.
- Ensuring the registration, account recovery, login failure (possibly due to wrong Password, Username) or URL path will use the same messages returned to the user for all results.
For example, when the user fails to log in due to the wrong password. If the Server returns the message “You entered wrong password”. An attacker can rely on that to know that the posted username exists, and simply drains the password until it succeeds. Instead, the server should return the message “Invalid Username or Password”, the attacker will not be able to remove any cases, exhausting will become much more complicated. - Limit the number of times or request a timeout after a number of unsuccessful login attempts. It is possible to lock the account (the way Facebook is applying), or after 2-3 minutes to be able to continue to login, this mechanism is quite common as when unlocking Iphone, your device will be unlocked. disabled after a number of times entering the wrong password
- Having mechanism to create, manage and store Session IDs safely, with high difficulty and disturbance, set expiration time as well as self-destruct after Logout
3. Sensitive Data Exposure
There are many Web applications and APIs that do not really protect well with sensitive information such as finance, health or personal information in the process of exchanging with the browser. Hackers can easily steal and modify those data to commit illegal acts
In the last few years, Sensitive Data Exposure is one of the most common and influential vulnerabilities. Most of the time is because sensitive information is not encrypted, or encrypted with a simple, common algorithm, easy to crack, an encryption key is generated unqualified, a password is hashed by an insecure algorithm. . Hackers can fully perform eavesdropping (Man In the Middle) to catch packet analysis
In other cases, when we call the API to get data to display on the interface, we only need some information, but the API returns many other fields including unnecessary and redundant information. While it does not directly exploit such information for offensive purposes, it can also be a basis for hackers to take further steps such as Social Enginering, potentially many risks to customers, as well as the system.
How is the system at risk of this vulnerability?
- Our application exchanges information in plain text.
- Use cryptographic algorithms that are too old and insecure at the present time (For example, some cryptosystems that were very popular in the past like DES but are now insecure)
- Weak locking mechanism, not safe enough. The choice of key size as well as the appropriate birth algorithm is extremely important
- The user-side application does not authenticate certificates when exchanging information with the server
Prevention
- Determine the sensitivity of the information stored based on the nature of the system and the law. From there choose the appropriate control mechanism for each level
- Filters and eliminates unnecessary sensitive information, minimizing the risk of loss
- Ensure the use of encryption algorithms, key generation standards, safety at the present time
- Do not store sensitive information in Cache
summary
Above are 3 of the top 10 OWASP 2020 security vulnerabilities. I will continue to work on this topic in the upcoming articles
Hopefully everyone has grasped some basic knowledge about concepts, risks and some methods to prevent the vulnerabilities mentioned in this article.