Jeff Williams, Chair
The OWASP Foundation
"Dedicated to finding and fighting the causes of
insecure software"
___
Secure Coding mailing list (SC-L)
SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailma
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 accordingly
Fortify has graciously donated these vulnerability writeups to OWASP,
where they will be maintained wikipedia-style. We have a strong team of
reviewers in place to review all changes daily. There are a total of
almost 500 vulnerabilities now, from Fortify, CLASP, and many other
sources. We're cr
aton [mailto:[EMAIL PROTECTED]
> Sent: Friday, May 26, 2006 10:54 AM
> To: [EMAIL PROTECTED]
> 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,
> a
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 "b
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 -ve
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 Secur
> 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
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 great
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 didn
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
;t work well for me. Too many
false 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 PROT
ou have to try to construct them. Doing them from code 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?
--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
#x27;design-flaw' is fine. But I agree with others 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: [
FYI -- Andrew van der Stock (OWASP Guide project lead) has posted a
challenge (http://www.greebo.net/?p=320)
to the PHP community -- get secure or become irrelevant. The tradeoffs being
discussed between power, simplicity, and security are relevant to all
environments. In fact, anyone desig
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
e visible to everyone.
I 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 t
Michael,
Don't hate the player, hate the game (quoting Ice-T). Developers aren't
going to just write code differently because we say so. Speaking frankly,
today there's really no incentive for them to write code securely. And no
amount of guidelines, super-complex code scanners, or jumping up an
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 dis
portant'.
--Jeff
- Original Message -
From: "ljknews" <[EMAIL PROTECTED]>
To: "Secure Coding Mailing List"
Sent: Tuesday, February 01, 2005 6:50 PM
Subject: Re: [SC-L] free lunch almost over
At 6:14 PM -0500 2/1/05, Jeff Williams wrote:
Sure. How many of those
Sure. How many of those are there?
--Jeff
- Original Message -
From: "ljknews" <[EMAIL PROTECTED]>
To: "Secure Coding Mailing List"
Sent: Tuesday, February 01, 2005 4:11 PM
Subject: Re: [SC-L] free lunch almost over
At 3:23 PM -0500 2/1/05, Jeff Williams wr
Right on! Great article. Concurrency is a huge issue and nowhere more
important than web applications. Many many developers are writing web apps
and not realizing that they are heavily multithreaded. They develop and test
on their desktop in a single-user environment, so they don't see the
prob
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
Subject: Re: [SC-L] How do we improve s/w developer awareness?
Date: Mon, 15 Nov 2004 20:40:13 -0500
Organization: Aspect Security, Inc.
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7b
We certainly have a lot to learn from the other communities, but security is
worse than the other *-ilities, because it is more difficult to see.
Consumers can tell which operating system is easier to use, and which one is
faster, but there is no way to know which is more secure today.
Until consu
ke an
article I wrote at OWASP --
http://www.owasp.org/columns/jwilliams/jwilliams4.html. At the very end is
a link to the GE Code Integrity Warranty which is a good example. Well, a
good example of one end of the spectrum anyway.
--Jeff
Jeff Williams
Aspect Security, Inc.
http://www.aspectsecurit
es.
Does anyone have pointers to articles on designing API's so that they are
easy to use securely?
--Jeff
Jeff Williams
Aspect Security
http://www.aspectsecurity.com
best practices. Almost every talk includes a process angle.
You can find out more and check out the agenda at http://www.owasp.org.
There are still a few seats left. I hope you can join us.
--Jeff
Jeff Williams
Aspect Security, Inc.
http://www.aspectsecurity.com
- Original Message -
From
29 matches
Mail list logo
