Re: [SC-L] OWASP Podcast 95 is live!

2013-07-02 Thread Jim Manico
http://www.secappdev.org/handouts/2012/Dan%20J.%20Bernstein/worst%20practices.pdf

--
Jim Manico
@Manicode
(808) 652-3805

On Jul 1, 2013, at 8:55 PM, Jeffrey Walton noloa...@gmail.com wrote:

Hi Jim,

Do you know if there is a slide deck available with the talk? It
sounds like there is, but Dr. Bernstein's Talk page
(http://cr.yp.to/talks.html) does not list an OWASP talk.

Jeff

On Wed, Jun 26, 2013 at 12:08 AM, Jim Manico jim.man...@owasp.org wrote:

I'm very pleased to announce that OWASP Podcast 95 is live! Special

thanks to Thomas Herlea who helped edit and produce this show.


This episode features Dan J. Bernstein, a computer science research

professor from the university of Illinois. He is speaking on

Cryptography Worst Practices.


Dan is a very sharp and controversial character. I hope you enjoy.


Direct download: https://www.owasp.org/download/jmanico/owasp_podcast_95.mp3

RSS Feed: https://www.owasp.org/download/jmanico/podcast.xml


Thanks for listening!


Aloha,

Jim Manico

OWASP Board Member

@Manicode
___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___


[SC-L] OWASP Podcast 95 is live!

2013-07-01 Thread Jim Manico
I'm very pleased to announce that OWASP Podcast 95 is live! Special
thanks to Thomas Herlea who helped edit and produce this show.

This episode features Dan J. Bernstein, a computer science research
professor from the university of Illinois. He is speaking on
Cryptography Worst Practices.

Dan is a very sharp and controversial character. I hope you enjoy.

Direct download: https://www.owasp.org/download/jmanico/owasp_podcast_95.mp3
RSS Feed: https://www.owasp.org/download/jmanico/podcast.xml

Thanks for listening!

Aloha,
Jim Manico
OWASP Board Member
@Manicode

___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___


[SC-L] 2013 OWASP Mobile Top 10 Call For Data

2013-05-21 Thread Jim Manico
Hello All,

We are pleased to announce the 2013 call for data to help refresh the Mobile 
Top 10 Risks for 2013 and publish a more formal publication. We are encouraging 
everyone to get involved.

The current Mobile Top Ten Risks are located here: 

https://www.owasp.org/index.php/OWASP_Mobile_Security_Project#tab.3DTop_Ten_Mobile_Risks

- What do we need? - 

Right now we are looking for data that represents the current state of mobile 
application security. We are soliciting not just vulnerability data, but also 
incident and attack data that reflects the real-world prevalence and 
significance of these issues. The goal in requiring both is to rank risks 
accordingly based on data as opposed to making assumptions. We will use this 
data to flesh out and re-evaluate the currently incomplete Mobile Top Ten 
Project.

- How can you contribute? - 

Contributing data is easy. All we require is anonymized statistics on the 
vulnerabilities you’ve seen in 2012-Present. If you have data on real-world 
incidents and attacks to share, these will be of great value as well as they 
will allow real-world impact to be better assessed. This can be just aggregate 
percentages, no need to tell us how many apps you’re doing if you’re not 
comfortable with that. Something like the below:

Issue: Something related to geolocation
Percentage Affected: X%
Number Affected: Y (only if you are comfortable with this)
Brief Description: This is a problem because xyz and also, bad things.

The data you submit does not necessarily have to reflect the current Top 10, it 
has to reflect what you are observing in the applications you analyze. At the 
same time, we would certainly love feedback on what you believe is correct or 
incorrect about the current list.

- What happens next? -

After a 60 day period we will review all submissions and re-draft the Mobile 
Top Ten based on the prevalence and impact of data provided by participants. 
After the submission period ends, there will be follow-on discussions and work 
to analyze the data. Participation in this initiative may require up to 10 
hours of efforts per week, so please take this into consideration before 
signing up.

- Spread the word. Make a difference! - 

Also, any help spreading the word on the Mobile Security Project is immensely 
helpful.  A Tweet/Facebook/Linkedin post, blog entry, etc. This initiative will 
fail if people don't know about it.  Anyone that you can promote this 
initiative to will help the cause.

We thank all of you in advance for your participation and hard work in making 
this initiative a success. Your participation will be noted and recorded when 
compiling the list of contributors for the final release of the Mobile Top 10 
Risks documentation.

- Get in touch and get involved. -

Please direct any questions or concerns to the Top 10 Refresh leaders, Jason 
Haddix (jason.had...@owasp.org), Jack Mannino (jack.mann...@owasp.org), and 
Mike Zusman (mike.zus...@owasp.org). 

We will be using a Google Group to collaborate on the Top 10 refresh: 
https://groups.google.com/a/owasp.org/forum/?hl=enfromgroups#!forum/owasp-mobile-top-10-risks

The OWASP Mobile Security project’s mailing list is also another way to get in 
touch with other contributors (owasp-mobile-security-proj...@lists.owasp.org).

Thank you!

Regards,
Jim Manico
OWASP Board Member and Volunteer
@Manicode

___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___


[SC-L] OWASP Podcast 93

2012-10-02 Thread Jim Manico

SC-L,

I'm very pleased to announce that OWASP Podcast 93, and interview with 
Frank Piessens from SecAppDev.org, is now live! 
http://secappdev.org/pages/31


In this show, Frank discusses why secure development is so difficult and 
presents various potential solutions to the problem being researched by 
the academic community.


Direct download: https://www.owasp.org/download/jmanico/owasp_podcast_93.mp3
iTunes subscription: 
http://itunes.apple.com/podcast/owasp-security-podcast/id300769012?mt=2

RSS Feed: https://www.owasp.org/download/jmanico/podcast.xml

Special thanks to Thomas Herlea for curating this and future 
SecAppDev.org presentations.


Thanks for listening.

- Jim Manico
OWASP Volunteer
j...@owasp.org
@manicode
___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___


[SC-L] OWASP Podcasts 2011

2011-03-19 Thread Jim Manico
Hello folks,

I just want to give you a quick update on the OWASP Podcast Series.

We pushed out 3 shows so far this year:

1) OWASP Podcast 83 from Dave Ferguson talks about how to properly
implement the Forgot Password feature in web apps. I'm a fan of this
podcast and would like the series to move more and more in this
prescriptive direction. Dave's podcast was also the basis for the
OWASP Forgot Password cheat-sheet.

http://www.owasp.org/download/jmanico/owasp_podcast_83.mp3
http://www.owasp.org/index.php/Forgot_Password_Cheat_Sheet

2) OWASP Podcast 82 from Dave Wichers. Dave is one of OWASP's board
members and donates a pretty insane amount of time assisting the OWASP
cause in a variety of ways (OWASP CFO, ASVS, Top Ten leader, etc, etc, etc).

http://www.owasp.org/download/jmanico/owasp_podcast_82.mp3
http://www.owasp.org/index.php/User:Wichers

3) OWASP Podcast 81 is an older show from Brian Chess prior to HP's
purchase of Fortify. Brian talked about how software security issues are
no longer just about business risk - its now life and death.

http://www.owasp.org/download/jmanico/owasp_podcast_81.mp3

I hope you enjoy. Feedback is always appreciated.

Regards,
Jim Manico
j...@owasp.org

___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___


Re: [SC-L] Java DOS

2011-02-13 Thread Jim Manico
Rafal,

It's not that tough to blacklist this vuln while you are waiting for your team 
to patch your JVM (IBM and other JVM's have not even patched yet). I've seen 
three generations of this filter already. Walk with me, Rafal and I'll show 
you. :)

1) Generation 1 WAF rule (reject one number only)

This mod security rule only blocks a small portion of the DOSable range. The 
mod security team is working to improve this now (no disrespect meant at all!)

SecRule ARGS|REQUEST_HEADERS @contains 2.2250738585072012e-308 
phase:2,block,msg:'Java Floating Point DoS Attack',tag:'CVE-2010-4476' 

Reference: http://mobile.twitter.com/modsecurity/status/35734652652093441

2) Generation 2 blacklist rejection J2EE filter (reject entire vulnerable range)

Team Adobe came up with this. It's actually quite accurate in *rejecting input* 
in the DOSable JVM numeric range:

public static boolean containsMagicDoSNumber(String s) {
   return s.replace(., ).contains(2225073858507201);
}

Reference: http://blogs.adobe.com/asset/2011/02/year-of-the-snail.html

3) Generation 3 IEEE data rounding J2EE validation POC (FTW from Brian Chess)

This is code from Brian Chess at HP/Fortify.  This a fairly impressive approach 
to this problem. I'm in the process of integrating this fix into ESAPI. This 
approach detects the evil range before trying to call parseDouble and returns 
the IEEE official value for any double in this range ( 2.2250738585072014E-308 
).

private static BigDecimal bigBad;
private static BigDecimal smallBad;

static {
BigDecimal one = new BigDecimal(1);
BigDecimal two = new BigDecimal(2);
BigDecimal tiny = one.divide(two.pow(1022));
// 2^(-1022) ­ 2^(-1076)
bigBad = tiny.subtract(one.divide(two.pow(1076)));   
//2^(-1022) ­ 2^(-1075)
smallBad = tiny.subtract(one.divide(two.pow(1075))); 
}

if (arg == null) return false;  // arg is null?  return.
String noDot = arg.replace(., );
if (!noDot.contains(2225073858507201)) return false;
// magic value not present?  return.
BigDecimal bd;
try {
bd = new BigDecimal(arg);
} catch (NumberFormatException e) {
return false;  // can't parse?  return.
}
if (bd.compareTo(smallBad)  0 || bd.compareTo(bigBad) 
0) return false;  // smaller than the smallest bad value or larger than
the largest bad value?  Return

 // if you get here you know you're looking at a bad value.  The final
value for any double in this range is supposed to be
2.2250738585072014E-308

Reference: via email direct from Brian Chess

_*Dr.*_ Chess, I'm very impressed. 

Aloha Raf,
Jim

 Hey Jim-
   Just a quick comment on black-listing... I think Brian already mentioned it 
 in his blog post but there are MANY variations of the magic number (range) so 
 black-listing may be even tougher than updating the JVM, in my humble 
 opinion. 
 
 Rafał Łoś
 InfoSec Specialist  Blogger
 
 
 
 On 2011-02-13 16:24:59 GMT James Manico j...@manico.net wrote:
 

 Hey Brian,

 I think it's critical that we discuss these issues with prescriptive
 remediation advice.

 1) Update your JVM, often easier said then done
 2) Build a blacklist filter looking for this specific numerical attack
 range. I already patched this in the ESAPI for Java security library
 which you will see in ESAPI 2.0 rc12 within a week or 2, but the
 credit goes to Adobe for being on top of this (and to Williams for
 pointing this out to me).

 http://blogs.adobe.com/asset/2011/02/year-of-the-snail.html

 I'm impressed team Adobe!

 -Jim Manico
 http://manico.net

 On Feb 12, 2011, at 10:13 PM, Brian Chess br...@fortify.com wrote:

 There's a very interesting vulnerability in Java kicking around.  I wrote 
 about it here:
   http://blog.fortify.com/blog/2011/02/08/Double-Trouble

 In brief, you can send Java (and some versions of PHP) into an infinite 
 loop if you can provide some malicious input that will be parsed as a 
 double-precision floating point number.

 This code used to look like the beginnings of some decent input validation:
