Re: [SC-L] OWASP Podcast 95 is live!
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!
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
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
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
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
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
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
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
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
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
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
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
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?
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
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
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
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!
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
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)
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!
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!
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
(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
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
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.
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
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
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
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
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
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
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)
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)
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)
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
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
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] FW: How Can You Tell It Is Written Securely?
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?
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
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
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
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
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
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
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
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. ___
