OWASP TOP 10-2013 Vulnerabilities:

What is OWASP?

The OWASP (Open Web Application Security Project) Founded in 2001 as an open-source security community centered around the goal of spreading application security awareness.

OWASP is a non-profit organization dedicated to providing unbiased, practical information about application security. OWASP Top 10 represents a broad consensus about the most critical security risks to web applications.

Adopting the OWASP Top 10 is perhaps the most effective first step towards changing the software development culture within your organization into one that produces secure code.

Top 10-2013 OWASP Vulnerabilities:

On June 12, 2013, the OWASP Top 10 for 2013 was officially released. The OWASP Top 10 Most Critical Web Application Security Risks are:

A1 Injection

A2 Broken Authentication and Session Management

A3 Cross-Site Scripting (XSS)

A4 Insecure Direct Object References

A5 Security Misconfiguration

A6 Sensitive Data Exposure

A7 Missing Function Level Access Control

A8 Cross-Site Request Forgery (CSRF)

A9 Using Components with Known Vulnerabilities

A10 Unvalidated Redirects and Forwards

Detail Explanation & Prevention Techniques of Top 10-2013 OWASP Vulnerabilities:

A1: Injection Attacks:

Injection flaws occur when attackers try to inject some malformed data or input (such as SQL queries etc.) via input parameters or data fields to the application/database.

A successful injection exploits attack can read sensitive data and can also modify the database and execute administration operations on the database.

These flaws are often found in SQL, LDAP, Xpath, or NoSQL queries, OS commands, XML Parsers, SMTP Headers, program arguments, etc.

Prevention Techniques

1. Using prepared statements (with parameterized queries) or stored procedures are best way to prevent.
2.  Input validation and Character escape to be implemented before passing it to interpreter.
3. Input validation such as Whitelist of user supplied inputs, but it is not a complete defense. OWASP ESAPI has an extensible library of whitelist input parameter routines.
4. Minimize database privileges to reduce impact of flaw.
5. Web Application Firewalls can also be used to filter out malicious data.
6. Database errors should not reveal critical information such as database structures or configuration details and should use customized general error messages.
7. Do not run application code/services with database admin/high privileged accounts.
8. Keep the database patched and harden the database configuration and OS by disabling unnecessary services and functionality.

A2: Broken Authentication and Session Management:

Here attacker uses flaws in authentication and session management functions (ex: exposed accounts, passwords and session ids, etc) to impersonate/pretend as original users.

These flaws could be in areas such as logout, password management, and timeouts, remember me, secret questions, account updates, etc.  So an attacker can use any of the flaws to attack an application.

Below are the basic vulnerable areas:

1. User credentials are not protected when stored using hashing or encryption.
2. Credentials can be guessed or overwritten through weak account management functions      
3. (e.g.:  Account creation, change password, recover password, weak session ids,     
4. Predictable Credentials like admin etc.)
5. Session IDs are exposed in URLs (ex: URL rewriting)
6. Session ids are vulnerable to session fixation attacks
7. Session IDs don’t timeout, or user session or authentication tokens, particularly single sign-on tokens are not invalidated properly during timeout.
8. Session IDs are not rotated after successful login.
9. Passwords, session ids and other credentials sent over unencrypted channels.

Prevention Techniques:

1. Strong Password policy should be in place.
2. All Passwords should be stored in Hashed or encrypted form to protect from exposure. Hashed form is preferred as it is not reversible.
3. Account Lockout policy should be enabled and also CAPTCHA can be used for multiple login attempts.
4. Secure and Http Only cookies – Set the secure flag on a cookie so that the browser will prevent the transmission of a cookie over an unencrypted channel.
5. Using the HttpOnly flag helps mitigate the risk of client side script accessing the protected cookie (if the browser supports it).
6. Protecting Credentials in Transit – The only effective technique is to encrypt the entire login transactions using SSL.
7. Session ID Protection -– Ideally, a user’s entire session should be protected via SSL. If this is done, then the session ID (e.g., session cookie) cannot be grabbed off the network, which is the biggest risk of exposure for a session ID.

If SSL is not viable for performance or other reasons then session IDs themselves must be protected in other ways. First, they should never be included in the URL as they can be cached by the browser, sent in the referrer header, or accidentally forwarded to a ‘friend’. Session IDs should be long, complicated, random numbers that cannot be easily guessed. Session IDs can also be changed frequently during a session to reduce how long a session ID is valid. Session IDs must be changed when switching to SSL, authenticating, or other major transitions.