Double.parseDouble(request.getParameter(d));
 Now it's the gateway to an easy DOS attack.  (At least until you get a 
 patch from your Java vendor, many of whom haven't released patches yet. 
 Oracle has released a patch.  Do you have it?)

 Until a few days ago, all major releases of Tomcat made matters worse by 
 treating part of the Accept-Language header as a double.  In other words, 
 you don't need to have any double-precision values in *your* code for your 
 app to be vulnerable.

 The SC-L corner of the world puts a lot of emphasis on training and on 
 looking for known categories of vulnerabilities.  That's all goodness.  But 
 this example highlights the fact that we have to build systems and 
 procedures that can quickly adapt to address new risks.

 Brian
 ___
 Secure Coding mailing list (SC-L) SC-L@securecoding.org
 List information, subscriptions, etc - 
 http

Re: [SC-L] InformIT: comparing static analysis tools

2011-02-04 Thread Jim Manico
Hello Chris,

Thanks for replying!

I think the reaction from my boss was not so much knee-jerk, but a
reasonable concern. The risk of persisting intellectual property on a
cloud service is real. And that risk differs depending on your business
(as well as many other factors). I'm eager to see vendors like Veracode
publish more assurance evidence, especially around how they write
software (I'm a lot less worried about the infrastructure in play, that
is pretty much a solved issue. Building secure software is not).

I published an OWASP Podcast with ChrisW recently
http://www.owasp.org/download/jmanico/owasp_podcast_80.mp3 and frankly,
I was impressed. The only issue that I thought was NOT answered in depth
was regarding software centric assurance evidence - especially since
that is your core business.

 (automated scanning plus manual penetration tests, multi-factor
authentication, extremely granular roles and access controls,
per-application backend encryption of results, flexible retention
policies, etc.).

Now this is a great start. I'd like to hear more. How do you do data
contextual access control? How you do key management for backend
encryption?  Are you encrypting db backups? How do you do input
validation and contextual encoding? How do you ensure that all queries
are parametrized/bound? Etc..etc... Perhaps we can get one of you on the
show to discuss how YOU write secure software, and how you prove that to
your clients? Assessment is interesting, but lessons in building
security in is much more important to our industry right now, IMO.

 First, the customer needs to understand that they are NOT, in fact,
uploading their code.They are uploading binaries -- compiled code, or
bytecode -- not their source.

Please note, it's trivial to convert bytecode to source code in both the
.NET and Java ecosystems. This distinction feels more sales centric, but
is not technically correct, IMO.

Regards,
Jim



 I'm not the Chris you posed the question to but I'll answer anyway.  :)
 
 Usually the type of response you described is a knee-jerk reaction.  It's a 
 different model than people are used to, and sometimes people are averse to 
 change, whether that's warranted or not.  It's important to get past the 
 initial reaction and actually have a substantive conversation.
 
 Naturally, we try to understand each customer's specific hang-ups, but 
 generally speaking there are a couple of things we always cover.  


 
 Viewing this with a wider lens, there are a lot of factors involved in 
 selecting a tool/service vendor.  One factor that comes into play for us is 
 simply that our solution scales, and many others do not.  We can address the 
 application supply chain problem in ways that others can't.  
 
 -chris
 
 
 Chris Eng
 Senior Director, Research
 Veracode, Inc.
 Office: 781.418.3828
 Mobile: 617.501.3280
 c...@veracode.com 

___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___


Re: [SC-L] InformIT: comparing static analysis tools

2011-02-03 Thread Jim Manico
Hey Gary,

Nice article. A brief note, Ounce is dead. The product was renamed
IBM Rational AppScan Source Edition after IBM's acquisition of Ounce.

Small matter but for what it's worth,
Jim

 hi sc-l,
 
 John Steven and I recently collaborated on an article for informIT.  The 
 article is called Software [In]security: Comparing Apples, Oranges, and 
 Aardvarks (or, All Static Analysis Tools Are Not Created Equal) and is 
 available here:
 http://www.informit.com/articles/article.aspx?p=1680863
 
 Now that static analysis tools like Fortify and Ounce are hitting the 
 mainstream there are many potential customers who want to compare them and 
 pick the best one.  We explain why that's more difficult than it sounds at 
 first and what to watch out for as you begin to compare tools.  We did this 
 in order to get out in front of test suites that purport to work for tool 
 comparison.  If you wonder why such suites may not work as advertised, read 
 the article.
 
 Your feedback is welcome.
 
 gem
 
 company www.cigital.com
 podcast www.cigital.com/silverbullet
 blog www.cigital.com/justiceleague
 book www.swsec.com
 
 ___
 Secure Coding mailing list (SC-L) SC-L@securecoding.org
 List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
 List charter available at - http://www.securecoding.org/list/charter.php
 SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
 as a free, non-commercial service to the software security community.
 Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
 ___

___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___


Re: [SC-L] InformIT: comparing static analysis tools

2011-02-03 Thread Jim Manico
Chris,

I've tried to leverage Veracode in recent engagements. Here is how the 
conversation went:

Jim:
Boss, can I upload all of your code to this cool SaaS service for analysis?

Client:
Uh no, and next time you ask, I'm having you committed.

I'm sure you have faced these objections before. How do you work around them?

-Jim Manico
http://manico.net

On Feb 3, 2011, at 1:54 PM, Chris Wysopal cwyso...@veracode.com wrote:

 
 Nice article.  In the 5 years Veracode has been selling static analysis 
 services we have seen the market mature.  In the beginning, organizations 
 were down in the weeds. What false positive rate or false negative rate does 
 the tool/service have over a test suite such as SAMATE.  Then we saw a move 
 up to looking at the trees.  Did the tool/service support the Java 
 frameworks I am using?  Now we are seeing organizations look at the forest. 
 Can I scale static analysis effectively over all my development sites, my 
 outsourcers, and vendors?  This is a good sign of a maturing market.
 
 It is my firm belief that software security has a consumption problem.  We 
 know what the defects are.  We know how to fix them.  We even have automation 
 for detecting a lot of them.  The problem is getting the information and 
 technology to the right person at the right time effectively and managing an 
 organization-wide program.  This is the next challenge for static analysis. 
 bias-alertI think SaaS based software is more easily consumed and this 
 isn't any different for software security/bias-alert
 
 -Chris
 
 -Original Message-
 From: sc-l-boun...@securecoding.org [mailto:sc-l-boun...@securecoding.org] On 
 Behalf Of Gary McGraw
 Sent: Wednesday, February 02, 2011 9:49 AM
 To: Secure Code Mailing List
 Subject: [SC-L] InformIT: comparing static analysis tools
 
 hi sc-l,
 
 John Steven and I recently collaborated on an article for informIT.  The 
 article is called Software [In]security: Comparing Apples, Oranges, and 
 Aardvarks (or, All Static Analysis Tools Are Not Created Equal) and is 
 available here:
 http://www.informit.com/articles/article.aspx?p=1680863
 
 Now that static analysis tools like Fortify and Ounce are hitting the 
 mainstream there are many potential customers who want to compare them and 
 pick the best one.  We explain why that's more difficult than it sounds at 
 first and what to watch out for as you begin to compare tools.  We did this 
 in order to get out in front of test suites that purport to work for tool 
 comparison.  If you wonder why such suites may not work as advertised, read 
 the article.
 
 Your feedback is welcome.
 
 gem
 
 company www.cigital.com
 podcast www.cigital.com/silverbullet
 blog www.cigital.com/justiceleague
 book www.swsec.com
 
 ___
 Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, 
 subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
 List charter available at - http://www.securecoding.org/list/charter.php
 SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as 
 a free, non-commercial service to the software security community.
 Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
 ___
 
 ___
 Secure Coding mailing list (SC-L) SC-L@securecoding.org
 List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
 List charter available at - http://www.securecoding.org/list/charter.php
 SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
 as a free, non-commercial service to the software security community.
 Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
 ___

___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___


[SC-L] OWASP CSRFGuard

2010-10-29 Thread Jim Manico
Hello,

 

The OWASP CSRF guard project (
http://www.owasp.org/index.php/Category:OWASP_CSRFGuard_Project ) has
recently been deemed inactive and I'm trying to help bring it back to
life.

 

I'm taking a survey of folks who have used CSRFGuard. In particular, I would
like to understand any potential modifications CSRFGuard users have had  to
make in order to implement it successfully for their website. I'd also like
to hear of any success stories of using CSRFGuard out of the box.

 

Any feedback regarding this matter is greatly appreciated. 

 

Thanks kindly + Aloha,

 

Jim Manico

OWASP Podcast Producer

OWASP ESAPI Project Manager

http://manico.net  

___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___


Re: [SC-L] [Esapi-dev] OWASP CSRFGuard

2010-10-29 Thread Jim Manico
 My gut feel here is that we gain a lot more by merging the work done here
into ESAPI. 

 

I agree 100%, I'm glad you said it first. J

 

- Jim

 

From: Chris Schmidt [mailto:chrisisb...@gmail.com] 
Sent: Friday, October 29, 2010 8:36 PM
To: Jim Manico; esapi-...@lists.owasp.org; SC-L@securecoding.org
Cc: owasp-lead...@lists.owasp.org
Subject: Re: [Esapi-dev] OWASP CSRFGuard

 

My gut feel here is that we gain a lot more by merging the work done here
into ESAPI. CSRFGuard is and has been a great project, but as it stands -
unmaintained right now (although it is a very simple project, with a very
low level of maintenance) it seems to me that a lot of traction and momentum
could be gained for the code by merging with the ESAPI project which is one
of the more active OWASP Projects AFAIK.

This is really just my $0.02 and I don't want to discount the work that has
been done on CSRF-Guard. As I stated it is a great project and I personally
have used it in 3 projects succesfully, but I also think that as such a
small project it seems to be an easy one to forget about in the grand scheme
of things.


On 10/29/10 9:09 AM, Jim Manico jim.man...@owasp.org wrote:

Hello,
 
The OWASP CSRF guard project (
http://www.owasp.org/index.php/Category:OWASP_CSRFGuard_Project ) has
recently been deemed inactive and I'm trying to help bring it back to
life.
 
I'm taking a survey of folks who have used CSRFGuard. In particular, I would
like to understand any potential modifications CSRFGuard users have had  to
make in order to implement it successfully for their website. I'd also like
to hear of any success stories of using CSRFGuard out of the box.
 
Any feedback regarding this matter is greatly appreciated. 
 
Thanks kindly + Aloha,
 
Jim Manico
OWASP Podcast Producer
OWASP ESAPI Project Manager
http://manico.net  

  _  

___
Esapi-dev mailing list
esapi-...@lists.owasp.org
https://lists.owasp.org/mailman/listinfo/esapi-dev

___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___


Re: [SC-L] Java: the next platform-independent target

2010-10-21 Thread Jim Manico
 PHP interpreter itself, and the occasional issues in Perl, and don't forget 
 some of the tidbits in ASP.Net, maybe all those should be tossed out as well, 
 and we should all move back to C. ;-)

I think the deprecation of these technologies for an enterprise is a wise idea. 
:) How can a large enterprise use PHP or ASP for security-critical applications 
with a straight face? Let's move forward to Ruby on Rails, Enterprise Java, 
.NET and other modern frameworks that are more mature from a security centric 
POV. 

I have no problem with server-side Java, especially when using a modern 
security framework like Spring Security or (wait for it) ESAPI. But client-side 
Java? Flash? There are a few large organizations who have banned both from 
their clients and they are more secure for it.

-Jim Manico
http://manico.net

On Oct 21, 2010, at 10:58 PM, Steven M. Christey co...@linus.mitre.org 
wrote:

 PHP interpreter itself, and the occasional issues in Perl, and don't forget 
 some of the tidbits in ASP.Net, maybe all those should be tossed out as well, 
 and we should all move back to C. ;-)
___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___


Re: [SC-L] Classification/Enumeration of Software Defect Mitigations

2010-10-21 Thread Jim Manico
You may wish to consider OWASP ASVS mitigation recommendations. You can 
word-smith negative recommendations of what •not• to do to come up with a great 
list of defensive recommendations.

