.
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
Jeff Williams, Chair
The OWASP Foundation
Dedicated to finding and fighting the causes of
insecure software
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
them
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.
It's the
]
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
Brian,
³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
vulnerability
alarms. Maybe that's what you meant by 'inhibit'.
--Jeff
Jeff Williams, CEO
Aspect Security
http://www.aspectsecurity.com
email: [EMAIL PROTECTED]
phone: 410-707-1487
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
architects.
--Jeff
Jeff Williams, CEO
Aspect Security
http://www.aspectsecurity.com
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Crispin Cowan
Sent: Wednesday
Um, so if there is no documentation you can't find design flaws?
--Jeff
-Original Message-
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
is
very difficult at best.
gem
-Original Message-
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
http://www.aspectsecurity.com/documents/Aspect_HCSS_Brief.ppt.
--Jeff
Jeff Williams
Aspect Security, Inc.
www.aspectsecurity.com
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
Hi,
I'd love to get this list's feedback on a new document from OWASP.
OWASP Secure Software Development Contract Annex
(http://www.owasp.org/documentation/legal.html)
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?
--Jeff
Jeff Williams
19 matches
Mail list logo
