OWASP Top 3 Application Severe Security Risks

posted in: Security | 0

Summary:

1. Injection: Impact SEVERE

Injection flaws, such as SQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing unauthorized data.

Threat Agents: Consider anyone who can send untrusted data to the system, including external users, internal users, and administrators.

Attack Vectors: (Exploitability EASY) Attacker sends simple text-based attacks that exploit the syntax of the targeted interpreter. Almost any source of data can be an injection vector, including internal sources.

Security Weakness: (Detectability AVERAGE) Injection flaws occur when an application sends untrusted data to an interpreter. Injection flaws are very prevalent, particularly in legacy code, often found in SQL queries, LDAP queries, XPath queries, OS commands, program arguments, etc. Injection flaws are easy to discover when examining code, but more difficult via testing. Scanners and fuzzers can help attackers find them.

Technical Impacts: Impact SEVERE

Injection can result in data loss or corruption, lack of accountability, or denial of access. Injection can sometimes lead to complete host takeover.

Am I Vulnerable To Injection?

The best way to find out if an application is vulnerable to injection is to verify that all use of interpreters clearly separates untrusted data from the command or query. For SQL calls, this means using bind variables in all prepared statements and stored procedures, and avoiding dynamic queries.

Checking the code is a fast and accurate way to see if the application uses interpreters safely. Code analysis tools can help a security analyst find the use of interpreters and trace the data flow through the application. Penetration testers can validate these issues by crafting exploits that confirm the vulnerability.

Automated dynamic scanning which exercises the application may provide insight into whether some exploitable injection flaws exist. Scanners cannot always reach interpreters and have difficulty detecting whether an attack was successful. Poor error handling makes injection flaws easier to discover.

Example Attack Scenario

The application uses untrusted data in the construction of the following vulnerable SQL call:

String query = “SELECT * FROM accounts WHERE custID='” + request.getParameter (“id”) +”‘”;

The attacker modifies the ‘id’ parameter in their browser to send: ‘ or ‘1’=’1. This changes the meaning of the query to return all the records from the accounts database, instead of only the intended customer’s.

http://example.com/app/accountView?id=’ or ‘1’=’1

In the worst case, the attacker uses this weakness to invoke special stored procedures in the database that enable a complete takeover of the database and possibly even the server hosting the database.

How Do I Prevent Injection?

Preventing injection requires keeping untrusted data separate from commands and queries.

1. The preferred option is to use a safe API which avoids the use of the interpreter entirely or provides a parameterized interface. Be careful of APIs, such as stored procedures, that are parameterized, but can still introduce injection under the hood.

2. If a parameterized API is not available, you should carefully escape special characters using the specific escape syntax for that interpreter. OWASP’s ESAPI has some of these escaping routines.

3. Positive or “white list” input validation with appropriate canonicalization is also recommended, but is nota complete defense as many applications require special characters in their input. OWASP’s ESAPI has an extensible library of white list input validation routines.

Refer OWASP SQL Injection Prevention Cheat Sheet:

http://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet

 

2. Broken Authentication and Session Management: Impact SEVERE

Application functions related to authentication and session management are often not implemented correctly, allowing attackers to compromise passwords, keys, session tokens, or exploit other implementation flaws to assume other users’ identities.

Developers frequently build custom authentication and session management schemes, but building these correctly is hard. As a result, these custom schemes frequently have flaws in areas such as logout, password management, timeouts, remember me, secret question, account update, etc. Finding such flaws can sometimes be difficult, as each implementation is unique.

Such flaws may allow some or even all accounts to be attacked. Once successful, the attacker can do anything the victim could do. Privileged accounts are frequently targeted.

Am I Vulnerable?

The primary assets to protect are credentials and session IDs.

1. Are credentials always protected when stored using hashing or encryption?

2. Can credentials be guessed or overwritten through weak account management functions (e.g., account creation, change password, recover password, weak session IDs)?

3. Are session IDs exposed in the URL (e.g., URL rewriting)?

4. Are session IDs vulnerable to session fixation attacks?

5. Do session IDs timeout and can users log out?

6. Are session IDs rotated after successful login?

7. Are passwords, session IDs, and other credentials sent only over TLS connections?

 