For example, instead of saying Never put sensitive data in HTTP GET requests 
I'd like to see us shift to control-centric language like Only use HTTPS POST 
to transmit sensitive data.

And in general Steve, a list of mitigations implies tactical approaches to 
Application Security (ie: fix specific flaws) which is fairly limited. I'd love 
to see this expanded to cover general defensive coding techniques and good 
security design principles that help dev's build secure apps from day 1.

And Steve, you only see me pop up when I have a criticism. But as I said when 
we went hiking on Kauai, I think you and team are doing outstanding work and 
I'm thankful for all of your efforts.

Regards,

-Jim Manico
http://manico.net

On Oct 22, 2010, at 12:39 AM, Steven M. Christey co...@linus.mitre.org 
wrote:

 
 All,
 
 Both WASC and the MITRE CWE team have begun exploring the feasibility of 
 enumerating or classifying the types of mitigations that are used to fix 
 software defects/weaknesses.  Does anybody know of such work in this area? 
 (We can draw from sources such as McGraw/Viega Building Secure Software, 
 and 'indirect' sources such as ESAPI, but I was wondering if there was 
 something that was a little more focused on mitigations.)
 
 CWE status:
 
 http://www.webappsec.org/lists/websecurity/archive/2010-10/msg00065.html
 
 WASC status:
 
 http://www.webappsec.org/lists/websecurity/archive/2010-10/msg00066.html
 
 
 
 Thanks,
 Steve
 ___
 Secure Coding mailing list (SC-L) SC-L@securecoding.org
 List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
 List charter available at - http://www.securecoding.org/list/charter.php
 SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
 as a free, non-commercial service to the software security community.
 Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
 ___

___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___


Re: [SC-L] [WEB SECURITY] SATE?

2010-06-09 Thread Jim Manico

Great SATE reply from Vadim Okun:


We have been releasing the real deep data. There have been delays, but there 
are no sinister reasons for the delays.

The results of the 2nd SATE (our report and all data) will be released in June 
(We promised to release between February and May, but we're late with the 
report).

We released the results of the 1st SATE last summer: our report, the raw tool 
reports, and our analysis of the reports. The data is available (below the list 
of cautions) from
http://samate.nist.gov/SATE2008.html

or a direct link:
http://samate.nist.gov/SATE2008/resources/sate2008.tar.gz

I will answer some specific points in Jim's email below, but first, let me 
describe some limitations of SATE and how we are addressing them. SATE 2008 had 
a number of big limitations, including:

1) We analyzed a non-random subset of tool warnings
2) Determining correctness of tool warnings turned out to be more complicated 
than a binary true/false decision. Also, determining relevance of a warning to 
security turned out more difficult than we thought.
3) In most cases, we did not match warnings from different tools that refer to 
the same weakness. When we started SATE, we thought that we could match 
warnings by line number and weakness name or CWE id. In fact, most weaknesses 
are more complex - see Section 3.4 of our report.
4) Analysis criteria were applied inconsistently.

In our publicly released analysis, we used the confirmed/unconfirmed markings 
instead of true/false markings. We describe the reasons for this in our report 
- Section 4.2, page 29 of
http://samate.nist.gov/docs/NIST_Special_Publication_500-279.pdf

In SATE 2009, we made some improvements, including:

1) Randomly select a subset of tool warnings for analysis
2) We also looked at tool warnings that were related to human findings by 
security experts.
3) Use 4 categories for analysis of correctness: true, true but insignificant 
(for security), false, unknown.  It is an improvement, but there are still 
problems: for example distinguishing true from true but insignificant is often 
hard.

   

1) false positive rates from these tools are overwhelming
 

First, defining a false positive is tough.  Also in SATE 2008, the criteria 
that we used for analysis of correctness were inconsistent, we did not analyze 
a random sample of warnings, our analysis had errors. Steve gave a good example 
in his reply. We corrected some of these problems in 2009, but still way to go.

   

2) the work load to triage results from ONE of these tools were
man-years
 

We are not the developers of the test cases, our knowledge of the test case 
code is very limited. Also, we used tools differently from their use in 
practice. We analyzed tool warnings for correctness and looked for related 
warnings from other tools, whereas developers use tools to determine what 
changes need to be made to software, auditors look for evidence of assurance.

   

3) by every possible measurement, manual review was more cost effective
 

As Steve said, SATE did not consider cost. In SATE 2009, we had security 
contractors analyze two of the test cases and report the most important 
security weaknesses. We then looked at tool warnings that report the same (or 
related) weakness. This will be released as part of 2009 release (The data set 
is too small for statistical conclusions.)

A big limitation of SATE has been the lack of ground truths about what security 
weaknesses really are in the test cases. This determination is hard for reasonably large 
software. We are trying to address this: manual analysis by security contractors, 
CVE-selected test cases.

   

the NIST team chose only a small percentage of the automated findings to review
 

A small percentage by itself should not be a problem if the selection of tool 
warnings is done correctly (it was not done correctly in SATE 2008).

Vadim


From: Jim Manico [...@manico.net]
Sent: Thursday, May 27, 2010 5:31 PM
To: 'Webappsec Group'
Subject: [WEB SECURITY] SATE?

I feel that NIST made a few errors in the first 2 SATE studies.

After the second round of SATE, the results were never fully released to
the public - even when NIST agreed to do just that at the inception of
the contest. I do not understand why SATE censored the final results - I
feel such censorship hurts the industry.

And even worse, I felt that vendor pressure encouraged NIST to not
release the final results. If the results (the real deep data, not the
executive summary that NIST release) were favorable to the tool vendors,
I bet they would have welcomed the release of the real data. But
instead, vendor pressure caused NIST to block the release of the final
data set.

The problems that the data would have revealed is:

1) false positive rates from these tools are overwhelming
2) the work load to triage results from ONE of these tools were man-years
3) by every possible measurement, manual

Re: [SC-L] SATE

2010-05-28 Thread Jim Manico
 of this study. For 
example, all of the Java app's in this study contained poor hash 
implementations. But because the tools (none of them) could see this, 
that finding was completely ignored. The coverage was limited ONLY 
to injection and data flow problems that tools have a chance of 
finding. In fact, the NIST team chose only a small percentage of the 
automated findings to review, since it would have taken years to 
review everything due to the massive number of false positives. Get 
the problem here?


I'm discouraged by SATE. I hope some of these problems are addressed 
in the third study.


- Jim
___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - 
http://krvw.com/mailman/listinfo/sc-l

List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC 
(http://www.KRvW.com)

as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___



--
Jim Manico
OWASP Podcast Host/Producer
OWASP ESAPI Project Manager
http://www.manico.net

___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___


[SC-L] Top Ten OWASP Podcast Series

2010-04-19 Thread Jim Manico

Hello SC-L,

We just released _*5 OWASP Podcasts*_ today in celebration of the 
release of the 2010 edition of the OWASP Top Ten! Big kudos to Dave 
Wichers and team for all of their hard working in making this release a 
success.


The Top Ten podcasts include:

Show 67: Jeff Williams on XSS Defense 
http://www.owasp.org/download/jmanico/owasp_podcast_67.mp3
Show 68: Kevin Keenan on Cryptographic Storage 
http://www.owasp.org/download/jmanico/owasp_podcast_68.mp3
Show 69: Eric Sheridan on CSRF Defense 
http://www.owasp.org/download/jmanico/owasp_podcast_69.mp3
Show 70: Michael Coates on TLS Configuration 
http://www.owasp.org/download/jmanico/owasp_podcast_70.mp3
Show 71: Robert Hansen on Insecure Redirects 
http://www.owasp.org/download/jmanico/owasp_podcast_71.mp3


PS: You can subscribe to our RSS feed here: 
http://www.owasp.org/download/jmanico/podcast.xml
..or do the same via iTunes 
http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewPodcast?id=300769012
..or see our show list on the web 
http://www.owasp.org/index.php/OWASP_Podcast#tab=Latest_Shows


PPS: The OWASP Podcast Series is non-commercial podcast released under 
the Creative Commons/ShareAlike license.


PPPS: Did someone say slow down ? I missed that as I was running by... ;)

Thanks for listening!

--
Jim Manico
OWASP Podcast Host/Producer
OWASP ESAPI Project Manager
http://www.manico.net

___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___


[SC-L] OWASP Podcast Series update

2010-04-14 Thread Jim Manico

Hello SC-L,

We have a few new shows on the OWASP Podcast Series that may interest 
you. They include:


Show 64: An interview with Andy Ellis (Director of Security @ Akamai) 
http://www.owasp.org/download/jmanico/owasp_podcast_64.mp3
Show 65: AppSec Roundtable with Boaz Gelbord, Dan Cornell, Jeff Williams 
and Johannes Ullrich (File Upload Security): 
http://www.owasp.org/download/jmanico/owasp_podcast_65.mp3
Show 66: An interview with Brad Arkin (Director of Product Security and 
Privacy at Adobe) http://www.owasp.org/download/jmanico/owasp_podcast_66.mp3


PS:

You can subscribe to our RSS feed here: 
http://www.owasp.org/download/jmanico/podcast.xml
..or do the same via iTunes 
http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewPodcast?id=300769012
..or see our show list on the web 
http://www.owasp.org/index.php/OWASP_Podcast#tab=Latest_Shows


PPS:

The OWASP Podcast Series is non-commercial podcast released under the 
Creative Commons/ShareAlike license.


Thanks for listening!

--
Jim Manico
OWASP Podcast Host/Producer
OWASP ESAPI Project Manager
http://www.manico.net

___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___


[SC-L] OWASP ESAPI 2.0 rc6 released!

2010-03-30 Thread Jim Manico

ESAPI 2.0 rc6 is now live!

You can download the complete zip file here:

http://owasp-esapi-java.googlecode.com/files/ESAPI-2.0-rc6.zip 
http://owasp-esapi-java.googlecode.com/files/ESAPI-1.4.3.zip


Online project documentation can be found here:

http://owasp-esapi-java.googlecode.com/svn/trunk_doc/2.0-rc6/site/project-reports.html 
http://owasp-esapi-java.googlecode.com/svn/trunk_doc/2.0-rc6/site/project-reports.html


Major enhancements include:

1) Major rewrite of the Encryptor implementation
2) Initial examples section included: \ESAPI-2.0-rc6\project\src\examples

Please see changelog.txt at the root of the zip file for more information.

Mahalo Nui Loa,
--
Jim Manico
OWASP Podcast Host/Producer
OWASP ESAPI Project Manager
http://www.manico.net
___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
___


[SC-L] OWASP Podcast Series

2010-02-05 Thread Jim Manico

Hello SC-L,

We have released 3 OWASP podcasts over the last few days for your 
listening pleasure:


#60 Interview with Jeremiah Grossman and Robert Hansen (Google pays for 
vulns)

http://www.owasp.org/download/jmanico/owasp_podcast_60.mp3

#59 AppSec round table with Dan Cornell, Boaz Gelbord, Jim Manico, 
Andrew van der Stock, Ben Tomhave and Jeff Williams

http://www.owasp.org/download/jmanico/owasp_podcast_59.mp3

#58 Interview with Ron Gula
http://www.owasp.org/download/jmanico/owasp_podcast_58.mp3

I hope you enjoy.

--
Jim Manico
OWASP Podcast Host/Producer
OWASP ESAPI Project Manager
http://www.manico.net

___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___


Re: [SC-L] BSIMM update (informIT)

