As always, OWASP is free and open for everyone. Please
forward this message to anyone who is interested in application security.
Thanks for your support.
Jeff Williams, Chair
The OWASP Foundation
Dedicated to finding and fighting the causes of
We're familiar with the CWE project and there's a lot of overlap between
our vulnerabilities - not surprising given that most came from the same
sources. Where possible we're trying to keep the same names. We've
found that some of the topics are really attacks, and have organized
Dinis Cruz wrote:
If you do accept that it is possible to build such sandboxes, then we
need to move to the next interesting discussion, which is the 'HOW'
Namely, HOW can an environment be created where the development and
deployment of such Sandboxes makes business sense.
Cc: Dinis Cruz; Stephen de Vries; Secure Coding Mailing List; owasp-
[EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: [WEB SECURITY] RE: [SC-L] Re: [WEB SECURITY] On sandboxes,
and why you should care
On 5/26/06, Jeff Williams [EMAIL PROTECTED] wrote:
Dinis Cruz wrote:
If you do
Stephen de Vries wrote:
With application servers such as Tomcat, WebLogic etc, I think we have a
special case in that they don't run with the verifier enabled - yet they
appear to be safe from type confusion attacks. (If you check the
startup scripts, there's no mention of running with
Two important clarifications for Java
(based on my experiments):
1) The verifier IS enabled for the classes
that come with the Java platform, such as those in rt.jar. So, for
example, if you create a class that tries to set System.security (the private variable
that points to the
Jeff, as you can see by Stephen de Vries's response on this thread,
you are wrong in your assumption that most Java code (since 1.2)
must go through the Verifier (this is what I was sure it was
happening since I remembered reading that most Java code executed
in real-world applications is not
I'm a strong advocate of static analysis, but drawing conclusions about
overall security based only on these tools is just silly. Even ignoring the
scripting language problem, these tools simply aren't even looking for many
of the types of problems that cause the most serious risks. They're
I'm not sure which of the three definitions in Brian's message you're not
concurring with, but I think he was only listing them as strawmen anyway.
In any case, there's no reason that static analysis tools shouldn't be able
to find errors of omission. We use our tools to find these 'dogs that
³Show me places in the program where property X holds²
Yes. That's it exactly. Current tools can answer this type of question to
some extent, but they're not really designed for it. The interaction
contemplated by most of the tools is more like show me the line of code the
alarms. Maybe that's what you meant by 'inhibit'.
Jeff Williams, CEO
email: [EMAIL PROTECTED]
From: John Steven [mailto:[EMAIL PROTECTED]
Sent: Friday, February 03, 2006 1:40 PM
that saying 'flaw' alone
doesn't help distinguish it from 'bug' in the minds of most developers or
Jeff Williams, CEO
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Crispin Cowan
Um, so if there is no documentation you can't find design flaws?
From: Gary McGraw [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 02, 2006 8:50 PM
To: Jeff Williams; Secure Coding Mailing List
Subject: RE: [SC-L] Bugs and flaws
I'm sorry, but it is just
very difficult at best.
From: Jeff Williams [mailto:[EMAIL PROTECTED]
Sent: Thu Feb 02 20:59:14 2006
To: Gary McGraw; 'Secure Coding Mailing List'
Subject:RE: [SC-L] Bugs and flaws
Um, so if there is no documentation you can't find design flaws
The *only* way to learn application security is to test applications
hands on and examine their source code. To encourage the next
generation of application security experts, the Open Web Application
Security Project (OWASP) has developed an extensive lesson-based
training environment called
did a talk on this at the NSA High Confidence Software and Solutions
conference a few weeks back. The slides are here
Aspect Security, Inc.
I would think this might work, but I - if I ran a software development
company - would be very scared about signing that contract... Even if
I did everything right, who's to say I might not get blamed? Anyway,
insurance would end up being the solution.
What you *should* be scared of is a contract
I'd love to get this list's feedback on a new document from OWASP.
OWASP Secure Software Development Contract Annex
Everyone involved with a software contracting relationship of any kind, even
within a single application team, should have a
a bunch of security features into
the libraries. I've seen far too many libraries that expose a very powerful
API and make it too easy for a developer to make security mistakes.
Does anyone have pointers to articles on designing API's so that they are
easy to use securely?
Mail list logo