cat slave diary

Category: OWASP

  • OWASP Development Guide – what do you want in, and what do you want out?

    It’s time to do some curating of the OWASP Developer Guide. This is where my tastes meet the community’s – what do you want in the Guide, and what do you want out of the guide?

    As much as I want to be comprehensive, there is a real risk that a 800 page book would never be read. There ARE easter eggs in the Guide that no one has found or bothered to e-mail me about yet, so I know it’s not being read widely.

    I want to ensure the Guide is used, in a way that the OWASP Top 10 and ESAPI are used daily throughout our industry.

    • What would you like to see IN the Guide? Why?
    • What would you like to see OUT of the Guide? Why?

    Let me know by June. I’ll be sure to share your thoughts with the Developer Guide mail list.

  • OWASP Guide 2013 Development

    It’s been nearly seven years since I finished the herculean effort of holding down a day job and leading, editing or excising the existing material, cat herding all the collaborators, and writing a goodly portion of the OWASP Developer Guide 2.0.

    I finished PDFing 2.0 around 4.30 am and pushing it to the OWASP website. I was rush packing for BlackHat as my plane was due to depart at 11 am. I checked my mail as I was shutting down my home lab, and got a last minute set of edits from Michael Howard on the crypto chapter (which is definitely not my strong suit). So I fired up Word again, made the changes, and issued 2.0.1 in Word and PDF format pretty much just as I had to walk out the door to catch the plane.

    That was the last time the Guide was formally issued.

    It’s time to pick up the whip, and dip the pen in the inkwell (well, TextMate this time – we are working in Wiki format at Google Code).

    I plan to write at least one blog entry a week to describe how we are going. I am determined this time to not write > 80% of the content. I simply don’t have the time, and honestly, if we’re going to do this before 2.0 can vote, I really need helpers.

    The first steps have been put into place:

    • Put out a mail to the Guide mail list asking if I can take over
    • Got a bunch of public and private e-mails saying yes, plus most pleasing to me of all – offers of help!
    • Got an e-mail from Vishal Garg, the previous leader – 1, saying that he had actually stood down last year (!)
    • Got an e-mail from Abraham Kang, the previous leader, saying that he would be happy to co-lead with me (awesome!)
    • Asked the Global Projects Committee to assign the project to me, along with a PM. I’ve not heard back from them, but at this stage, I’m happy to do first, apologise later.

    Current status

    I’ve been reading the current materials out of the SVN repo. Oh wow. So much work to do. My plan is to use a few hours each day to write a precis of what I have in mind for each section, and then farm out the work to all those who volunteered.

    I have to make a few basic executive decisions. These help get the project re-oriented in the right way, so as to encourage lateral thinking about some of the hardest topics in our industry. I need the Guide to lead the charge against group think that XSS or SQL injection is insolvable, or that (weak) passwords will be with us forever. Other decisions are just necessary for logistical reasons. I will try to make as few unilateral decisions as possible.

    First executive decision: We cannot possibly know what will be the new hotness.

    Developers are a creative and fickle bunch. Business would love us to code everything in COBOL or VB … or Java, but that’s not how the game is played. Freaking awesome developers (the taste makers) choose new and interesting things to them at least once or twice a year or more. A pool of talent builds behind the cooler / better marketed languages / frameworks. Not knowing what will be the next new hotness is my only real assumption whilst we develop the new version of the Guide. 

    During Guide 2.0 development, classic ASP was winning the battle over ASP.NET, PHP was very popular and very insecure, and J2EE was just starting the process of moving from Struts 1.x to Spring, modulo a dead end or two (JSR-168 comes to mind). Ruby on Rails was a brand new plaything with a few fervent supporters. How times have changed.

    What hasn’t changed are the underlying principles of web application security. I don’t care if you are writing in technologies like Ajax, GWT, Ruby on Rails, Haskell, or you’ve moved to a web flow type model – we know what works and what doesn’t, and to a large extent, it’s in the existing Guide 2.0.

    So I want to move the Guide up a level to be a hybrid architecture / detailed design guide, rather than an implementation guide, a set of repeatable architectural / design patterns that are easily adaptable and applicable cross-language, cross-framework, and be aware of new fads that come and go without knowing exactly what they are.

    Second Executive Decision: Diagrams must not suck

    The Guide has always needed a lot more diagrams than it has. The diagrams I drew back in 2004 and 2005 … suck. I have the originals here, but honestly, I don’t feel we should re-use them.

    I will be approaching the Projects committee to find us a good graphic designer to give a cohesive design language for us to do the diagrams in, or simply farm out our hand drawn diagrams to someone who can do them all in the one style in a way that looks good in the Wiki, Word, iPad and PDF versions of the Guide.

    In the meantime, I will hand draw and photograph the diagrams I have in mind and include them in the wiki as markup. That way, we’re not spending hours in a diagramming tool when we really need to be writing at this stage.

    Third executive decision: Distributed computing

    In 2005, the problem of race conditions in web apps was only really in J2EE web apps that did the very wrong but very arcane things. I had planned for 2.0 (and then 2.1) to include a distributed computing chapter that discussed race conditions, but it’s time to include a detailed discussion on asynchronous, distributed computing: i.e. cloud computing.

    Not only do we need to take into account the many threads / cores of a typical processor today, thus meaning that any server worth its salt will have multi-threading issues, there are parallel languages (F# with the parallel extensions to .NET, and Go for two), and there is Ajax and all the multitude of frameworks that support asynchrony. I don’t want to forget the oldest of them all – batch and background processes that can still produce surprising results.

    So its time to bring this bunch of issues to the forefront, because the cloud genie is out of the bottle, Ajax is well and truly plastered all over the Internet, and if there’s ever a new single core CPU running a new single threaded OS ever again, I’d be immensely surprised.

    Where to from here?

    It’s time to gather the offers for support and start to build a road map, and build consensus on where we should be going. In my view, we need to and indeed must lead the industry by at least two-three years to be relevant on day one of our launch. 2.0 was ahead of its time, but only just, and in the last seven years, my lack of foresight / bravery in targeting the absolutely crazy bleeding edge meant irrelevance by 2008 at the latest.

    If you want to help, please join the mail list and please offer your services. It’s time to get OWASP Developer Guide 2013 going again.

  • Security trends for 2012

    1. Folks will continue to use abc123 as their password. They will then be surprised when they’re completely pwned.
    2. Folks will continue to not patch their apps and operating systems. They will then be surprised when they’re completely pwned.
    3. Folks will continue to use apps as administrator or god like privileges. They will then be surprised when they’re completely pwned.
    4. Folks will continue to click shit. They will then be surprised when they’re completely pwned.
    5. van der Stock’s immutable law of gullibility: Folks will continue to be sucked in by incredibly basic scams. They will then be surprised when they’re completely pwned.
    6. Folks despite extensive and continuous evidence to the contrary for over 25 years, will continue to be sucked in by grandiose vendor claims (“buy X now, and you’ll be protected from X…”) in the unfounded belief that technological solutions can fix people problems. They will then be surprised when they’re completely pwned.
    7. Folks will continue to allow mobile and web apps to transmit their sensitive crap without any form transport layer encryption. They will then be surprised when they’re completely pwned.
    8. Folks will turn on a firewall and think they’re safe. They will then be surprised when they’re completely pwned. It’s not 1995 any more. Never was.
    9. Folks will continue to run old crap, or allow old crap to connect to them. They will then be surprised when they’re completely pwned.
    10. Folks will continue to think that they will be safe if they just virtualize or cloud enable their crappy apps. They will then be surprised when they’re completely pwned.
    If we can’t learn from our most basic of basic mistakes, 2012 will be exactly like 1989 – 2011. And that’s sad.
    Because I hate solution free hand waving posts like the above, here are some basic solutions:
    • Adopt strong authentication TODAY – passwords have NEVER been appropriate.
    • Patch your crap.
    • Implement low privilege users and service accounts.
    • Don’t click shit.
    • Learn about basic phishing and scams.
    • Fire folks who post on Twitter or Facebook all day. You know who they are.
    • Don’t buy any product marked “Protects against APT”. If you do, fire yourself as you’re an idiot.
    • Only use products that use SSL. If you don’t know, assume it doesn’t and find something that does.
    • Evaluate your security needs with 2012 in mind – firewalls alone are a few sheep short of a full paddock.
    • Upgrade to the latest OS and apps. Not only will your users love you, it’ll be harder to attack you.
    • Protect data assets no matter where they are. The plumbing is unimportant.

  • On APT

    Recently, RSA was attacked by adversaries who targeted their two factor authentication fobs.

    These devices have known MITM issues, but folks still used them because there was so little information out there to say that a better choice is required. RSA liked it that way.

    RSA chose not to discuss the details of the attack, using the old furphy that disclosure will damage their customers (reality: it would damage RSA’s brand). RSA’s silence allowed

    Advanced

    Persistent

    Threats

    to execute the boldest cryptographic information warfare attack since Enigma.

    RSA’s (IMHO) cowardly silence has actually damaged their customers in highly spectacular fashion. RSA told us nothing, so we couldn’t ask our clients to change vendors in a staged way, or to disable access, or put in other controls. We could guess, but business decisions are not made that way.

    Now the brand damage to RSA will truly begin. This is the end of the simple RSA fob. Even if a better algoritm or fob is used, RSA are toast as no one will trust them any more, particularly in the sort of organizations that buy fobs by the palette.

    APT boosters have said vociferously – “see, it was APT!”. Yep, I agree. It’s one of the few times that truly worthy attacks are out in the open enough for us to get a small glimpse into what’s really going on.

    Unfortunately, due to widespread abuse of the term, APT is the laughing stock of the information security world. The folks who routinely use it with knowledge can’t discuss why APT is any different to the other threats out there today. Everyone else has no clue.

    I’ve seen CSOs give up, thinking that since these attackers are so advanced, surely we can’t protect against them, or they buy stuff marked “Solves APT TODAY!1!” when in fact, hard work is required. Nothing very hard, just simple stuff like input validating every field and not tolerating insecure software any more.

    But for your average CSO, finding out if an application was developed in a secure fashion and that every parameter is validated is impossible. It shouldn’t be. But that’s not the main point of today’s post.

    It’s moderately clear in the fog of active disinformation that the weaknesses used in the RSA, Sony, and PBS hacks are well known and easily exploitable. The solution is like losing weight. There is a simple solution that works – albeit slowly. It’s called eating the right amounts of good food for a year or two and exercising hard every day. Anyone who has tried to lose weight, including myself, knows that we really just want an APT strength diet pill.

    I think most of us in our industry will acknowledge that penetration testing has become “different” over the last few years, from literally shooting fish in a barell with the most rudimentary or no tools, to requiring a fair bit of work, and moving up the value chain to find interesting and exploitable issues the business cares about.

    In terms of results, I think we’re still finding 10-20 things wrong in every app. Attackers need one. This is the attacker’s advantage. The number of weaknesses, the type of weaknesses, and the severity of the weaknesses are NOT “advanced” in any way shape or form in 95%+ of the code reviews and penetration tests I perform. The other 5% have been working with me for a while, are mature risk managers, and they’re hard to attack as a result.

    But because of the hard core mystique surrounding the use of the term “APT”, we’re seeing completely inappropriate uses of the term everywhere from anti-virus scanners through to security appliances that promise data loss protection but forget that the information security triangle is people-process-technology. Putting one in place doesn’t solve the other two, nor negate your responsiblities to put in appropriate controls that PEOPLE can live with to do their JOBS and make the business MONEY.

    My twitter icon is the famous drive around control image:

    Access controls are only for those with easy access
    Access controls are only for those with easy access

    This is where folks promoting APT fail. I am not denying that the attackers who have found a end run around a widely known security control are

    Advanced

    Persistent

    Threats

    Anyone who targeted a particular firm, and utterly broke a long standing crypto system, and everything else required to obviate hardened controls of at least two military industrial giants are worthy of the term APT.

    Unfortunately, APT as a term is so brand damaged in the info sec community (try saying it at a public event without being openly laughed at), that we have to choose a better one, one that marketers would never dream of using inappropriately. I don’t know what it is, but surely

    Enemy Combatent

    or

    Soon To Be A Small Pile Of Glowing Ash (STBASPOGA, or the more friendly sounding Strasbourg)

    are right up there.

    Worse still, the fact that these Strasbourgs really are APTs doesn’t mean that we should forget to do the hard work, but instead demonstrates the paucity of protective information security research. Some of you might remember me saying a year or two ago that too much attention is paid to those who hack, and not enough on those who defend. Strasbourgs should mean more dollars in pro-active research. We need to make it difficult to develop insecure software. We should make easy to determine if Acme’s latest release of their widgets are insecure. We should have metrics that easily demonstrate insecure software costs more. We should make it legally untenable to ship insecure software, and give redress to consumers when their investments, privacy and intellectual property are violated due to stupid, simple weaknesses that we knew about in 1965.

  • Upcoming speaking engagements – AusCERT and iTSMF

    I am scheduled to talk or give tutorials at a couple of places so far this year.

    AusCERT

    I am giving a two day Secure Coding tutorial using OWASP’s Application Security Verification Standard.

    This course is different to most security training courses you’ll ever take. It teaches architects, lead developers and developers how to design and code in a positive fashion. You’ll learn of about 80 controls over the two days, and complete four hands on labs and a bunch of demos. Of course, you’ll see me demonstrate ninja levels of breaking crappy applications, but my primary goal is for you to build secure software.

    Now that you want to come, you should bring your laptop with the ability to run a 64 bit VMware VM. As the VM is Linux, it could be converted to KVM, Xen, Parallels, or Virtual Box. You can take the VM home along with the slides and learn even more later.

    This is the cheapest method of getting instructor led training by me. Registration here. There’s about 10 spots left as far as I’m aware.

    itSMF

    Later in the year, I am giving my well received talk at itSMF, an ITIL aligned operations conference, on how to make your security dollars work harder for you. This talk is aimed at CIO, CISO’s, and those who are tasked at securing their stuff with ever less budget, or ever more capability (or both).

  • OWASP Podcast 82 – Authorship of OWASP Top 10 2007

    Dave Wichers* appears in the latest OWASP Podcast (go get it!). In the podcast, he goes through the huge number of OWASP projects he’s been involved in. There’s no doubt Dave’s massive investment in time, intellectual property, and money have been instrumental to OWASP’s success. Without Jeff and Dave’s leadership and contributions, OWASP would be a far poorer place.

    But…. the problem starts when he goes through attribution for the OWASP Top 10, starting around the 17 minute mark. Dave says “Jeff Williams and I basically wrote it” (17:10 onwards), and had various people in OWASP review it such as Dinis Cruz and myself. This is exactly what happened for the 2004 version. But the way it was said implies that the OWASP Top 10 2007 was Dave and Jeff’s and I reviewed that too. I’m sure Dave didn’t mean to miss out on appropriate attributions (he’s a straight up and down sort of guy), but just in case anyone thinks like I did when listening to the podcast, I’d like to set the story straight:

    The OWASP Top 10 2004 was Jeff and Dave’s. Absolutely agree with this. I’m pretty sure I reviewed it as I was working on the Developer Guide 2.0 at the time.

    The OWASP Top 2010 is primarily Jeff and Dave’s efforts. No problems. I gave up leadership in the project sometime in 2008 when I had to concentrate on personal matters. At that time, I had no draft or made any effort to update the text. Dave’s effort to restart the project didn’t start until after I’d left Aspect. After the draft PPTX was complete, I reviewed drafts of the release candidates, along with about another 30 or so folks.

    The OWASP Top 10 2007 is primarily mine in methodology (strict adherence to MITRE statistics in 2006), research and development, authorship, editing and leadership. For example, I sat down with Raoul Endres in a pho restaurant in a wintery day Melbourne, Australia well before I moved to the USA and worked out the methodology. I delivered a draft to about 30 folks in early January of 2007. Jeff Williams and Dave re-wrote and included a few items that I disagreed with (effectively two crypto sections that were not representative in the statistics), and dropped important issues that I felt strongly about. You don’t win them all, but I would have loved for these findings to have made it.

    Some of the sections I wrote up in the draft that missed out in the final version:

    • A7 – Malformed input (dropped – a bad call in my opinion as nearly all flaws are due to insufficient input validation and output encoding)
    • A8 – Broken authorization (dropped – a bad call in my opinion, as most of the easily discovered business logic flaws are authorization related)
    • A9 – Insecure cryptography and communications (became A8 – A9 in the final version)
    • A10 – Privilege escalation (dropped – a bad call in my opinion, as attackers try to do this all the time)

    You can see an early draft here. DO NOT USE THIS VERSION – IT’S NOT OFFICIAL!

    I strongly disagreed with the dropping of RFI as it’s one of the biggest reasons that PHP sites are taken over, and PHP is by far the most prevalent server platform. RFI belongs in the OWASP Top 10 probably as the #1 item in the Security Configuration section. There are still millions of sites with this particular flaw.

    Call me hypersensitive to the way Dave phrased just one sentence in 45 minutes, but I want folks to realize that I didn’t dedicate many nights and weekends to the OWASP Top 10 2007 to have that taken away from me in glossing over of efforts. I also want to make sure that folks understand that I consider Jeff and Dave friends and utterly respect their long time efforts with OWASP.

    * Full disclosure – I worked for Aspect Security between December 2006 and January 2009. Dave and Jeff are founders of Aspect Security and thus my employer during the latter stages of Top 10 2007 gestation. I had a great time at Aspect, worked with amazing customers on cool projects, and have very fond memories of the USA.

  • Need a secure code review? We have slots available

    I don’t normally pimp my employer, but I’d rather be doing secure code reviews than pen tests any day of the week. 🙂

    We have open slots in our schedule for secure code reviews starting from mid March 2011.

    We perform our code reviews against the OWASP Application Security Verification Standard

    • Level 2B – Automated Review using Fortify 360 coupled with a manual verification of 83 items (Architecture, Authentication, Authorization, Session Management, Data Protection, Cryptography, etc)
    • Level 3 – Includes all of the above, but 110 inspection points. The sweet spot of our reviews in my personal opinion.
    • Level 4 – Includes all of the above, plus manual inspection for trojans, backdoors, etc.

    These reviews help folks wishing to comply with PCI DSS or PCI PA DSS, or just wish to know that their websites are safe and secure.

    If you’d like to discuss things further, please e-mail avanderstock (at) purehacking.com.

  • Take Two on Top 10 2010 Security Defenses

    A little while ago, I was thoroughly sick of the usual attack attack attack gumpf, and decided to put up a competition for Top 10 defenses.

    Epic fail.

    Looking back at it, attacking the attackers is not a winning strategy. It’s a fact of human nature that it’s better to be a hot firefighter putting out a fire that costs a million bucks to put right than to be the materials engineer who designs cheap fireproof cladding. I’m burying the hatchet as I burnt a fair bit of goodwill in my original announcement, which not my intention at all. We still need folks to break stuff and disprove snake oil, so there’s a place for the dark side whether I agree with the focus on the dark side or not.

    Just two nominations made Andrew sad despite the worthiness of the submissions.

    1. Rob Lewis nominated Trustifier http://trustifier.com/ryu/features.html
    2. I nominated Josh Zlatin, a colleague for the work he has done on PureWAF, extensions for the OWASP Core Rule Set + Mod Security. You can see the results of PureWAF on Pure Hacking’s website, which is behind our WAF in the cloud service. That’s not an invitation to attack us, just sayin’

    Please discuss or vote in the comments section for who you think should get the non-existant gong.

    The Sorta Inaugural 2011 Pure Hacking Top Web App Sec Defenses Competition

    There’s a couple of changes. Pure Hacking will be sponsoring the competition in 2011. There will be categories, such as Life Time Achievement, Best Security Architecture, Best Left Field Idea, Best Secure Business Idea, Best Quick and Dirty Defense, Best Educator, and of course Best Defense. I will detail more about the categories as time goes on. I will be getting inappropriate statuettes made with engraving and everything. If you feel like you can donate something to boost the booty, contact me.

    As for nominations, I will keep a running tally of awesomeness from my RSS feeds and other sources. You can nominate your favorite folks and defenses by e-mailing me – vanderaj ( at ) owasp.org. Come December 1, 2011, I’ll put them up for voting at which time I will disclose the prizes.

    So far –

    1. OWASP’s XSS roundtable at the OWASP Summit in Portugal is a worthy nominee. Let’s stamp out XSS.

    2. I think Gunnar Peterson should get a Lifetime Prize just for being Gunnar. If more of us thought like Gunnar, the world would be a safer place and folks would be making a LOT more money than they do today.

    Please keep this competition in mind throughout 2011.

  • Security checklists are not bad, it’s how they’re used

    There’s a meme that’s been running around the anti-PCI DSS crowd for a while, that’s starting to get good traction in otherwise sane infosec folks:

    • (Paraphrasing) Checklists don’t work

    Actually, PCI DSS is making in-roads in containing data breaches. See for yourself.

    So what’s the big deal?

    Those who know me, know several things:

    • I wrote the OWASP Developer Guide 2.0, the grand daddy of security advice.
    • I was primary author of OWASP Top 10 2007, which is in PCI DSS 1.1 and later.

    Thus you’d expect me to defend checklists. And I will, but not in the way you’d expect.

    I rail against checkbox / “pass a test” thinking. If you’ve taken a training course by me, you’ll know that I’ll tell you don’t collect ANY logs unless you’re going to do something useful with them. I tell you to use security as a competitive advantage – e.g. raise transaction limits by reducing your risk exposure. I tell you to align application security with enabling secure business. Security is not a speed hump. Security is not brakes on a car. Security is the mind set, knowledge and activities that allows you to do things you can NEVER do without security.

    So where do I think checkboxes have a place? For trained professionals. Pilots have extensive checklists. They work – flying is THE safest form of transport, despite working against a few very ouchy laws of physics.

    We (and in particular, I) have created checklists that work. We know that SQL injection is a problem. Don’t include it – it’s negligence to do so. It’s #1 job in the Top 10 2010. We know that XSS and input validation / output encoding is a problem. Don’t include it – it’s negligence. It’s #2 on the Top 10 2010.

    My mind was made up a few years ago, shortly after I finished the Developer Guide that it’s insufficient to engage with info sec teams. We must fix the frameworks. Make it hard to do SQL injection or XSS by default.

    We must engage with the business and raise their expectations from “okay, I gotta set fire to $10k for a review, where do I sign?” to being a trusted business partner, enabling them to do amazing things that are simply unimaginable a few years ago, but safely. Security enables secure business. Any consultant, any info sec person who forgets this, forgets who pays their bills.

    This is not to say that I want you to do ONLY the things in whatever checklist you decide on. I included this text in the Top 10 2007, and it stands true today:

    The primary aim of the OWASP Top 10 is to educate developers, designers, architects and organizations about the consequences of the most common web application security vulnerabilities. The Top 10 provides basic methods to protect against these vulnerabilities – a great start to your secure coding security program.
    Security is not a one-time event. It is insufficient to secure your code just once. By 2008, this Top 10 will have changed, and without changing a line of your application’s code, you may be vulnerable. Please review the advice in Where to go from here for more information.
    A secure coding initiative must deal with all stages of a program’s lifecycle. Secure web applications are only possible when a secure SDLC is used. Secure programs are secure by design, during development, and by default. There are at least 300 issues that affect the overall security of a web application. These 300+ issues are detailed in the OWASP Guide, which is essential reading for anyone developing web applications today.
    This document is first and foremost an education piece, not a standard. Please do not adopt this document as a policy or standard without talking to us first! If you need a secure coding policy or standard, OWASP has secure coding policies and standards projects in progress. Please consider joining or financially assisting with these efforts.

    Think outside of the box. Create high technology business enablers that your competitors think are indistinguishable from magic. But whatever you do, don’t give the checklist to an unqualified person. That’s simply not their point.

    p.s Stop bitching about PCI DSS. It’s an unqualified success at what it set out to do.

  • Passwords are neither free nor cheap

    I don’t know how many clients over the last decade I’ve been trying to get this basic fact through their very thick business skulls, but here goes again:

    PASSWORDS ARE NOT FREE
    PASSWORDS ARE NOT CHEAP
    PASSWORDS ARE NOT SAFE
    PASSWORDS ARE NOT ACCEPTABLE FOR HIGH VALUE DATA / APPLICATIONS. EVER.

    Vodaphone has found this out to their immense cost and on going public relations disaster.

    By changing the faulty business decision (passwords) every 24 hours, VHA are sticking their finger in the leaky dyke. They sell mobile phones. They could step up to two factor / transaction signing with mobiles for CHEAPER than passwords. Especially for them. This is an opportunity for VHA to say – look we’re leveraging our unique selling point (mobile phone operator) to provide world class security. Instead, they choose passwords.

    Stop using passwords. Their time was done more than 10 years ago, if ever.