2010-02-04 Thread Jim Manico
Why are we holding up the statistics from Google, Adobe and Microsoft ( 
http://www.bsi-mm.com/participate/ ) in BDSIMM?


These companies are examples of recent epic security failure. Probably 
the most financially damaging infosec attack, ever. Microsoft let a 
plain-vanilla 0-day slip through ie6 for years, Google has a pretty 
basic network segmentation and policy problem, and Adobe continues to be 
the laughing stock of client side security. Why are we holding up these 
companies as BDSIMM champions?


- Jim



On Wed, 3 Feb 2010, Gary McGraw wrote:

Popularity contests are not the kind of data we should count on.  But 
maybe we'll make some progress on that one day.


That's my hope, too, but I'm comfortable with making baby steps along 
the way.


Ultimately, I would love to see the kind of linkage between the 
collected

data (evidence) and some larger goal (higher security whatever THAT
means in quantitative terms) but if it's out there, I don't see it


Neither do I, and that is a serious issue with models like the BSIMM 
that measure second order effects like activities.  Do the 
activities actually do any good?  Important question!


And one we can't answer without more data that comes from the 
developers who adopt any particular practice, and without some 
independent measure of what success means.  For example: I am a big 
fan of the attack surface metric originally proposed by Michael Howard 
and taken up by Jeanette Wing et al. at CMU (still need to find the 
time to read Manadhata's thesis, alas...)  It seems like common sense 
that if you reduce attack surface, you reduce the number of security 
problems, but how do you KNOW!?


The 2010 OWASP Top 10 RC1 is more data-driven than previous 
versions; same

with the 2010 Top 25 (whose release has been delayed to Feb 16, btw).
Unlike last year's Top 25 effort, this time I received several 
sources of

raw prevalence data, but unfortunately it wasn't in sufficiently
consumable form to combine.


I was with you up until that last part.  Combining the prevalence 
data is something you guys should definitely do.  BTW, how is the 
2010 CWE-25 (which doesn't yet exist) more data driven??


I guess you could call it a more refined version of the popularity 
contest that you already referred to (with the associated 
limitations, and thus subject to some of the same criticisms as those 
pointed at BSIMM): we effectively conducted a survey of a diverse set 
of organizations/individuals from various parts of the software 
security industry, asking what was most important to them, and what 
they saw the most often.  This year, I intentionally designed the Top 
25 under the assumption that we would not have hard-core quantitative 
data, recognizing that people WANTED hard-core data, and that the few 
people who actually had this data, would not want to share it.  (After 
all, as a software vendor you may know what your own problems are, but 
you might not want to share that with anyone else.)


It was a bit of a surprise when a handful of participants actually had 
real data - but, then the problem I'm referring to with respect to 
consumable form reared its ugly head.  One third-party consultant 
had statistics for a broad set of about 10 high-level categories 
representing hundreds of evaluations; one software vendor gave us a 
specific weakness history - representing dozens of different CWE 
entries across a broad spectrum of issues, sometimes at very low 
levels of detail and even branching into the GUI part of CWE which 
almost nobody pays attention to - but only for 3 products.  Another 
vendor rep evaluated the dozen or two publicly-disclosed 
vulnerabilities that were most severe according to associated CVSS 
scores.  Those three data sets, plus the handful of others based on 
some form of analysis of hard-core data, are not merge-able. The irony 
with CWE (and many of the making-security-measurable efforts) is that 
it brings sufficient clarity to recognize when there is no clarity... 
the known unknowns to quote Donald Rumsfeld.  I saw this in 1999 in 
the early days of CVE, too, and it's still going on - observers of the 
oss-security list see this weekly.


For data collection at such a specialized level, the situation is not 
unlike the breach-data problem faced by the Open Security Foundation 
in their Data Loss DB work - sometimes you have details, sometimes you 
don't. The Data Loss people might be able to say well, based on this 
100-page report we examined, we think it MIGHT have been SQL 
injection but that's the kind of data we're dealing with right now.


Now, a separate exercise in which we compare/contrast the customized 
top-n lists of those who have actually progressed to the point of 
making them... that smells like opportunity to me.



I for one am pretty satisfied with the rate at which things are
progressing and am delighted to see that we're finally getting some raw
data, as good (or as bad) as it may be.  The data 

[SC-L] ESAPI 1.4.4 released!

2010-01-31 Thread Jim Manico
I'm very pleased to announce the release of the OWASP Enterprise 
Security API Library (ESAPI) version 1.4.4 for Java version 1.4 and 
above! This is an open source project under the BSD license.


Changelog:  
http://owasp-esapi-java.googlecode.com/svn/branches/1.4/changelog.txt


Other important links:

   * You may download the complete .zip release at
 http://owasp-esapi-java.googlecode.com/files/ESAPI-1.4.4.zip
   * The ESAPI 1.4.4 Javadoc's can be found here:
 http://owasp-esapi-java.googlecode.com/svn/trunk_doc/1.4.4/index.html
   * ESAPI users may ask questions regarding ESAPI usage and
 configuration here:
 https://lists.owasp.org/mailman/listinfo/esapi-user
   * Developers interested in contributing to ESAPI may sign up for the
 ESAPI developers email list here:
 https://lists.owasp.org/mailman/listinfo/esapi-dev

Our sincere /Mahalo Nui Loa http://en.wikipedia.org/wiki/Mahalo /to 
all of the many developers and users who have contributed to the ESAPI 
project in some way.


Warm Regards,

--
Jim Manico
OWASP Podcast Host/Producer
OWASP ESAPI Project Manager
http://www.manico.net

___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___


[SC-L] ESAPI for JavaScript!

2010-01-18 Thread Jim Manico
The newest version of ESAPI4JS is out! There are some significant new
features, namely i18n support and validation.

You can download the 0.1.2 distribution here:
http://code.google.com/p/owasp-esapi-js/downloads/detail?name=esapi4js-0.1.2.zip

As always, comments and questions are welcome and encouraged directly to
the projects author at chrisisb...@gmail.com !

Other ESAPI resources:

OWASP ESAPI Developer
http://www.owasp.org/index.php/Category:OWASP_Enterprise_Security_API

Check out OWASP ESAPI for Java
http://code.google.com/p/owasp-esapi-java/

Thanks all.

-- 
Jim Manico
OWASP Podcast Host/Producer
OWASP ESAPI Project Manager
http://www.manico.net

___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___


Re: [SC-L] Ramesh Nagappan Blog : Java EE 6: Web Application Security made simple ! | Core Security Patterns Weblog

2010-01-08 Thread Jim Manico
 (For which apps will developers  
have

 their expectations met adopting ESAPI? Which won't?)
   * A document describing experiment results: before and after ESAPI:
 how many results does a pen-test find?, 'Code review?
   * Write an adoption guide. Apps are only created in a green-field
 once. Then they live in maintenance forever. How do you apply
 ESAPI to a real-world app already in production without risk/ 
regression?


* Generate an argument as to why ESAPI beats these alternatives. Is  
it cost? Speed-to-market? What?
* Finally, realize that it's OK that there's more than one way to do  
things. Revel in it. It's what makes software an exciting field.


In the meantime, rest assured that those of us out there that have  
looked get that ESAPI can be a good thing.



John Steven
Senior Director; Advanced Technology Consulting
Desk: 703.404.9293 x1204 Cell: 703.727.4034
Key fingerprint = 4772 F7F3 1019 4668 62AD  94B0 AE7F EEF4 62D5 F908

Blog: http://www.cigital.com/justiceleague
Papers: http://www.cigital.com/papers/jsteven
http://www.cigital.com
Software Confidence. Achieved.

On Jan 7, 2010, at 10:56 AM, Jim Manico wrote:


John,

You do not need OWASP ESAPI to secure an app. But you need A ESAPI
for your organization in order to build secure Apps, in my opinion.
OWASP ESAPI may help you get started down that path.

An ESAPI is no silver bullet, there is no such thing as that in
AppSec. But it will help build secure apps.

Jim Manico

On Jan 6, 2010, at 6:20 PM, John Steven jste...@cigital.com wrote:


All,

With due respect to those who work on ESAPI, Jim included, ESAPI is
not the only way to make a secure app even remotely possible. And
I believe that underneath their own pride in what they've done--some
of which is very warranted--they understand that. It's hard not to
become impassioned in posting.

I've seen plenty of good secure implementations within
organizations' own security toolkits. I'm not the only one that's
noticed: the BSIMM SSF calls out three relevant activities to this
end:

SDF 1.1 Build/publish security features (*1)
SDF 2.1 Find/publish mature design patterns from the organization
(similar URL)
SDF 2.3  Build secure-by-design middleware frameworks/common
libraries (similar URL)

Calling out three activities within the SSF means that it can't just
be John Steven's top client (whatever that means) that's doing
this either. I've formally reviewed some of these toolkits and I'd
pit them against ESAPI and expect favorable results. Plenty of
organizations are doing a great job building stuff on top of
profoundly broken platforms, frameworks, and toolkits... and they're
following a 'secure SDL' to get there. ESAPI can not be said to have
adhered to that rigor (*2). Organizations care about this risk
regardless of the pedigree and experience of those who are building
it.

Is the right answer for everyone to drop everything and build their
own secure toolkit? I don't think so. I like that the OWASP
community is taking a whack at something open and free to share.
These same people have attempted to improve Java's security through
the community process--and though often correct, diligent, friendly,
and well-intentioned, their patience has often been tested to or
beyond the breaking point: those building the platforms and
frameworks simply aren't listening that well yet. That is very sad.

One thing I've seen a lot of is organizations assessing, testing,
hardening, documenting, and internally distributing their own
versions of popular Java EE toolkits (the secure struts
phenomenon). I've seen some organizations give their developers
training and write SAST rules to automatically verify correct use of
such toolkits. I like this idea a hell of a lot as an alternative to
an ESAPI-like approach. Why? A few reasons:

1) Popularity - these toolkits appeal to developers: their
interfaces have been voted on by their adopting user population--
not conceived and lamented principally by security folk. No one
forces developers to go from Struts to Spring they do it because it
saves them time, makes their app faster, or some combination of
important factors.

2) Changes App Infrastructure - MVC frameworks, especially, make up
the scaffolding (hence the name 'Struts') of an application. MVC
code often touches user input before developer's see it and gets the
last chance to encode output before a channel (user or otherwise)
receives it. Focusing on an application's scaffolding allows in some
cases, a best-chance of touching all input/out and true invisibility
relative to developer generated code. Often, its configuration is
declarative in nature as well--keeping security from cluttering up
the Java code. Note that this approach is fundamentally different
from Firewalls and some dynamic patching because it's in the
app (an argument made recently by others in the blogosphere).

3) Top-to-Bottom Secure by Default - Declarative secure-by-default
configuration of the hardened toolkit

Re: [SC-L] Ramesh Nagappan Blog : Java EE 6: Web Application Security made simple ! | Core Security Patterns Weblog

2010-01-07 Thread Jim Manico

John,

You do not need OWASP ESAPI to secure an app. But you need A ESAPI  
for your organization in order to build secure Apps, in my opinion.  
OWASP ESAPI may help you get started down that path.


An ESAPI is no silver bullet, there is no such thing as that in  
AppSec. But it will help you build secure apps.


Jim Manico

On Jan 6, 2010, at 6:20 PM, John Steven jste...@cigital.com wrote:


All,

With due respect to those who work on ESAPI, Jim included, ESAPI is  
not the only way to make a secure app even remotely possible. And  
I believe that underneath their own pride in what they've done--some  
of which is very warranted--they understand that. It's hard not to  
become impassioned in posting.


I've seen plenty of good secure implementations within  
organizations' own security toolkits. I'm not the only one that's  
noticed: the BSIMM SSF calls out three relevant activities to this  
end:


SDF 1.1 Build/publish security features (*1)
SDF 2.1 Find/publish mature design patterns from the organization  
(similar URL)
SDF 2.3  Build secure-by-design middleware frameworks/common  
libraries (similar URL)


Calling out three activities within the SSF means that it can't just  
be John Steven's top client (whatever that means) that's doing  
this either. I've formally reviewed some of these toolkits and I'd  
pit them against ESAPI and expect favorable results. Plenty of  
organizations are doing a great job building stuff on top of  
profoundly broken platforms, frameworks, and toolkits... and they're  
following a 'secure SDL' to get there. ESAPI can not be said to have  
adhered to that rigor (*2). Organizations care about this risk  
regardless of the pedigree and experience of those who are building  
it.


Is the right answer for everyone to drop everything and build their  
own secure toolkit? I don't think so. I like that the OWASP  
community is taking a whack at something open and free to share.  
These same people have attempted to improve Java's security through  
the community process--and though often correct, diligent, friendly,  
and well-intentioned, their patience has often been tested to or  
beyond the breaking point: those building the platforms and  
frameworks simply aren't listening that well yet. That is very sad.


One thing I've seen a lot of is organizations assessing, testing,  
hardening, documenting, and internally distributing their own  
versions of popular Java EE toolkits (the secure struts  
phenomenon). I've seen some organizations give their developers  
training and write SAST rules to automatically verify correct use of  
such toolkits. I like this idea a hell of a lot as an alternative to  
an ESAPI-like approach. Why? A few reasons:


1) Popularity - these toolkits appeal to developers: their  
interfaces have been voted on by their adopting user population-- 
not conceived and lamented principally by security folk. No one  
forces developers to go from Struts to Spring they do it because it  
saves them time, makes their app faster, or some combination of  
important factors.


