[Owasp-defenders] Seeking Feedback on Proposal: OWASP Top 10 Web Application Security Risks for Defenders Community

Owasp-defenders owasp-defenders at lists.owasp.org
Fri Jul 29 09:47:42 EDT 2011

Greetings OWASP Defenders Community!  I have a proposal that I wanted to
send to the list for feedback.

The current OWASP Top 10 Web Application Security Risks Project is geared
towards developers.  I have often been asked by customers for a Top 10 list
of risks (attacks, vulns, etcŠ) for Operational Security/Infrastructure
teams ­ meaning the new OWASP Defenders Community.  With this idea In mind,
I have put together a DRAFT Top 10 of app security risks for the Defenders
community.  The idea for this list is that these are threats that OpSec
should be addressing for web applications rather than Developers.  Perhaps
this could be a sub-project of the main OWASP Top 10 Project.

If you all see value in this, then I propose that we move forward with a
more formal voting process to properly rank these items and/or add in new
ones.  The ranking below was obtained by cross referencing the WASC Web
Hacking Incident Database (WHID) data -
>  ­ as well as data from Trustwave customers.

Top 10 Application Security Risks for Defenders Community
A1: Application Level Denial of Service
Rationale for inclusion: App-level DoS is currently the #1 ranked attack
resulting in system downtime in the WASC Web Hacking Incident Database -
How to fix: Organizations need to update their web server configs to both
tune them for optimum performance and to mitigate Slow DoS Attacks -

A2: Information Leakage and Improper Error Handling
Rationale for inclusion: The vast majority of SQL Injection attacks leverage
detailed SQL error messages to both fine tune their attack payloads and to
use then error pages as the conduit for exfiltrating data.
How to fix: Most application platforms have configuration settings do
disable detailed error messages (such as ASP.Net's "customError" setting in

A3: Brute Force Authentication Attack
Rationale for inclusion: Automated password guessing tools, combined with
poor user and default passwords make it too easy for attackers to enumerate
valid credentials for password protected sites.
How to fix: Implement authentication velocity monitoring capabilities to
identify automated authentication attacks.  Implement response capabilities
such as CAPTCHAs.

A4: Unpatched third party software
Rationale for inclusion: Sites running 3rd party software (like WordPress,
Joomla, etcŠ) are often compromised due to emerging vulnerabilities
discovered in the main source code and/or plugins.
How to fix: Organizations must be diligent in monitoring for new versions
and installing them quickly.

A5: Insufficient Transport Layer Protection
Rationale for inclusion: Many organizations have not properly implemented
SSL/TLS encryption for secure communications which exposes sensitive
credentials/data to interception by 3rd parties.
How to fix: Verify SSL setup as site like https://www.ssllabs.com/.

A6: Social Engineering Attack
Rationale for inclusion: Attackers will often target IT/Help Desk personnel
to get account passwords reset or update DNS server addresses in domain
hosting companies.
How to fix: All IT staff need to have formal Social Engineering training
which should include Red Team, non-announced exercises.

A7: Misconfigured third party software
Rationale for inclusion: Default installations of software such as PHP (with
register_globals On) allow for attacks such as Remote File Inclusion (RFI).
How to fix: Default configurations should be thoroughly reviewed and updated
to restrict un-needed capabilities.

A8: Unsecured Remote Administrative Interfaces
Rationale for inclusion: Attackers will often target remote administrative
interfaces as it will allow them the ability to control the web application
and add in custom code (such as malware links).
How to fix: Implement Access Control Lists (ACLs) to restrict access to
authorized clients.

A9: Insufficient Application Logging
Rationale for inclusion: The default web server logging is very poor from an
incident response perspective.  If an incident does occur, the logging
details are not sufficient for response efforts to confirm a compromise and
verify what data was exposed.
How to fix: Increase web server logging and/or install a web application

A10: Insufficient Application Monitoring
Rationale for inclusion: Failure to properly monitor and react to active
attacks often result in eventual compromises.
How to fix: Organizations must implement a continuous (24x7), real-time
application monitoring capability in order to quickly identify active
attacks and respond appropriately.

Ryan Barnett
OWASP ModSecurity Core Rule Set Project Leader

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-defenders/attachments/20110729/588187c5/attachment.html 

More information about the Owasp-defenders mailing list