• Browser Caching – Authentication and session data should never be submitted as part of a GET request, but POST request should always be used instead. Authentication pages should be marked with all varieties of the no cache tag to prevent someone from using the back button in a user’s browser to backup to the login page and resubmit the previously typed in credentials.
• Re-Authentication process for some critical communications.
• Session tokens should be expired on server and destroyed when a browser is closed.
• Strong effort should also be make to prevent XSS vulnerability which can be used to    steal session ids.
• OWASP strongly recommends to meet all the authentication and session management requirements mentioned in  OWASP’s Application Security Verification Standard (ASVS) areas V2 (Authentication) and V3 (Session Management).

A3: Cross-Site Scripting:

XSS attack occurs when an attacker injects a malicious code or client-side scripts into the vulnerable application and this code or script will be executed. Here, the attacker doesn’t attack the application but the users of the application.

The impact of the attack varies a lot such as from session hijacking, disclosure of the sensitive data, CSRF attacks, and more. If the victim has admin rights, it can lead to code execution on the server.

XSS is categorized into three types: Reflected Cross-Site Scripting, Stored Cross-Site Scripting, and DOM Based Cross-Site Scripting

Reflected Cross-Site Scripting:

This is one of the most common types of XSS. This attack occurs when a malicious script is sent to the application through the Request and the same script is reflected back to the browser and executed at the victim machine.

Using phishing emails and social engineering techniques, the attacker tricks the user to perform his intended action such as clicking on the link and it will end up executing the script to send the request and the same will be reflected and executed at the victim browser.

Stored Cross-Site Scripting:

Stored XSS is a more dangerous type in XSS. This attack occurs when a malicious script is injected and stored in the application. So whenever users navigate to the page (ex: Comments section, forum, etc.) in which script is stored, this script will be executed.

DOM Based Cross-Site Scripting:

This is a bit of an advanced type of cross-site scripting.  This attack occurs as a result of modifying the DOM environment of the user’s browser used by the client-side script so that this code runs in an unexpected manner.

This Vulnerability can lead to stealing a user’s sessions, credentials, keylogging.

Prevention Techniques:

XSS attacks are possible mainly because the server is not escaping special characters in the output. There are 4 broad strategies for defeating XSS:

1. Character Escaping
2. Output encoding
3. Whitelisting good input
4. Blacklisting bad input

Character Escaping:

To prevent any malicious HTML from rendering. Escaping these characters involves turning them into their entity equivalents < and >, which will not be interpreted as HTML tags by a browser.

Output Encoding:

The purpose of output encoding (as it relates to Cross-Site Scripting) is to convert untrusted input into a safe form where the input is displayed as data to the user without executing as code in the browser.

Whitelisting:

Create a whitelist of characters required by the application. Once this whitelist is ready, the application should disallow all requests containing any character apart from those in the whitelist.

Blacklisting:

The application should not accept any script, special character or HTML in fields whenever not required. It should escape special characters that may prove to be harmful. Some of the main characters used in scripts that must be escaped are as follows:

