RE: Top Ten Web App Sec Problems

["Craig, Scott" <SCraig () kmart com>]

- Insecure Storage of Keys and Passwords
- Insecure Backside Protocols
- Insecure Use of Encryption

The above three items you listed I've seen too many times. 

These types of issues are bad for security among internal people as well as
hackers. I've talked to companies specializing in "plug and play" web
portals for
use as corporate portals and they don't seem to care about security as a
priority.
Developers don't realize that there has been methods for clients to see the
code that
goes into an ASP script, and that the backend database access is not as
hidden as they thought.
In addition, it's been tough preaching differences between development and
production systems
in using different databases and accounts. Backend systems to web front ends
may do things
such as process (refill) prescription drugs, manage an employee's payroll
(W4 changes, Savings Plans, etc),
read corporate email, order merchandise (credit card usage), etc. Accounts
used for such systems don't always get managed by a proper security
organization, but are controlled by developers who believe the world is a
safe place.

Encryption. There are big name software providers for E-Commerce who don't
manage encryption of credit card numbers in their database.

> -----Original Message-----
> From: Jeff Williams @ Aspect 
> [mailto:jeff.williams () aspectsecurity com] 
> Sent: Monday, December 02, 2002 9:16 PM
> To: webappsec () securityfocus com
> Subject: Re: Top Ten Web App Sec Problems
>
>
> Steven, thanks for searching the public databases. That will 
> help provide some better justification for our top ten list. 
> I'm afraid that many serious flaws won't make it into those 
> lists because they only apply to one site's custom code.  I 
> believe the best top ten list is going to come from the minds 
> of the people on this list who have been inside web 
> applications for the past few years.
>
> Another issue in putting together a "top ten" list is the 
> "superclass" issue you raised.  Some of these problems are 
> categories, others are very specific instances of a 
> vulnerability. I think we should try to list vulnerabilities 
> that are "just right" ;-)  We should try to minimize overlap 
> between vulnerabilities, yet draw a big enough circle that a 
> reasonable class of problems is represented.
>
> A final factor that should go into the "top ten" decision 
> process is the overall risk represented by a vulnerability.  
> How easy is the hole to discover?  Are there existing tools 
> to search for it?  Do you need special tools to exploit?  
> What are the consequences of exploiting the hole?  Our 
> choices should represent the ones that we think will be the 
> most serious for industry during the next year or so.
>
> Here's my initial list of candidates -- obviously there are 
> more than 10, so we'll need to weed out a few
>
>   - Cross Site Scripting (XSS)
>   - Operating System Command Injection
>   - Thread Safety Problems
>   - Reliance on Client-Side Security
>   - SQL Injection
>   - Error Handling (includes stack traces, database dumps, 
> error codes)
>   - Buffer Overflow (includes format strings)
>   - Tainted Parameters
>   - Insecure Use of Encryption
>         (includes key and cert handling, algorithm, initialization,
> randomness)
>   - Insecure Email Functions (send an email from our site)
>   - Insecure Storage of Keys and Passwords
>   - Insecure Backside Protocols
>         (includes credentials and use of ssl)
>   - Insecure Server Configuration
>         (latest patches, dir listing, traversal, sandbox, 
> sample apps, old files, ssl)
>   - Broken Access Control (includes canonicalization - URL, 
> hex, unicode)
>   - Broken Authentication (includes credentials in cleartext)
>   - Session Hijacking
>   - Broken Account Management
>         (includes password changing, forgot my password)
>   - Revealing Client-Side Comments
>
> I'm looking forward to everyone's feedback on these.
>
> --Jeff
>
> Jeff Williams
> Aspect Security, Inc.
> www.aspectsecurity.com
>
> ----- Original Message -----
> From: Steven M. Christey
> To: webappsec () securityfocus com
> Sent: Monday, December 02, 2002 4:33 PM
> Subject: Re: Top Ten Web App Sec Problems
>
>
>
> Based on CVE statistics, cross-site scripting is the 2nd most 
> frequently publicly reported vulnerability this calendar 
> year, overall.  Since XSS is mostly specific to web apps, 
> this probably makes it the #1 vulnerability in deployed web 
> apps (though web browsers and servers are sometimes subject 
> to XSS too).
>
> I do not have an easy way of finding the CVE items for 
> web-specific vulnerabilities and summarizing those.  Also, 
> the vulnerability statistics are not as low-level as I'd like 
> with respect to web-specific issues like parameter tampering.
>
> For what it's worth, here are my general impressions for web 
> apps (which excludes server- and browser-side vulnerabilities):
>
>
> Top Three (my best guess)
> -------------------------
>
> - XSS is widespread.
>
> - Probably a good percentage of all reported directory traversal
>   issues are in web apps; wild guess is 50-60% of all traversal.
>   Note: this includes many canonicalization errors, but I don't have
>   that level of detail.
>
> - Probably a good percentage of authentication and privilege
>   escalation errors are in web apps; my wild guess is 50-60% of all
>   reported authentication issues, and 30-40% of all privilege
>   management issues.
>
>
> Others
> ------
>
> - Other common issues are: (a) storing sensitive files under the web
>   document root with world-readable/writable permissions, (b)
>   plaintext passwords, (c) buffer overflows [although probably near
>   the tail end of the top ten, since many web apps use scripting
>   languages that aren't subject to overflows], (d) shell
>   metacharacters, and (e) real pathname information leaks [though
>   there are several different causes of such leaks]
>
> - High-profile, "interesting" bugs like SQL injection and PHP remote
>   file execution / variable tampering are not that frequent,
>   relatively speaking.  This makes some sense since many web apps
>   don't use a database, and many don't use PHP.
>
> - As I said in my Bugtraq post last week, "malformed input" is a
>   poorly understood "superclass" of vulnerability.  Upon reflection, I
>   don't think I've seen too many issues in web apps that are related
>   to malformed inputs.  If this is true (and it may not be), then I
>   wonder if auditors are even looking for this type of issue, as it
>   often results in "only" a DoS whose scope may be limited.
>
>
>
> Steve