2) Changes App Infrastructure - MVC frameworks, especially, make up  
the scaffolding (hence the name 'Struts') of an application. MVC  
code often touches user input before developer's see it and gets the  
last chance to encode output before a channel (user or otherwise)  
receives it. Focusing on an application's scaffolding allows in some  
cases, a best-chance of touching all input/out and true invisibility  
relative to developer generated code. Often, its configuration is  
declarative in nature as well--keeping security from cluttering up  
the Java code. Note that this approach is fundamentally different  
from Firewalls and some dynamic patching because it's in the  
app (an argument made recently by others in the blogosphere).


3) Top-to-Bottom Secure by Default - Declarative secure-by-default  
configuration of the hardened toolkit allows for securing those data  
flows that never make it out of the scaffolding into the app. If an  
organization wrote their own toolkit-unware security API, they'd  
have to not only assure their developers call it each-and-every  
place their it's needed but they'd also need to crack open the  
toolkits and make sure THEY call it too. Most of the time, one  
actively wants to avoid even having this visibility let along  
maintenance problem: it's a major headache.


and, most importantly,

4) Less Integration points - Developers are already going to have to  
integrate against a MVC framework, so why force them to integrate  
against YA (yet-another) API? The MVC frameworks already contend  
with things like session management, input filtering, output- 
encoding, and authentication. Why not augment/improve that existing  
idiom rather than force developers to use it and an external  
security API?


The ESAPI team has plenty of responses to the last question... not  
the least of which is ...'cause [framework XXX] sucks. Fair. Out

Re: [SC-L] Functional Correctness

2009-08-22 Thread Jim Manico
We are approaching huge industry-wide application security critical  
mass for the first time. Now is the time to strike. If all we teach is  
input validation+canonicalization, query parameterization, and output  
encoding, we stop xss and sqli via education


Jim Manico

On Aug 21, 2009, at 11:54 AM, Brad Andrews andr...@rbacomm.com wrote:



I completely agree, though how are we really going to reach this  
point?  We have been talking about this at least since I got into  
development in the early 1980s.  We are not anywhere closer, though  
we have lots of neat tools that do lots of neat stuff.   
Unfortunately, our programs are also a lot more complicated, making  
the correct proof much more difficult.


Can we really believe it is just around the corner to prove this?

--

Brad Andrews
RBA Communications
CISM, CSSLP, SANS/GIAC GSEC, GCFW, GCIH, GPCI


Quoting Cassidy, Colin (GE Infra, Energy) colin.cass...@ge.com:


Martin Gilje Jaatun wrote:


Karen, Matt  all,

Goertzel, Karen [USA] wrote:
 I'm more devious. I think what needs to happen is that we
need to redefine what we mean by functionally correct or
quality code.

___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com 
)

as a free, non-commercial service to the software security community.
___

___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___


Re: [SC-L] IBM Acquires Ounce Labs, Inc.

2009-07-28 Thread Jim Manico
A quick note, in the Java world (obfuscation aside), the source and  
binary is really the same thing. The fact that Fortify analizes  
source and Veracode analizes class files is a fairly minor detail.


Jim Manico

On Jul 28, 2009, at 7:40 AM, Arian J. Evans arian.ev...@anachronic.com 
 wrote:



Right now, officially, I think that is about it. IBM, Veracode, and
AoD (in Germany) claims they have this too.

As Mattyson mentioned, Veracode only does static binary analysis (no
source analysis). They offer dynamic scanning but I believe it is
using NTO Spider IIRC which is a simplified scanner that targets
unskilled users last I saw it.

At one point I believe Veracode was in discussions with SPI to use WI,
but since the Veracoders haunt this list I'll let them clarify what
they use if they want.

So IBM: soon.

Veracode: sort-of.

AoD: on paper

And more to come in short order no doubt. I think we all knew this was
coming sooner or later. Just a matter of when.

The big guys have a lot of bucks to throw at this problem if they want
to, and pull off some really nice integrations. Be interesting to see
what they do, and how useful the integrations really are to
organizations.

--
Arian Evans





On Tue, Jul 28, 2009 at 9:29 AM, Matt Fisherm...@piscis- 
security.com wrote:
Pretty much. Hp /spi has integrations as well but I don't recall  
devinspect ever being a big hit.  Veracode does both as well as  
static binary but as asaas model. Watchfire had a RAD integration  
as well iirc but it clearly must not haved had the share ounce does.


-Original Message-
From: Prasad Shenoy prasad.she...@gmail.com
Sent: July 28, 2009 12:22 PM
To: Kenneth Van Wyk k...@krvw.com
Cc: Secure Coding SC-L@securecoding.org
Subject: Re: [SC-L] IBM Acquires Ounce Labs, Inc.


Wow indeed. Does that makes IBM the only vendor to offer both Static
and Dynamic software security testing/analysis capabilities?

Thanks  Regards,
Prasad N. Shenoy

On Tue, Jul 28, 2009 at 10:19 AM, Kenneth Van Wykk...@krvw.com  
wrote:
Wow, big acquisition news in the static code analysis space  
announced today:


http://news.prnewswire.com/DisplayReleaseContent.aspx?ACCT=104STORY=/www/story/07-28-2009/0005067166EDATE=


Cheers,

Ken

-
Kenneth R. van Wyk
KRvW Associates, LLC
http://www.KRvW.com

(This email is digitally signed with a free x.509 certificate from  
CAcert.

If you're unable to verify the signature, try getting their root CA
certificate at http://www.cacert.org -- for free.)






___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com 
)
as a free, non-commercial service to the software security  
community.

___



___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com 
)

as a free, non-commercial service to the software security community.
___

___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com 
)

as a free, non-commercial service to the software security community.
___



___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com 
)

as a free, non-commercial service to the software security community.
___

___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___


Re: [SC-L] Security Architecture Cheat Sheet - Lenny Zeltser

2009-06-20 Thread Jim Manico
Very nice work.

Since this is written under the creative common 3 license, I put a copy 
(with attribution to Lenny) on OWASP.org at 
http://www.owasp.org/index.php/Security_Architecture_Cheat_Sheet in case 
anyone wishes to collaborate on this guide.

- Jim


- Original Message - 
From: Prasad Shenoy prasad.she...@gmail.com
To: SC-L@securecoding.org
Sent: Friday, June 19, 2009 10:18 AM
Subject: [SC-L] Security Architecture Cheat Sheet - Lenny Zeltser


 Lenny Zeltser has published a Security Architecture Cheat Sheet. Out
 of his many cheat sheets, this one in particular might be of interest
 (in order of relevance :-)) to coders and architects on the group.

 http://www.zeltser.com/security-management/security-architecture-cheat-sheet.pdf

 Regards,
 Prasad Shenoy
 ___
 Secure Coding mailing list (SC-L) SC-L@securecoding.org
 List information, subscriptions, etc - 
 http://krvw.com/mailman/listinfo/sc-l
 List charter available at - http://www.securecoding.org/list/charter.php
 SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
 as a free, non-commercial service to the software security community.
 ___
 

___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___


[SC-L] OWASP Podcast #23 - Dr. Boaz Gelbord

2009-06-02 Thread Jim Manico
Hello SC-L,

OWASP Podcast #23, an interview with Dr. Boaz Gelbord, is now live. 
http://www.owasp.org/download/jmanico/owasp_podcast_23.mp3

Boaz co-authored the 2009 OWASP Security Spending Benchmarks Project with 
Jeremiah Grossman.  Boaz is also the new OWASP Developers Guide project lead.

Thanks for listening, I hope you enjoy.

Regards,
Jim Manico
Aspect Security/OWASP Podcast Host

RSS: http://www.owasp.org/download/jmanico/podcast.xml
iTunes: 
http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewPodcast?id=300769012 



___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___


[SC-L] OWASP Podcast #22

2009-05-22 Thread Jim Manico
Hello SC-L,

OWASP Podcast #22, an interview with Dan Cornell, CTO of the Denim Group - is 
now live!  http://www.owasp.org/index.php/Podcast_22

Dan is a smart cookie who puts in incredible amount of time volunteering for 
OWASP. He's a great guy with a very pragmatic perspective on Application 
Security. I hope you enjoy!

Aloha from Kauai,
Jim Manico
OWASP Podcast Series Host
___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___


[SC-L] OWASP Podcast Update

2009-05-13 Thread Jim Manico
Hello sc-l,

OWASP Podcast #19 and #20 were both released this week!  

OWASP Podcast #19 is a 55 minute news commentary program 
http://www.owasp.org/download/jmanico/owasp_podcast_19.mp3

OWASP Podcast #20 is a 13 minute interview with Mike Baily; the researcher who 
disclosed multiple CSRF vulns in the AV vendor space
http://www.owasp.org/download/jmanico/owasp_podcast_20.mp3

Thanks kindly for listening!

Jim Manico
OWASP Podcast Series Host
podc...@owasp.org 

Archives: https://www.owasp.org/index.php/OWASP_Podcast#tab=Latest_Shows
RSS Feed: http://www.owasp.org/download/jmanico/podcast.xml___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___


[SC-L] OWASP Podcast 17

2009-04-23 Thread Jim Manico
Hello sc-l,

OWASP Podcast 17 - an Interview with Robert RSnake Hansen - is now live. 

Show Notes: https://www.owasp.org/index.php/Podcast_17
Direct Download: http://www.owasp.org/download/jmanico/owasp_podcast_17.mp3
RSS: http://www.owasp.org/download/jmanico/podcast.xml
iTunes: 
http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewPodcast?id=300769012

Thanks for listening,
- Jim Manico
___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___


[SC-L] OWASP Podcast 15

2009-04-06 Thread Jim Manico
I had the pleasure of interview Dr. Brian Chess from Fortify Software for OWASP 
Podcast 15. Brian talked about BSIMM and more - demonstrated a lot of class as 
always. Have a listen!

Direct Link: http://www.owasp.org/download/jmanico/owasp_podcast_15.mp3

To stay connected to the OWASP Podcast Series:

OWASP Podcast Homepage: http://www.owasp.org/index.php/OWASP_Podcast
RSS Feed: http://www.owasp.org/download/jmanico/podcast.xml
iTunes: 
http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewPodcast?id=300769012
Twitter: http://twitter.com/manicode (production updates)