<> ( ) ‘ ” / \  * ; : = { } `(backtick) % + ^ ! – \x00-\x20 (x is a hexadecimal notation – it includes Space, Tab, Carriage Return, and Linefeed.)

A4: Insecure Direct Object References:

Applications frequently use the actual name or key of an object (ex: file, directory, database record, or key as URL or form parameter) when generating web pages. Here applications don’t always verify whether the user is authorized to access the target object. This leads to insecure direct object reference flaws. Attackers can easily manipulate parameter values to access other objects without authorization.

Prevention Techniques:

1. Avoid exposing private object references to users wherever possible such as primary keys or file names.
2. Use per user or session indirect object references. (OWASP’s ESAPI includes both sequential and random access reference maps that developers can use to eliminate direct object references)
3. We should implement access control check in direct object reference and all referenced objects.
4. Allow access to the user on basis of its privileged matrix.
5. Do not allow the user to directly call any object from the database.
6. Restrict user to download contents that he is authorized for.
7. The best solution is to use an index value or reference map to prevent parameter manipulation attack.

A5: Security Misconfiguration:

This vulnerability arises when the security settings of the webserver or application are not configured properly and left with default and insecure values. Misconfiguration can occur at application level to network-level etc. such as webserver, network devices, servers, database, frameworks, and virtual machines.

Automated scanners can be useful in detecting misconfigurations. This flaw can give attackers access to data or the functionality of the system.

Prevention Techniques:

1. Need to keep all software up-to-date and patches in a timely manner including all code libraries.
2. Disable administrator interfaces.
3. Running scans and audits periodically.
4. Don’t give any information about stack in error messages.
5. Delete unused pages and user accounts.
6. Change default usernames and passwords and use strong and unique passwords for every account.
7. White list WebPages.  Serve pages that are allowed and disallow any pages other than *.html, *.jsp, *.js, *.css etc. Whitelist are better than blacklist.
8. Make sure that no unnecessary features are enabled or installed (ex: ports, services, pages, accounts, privileges).
9. Disable directory listing if they are not necessary or set access control request to deny all requests.

A6: Sensitive Data Exposure:

This vulnerability occurs when an application fails to protect its sensitive information from revealing to illegitimate users and attackers. The attacker’s approach could be man-in-the-middle attacks, stealing clear text data from the servers, etc. One of the main reasons for this flow is not encrypting sensitive data.

Attackers will try to steal encryption keys rather than attacking crypto itself. When crypto is employed, weak key generation and management, and weak algorithm, protocol, and cipher usage are common, particularly for weak password hashing storage techniques.

Typically sensitive information includes Personally Identifiable Information (PII), Credit card information, credentials, etc.

Prevention Techniques:

1. Make sure to encrypt the sensitive data at rest and in transit.
2. Encrypt all data in transit with secure protocols such as TLS with perfect forward secrecy (PFS) ciphers, cipher prioritization by the server, and secure parameters. Enforce encryption using directives like HTTP Strict Transport Security (HSTS).
3. Ensure passwords are stored with algorithm specially used for password protection such as  BCRYPT, PBKDF2, SCRYPT
4. Disable auto complete on forms and disable caching for pages that contain sensitive data.
5. Don’t store sensitive data unnecessarily. Discard it as soon as possible or use PCI DSS compliant tokenization or even truncation. Data that is not retained cannot be stolen.
6. Credentials information should not be used in configuration file or properties file. If possible encrypt this information and avoid Password in configuration file.   
7. Classify the data as per the privacy laws, regulatory requirements, or business needs.

A7: Missing Function Level Access Control:

This Vulnerability occurs when the application doesn’t verify the function level access rights before making that functionality accessible to the user. Basically, applications fail to enforce sufficient authorization to certain actions. Administrative functions are key targets for attackers.

Prevention Techniques:

1. Default should be access deny all, requiring explicit grants to specific roles for access to every function.
2. If the function involved in workflow, make sure the conditions are in proper state to allow access.
3. Only show the functions that users can access with its privileges
4. Use Access control lists and role-based authentication mechanisms and minimize CORS usage.

A8: Cross-Site Request Forgery:

CSRF exploits the trust that a server/website has for the user whereas Cross-Site Scripting (XSS) exploits the trust that the user has for the server/website.

Cross-site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application to which he/she is currently authenticated. With a little help from social engineering (like sending a link via email/chat), an attacker may trick the users of a web application into executing actions of the attacker’s choosing. A successful CSRF exploit can compromise end-user data and may allow an attacker to perform an account hijack. If the targeted end-user is the administrator account, this can compromise the entire web application.

An attacker creates a special page and tricks the user into visiting it while the user is logged in to the application. This special page triggers a request to the application with the user’s session information. This request may be for Create User.

The request is forged to look like a valid request for this operation. All the details required for the operation to succeed are present as query-string/POST variables. When the request is sent from the victim’s machine, valid cookies with the session information are also sent.

The application misunderstands that this request is valid, as it contains the cookies. So, the operation succeeds without the user’s knowledge.

The special page is quite easy to create. It might be a simple HTML page with an img alt=* src=” “tag with the source pointing to the page that performs the operation

Prevention Techniques:

1. Append unpredictable challenge tokens to each request and associate them with user’s session. It is important to limit a time period to which token is valid. This techniques is called as Synchronizer Token Pattern.
2. Please check the OWASP cheat sheet for more information-https://www.owasp.org/index.php/CrossSite_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet
3. Never allow any changes to data via GET requests.
4. Limiting the lifetime of session cookies.
5. We can also use CSRF Filter or anti CSRF packages such as the OWASP CSRF Gaurd
6. Checking the HTTP Referer header to see if the request is coming from an authorized page is commonly used for embedded network devices because it does not increase memory requirements. However a request that omits the Referer header must be treated as unauthorized because an attacker can suppress the Referer header by issuing requests from FTP or HTTPS URLs. This strict Referer validation may cause issues with browsers or proxies that omit the Referer header for privacy reasons. Also, old versions of Flash (before 9.0.18) allow malicious Flash to generate GET or POST requests with arbitrary HTTP request headers using CRLF Injection. Similar CRLF injection vulnerabilities in a client can be used to spoof the referrer of an HTTP request.
7. Use the “double-submitted cookie” method as described by Felten and Zeller:

When a user visits a site, the site should generate a pseudorandom value and set it as a cookie on the user’s machine. The site should require every form submission to include this value as a form value and also as a cookie value. When a POST request is sent to the site, the request should only be considered valid if the form value and the cookie value are the same, because of the same-origin policy, an attacker cannot read or modify the value stored in the cookie. To successfully submit a form on behalf of the user, the attacker would have to correctly guess the pseudorandom value. If the pseudorandom value is cryptographically strong, this will be prohibitively difficult.

This technique requires JavaScript, so it may not work for browsers that have JavaScript disabled

• Check if any links and form lack of Unpredictable (CSRF) Tokens. Without such tokens, attackers can forge malicious requests.
• An alternate defense could to prove that he is intended user via reauthentication or CAPTCHA
• Multistep transactions can also useful a little.
• Requiring the client to provide authentication data in the same HTTP request used perform any operation with security implications.

A9: Using Components with Known Vulnerabilities:

Developers use components within applications such as frameworks, libraries, and other software modules. These components might have some known and existing vulnerabilities. Some of the largest breaches have relied on exploiting know vulnerabilities. Organizations can give priority to this issue based on the assets and classification of data.

This vulnerability can be in any components such as OS, web/application server, database, applications, APIs and all components, runtime environments, and libraries. Automated scanners will be useful in identifying this flaw.

Applications will be at risk If you do not fix or upgrade the underlying platform, frameworks, and dependencies in a risk-based, timely fashion. This commonly happens in environments when patching is a monthly or quarterly task under change control, which leaves organizations open to many days or months of unnecessary exposure to fixed vulnerabilities.

Struts 2 remote code execution vulnerability that enables execution of arbitrary code on the server is an example of “Using components with known vulnerabilities”.

Prevention Techniques:

1. Be up-to-date with all the components used in application and there should be patch management policy in place.
2. Identify all components and version and monitor security of these components.
3. Stay up-to-date with vulnerability news and scan the application regularly.
4. Remove unused dependencies, unnecessary features, components, files, and documentation.
5. Download the components only from authentic sources and secure links.
6. Every organization must ensure that there is an ongoing plan for monitoring, triaging, and applying updates or configuration changes for the lifetime of the application or portfolio.

A10: Unvalidated Redirects and Forwards:

Web applications frequently redirect and forward users to other pages and websites, and use untrusted data to determine the destination pages. Without proper validation, attackers can redirect victims to phishing or malware sites, or use forwards to access unauthorized pages.

Unvalidated redirects and forwards are possible when a web application accepts untrusted input that could cause the web application to redirect the request to a URL contained within untrusted input. By modifying untrusted URL input to a malicious site, an attacker may successfully launch a phishing scam and steal user credentials. Because the server name in the modified link is identical to the original site, phishing attempts may have a more trustworthy appearance. Unvalidated redirect and forward attacks can also be used to maliciously craft a URL that would pass the application’s access control check and then forward the attacker to privileged functions that they would normally not be able to access.

Review the code for redirects and forwards, identify if the target URL is hardcoded and not validated then the application is vulnerable.

Prevention Techniques:

1. Simply avoid using redirects and forwards.
2. If used, do not allow the URL as user input for the destination. This can usually be done. In this case, you should have a method to validate URL.
3. If user input can’t be avoided, ensure that the supplied value is valid, appropriate for the application, and is authorized for the user.
4. It is recommended that any such destination input be mapped to a value, rather than the actual URL or portion of the URL, and that server side code translate this value to the target URL.
5. Sanitize input by creating a list of trusted URL’s (lists of hosts or a regex).
6. Use an intermediate disclaimer page that provides user with a clear warning that they are leaving the current site.
7. Ensure that no externally supplied requests are honored by requiring that all redirect requests include a unique nonce generated by the application. Be sure that nonce is unpredictable.
8. URL Validation can also be done by allowable URLs in database.

Found this article interesting? Follow DefenseLead on Twitter, Facebook and LinkedIn to read more exclusive content.

• DefenseLead Official Twitter Page
• DefenseLead Official Facebook Page
• LinkedIn
• DefenseLead Contact Us
• DefenseLead RSS Feed