OWASP Top 10 Vulnerabilities |Application Security Attacks
What is OWASP?
OWASP stands for The Open Web Application Security Project. It is a non-profit foundation that works to improve application security for software. Through community-led projects globally, it is a great source for tools, resources, education & training for developers and technologists to secure the web and mobile applications. Read our article to learn more about the OWASP top 10 vulnerabilities with examples.
What are the OWASP Top 10 vulnerabilities?
The OWASP Top 10 is a standard for developers and web application security, representing the most critical security risks to web applications. By using the OWASP Top 10, developers ensure that secure coding practices have been considered for application development, producing more secure code. We have included OWASP top 10 risks with examples to equip the reader within the context of application security attacks.
Why is OWASP important?
OWASP Top 10 web application vulnerabilities list is released every 2–3 years in accordance with the ongoing threats due to changing threat landscape. Its importance is directly tied to its checklist nature based on the risks and their impacts on web application development. OWASP top 10 compliance has become the go-to standard for web application security testing.
For security testing based on OWASP Top 10 issues, please refer to our penetration testing services from the top menu. The following image is taken from official OWASP source depicting changes from the previous version (OWASP Top 10 -2013) to current version i.e. 2017.
We have included OWASP Top 10 attacks and defences in this article.
What are the OWASP Top 10 Application Security Risks? How to prevent Web Application Attacks?
Injection flaws
Injection flaws in the security world are one of the most famous vulnerabilities. Injection flaws such as SQL, NoSQL, OS, LDAP, HTML, JS occur when untrusted data or untrusted input is sent to an interpreter as part of a query or a command. If it’s sent as a query, then it’s known as script injection (SQL, HTML). If it’s sent as part of a command then it is known as command injection (for example, OS, LDAP). Due to the lack of strict input validation on the server-side, malicious input can make way as a query or command to enumerate backend information.
Due to the attractiveness of databases containing secret information, unfortunately, SQL injection attacks have been very common attack vector in the recent past.
Example
An example of SQL injection vulnerability would be UNION or Blind SQL injection attacks to enumerate information from the database. In the case of OS command injection, some of the useful commands are whoami, uname -a (linux), ver (windows), netstat, ping, etc for initial information about the underlying system. Further exploitation is performed by attackers leading up to compromise by initiating connections to attacker owned systems outside, or escalating privileges on the underlying system.
How do you prevent injection flaws?
The core concept behind injection flaws is the lack of input validation and sanitisation of data used by the application. Any input request that contains parameters as input can be vulnerable to a code injection flaw. This could be OS code injection, SQL injection or simple script injection based on the underlying code of vulnerable function in use.
To protect web applications against SQL injection attacks, it is important to separate data from commands and queries. Use of prepared statements (with parameterised queries) is how developers should write database queries. This allows to first define all the SQL code and then pass each parameter to the query, therefore, distinguishing between code and data irrespective of user input (malicious or legit).
Broken authentication
A broken authentication vulnerability could allow an attacker to utilise manual or automatic methods to take over a user account, leading up to complete control of the underlying system. Broken authentication and session management flaws are often identified during web application penetration testing projects. These flaws relate to authentication mechanisms such as login mechanisms, keys, session tokens, or implementation flaws that may allow an attacker to compromise passwords by launching brute force attacks, take over user sessions, enumerate legitimate user information, and related implications.
Examples of broken authentication vulnerabilities
- Username enumeration based on changes observed in the application’s behaviour to identify valid usernames.
- Brute-force attacks where an attacker uses trial and error method to guess valid user credentials using wordlists of usernames and passwords.
- Applications allowing password attacks such as credential stuffing where stolen credentials from another database are tested against your application user accounts
- Allowing default, weak or trivial usernames and passwords
- Flawed two-factor verification logic where the application fails to verify the same user during the second step of authentication mechanism
How to prevent broken authentication attacks?
Implement multi-factor authentication to prevent automated, brute force, credential stuffing attacks
- Do not allow username enumeration opportunities on forgot password, login forms, registration pages.
- Use input form such as secure captcha against automated attacks
- Do not allow new user registrations without verification of the new account
- Ensure password complexity is checked on the server-side, in line with password policy requirements
For the popular CMS (Content Management Systems), it’s quite easy to stop a large number of attacks that target default paths, installations or settings. For instance, you can restrict administration interface access to the visitors of the website (only needed for your developers):
- /wp-admin/ on WordPress
- /index.php/admin on Magento
- /umbraco/login.aspx on Umbraco
- /admin for OpenCart
- /user/login on Drupal
- /administrator on Joomla!
Read the entire article originally published here.