Example Attack Scenarios

Scenario #1: Airline reservations application supports URL rewriting, putting session IDs in the URL:

http://example.com/sale/saleitems;jsessionid=2P0OC2JDPXM0OQSNDLPSKHCJUN2JV?dest=Hawaii

An authenticated user of the site wants to let his friends know about the sale. He e-mails the above link without knowing he is also giving away his session ID. When his friends use the link they will use his session and credit card.

Scenario #2: Application’s timeouts aren’t set properly. User uses a public computer to access site. Instead of selecting “logout” the user simply closes the browser tab and walks away. Attacker uses the same browser an hour later, and that browser is still authenticated.

Scenario #3: Insider or external attacker gains access to the system’s password database. User passwords are not encrypted, exposing every user’s password to the attacker.

How Do I Prevent This?

The primary recommendation for an organization is to make available to developers:

1. A single set of strong authentication and session management controls. Such controls should strive to:

a) Meet all the authentication and session management requirements defined in OWASP’s Application Security Verification Standard (ASVS) areas V2 (Authentication) and V3 (Session Management).

b) Have a simple interface for developers. Consider the ESAPI Authenticator and User APIs as good examples to emulate, use, or build upon.

2. Strong efforts should also be made to avoid XSS flaws which can be used to steal session IDs.


3. Insecure Cryptographic Storage: Impact SEVERE

Many web applications do not properly protect sensitive data, such as credit cards, SSNs, and authentication credentials, with appropriate encryption or hashing. Attackers may steal or modify such weakly protected data to conduct identity theft, credit card fraud, or other crimes.

Threat Agents: Consider the users of your system. Would they like to gain access to protected data they aren’t authorized for? What about internal administrators?

Attackers typically don’t break the crypto. They break something else, such as find keys, get cleartext copies of data, or access data via channels that automatically decrypt.

The most common flaw in this area is simply not encrypting data that deserves encryption. When encryption is employed, unsafe key generation and storage, not rotating keys, and weak algorithm usage is common. Use of weak or unsalted hashes to protect passwords is also common. External attackers have difficulty detecting such flaws due to limited access. They usually must exploit something else first to gain the needed access.

Failure frequently compromises all data that should have been encrypted. Typically this information includes sensitive data such as health records, credentials, personal data, credit cards, etc.

Am I Vulnerable?

The first thing you have to determine is which data is sensitive enough to require encryption. For example, passwords, credit cards, health records, and personal information should be encrypted. For all such data, ensure:

1. It is encrypted everywhere it is stored long term, particularly in backups of this data.

2. Only authorized users can access decrypted copies of the data.

3. A strong standard encryption algorithm is used.

4. A strong key is generated, protected from unauthorized access, and key change is planned for.

Example Attack Scenarios

Scenario #1: An application encrypts credit cards in a database to prevent exposure to end users. However, the database is set to automatically decrypt queries against the credit card columns, allowing a SQL injection flaw to retrieve all the credit cards in cleartext. The system should have been configured to allow only back end applications to decrypt them, not the front end web application.

Scenario #2: A backup tape is made of encrypted health records, but the encryption key is on the same backup. The tape never arrives at the backup center.

Scenario #3: The password database uses unsalted hashes to store everyone’s passwords. A file upload flaw allows an attacker to retrieve the password file. All the unsalted hashes can be brute forced in 4 weeks, while properly salted hashes would have taken over 3000 years.

How Do I Prevent This?

The full perils of unsafe cryptography are well beyond the scope of this Top 10. That said, for all sensitive data deserving encryption, do all of the following, at a minimum:

1. Considering the threats you plan to protect this data from (e.g., insider attack, external user), make sure you encrypt all such data at rest in a manner that defends against these threats.

2. Ensure offsite backups are encrypted, but the keys are managed and backed up separately.

3. Ensure appropriate strong standard algorithms and strong keys are used, and key management is in place.

4. Ensure passwords are hashed with a strong standard algorithm and an appropriate salt is used.

5. Ensure all keys and passwords are protected from unauthorized access.

For a more complete set of requirements and problems to avoid in this area, see the ASVS requirements on Cryptography (http://www.owasp.org/index.php/ASVS).

Previous Post
Next Post

Leave a Reply