Re: [SC-L] Announcing LAMN: Legion Against Meaningless certificatioNs
I notice certs like CISSP when hiring. It says the person has a basic understanding of all IS security areas. Nothing more. If someone can't pass the CISSP then I have to wonder why. -Original Message- From: Paco Hope p...@cigital.com To: SC-L@securecoding.org SC-L@securecoding.org Date: Thu, 19 Mar 2009 11:36:45 -0400 Subject: Re: [SC-L] Announcing LAMN: Legion Against Meaningless certificatioNs On 3/18/09 5:29 PM, Jeremy Epstein jeremy.j.epst...@gmail.com wrote: If you don't have a CISSP, CISM, MCSE, or EIEIO - and you're proud of it ...then I'd say you have an overly simplistic view of the world. Anyone who believes that a credential automatically conveys some magical knowledge that you didn't have before is just as overly-simplistic as someone who disparages all credentials equally. It just isn't a black and white world. Paco -- Paco Hope, CISSP, CSSLP Technical Manager, Cigital, Inc http://www.cigital.com/ [http://www.cigital.com/] ? +1.703.585.7868 Software Confidence. Achieved. ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l [http://krvw.com/mailman/listinfo/sc-l] List charter available at - http://www.securecoding.org/list/charter.php [http://www.securecoding.org/list/charter.php] SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com [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] Some Interesting Topics arising from the SANS/CWE Top 25
We are still struggling on simple definitions. I frequently hear names like lack of input filtering and csrf referred to as vulnerabilities when in reality one is an attack vector and the other an attack. You (correctly in my opinion) refer to input validation and encoding as countermeasures. Though I cringe a little with your definition of input as it sounds a little too user-centric. Input can come from any untrusted source which is not limited to a direct person. I find it amazing how encoded data or bound variables are used to stuff data into a datastore and then that same data is considered trusted when being re-used even by the same application. I do agree with your notion that input validation is frequently insufficient as it is often necessary to include problematic characters or combinations of characters to satisfy the business requirements. jt -Original Message- From: Greg Beeley greg.bee...@lightsys.org To: SC-L@securecoding.org Cc: Steven M. Christey co...@linus.mitre.org Date: Tue, 13 Jan 2009 16:41:34 -0800 Subject: Re: [SC-L] Some Interesting Topics arising from the SANS/CWE Top 25 Steve I agree with you on this one. Both input validation and output encoding are countermeasures to the same basic problem -- that some of the parts of your string of data may get treated as control structures instead of just as data. For the purpose of this email I'm using a definition of input validation as sanitizing/restricting data at its entry to a program, and encoding as the generation of any string in any format other than straight binary-safe data. (obviously in many cases you will have a more complex architecture with individual modules/classes also doing their own input validation too). Having both countermeasures in place is a belt-and-suspenders perspective which is healthy. However, input validation is primarily tied to business requirements (what characters are required in the data field), and output encoding is tied to a technical knowledge of the output format being used (whether HTML, SQL, a shell command, CSV data, text for an eval() call, a UTF-8 string, etc.). The only upside to relying primarily on input validation is that it gives a sort of perimeter protection, a firewall of sorts to the data coming in that tends to protect all of the code behind the firewall. But it necessarily is not likely to be a very smart firewall. One big problem to relying primarily on input validation is that input validation can be very far structurally removed from the point that causes the trouble -- the injection/encoding point. In fact, the programmer doing the input processing may have no knowledge of how the data may be encoded later, and in fact the encodings needed may change with time as well. Proper output encoding puts the countermeasure in the same place as the knowledge of the output format, and puts the responsibility where the expertise is. It also makes the code much easier to audit, as you can tell easily that the encoding process isn't vulnerable without having to trace the route of every single encoded data item through the code and back up to its entry point into the program (of course for thorough auditing you'd do that anyhow but for purposes other than just that one encoding point). A second big problem - as mentioned - is that input validation relies on business requirements -- and you can't guarantee that the business requirements won't require you to permit troublesome characters in the data field, as in the example you gave. - Greg Steven M. Christey wrote: For example, is SQL injection strictly an input validation vulnerability, or output sanitization/validation/encoding or whatever you want to call it? In a database, the name O'Reilly may pass your input validation step, but you need to properly quote it before sending messages to the database. And the actual database platform itself has no domain model to validate whether the incoming query is consistent with business logic. My personal thinking, which seems reflected by many web application people, is that many injection issues are related to encoding at their core, and the role of input validation is more defense-in-depth (WITH RESPECT TO INJECTION ONLY). Yet smart people insist that it's still input validation, even when presented with the example I gave. So So what's the perspective difference that's causing the disconnect? ___ 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
Re: [SC-L] Lateral SQL injection paper
If I use Parameterized queries w/ binding of all variables, I'm 100% immune to SQL Injection. Sure. You've protected one app and transferred risk to any other process/app that uses the data. If they use that data to create dynamic sql, then what? jt -Original Message- From: Jim Manico [EMAIL PROTECTED] To: Kenneth Van Wyk [EMAIL PROTECTED] Cc: Secure Coding SC-L@securecoding.org Date: Mon, 28 Apr 2008 15:27:58 -0400 Subject: 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 dont take user input can be exploited if SYSDATE is used. The lesson here is always, always validate and dont 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] Comparing Scanning Tools
Fortify is a company with several products. Which product are you referring to? I've used some of thier products (and think highly of them), but I have not used all of them. What I like most about thier approach is they are trying to address all parts of the life cycle. The IDE plug-in enforces secure development at the point that code is written/changed. The scanner/workbench supports the build and audit processes. Other components work at runtime. Are they perfect? Honestly, I've not seen anything that is ever perfect. Are they good and getting better? I belive so. jt -Original Message- From: McGovern, James F (HTSC, IT) [EMAIL PROTECTED] To: sc-l@securecoding.org Date: Mon, 5 Jun 2006 16:50:17 -0400 Subject: [SC-L] Comparing Scanning Tools The industry analyst take on tools tends to be slightly different than software practitioners at times. Curious if anyone has looked at Fortify and has formed any positive / negative / neutral opinions on this tool and others... *** ** 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 ___ 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
Re: [SC-L] certification for engineers/developers?
Depending on the specific certification, some do have benefits. Depending on the degree, some do have benefits. Neither guarantees that an individual can play a good game, only that they can talk a good game. If the job requires talking a good game then degrees and certs are great. I've met way too many that can only talk a good game and that is just as prevalent (maybe more so) with degrees than with certs. Having certs/degrees can get you a level of respect when dealing with people that don't know you. Is that fair? That is really irrelevant as that is just how the world works right now. I've met plenty of CISSPs that don't know what a hashing algorithm is or why you would use that over a reversible algorithm. I've met college grads that can explain how a compiler works, but cannot get a fairly simple business application even close to working as needed. Bottom line. When interviewing, I could care less if they have a degree or are certified. I ask questions that require thought, understanding, and longer explanations. It allows them to demonstrate their understanding of the topic and proof of their resume. Ask to see some of thier coding and to explain how it works and why they made some of the choices that they did. Given certifications, degrees, or experience, I'll take experience every time. jt -Original Message- Yeah, I give certifications weight; *negative* weight. The more certifications someone advertises, the *less* clueful I assume that they are. All other factors being equal, that is; I certainly know people who have both certs and clue, but I find that is the exception, not the rule. Advanced degrees are another matter: P.S. I am totally serious about the certificates, they go to the *bottom* of my resume pile.
