Monday, July 3, 2017

OWASP Top 10 2017

Open Web Application Security Project

An online community with a goal to raise awareness about application security. It does so by identifying some of the most critical risks facing organizations. Each year the top 10 OWASP threats are published.

Here I review the top 10 OWASP draft list for 2017.  Formal publication is not expected till July/August.

All involve allowing untrusted or manipulated requests, command or queries to be executed by a web application. These requests bypass the applications intended logic
SQL Injection
Code Injection
OS Commanding
XML Injection
Buffer Overflow

Use a vetted library/framework
Use an api, avoiding the use of an interpreter
Run the app with minimum privileges
Input sanitization i.e. whitelist only allowed characters

Broken Authentication and Session Management
Capture or Bypass the authentication methods used by a web app. A session id is created following login and these needs to be secured.

Avoid unencrypted conections
Avoid predictable login credentials. web ap needs to enforce strong passwords
Ensure session id timeouts and when a user logs out
credentials need to be hashed or encrypted
Do not use session ids in the url

Cross Site Scripting
Injected of untrusted snippets of Javascript are placed into web application. The script is executed by the victim who is visiting the target site. 3 primary types
Reflected XSS. An attacker sends the victim a link that has an embedded script
Stored XSS. An attacker is able to plant a persistent script on the web site
DOM based XSS.

Use a vetted library/framework
input validation
output encoding

Broken Access Control
Access control, sometimes called authorization, is how a web application grants access to content and functions to some users and not others. These checks are performed after authentication, and govern what ‘authorized’ users are allowed to do. Access control are insidiously difficult to implement correctly.

Insecure Id’s: Web applications should not rely on the secrecy of any id’s for protection.
Forced Browsing Past Access Control Checks:  Many sites require users to pass certain checks before being granted access to certain URLs that are typically ‘deeper’ down in the site. These checks must not be bypassable
Path Traversal: Such attacks try to access files that are normally not directly accessible by anyone, or would otherwise be denied if requested directly.
File Permissions  Only: Files that are specifically intended to be presented to web users should be marked as readable using the OS’s permissions mechanism, most directories should not be readable, and very few files, if any, should be marked executable.
Client Side Caching: Developers should use multiple mechanisms, including HTTP headers and meta tags, to be sure that pages containing sensitive information are not cached by user’s browsers

Security Misconfiguration
Incorrectly assembling the safeguards for a web application.  These misconfigurations typically occur when holes are left in the security framework of an application by systems administrators, DBAs or developers.  They can occur at any level of the application stack including the platform, web server, application server, database, framework and custom code. These security misconfigurations can lead an attacker right into the system and result in a partially or even totally compromised system.

Develop a repeatable process to reduce the surface of vulnerability
Disable default accounts and change passwords
Keep software up-to-date
Develop a strong application architecture that effectively isolates components and encrypts data which is especially important with sensitive data.
Disable any unnecessary files or features
Don’t present stack tracers to users
Ensure security settings in development frameworks and libraries are set to secure values
Run tools (i.e. automated scanners) and perform regular audits to identify holes in the security configuration

Sensitive Data Exposure
Sensitive data exposure vulnerabilities can occur when an application does not adequately protect sensitive information from being disclosed to attackers. For many applications this may be limited to information such as passwords, but it can also include information such as credit card data, session tokens, or other authentication credentials.
Don’t store sensitive data if you don’t need it. Be sure to encrypt the necessary sensitive data during storage, transit, and display.
Salting and encrypting sensitive data in storage, using TLS/SSL on pages displaying sensitive data, disabling caching of these pages

Insufficient Attack Protection
Applications need to detect, prevent, and respond to both manual and automated attacks
Defense in Depth: Implemented more than one security control supporting each other. E.g. deploy secure code, but also use technologies like Web Application Firewalls (WAFs) to prevent some kinds of attacks.
A strong application architecture that provides effective, secure separation between components and tenants.
Detect Attacks: Detect unexpected conditions early in the code and generate appropriate logging messages and security alerts. Correlate the logging of all involved components.
Respond to Attacks: Attacks may be critical to timely reaction. Decide by kind and severity whether to respond automatically (e.g. through OWASP AppSensor) or manually, e.g. develop temporary virtual patches using a WAF.

Cross-Site Request Forgery
A malicious website will send a request to a web application that a user is already authenticated against from a different website. This way an attacker can access functionality in a target web application via the victim's already authenticated browser.
The most common method to prevent Cross-Site Request Forgery (CSRF) attacks is to append unpredictable challenge tokens to each request and associate them with the user’s session. Such tokens should at a minimum be unique per user session, but can also be unique per request. By including a challenge token with each request, the developer can ensure that the request is valid and not coming from a source other than the user

Using Components With Known Vulnerabilities
Vulnerabilities in third-party libraries and software are extremely common and could be used to compromise the security of systems using the software.

Keep frameworks, modules and components up to date. Ensure that the latest patches are installed. Maintain a non-production system to test the patches. Have a split between Dev, Test and Live environments with easy ways to move new code from Dev to Test to Live during your testing process.
Another important tactic in guarding against vulnerabilities in third party frameworks, modules and components is to only use the parts that you need to deliver the application or service. Disable those parts you are not using.
Stay up to date with supplier security bulletins, project blogs, release notes, and with the information published on trusted security sites.

Underprotected APIS
All the different types of injection, authentication, access control, encryption, configuration, and other issues can exist in APIs just as in a traditional application.
Ensure client server API communications are secured
Use strong authentication, and access control scheme
Parser configuration is hardened


Security needs to be incorporated throughout the lifecycle
  • Threat Modeling/ Security Assess Application
  • Secure Design and Review
  • Secure Coding and Code Review
  • Penetration Testing
  • Remediation

Other publications include the 
           OWASP wiki

           OWASP Developer’s Guide

           OWASP Testing Guide

           OWASP Code Review Guide

           OWASP Prevention Cheat Sheets

           OWASP ASVS – Application Security Verification Standard

No comments: