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.
Injection
Vulnerability
All involve allowing untrusted or manipulated requests, command or
queries to be executed by a web application. These requests bypass the
applications intended logic
e.g.
SQL Injection
Code Injection
OS Commanding
XML Injection
Buffer Overflow
Preventions
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
Vulnerability
Capture or Bypass the authentication methods used by a web app. A
session id is created following login and these needs to be secured.
Preventions
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
Vulnerability
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.
Preventions
Use a vetted
library/framework
input validation
output encoding
Broken Access Control
Vulnerability
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.
Preventions
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
Vulnerability
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.
Preventions
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
Vulnerability
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.
Preventions
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
Vulnerability
Applications need to detect, prevent, and
respond to both manual and automated attacks
Preventions
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
Vulnerability
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.
Preventions
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
Vulnerability
Vulnerabilities in third-party
libraries and software are extremely common and could be used to compromise the
security of systems using the software.
Preventions
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
Vulnerability
All the different types of injection, authentication, access control,
encryption, configuration, and other issues can exist in APIs just as in a
traditional application.
Preventions
Ensure client server API communications are secured
Use strong authentication, and access control scheme
Parser configuration is hardened
Footnote
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
https://www.owasp.org/index.php/Main_Page
• OWASP
Developer’s Guide
https://www.owasp.org/index.php/OWASP_Guide_Project
• OWASP
Testing Guide
https://www.owasp.org/index.php/OWASP_Testing_Project
• OWASP
Code Review Guide
https://www.owasp.org/index.php/Category:OWASP_Code_Review_Project
• OWASP
Prevention Cheat Sheets
https://www.owasp.org/index.php/OWASP_Cheat_Sheet_Series
• OWASP
ASVS – Application Security Verification Standard
https://www.owasp.org/images/3/33/OWASP_Application_Security_Verification_Standard_3.0.1.pdf