PS: For bonus points; spot where the Berkley PhD calls OWASP members Hippies 
=D 
___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___


Re: [SC-L] BSIMM: Confessions of a Software SecurityAlchemist(informIT)

2009-03-22 Thread Jim Manico
 even argue
 that security testing IS functional testing, but anyway...

 If you're going to innovate, you must as well jump the curve*.

 -ben

 * see Kawasaki Art of Innovation
 http://blog.guykawasaki.com/2007/06/art_of_innovati.html

 Gary McGraw wrote:
 Aloha Jim,

 I agree that security bugs should not necessarily take precedence
 over other bugs.  Most of the initiatives that we observed cycled ALL
 security bugs into the standard bug tracking system (most of which
 rank bugs by some kind of severity rating).  Many initiatives put
 more weight on security bugs...note the term weight not drop
 everything and run around only working on security.  See the CMVM
 practice activities for more.

 The BSIMM helps to measure and then evolve a software security
 initiative.  The top N security bugs activity is one of an arsenal of
 tools built and used by the SSG to strategically guide the rest of
 their software security initiative.  Making this a top N bugs of any
 kind list might make sense for some organizations, but is not
 something we would likely observe by studying the SSG and the
 software security initiative.  Perhaps we suffer from the looking
 for the keys under the streetlight problem.

 gem


 On 3/19/09 2:31 PM, Jim Manico j...@manico.net wrote:

 The top N lists we observed among the 9 were BUG lists only.  So
 that means that in general at least half of the defects were not
 being identified on the most wanted list using that BSIMM set of
 activities.

 This sounds very problematic to me. There are many standard software
 bugs that are much more critical to the enterprise than just security
 bugs. It seems foolhardy to do risk assessment on security bugs only
 - I think we need to bring the worlds of software development and
 security analysis together more. Divided we (continue to) fail.

 And Gary, this is not a critique of just your comment, but of
 WebAppSec at large.

 - Jim


 - Original Message - From: Gary McGraw g...@cigital.com
 To: Steven M. Christey co...@linus.mitre.org Cc: Sammy Migues
 smig...@cigital.com; Michael Cohen mco...@cigital.com; Dustin
 Sullivan dustin.sulli...@informit.com; Secure Code Mailing List
 SC-L@securecoding.org Sent: Thursday, March 19, 2009 2:50 AM
 Subject: Re: [SC-L] BSIMM: Confessions of a Software Security
 Alchemist (informIT)


 Hi Steve,

 Sorry for falling off the thread last night.  Waiting for the posts
 to clear was not a great idea.

 The top N lists we observed among the 9 were BUG lists only.  So
 that means that in general at least half of the defects were not
 being identified on the most wanted list using that BSIMM set of
 activities. You are correct to point out that the Architecture
 Analysis practice has other activities meant to ferret out those
 sorts of flaws.

 I asked my guys to work on a flaws collection a while ago, but I
 have not seen anything yet.  Canuck?

 There is an important difference between your CVE data which is
 based on externally observed bugs (imposed on vendors by security
 types mostly) and internal bug data determined using static
 analysis or internal testing.  I would be very interested to know
 whether Microsoft and the CVE consider the same bug #1 on internal
 versus external rating systems.  The difference is in the term
 reported for versus discovered internally during SDL activity.

 gem

 http://www.cigital.com/~gem


 On 3/18/09 6:14 PM, Steven M. Christey co...@linus.mitre.org
 wrote:



 On Wed, 18 Mar 2009, Gary McGraw wrote:

 Many of the top N lists we encountered were developed through the
  consistent use of static analysis tools.
 Interesting.  Does this mean that their top N lists are less likely
 to include design flaws?  (though they would be covered under
 various other BSIMM activities).

 After looking at millions of lines of code (sometimes
 constantly), a ***real*** top N list of bugs emerges for an
 organization.  Eradicating number one is an obvious priority.
 Training can help.  New number one...lather, rinse, repeat.
 I believe this is reflected in public CVE data.  Take a look at the
 bugs that are being reported for, say, Microsoft or major Linux
 vendors or most any product with a long history, and their current
 number 1's are not the same as the number 1's of the past.

 - Steve


 ___ Secure Coding
 mailing list (SC-L) SC-L@securecoding.org List information,
 subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List
 charter available at - http://www.securecoding.org/list/charter.php
  SC-L is hosted and moderated by KRvW Associates, LLC
 (http://www.KRvW.com) as a free, non-commercial service to the
 software security community.
 ___




 ___ Secure Coding mailing
 list (SC-L) SC-L@securecoding.org List information, subscriptions,
 etc - http://krvw.com/mailman/listinfo/sc-l List charter available at
 - http://www.securecoding.org

Re: [SC-L] BSIMM: Confessions of a Software Security Alchemist (informIT)

2009-03-19 Thread Jim Manico
 The top N lists we observed among the 9 were BUG lists only.  So that 
 means that in general at least half of the defects were not being 
 identified on the most wanted list using that BSIMM set of activities.

This sounds very problematic to me. There are many standard software bugs 
that are much more critical to the enterprise than just security bugs. It 
seems foolhardy to do risk assessment on security bugs only - I think we 
need to bring the worlds of software development and security analysis 
together more. Divided we (continue to) fail.

And Gary, this is not a critique of just your comment, but of WebAppSec at 
large.

- Jim


- Original Message - 
From: Gary McGraw g...@cigital.com
To: Steven M. Christey co...@linus.mitre.org
Cc: Sammy Migues smig...@cigital.com; Michael Cohen 
mco...@cigital.com; Dustin Sullivan dustin.sulli...@informit.com; 
Secure Code Mailing List SC-L@securecoding.org
Sent: Thursday, March 19, 2009 2:50 AM
Subject: Re: [SC-L] BSIMM: Confessions of a Software Security Alchemist 
(informIT)


 Hi Steve,

 Sorry for falling off the thread last night.  Waiting for the posts to 
 clear was not a great idea.

 The top N lists we observed among the 9 were BUG lists only.  So that 
 means that in general at least half of the defects were not being 
 identified on the most wanted list using that BSIMM set of activities. 
 You are correct to point out that the Architecture Analysis practice has 
 other activities meant to ferret out those sorts of flaws.

 I asked my guys to work on a flaws collection a while ago, but I have not 
 seen anything yet.  Canuck?

 There is an important difference between your CVE data which is based on 
 externally observed bugs (imposed on vendors by security types mostly) and 
 internal bug data determined using static analysis or internal testing.  I 
 would be very interested to know whether Microsoft and the CVE consider 
 the same bug #1 on internal versus external rating systems.  The 
 difference is in the term reported for versus discovered internally 
 during SDL activity.

 gem

 http://www.cigital.com/~gem


 On 3/18/09 6:14 PM, Steven M. Christey co...@linus.mitre.org wrote:



 On Wed, 18 Mar 2009, Gary McGraw wrote:

 Many of the top N lists we encountered were developed through the
 consistent use of static analysis tools.

 Interesting.  Does this mean that their top N lists are less likely to
 include design flaws?  (though they would be covered under various other
 BSIMM activities).

 After looking at millions of lines of code (sometimes constantly), a
 ***real*** top N list of bugs emerges for an organization.  Eradicating
 number one is an obvious priority.  Training can help.  New number
 one...lather, rinse, repeat.

 I believe this is reflected in public CVE data.  Take a look at the bugs
 that are being reported for, say, Microsoft or major Linux vendors or most
 any product with a long history, and their current number 1's are not the
 same as the number 1's of the past.

 - Steve


 ___
 Secure Coding mailing list (SC-L) SC-L@securecoding.org
 List information, subscriptions, etc - 
 http://krvw.com/mailman/listinfo/sc-l
 List charter available at - http://www.securecoding.org/list/charter.php
 SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
 as a free, non-commercial service to the software security community.
 ___
 

___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___


Re: [SC-L] BSIMM: Confessions of a Software Security Alchemist (informIT)

2009-03-19 Thread Jim Manico
That's a bit of dodging the question, I'd like to hear more. You comment 
below implied that it was your consistent use of vendor-based static analyis 
tool that allowed you to figure out top N list of bugs for a specific 
organization. Leading with static analysis as your primary analysis driver 
concearns me. Will you elaborate, please?

- Jim

- Original Message - 
From: Gary McGraw g...@cigital.com
To: Jim Manico j...@manico.net; Steven M. Christey 
co...@linus.mitre.org
Cc: Sammy Migues smig...@cigital.com; Dustin Sullivan 
dustin.sulli...@informit.com; Secure Code Mailing List 
SC-L@securecoding.org
Sent: Thursday, March 19, 2009 9:04 AM
Subject: Re: [SC-L] BSIMM: Confessions of a Software Security Alchemist 
(informIT)


Actually no.  See: http://www.cigital.com/papers/download/j15bsi.pdf
(John Steven,   State of Application Assessment, IEEE SP)

I am not a tool guy, I am a software security guy.

gem

http://www.cigital.com/~gem


On 3/19/09 2:58 PM, Jim Manico j...@manico.net wrote:

 Many of the top N lists we encountered were developed through the
 consistent use of static analysis tools.  After looking at millions of
 lines of code (sometimes constantly), a ***real*** top N list of bugs
 emerges for an organization.

You mean a real list of what a certain vendors static analysis tools find.
If you think that list really measures the risk of an organizations software
security posture - that might ne considered to be insane! =)

- Jim

- Original Message -
From: Gary McGraw g...@cigital.com
To: Steven M. Christey co...@linus.mitre.org
Cc: Sammy Migues smig...@cigital.com; Dustin Sullivan
dustin.sulli...@informit.com; Secure Code Mailing List
SC-L@securecoding.org
Sent: Wednesday, March 18, 2009 11:54 AM
Subject: Re: [SC-L] BSIMM: Confessions of a Software Security Alchemist
(informIT)


 Hi Steve,

 Many of the top N lists we encountered were developed through the
 consistent use of static analysis tools.  After looking at millions of
 lines of code (sometimes constantly), a ***real*** top N list of bugs
 emerges for an organization.  Eradicating number one is an obvious
 priority.  Training can help.  New number one...lather, rinse, repeat.

 Other times (like say in the one case where the study participant did not
 believe in static analysis for religious reasons) things are a bit more
 flip (and thus suffer from the no data problem I like to complain
 about).  I do not recall a case when the top N lists were driven by
 customers.

 Sorry I missed your talk at the SWA forum.  I'll chalk that one up to NoVa
 traffic.

 gem

 http://www.cigital.com/~gem


 On 3/18/09 5:47 PM, Steven M. Christey co...@linus.mitre.org wrote:



 On Wed, 18 Mar 2009, Gary McGraw wrote:

 Because it is about building a top N list FOR A PARTICULAR ORGANIZATION.
 You and I have discussed this many times.  The generic top 25 is
 unlikely to apply to any particular organization.  The notion of using
 that as a driver for software purchasing is insane.  On the other hand
 if organization X knows what THEIR top 10 bugs are, that has real value.

 Got it, thanks.  I guessed as much.  Did you investigate whether the
 developers' personal top-N lists were consistent with what their customers
 cared about?  How did the developers go about selecting them?

 By the way, last week in my OWASP Software Assurance Day talk on the Top
 25, I had a slide on the role of top-N lists in BSIMM, where I attempted
 to say basically the same thing.  This was after various slides that tried
 to emphasize how the current Top 25 is both incomplete and not necessarily
 fully relevant to a particular organization's needs.  So while the message
 may have been diluted during initial publication, it's being refined
 somewhat.

 - Steve


 ___
 Secure Coding mailing list (SC-L) SC-L@securecoding.org
 List information, subscriptions, etc -
 http://krvw.com/mailman/listinfo/sc-l
 List charter available at - http://www.securecoding.org/list/charter.php
 SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
 as a free, non-commercial service to the software security community.
 ___




