1. Injection vulnerability (Malicious code insertion error)
Concept
Injection is a flaw that occurs due to a lack of reliable input filtering. When you pass unfiltered data to database (such as SQL injection vulnerability), to browser (XSS vulnerability), to LDAP server (LDAP Injection vulnerability) or to any other location. The problem is that an attacker can inject malicious code to cause data breaches and take control of the client’s browser.
Consequence
Injection may result in data loss, interruption or disclosure to third parties, lost accounts, or denied access. Sometimes, injection leads to take control.
Prevention
The basic principle against injection is to separate the submitted data from direct execution and queries
- There are mechanisms to check and filter input data such as limit size, remove special characters, …
- Use Store procedures in the database. It means putting SQL queries into a procedure (almost like a function in programming languages), data is passed into the procedure through parameters -> separates data from code
- Do not show an exception or error message to avoid an attacker from being able to speculate on the outcome
- Set up user rights for the appropriate users
- Actively use vulnerability scanning tools
- Backup data regularly
2. Broken Authentication
Concept
This is a vulnerability related to user authentication, improperly implemented session management, weak management mechanisms -> allowing Hackers to crack passwords, keys, session tokens or take advantage of. exploits other vulnerabilities to gain temporary or permanent user identities.
An attacker easily finds 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 for an attack against this vulnerability. With having access to several accounts, or just one admin account is enough for a hacker to harm the whole system. Depending on the nature of the system, it allows hackers to commit many illegal acts such as money laundering, asset theft, identity, sensitive information disclosure, …
So what kind of system would be at risk of dealing with this vulnerability?
- Application that allows hackers to launch 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 (in case the user forgets the password) is weak or insecure, such as the question answering mechanism that you often see if you used Yahoo 7-8 years ago, this is really a solution. France is very bad at the moment
- Store password in Plaintext format (plaintext) without encryption, or use encryption algorithms or simple hashes, easily crack
- Lack of or ineffective 2-factor 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
Consequence
Hackers have to gain access to some accounts or only need 1 admin account to break into the system.
Due to the purpose of the system, Broken Authentication is able to allow money transfer, revealing sensitive information with high security.
Prevention
- Deploying two-factor authentication against automated attacks like 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 in the top 10000 worst passwords
https://github.com/danielmiessler/SecLists/tree/master/Passwordsand not allow these passwords 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 may be the account lockout (the way Facebook is applying), or after 2-3 minutes you can continue to log in, this mechanism is quite common as when unlocking the Iphone, your device will be disabled. disabled after a number of times entering the wrong password
- There is a secure mechanism for generating, managing and storing Session IDs, with high difficulty and disturbance, setting expiration times as well as self-destructing after Logout.
3. XSS (Cross Site Scripting) vulnerability
Concept
The Cross-site Scripting (XSS) vulnerability is a very common vulnerability. The attacker inserts scripts into the web application. When this input is not filtered, it will be executed by malicious code on the user’s browser. An attacker can obtain user cookies on the system or trick users into malicious websites.
=> Mechanism: Hacker will input script code input box, then server will save to database and when user send request to server, server will load data from database to process and that script code is executed and hacker may obtain a user’s cookie or redirect the user to a more dangerous web.
Consequence
The script is executed at the user interface so that hackers can perform tasks: stealing credentials, sessions, or delivering malware to the victim.
Prevention
- Use frameworks that automatically detect XSS like (Ruby on Rails, ReactJS, Laravel)
- One simple way of web security is to not return the HTML tag to the user. This also protects against HTML Injection – a similar attack in which a hacker attacks HTML content – has no serious impact but is quite troublesome for users. Usually the solution is simply Encode (convert to another data) all HTML tags.
4.Broken Access Control:
Concept
This is a common error about decentralization in the system. Decentralization errors are often caused by the lack of automatic error detectors or ineffective testing methods or testing functions that cause the system to leak.
Consequence
Technically, hackers who can access and have the same permissions as user or admin, or a user knowledgeable about system functions can also call and execute these functions (Example: Add, Edit , Delete records)
Prevention
- Restrict API and controller access to minimize damage.
- Implementing access control mechanisms and executing it application-wide.
- JWT tokens should be disabled on the server when logged out.
- It is advisable to install rules on the Model to handle database operations.
5.Sensitive Data Exposure:
Concept
This vulnerability belongs to the crypto and resource aspect. Sensitive data must be encrypted at all times, including when it is sent and when stored – no exceptions are allowed. Credit card information and user passwords are never sent or stored unencrypted. Obviously encryption and hashing algorithms are not a weak way of security. In addition, web security standards suggest AES (256 bit or higher) and RSA (2048 bit or higher).
It should be said that Session IDs and sensitive data should not be passed in sensitive URLs and cookies should have a security flag.
Consequence
Disclosing sensitive information will seriously affect that individual.
How to prevent holes
- Use HTTPS with the proper certificate and PFS (Perfect Forward Secrecy). Do not receive anything on non-HTTPS connections. There is a safety flag on the cookie.
- You need to limit your potentially exposed data. If you don’t need this sensitive data, please destroy it. Data you don’t have cannot be stolen.
- Never store credit card information, otherwise have to deal with PCI compliance. Sign up for a payment processor like Stripe or Braintree.
- If you have sensitive data you really need, encrypt it and make sure all passwords are used by the Hash function for protection. For Hash, bcrypt should be used. If you are not using bcrypt encryption, learn about the Salt code to prevent rainbow table attacks.
- Do not store encryption keys in addition to protected data. This is like a car lock with the key always there. Protect your backups with encryption and make sure your keys are private.
Conclusion
Above are some of my studies about some of the vulnerabilities of OWASP web security. Thank you everyone for referencing my article. Let’s see part 2 of the article at …