OWASP Top 10 Security Risks – Part I

OWASP stands for the Open Web Application Security Project, an online community that produces articles, methodologies, documentation, tools, and technologies in the field of web application security.

OWASP Top 10 is the list of the 10 most seen application vulnerabilities. It also shows their risks, impacts, and countermeasures. Updated every three to four years, the latest release has been released this year. Let’s dive into it!

The Top 10 OWASP vulnerabilities are:

1. Injection
2. Broken Authentication
3. Sensitive data exposure
4. XML External Entities (XXE)
5. Gent PrizreniBroken Access control
6. Security misconfigurations
7. Cross Site Scripting (XSS)
8. Insecure Deserialization
9. Using Components with known vulnerabilities
10. Insufficient logging and monitoring

1. Injection

An injection of code happens when an attacker sends invalid data to the web application with the intention to make it do something different from what the application was designed/programmed to do.

Perhaps the most common example around this security vulnerability is the SQL query consuming untrusted data. You can see one of OWASP’s examples below:

String query = "SELECT * FROM accounts WHEREcustID = '" + request.getParameter("id") + "'";

This query can be exploited by calling up the web page executing it with the following URL: http://example.com/app/accountView?id=’or’1’=’1, causing the return of all the rows stored on the database table.

The core of a code injection vulnerability is the lack of validation and sanitization of the data consumed by the web application, which means that this vulnerability can be present on almost any type of technology.

Here is another example of an SQL injection that affected over half a million websites that had the YITH WooCommerce Wishlist plugin for WordPress:

The SQL injection shown above could cause a leak of sensitive data and compromise an entire WordPress installation.

How do you prevent code injection vulnerabilities?

Preventing code injection vulnerabilities really depends on the technology you are using on your website. For example, if you use WordPress, you could avoid code injection vulnerabilities by keeping it to a minimum of plugin and themes installed.

If you have a tailored web application and a dedicated team of developers, you need to make sure to have security requirements your developers can utilize when designing and writing software. This will allow them to keep thinking about security during the lifecycle of the project.

Here are OWASP’s technical recommendations to prevent SQL injections:

• The preferred option is to use a safe API, which avoids the use of the interpreter entirely or provides a parameterized interface or migrate to use Object Relational Mapping Tools (ORMs).
  Note: Even when parameterized, stored procedures can still introduce SQL injection if PL/SQL or T-SQL concatenates queries and data, or executes hostile data with EXECUTE IMMEDIATE or exec().
• Use positive or “whitelist” server-side input validation. This is not a complete defense as many applications require special characters, such as text areas or APIs for mobile applications.
• For any residual dynamic queries, escape special characters using the specific escape syntax for that interpreter.
  Note: SQL structure such as table names, column names, and so on cannot be escaped, and thus user-supplied structure names are dangerous. This is a common issue in report-writing software.
• Use LIMIT and other SQL controls within queries to prevent mass disclosure of records in case of SQL injection.

From these recommendations you can abstract two things:

• Separation of data from the web application logic
• Settings to limit data exposure in case of successful injection attacks

Code injections represent a serious risk to website owners because if certain criteria are met, these attacks can lead to a hostile takeover or to the leaking of confidential information.

2. Broken Authentication

A broken authentication vulnerability can allow an attacker to use manual and/or automatic mediums to try to gain control over any account he/she wants in a system – or even worse – to gain complete control over the system.

Websites with broken authentication vulnerabilities are very common on the web. Broken Authentication usually refers to logic issues that occur on the application authentication’s mechanism, like bad session management prone to username enumeration.

To avoid broken authentication put into practice not leaving the login page for admins publicly accessible to all visitors of the website:

• /administrator on Joomla!,
• /wp-admin/ on WordPress,
• /index.php/admin on Magento,
• /user/login on Drupal.

The second most common form of this flaw is allowing users to brute force username/password combination against those pages.

Types of Vulnerabilities

However, these vulnerabilities can come in many forms. According to OWASP, a web application contains a broken authentication vulnerability if it:

• Permits automated attacks such as credential stuffing, where the attacker has a list of valid usernames and passwords.
• Permits brute force or other automated attacks.
• Permits default, weak, or well-known passwords, such as”Password1″ or “admin/admin“.
• Uses weak or ineffective credential recovery and forgot-password processes, such as “knowledge-based answers”, which cannot be made safe.
• Uses plain text, encrypted, or weakly hashed passwords.
• Has missing or ineffective multi-factor authentication.
• Exposes Session IDs in the URL (e.g., URL rewriting).
• Does not rotate Session IDs after successful login.
• Does not properly invalidate Session IDs. User sessions or authentication tokens (particularly single sign-on (SSO) tokens) aren’t properly invalidated during logout or a period of inactivity.

Writing insecure software results in most of these vulnerabilities. They can be attributed to many factors, such as lack of experience from the developers. It can also be the consequence of more institutionalized failures such as organizations rushing software releases, in other words, choosing working software over secure software.

How do you prevent broken authentication vulnerabilities?

In order to avoid broken authentication vulnerabilities, make sure the developers apply to the best practices of website security and support them by providing access to external security audits and enough time to properly test the code before deploying to production.

OWASP’s technical recommendations are the following:

• Where possible, implement multi-factor authentication to prevent automated, credential stuffing, brute force, and stolen credential re-use attacks.
• Do not ship or deploy with any default credentials, particularly for admin users.
• Implement weak-password checks, such as testing new or changed passwords against a list of the top 10000 worst passwords.
• Ensure registration, credential recovery, and API pathways are hardened against account enumeration attacks by using the same messages for all outcomes.
• Limit or increasingly delay failed login attempts. Log all failures and alert administrators when credential stuffing, brute force, or other attacks are detected.
• Use a server-side, secure, built-in session manager that generates a new random session ID with high entropy after login. Session IDs should not be in the URL. Ids should also be securely stored and invalidated after logout, idle, and absolute timeouts.

Source:Securi