___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___


Re: [SC-L] Rigged podcasts can leak your iTunes username/password |Zero Day | ZDNet.com

2009-03-12 Thread Jim Manico
On the topics of Podcast, I'm very pleased to announce the release of the 
non-rigged live release of OWASP Podcast #12, an Interview with Ryan C. 
Barnet.

Ryan Barnett talks about the OWASP ModSecurity core ruleset project and WAF 
technology in general. Ryan has such incredible experience in this space - I 
was really impressed with his dept - as well as his use of Football as 
metaphor! =)

To listen to OWASP Podcast #11 you can, download the mp3 file directly , 
subscribe to the RSS feed or subscribe directly through iTunes!

Aloha from OWASP Podcast HQ,
Jim 

___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___


[SC-L] OWASP Podcast #6

2009-02-05 Thread Jim Manico
Hello SC-L

I just pushed OWASP Podcast #6 live at
http://www.owasp.org/index.php/Podcast_6 - an OWASP Roundtable with
Brian Holyfield, Marcin Wielgoszewski, Andre Gironda and myself, Jim
Manico. Our focus was WAF's.

Thanks and I hope  you enjoy,
Jim Manico
___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___


Re: [SC-L] Some Interesting Topics arising from the SANS/CWE Top 25

2009-01-15 Thread Jim Manico
 I'd like to offer a different view for your consideration, which is
that /*input validation and output encoding actually don't have anything
to do with security*/. Those techniques are essential software building.

I'm really confused with this statement - and almost feel it's
dangerous. Encoding, especially, is the cornerstone of building secure
web applications. In particular, _encoding data within the correct
context of usage_  is the basis for defending against approximately 2/3
of all classes of web vulnerabilities - XSS and SQLi in particular.
Sure, bad or no encoding is definitely a bug - but it's also impossible
to build a secure web application without proper use of encoding. So
to say that output encoding actually don't have anything to do with
security seems like a fairly radically incorrect statement. Sure, we
should split up encoding into multiple categories - but I still think
it's the cornerstone to secure programming practices. Libraries like
ESAPI make such tasks very easy, too.

However, I agree that Validation is overhyped. Input validation is
really relevant to (web) security if you ever accept HTML from a user
(ala validation tools like AntiSamy). You also need to solve malicious
file upload attacks (if you support that feature) with input validation.
Of course there are different considerations for the think client world
when it comes to this topic.

So, in short:

Encoding and Validation are software building blocks - that are
fundamental for (especially web) software to defend against injection
attacks (at least) - therefore making validation and coding have
something to do with security

- Jim


 blocks. While it is true that omission to use these techniques often
 causes security issues, that only means such programs are insecure in
 addition to being defective. I think that it's inherently wrong to
 associate input validation and output encoding with security. Fix the
 defects and the security issues will go away. On the other hand, if
 you only fix the security issues you may be left with a number of
 defects on your hands.

 Input validation layers should focus on accepting only valid data (per
 business requirements), while code that transmits data across system
 boundaries should focus on using the exchange and communication
 protocols correctly.

 Actually, now that I think about it more, I think we are struggling
 with the term input validation because the term has been overloaded.
 In the one sense, we are talking about validating user input, which
 mostly needs to concern itself with adhering to business requirements.
 This meaning is not very important for security, but the other one,
 validating data before something is done with it, is. If you take a
 web application for example, you would ideally verify that all user
 submitted data adheres to your business requirements.

   

___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___


Re: [SC-L] FW: How Can You Tell It Is Written Securely?

2008-12-01 Thread Jim Manico
 written horrendously but were very secure (in the
 sense that they abided to all security-relevant business requirements)
 and I have seen many applications written using the 'best practices' in
 coding and developed with very mature processes that could be hacked in
 minutes.

 So, are there any studies that proof that a company that performs some
 tests (e.g. pen-tests) or include security requirements in the contracts
 ultimately is better off than a company that does not do what we
 consider 'best practices'? And if we don't have that proof, shouldn't we
 be very prudent in what we advise to our customers? 

 Please note that my company sells security related software and performs
 vulnerability assessments, so I'm not saying that these are useless
 (:)), but maybe there are better methods than penetrate  patch or
 enforcing very heavy processes on innocent development teams... So, this
 is question to this list: Are we on the right track? Is application
 security really improving? Do we measure the correct things and in the
 correct way? My point of view is that only certain vulnerabilities are
 less common than in the early days just because of more mature
 frameworks, but not due to better processes or after the fact testing.
 Does this mean all efforts were vain? Or did the threat landscape
 change? And yes, there are many vendor driven statistics floating around
 but they really cannot be considered unbiased ... Lots of questions,
 maybe not all relevant for the Secure Coding list, but Secure Coding
 should have an final objective. Or not?

 Herman
 [EMAIL PROTECTED]
 
 This communication, including attachments, is for the exclusive use of 
 addressee and may contain proprietary, confidential and/or privileged 
 information.  If you are not the intended recipient, any use, copying, 
 disclosure, dissemination or distribution is strictly prohibited.  If you are 
 not the intended recipient, please notify the sender immediately by return 
 e-mail, delete this communication and destroy all copies.
 


 ___
 Secure Coding mailing list (SC-L) SC-L@securecoding.org
 List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
 List charter available at - http://www.securecoding.org/list/charter.php
 SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
 as a free, non-commercial service to the software security community.
 ___
   


-- 
Jim Manico, Senior Application Security Engineer
[EMAIL PROTECTED] | [EMAIL PROTECTED]
(301) 604-4882 (work)
(808) 652-3805 (cell)

Aspect Security™
Securing your applications at the source
http://www.aspectsecurity.com

___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___


Re: [SC-L] How Can You Tell It Is Written Securely?

2008-11-27 Thread Jim Manico
  OK.  So you decide to outsource your programming assignment to Asia
and demand that they deliver code that is so locked down that it cannot
misbehave.  How can you tell that what they deliver is truly locked
down?  Will you wait until it gets hacked?  What simple yet thorough
inspection process is there that'll do the job?  Doesn't exist, does it?

This most important thing you can do is provide very specific security
requirements as part of your vendor contract BEFORE you hire a vendor -
and the process of building these security requirements might call for
bringing in a security consultant if you do not have the expertise in-shop.

Requirements that allow a vendor to actually provide security are line
items like (assuming its a web app):

Provide input validation for every piece of user data. Do so by mapping
every unique piece of user data  to a regular expression that is placed
inside a configuration file.
Provide CSRF protection by creating and enforcing a form nonce for
every user session

After you build this list for your company, it should provide you with a
core list of security requirements that you can add to any PO.

- Jim

  
  
 MARK ROCKMAN
 MDRSESCO LLC 
 

 ___
 Secure Coding mailing list (SC-L) SC-L@securecoding.org
 List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
 List charter available at - http://www.securecoding.org/list/charter.php
 SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
 as a free, non-commercial service to the software security community.
 ___
   


-- 
Jim Manico, Senior Application Security Engineer
[EMAIL PROTECTED] | [EMAIL PROTECTED]
(301) 604-4882 (work)
(808) 652-3805 (cell)

Aspect Security™
Securing your applications at the source
http://www.aspectsecurity.com

___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___


Re: [SC-L] Secure Coding Standards

2008-09-28 Thread Jim Manico
Andrew van der Stock is also approaching this issue from a high level at

http://www.greebo.net/2008/09/24/coding-standard/

His list looks rather complete.

- Jim

 My thoughts...

 You standards really need more context - the standards for Java thick
 client vs Java server/web code would be rather different, for example.
 Make sure your guide gives recomendations specific to the context of
 the application type.

 On that note, other thoughts

 * Robert Seacord's guide is one of the best guides to secure coding in
 the C++ world but does not address web based or non C++ programming.
 a) I would also read Ken's book on this topic - great stuff.
 b) Microsoft books on their trustworthy computing initiative for
 the .NET world are very well written.
 * The SANS's courses and certs are really network/infrastructure
 centric and are not that helpful for the software engineer
 * The Sun link is way to general - nothing specific to really help the
 programmer write secure code.
 * 4-7 are way to general.

 In the web world, OWASP is by far the best. See:
 http://www.owasp.org/index.php/Category:OWASP_Guide_Project

 - Jim
 I am looking for a comprehensive set of secure coding standards to
 implement into my dev organization. These standards should cover
 Java, Web, and C/C++ as well as guidelines for using features like
 encryption, authentication, SSO, SSL, etc. I am open to both publicly
 available standards as well as commercially available standards. So
 far, I found

1. www.securecoding.cert.org http://www.securecoding.cert.org/ -
   thanks to Robert C. Seacord,
   http://krvw.com/pipermail/sc-l/2008/001401.html
2. http://java.sun.com/security/seccodeguide.html
3. http://wiki.services.openoffice.org/wiki/Cpp_Coding_Standards
4. DHS Build Security In (kind of) -
   https://buildsecurityin.us-cert.gov/daisy/bsi/home.html
5. SANS Software Security Institute - http://www.sans-ssi.org/
6. CERT Top 10 Secure Coding Practices -
   
 https://www.securecoding.cert.org/confluence/display/seccode/Top+10+Secure+Coding+Practices
7. SANS GIAC Secure Software Programmer - http://www.sans.org/gssp/

  I would greatly appreciate any pointers to other links or to
 companies who have developed and sell these standards.
  
 Thanks in advance.
  
 An0n S3c.

  

 

 ___
 Secure Coding mailing list (SC-L) SC-L@securecoding.org
 List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
 List charter available at - http://www.securecoding.org/list/charter.php
 SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
 as a free, non-commercial service to the software security community.
 ___
   


 -- 
 Jim Manico, Senior Application Security Engineer
 [EMAIL PROTECTED] | [EMAIL PROTECTED]
 (301) 604-4882 (work)
 (808) 652-3805 (cell)

 Aspect Security™
 Securing your applications at the source
 http://www.aspectsecurity.com

 ---
 Management, Developers, Security Professionals ...
 ... can only result in one thing. BETTER SECURITY.
 http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference  
 Sept 22nd-25th 2008

   


-- 
Jim Manico, Senior Application Security Engineer
[EMAIL PROTECTED] | [EMAIL PROTECTED]
(301) 604-4882 (work)
(808) 652-3805 (cell)

Aspect Security™
Securing your applications at the source
http://www.aspectsecurity.com

---
Management, Developers, Security Professionals ...
... can only result in one thing. BETTER SECURITY.
http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference  
Sept 22nd-25th 2008


___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___


Re: [SC-L] Survey

2008-08-26 Thread Jim Manico
How does xHTML help stop access control vulnerabilities? Authorization
issues? CSRF problems?

And who is to say that an attacker cannot still do server side injection
(sql injection, ldap injection) or timing attacks?

I'm just getting started. xHTML is only one tiny piece of the outbound
encoding problem.

Hey, while we are at it - who is to say that someone mounting a MITM
attack could not modify/corrupt data and still be (woo ho) xHTML valid?

- Jim

 Hi Jim,

  There are plenty of sites that are perfectly x/html valid that are
 completely insecure.

 Well, perhaps too many people have been listening to this drumbeat:
 In fact, a non-developer: such as someone in marketing who uses
 Dreamweaver, could also do almost as much as a normal WAF by saving
 their content as valid XHTML. This would buy the organization basic
 application security functionality, which is what WAF also attempts to
 do.

 http://www.tssci-security.com/archives/2008/06/27/week-of-war-on-wafs-day-5-final-thoughts/

 I rest my case.
 Stephen

 On Mon, Aug 25, 2008 at 7:05 AM, Jim Manico [EMAIL PROTECTED]
 mailto:[EMAIL PROTECTED] wrote:

 There are plenty of sites that are perfectly x/html valid that are
 completely insecure.

 There are plenty of sites that follow perfect w3c and other
 standards that are completely insecure.

 There are plenty of sites that are top-tier security vendors that,
 at least in the past, have been insecure.

 - Jim


 At 11:11 AM -0400 8/24/08, Paco Hope wrote:

   
 Clearly the survey's content is only of interest if the HTML validates.
 
 The publisher of the web page is not in the security business,
 they are in the publishing business.  But how can I respect
 their publishing expertise if they fail a simple automatic
 test.

 And how can their target audience of security folk, who depend
 strongly on following standards respect the knowledge of a
 publisher who does not follow publishing standards.

   
 On Aug 24, 2008, at 9:47 AM, ljknews [EMAIL PROTECTED] 
 mailto:[EMAIL PROTECTED] wrote:

 
 At 2:43 PM -0400 8/22/08, Gary McGraw wrote:

   
 BankInfoSecurity is running a survey on software security that some
 of you may be interested in participating in.  Try it yourself here:

 http://www.bankinfosecurity.com/surveys.php?surveyID=1
 
 Hmmm.  http://validator.w3.org says there are 973 errors on that page.
   


 -- 
 Jim Manico, Senior Application Security Engineer
 [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] | [EMAIL PROTECTED] 
 mailto:[EMAIL PROTECTED]
 (301) 604-4882 (work)
 (808) 652-3805 (cell)

 Aspect Security™
 Securing your applications at the source
 http://www.aspectsecurity.com

 ---
 Management, Developers, Security Professionals ...
 ... can only result in one thing. BETTER SECURITY.
 http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference  
 Sept 22nd-25th 2008

 


 ___
 Secure Coding mailing list (SC-L) SC-L@securecoding.org
 mailto:SC-L@securecoding.org
 List information, subscriptions, etc -
 http://krvw.com/mailman/listinfo/sc-l
 List charter available at -
 http://www.securecoding.org/list/charter.php
 SC-L is hosted and moderated by KRvW Associates, LLC
 (http://www.KRvW.com)
 as a free, non-commercial service to the software security community.
 ___




-- 
Jim Manico, Senior Application Security Engineer
[EMAIL PROTECTED] | [EMAIL PROTECTED]
(301) 604-4882 (work)
(808) 652-3805 (cell)

Aspect Security™
Securing your applications at the source
http://www.aspectsecurity.com

---
Management, Developers, Security Professionals ...
... can only result in one thing. BETTER SECURITY.
http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference  
Sept 22nd-25th 2008


___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___


Re: [SC-L] Survey

2008-08-26 Thread Jim Manico
Making a very complex Ajax rich-client web applications perfectly xHTML
valid is not easy. Most of the enterprise world goes way beyond simple
flat file xHTML. Add in (the real reality of) highly database-drive
dynamically generated javascript/ajax heavy pages, and I continue to
conjecture that perfect xHTML is not only not that important but very
difficult to accomplish. Or at least it's not simple as you state below.

Heck, who is to say that you can't accomplish XSS or other client-side
attacks and still be xHTML compliant?

I think you would go a lot further in securing your apps if you got
programmers to html entity encode output data, actually do access
control right, encode data on the server side to prevent injection
attacks, etc.

Sure the WAF world would like xHTML - but we do not live in a perfect
world. Most sites are not xHTML compliant in the enterprise.

- Jim

 At 9:12 AM -1000 8/26/08, Jim Manico wrote:

   
 How does xHTML help stop access control vulnerabilities?
  Authorization issues? CSRF problems?
 

 It is indicative of the caliber of the people who built
 the site.

 My immediate interest is that validation combats browser crashes.

 I am not interested in dealing with people who cannot get
 the simple things right.
   


-- 
Jim Manico, Senior Application Security Engineer
[EMAIL PROTECTED] | [EMAIL PROTECTED]
(301) 604-4882 (work)
(808) 652-3805 (cell)

Aspect Security™
Securing your applications at the source
http://www.aspectsecurity.com

---
Management, Developers, Security Professionals ...
... can only result in one thing. BETTER SECURITY.
http://www.owasp.org/index.php/OWASP_NYC_AppSec_2008_Conference  
Sept 22nd-25th 2008


___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___


Re: [SC-L] Lateral SQL injection paper

2008-04-28 Thread Jim Manico

 Anyone else have a take on this new attack method?

If I use Parameterized queries w/ binding of all variables, I'm 100% 
immune to SQL Injection.


In Java (for Insert/Update/etc) just use PreparedStatement + variable 
binding.


There are similar constructs in all languages.

Although the attack is cool - the defense is still the same.

Grey Box Testing (code review and pen testing) will uncover all SQL 
Injection flaws in even the largest app in very little time.


- Jim



Greetings SC-Lers,

Things have been pretty quiet here on the SC-L list...

I hope everyone saw David Litchfield's recent announcement of a new 
category of SQL attacks.  (Full paper available at 
http://www.databasesecurity.com/dbsec/lateral-sql-injection.pdf)


He refers to this new category as lateral SQL injection attacks.  
It's very different than conventional SQL injection attacks, as well 
as quite a bit more limited.  In the paper, he writes:


Now, whether this becomes exploitable in the normal sense, I 
doubt it... but in very
specific and limited scenarios there may be scope for abuse, for 
example in cursor
snarfing attacks - 
http://www.databasesecurity.com/dbsec/cursor-snarfing.pdf.


In conclusion, even those functions and procedures that don’t take 
user input can be
exploited if SYSDATE is used. The lesson here is always, always 
validate and don’t let
this type of vulnerability get into your code. The second lesson is 
that no longer should
DATE or NUMBER data types be considered as safe and not useful as 
injection vectors:

as this paper has proved, they are. 


It's definitely an interesting read, and anyone doing SQL coding 
should take a close look, IMHO.  It's particularly interesting to see 
how he alters the DATE and NUMBER data types so that they can hold SQL 
injection data.  Yet another demonstration of the importance of doing 
good input validation  -- preferably positive validation.  As long as 
you're doing input validation, I'd think there's probably no need to 
back through your code and audit it for lateral SQL injection vectors.


Anyone else have a take on this new attack method?  (Note that I don't 
normally encourage discussions of specific product vulnerabilities 
here, but most certainly new categories of attacks--and their impacts 
on secure coding practices--are quite welcome.)



Cheers,

Ken

-
Kenneth R. van Wyk
SC-L Moderator

KRvW Associates, LLC
http://www.KRvW.com







___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___
  


___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___


Re: [SC-L] InformIT: budgeting for software security

2008-04-12 Thread Jim Manico
No, there is not a direct connection but Green and InfoSec do have a few 
degrees of connection.


InfoSec - Is a part of - IT - manages - Datacenters - suck up 3% of 
word power - is becoming more expensive -  Green -  Al Gore


  RSA conferences *were *focused on infosec, and on cryptography in 
particular


RSA is a Marketing/Fluff event - As Gary pointed out, there is a 1000-1 
Marketer vs attendee ratio. Case and point: SANS is teaching there now! :D


- Jim


Jim,

In response to Stephen's question, you wrote...

  

What does 'green technology' have to do with infosec?
  
Data centerers worldwide use at least 3% of all global electricity. With 
the growing cost of oil/power - most large corporations are looking for 
ways to reduce power consumption at their data centers. Google is 
building new database centers near cheap power, cheap land, and cheap 
water. Sun has bet the farm on Green issues. IBM and Intel have 
green/sustainability departments as well.


http://www.baselinemag.com/c/a/Infrastructure/Disruptive-Forces-Sun-Microsystems/



Maybe I need someone to connect the dots for me, but IMO, your response
_still_ doesn't adequately answer Stephen's question.

You addressed why 'green technology' is good in general and why businesses
are pursuing it, but not what it has to do w/ information security. Certainly,
if there is a connection here, is is not a direct one.

I don't want to speak for Stephen (but will anyways ;-), but I think it's unfair
to interpret his remark as implying that green technology is bad or some sort
of voodoo. In the context, I think his concern was that in the past, the RSA
conferences were focused on infosec, and on cryptography in particular. 
Apparently,
based on Stephen and gem's comments, it seems to have lost its focus. I think
that's all that was being implied here.

-kevin
---
Kevin W. Wall   Qwest Information Technology, Inc.
[EMAIL PROTECTED]   Phone: 614.215.4788
The reason you have people breaking into your software all 
over the place is because your software sucks...

 -- Former White House cyber-security adviser, Richard Clarke,
at eWeek Security Summit


This communication is the property of Qwest and may contain confidential or
privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful.  If you have received this communication 
in error, please immediately notify the sender by reply e-mail and destroy 
all copies of the communication and any attachments.
  



--
Jim Manico, Senior Application Security Engineer
[EMAIL PROTECTED] | [EMAIL PROTECTED]
(301) 604-4882 (work)
(808) 652-3805 (cell)

Aspect Security™
Securing your applications at the source
http://www.aspectsecurity.com

___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___


Re: [SC-L] Secure Coding Books

2008-03-07 Thread Jim Manico
How to break web software is one of the best web security coder- 
centric books I have read. Its concise and useful.

Sent from my iPhone

On Mar 7, 2008, at 7:45 AM, Lawson, David L  
[EMAIL PROTECTED] wrote:

 I've read several secure coding books in the past, and was wondering  
 if
 anyone has recommendations for secure coding books (preferably from  
 the
 last year or two).

 Thanks,

 David Lawson
 ___
 Secure Coding mailing list (SC-L) SC-L@securecoding.org
 List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
 List charter available at - http://www.securecoding.org/list/charter.php
 SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com 
 )
 as a free, non-commercial service to the software security community.
 ___
___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___


Re: [SC-L] Darkreading: Getting Started

2008-01-10 Thread Jim Manico
Gary,

Interesting article. May I ask, why get started with only one of these 
approaches? Since 1-3 effects different parts of the organization 
(portfolio risk seems like a biz-management approach, top-down framework 
seems to effect software development management, and training effects 
developers, primarily) - why not *start* an initiative on all levels? In 
fact, doesn't it really take all of the above to truly effect permanent 
change in an organization?

4) Makes me nervous. I worry if you just toss a very expensive static 
code analysis or app scanning tool at development staff, you only 
provide a false sense of security since the coverage of even the best 
application security tools is very limited. Doesn't it take rather 
in-depth developer training and awareness for a tool to be truly useful?

- Jim
 hi sc-l,

 One of the biggest hurdles facing software security is the problem of how to 
 get started, especially when faced with an enterprise-level challenge.  My 
 first darkreading column for 2008 is about how to get started in software 
 security.  In the article, I describe four approaches:
 1. the top-down framework;
 2. portfolio risk;
 3. training first; and
 4. leading with a tool.

 We've tried them all with some success at different Cigital customers.

 Are there other ways to get started that have worked for you?

 By the way, I can use your help.  Darkreading is beginning to track reaction 
 to topics more carefully than in the past.  You can help make software 
 security more prominent by reading the article and passing the URL on to 
 others you may find interested.  Another thing that helps is posting to the 
 message boards.  Thanks in advance.

 Here's to even more widespread software security in 2008!

 gem

 company www.cigital.com
 podcast www.cigital.com/silverbullet
 blog www.cigital.com/justiceleague
 book www.swsec.com

 ___
 Secure Coding mailing list (SC-L) SC-L@securecoding.org
 List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
 List charter available at - http://www.securecoding.org/list/charter.php
 SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
 as a free, non-commercial service to the software security community.
 ___



   

-- 

Best Regards,
Jim Manico
[EMAIL PROTECTED]
808.652.3805 (c)


___
Secure Coding mailing list (SC-L) SC-L@securecoding.org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
___