cat slave diary

Blog

  • Coding Standard

    I’m repro-ing this from the OWASP Top 10 mail list. I would like to hear folks’ thoughts about what I have included, taking into account that this is designed to be a standard, and not just a guide.

    The OWASP Top 10 Coding Standard

    I’ve been working on this on and off (mostly off) ever since getting a few comments back in 2005 that the Guide was too big. The big idea is that it’s short and every single item is actionable. If it’s not actionable, it’s not in there. It doesn’t try to fix everything, just the 80-90% of things that really bite folks. Looking through the breach chronology, I think if folks had to stick to this list, they would have been safe, or at least a lot better off.

    My goals are

    * Scalable – works from a single open source developer through to major enterprises through to huge ISVs
    * Applicable – nothing in here is because I wear tin foil underwear, but because it’s essential for a secure app – the omission of that one item will create insecurity
    * Easy to apply for new code – the proper way should be the fastest, easiest way to do it right without causing performance issues
    * Not hard for old code – the controls in here are going to be a stretch for the billions of lines of existing (crap) code. We can’t ask all that millions and millions of lines of COBOL or Java or C# or VBScript or PHP to be secure overnight. It’s not possible.

    To make it scalable, I propose a self-rating system, where single developers and small groups can state up front that they’ve complied with the small group version, with the sole exception of framework authors, who would have to comply with all relevant sections. I’m sick of frameworks being insecure because they can’t be bothered or believe (wrongly) that it’s not their problem. If you’re a framework / library author, such behavior / attitudes are criminally negligent as far as I’m concerned (Jack Slocum – I mean you! http://extjs.com/forum/showthread.php?p=68097#post68097 ). Large ISVs and enterprises have no excuses as they can generally afford this stuff; it’s just as cheap to do it the right way as the wrong way. Just pick those controls that are essential for the risk level and do them.

    My current outline is:

    1. Secure Development Lifecycle Best Practices
    – Discussion about SDLCs and ensure that folks have one
    – Development methodology – mandatory. Just pick one, add security as necessary
    – Code repository – mandatory. I never seen secure code without one
    – Defect tracker – mandatory. I never seen secure code without one
    – Peer review of checkins and break the build check in policy – nice to have
    – SCA tools – nice to have
    – Way to report security bugs – nice to have (although required by some RFCs)

    2. Secure Architecture and Design
    – Apply Security Principles to your design
    – Apply Risk Management to your design
    – Picking and implementing the correct controls for your app
    – Architecture Reference Model for Initiator / Approver / Receiver transactions
    – Architecture Reference Model for privileged CSR, admin features / apps
    – Documentation – mandatory. Secure apps have documentation

    3. Authentication
    – Evidence of identity
    – UML Sequence diagrams for common login and credential management scenarios for two factor, trx signing and SMS authentication
    – UML Sequence diagrams for low value login and credential management scenarios using passwords. This has in-built countermeasures for brute forcing, etc
    – Prohibition against questions and answers (this is how Sarah Palin was attacked. I’ve been railing against them since at least 2004 – see the Guide 2.0 drafts and final text)
    – Prohibition against CAPTCHA if disabled access is required (usually is)

    4. Access Control
    – Create an access control matrix for each secured function and secured resource
    – Deny all by default
    – Principle of Least privilege
    – Fail closed
    – Environment Access Control
    – Controller / Business Logic Access Control
    – Data Access Control
    – Access Reference Maps
    – Presentation Access Control

    5. Validation and Encoding
    – Validate from all sources (trust boundaries, where and how much to validate at that layer)
    – Canocalization
    – Input validation methods (positive validation only, how to validate text fields, fail safe, etc)
    – Output encoding (ESAPI like – encodeForJavaScript, encodeForXml() etc)

    6. Data Protection
    – Define a Collection and Retention of Sensitive Data Policy. Stick to it
    – Protect Data at rest (what to encrypt and where, backups)
    – In transit (SSL, IPsec, etc)

    7. Securely Accessing Services
    – Ajax and JSON
    – REST
    – Web Services (WS-Security)
    – Operating System
    – Databases (use only safe mechanisms, low privilege access)
    – Directories
    – Message queues and reliable messaging mechanisms
    – Mainframes

    8. Accountability
    – Error handling (fail safe / closed, etc)
    – Logging
    – Auditing

    9. Debugging, Testing and Maintenance
    – Do not deploy test or debug code into production
    – How to fix security bugs once and properly
    – How to write security tests for fixes
    – Prohibition against Easter eggs and magic modes

    10. Testing and Assurance
    – How to build up assurance
    – Doing your own security tests every build
    – When to get a SME involved
    – SCA tools – nice to have
    – Dynamic tools and services – nice to have

    Obviously, this is starting to look like the Developer Guide 3.0. I’m not sure that it can be done in any less volume, but we should try, especially as the non-control stuff in the Developer Guide 3.0 is going to the ADSR, the Testing Guide and the Code Review Guide.

    Thoughts?

  • WebScarab For Eclipse

    This lunchtime, I did something I’ll probably later regret: creating a new project. As if I don’t have enough on my plate already.

    The idea has been rattling around my head for a while – I use Eclipse nearly all day, and I figured that Eclipse is a great toolchain hosting platform. It gets rid of some of the issues surrounding the re-platforming of WebScarab Classic features to NG, which seems to have been stalled for a long time, and adds more of its own issues, such as what will I do with other projects I have commitments such as ESAPI for PHP and the OWASP Guide.

    The biggest challenge is the initial muck work of porting software not designed for Eclipse to Eclipse in a reasonable way and not getting side tracked with all the great ideas I’ve got – all of which rely upon the engine and basic functionality to exist prior to even starting them.

    There’s a lot of ideas I want to get into a tool, and so if you’re interested in helping, please call by the Google Code site:

    http://code.google.com/p/owasp-webscarab-eclipse/

  • Black Hat 2008

    Well, I’m back from another year at Black Hat. This time, I taught one of my company’s 2D Web Application Security courses.

    I think I may have been one of the very few courses that concentrated on defense, which is Black Hat’s tongue in cheek slogan (“Digital Self Defense”). I taught the folks in there (about a 50/50 mix of devs and PMs/architects/designers etc) not only “this is a SQL injection” but hey, we have a complete solution for this, and this is how it works.

    The class was originally 15 – 20 in size, but ended up being more than double that. I’m pleased with the outcome and how many folks really liked the course. Hopefully, it will lead BH into more actual digital self defense rather than just claiming that territory whilst promoting offense, offense, offense.

    I met up with a fair number of folks, including Dinis, and all too briefly Jeremiah, RSnake, Arian Evans, the blokes from the NAB (Justin et al), my mate Justin Derry who is now at Fortify, and a bunch of others.

    I took in almost all of the appsec 1.0 / webappsec 2.0, except for the last session of the last day. It was a good conference and well worth the visit this year. There are always a couple of weak talks, including the one from the network pen testers who have cottoned on to 0days involving web apps which I found very amusing because they thought they were so hard core and l33t. Here’s a hint guys: if you can’t get 8-20 0days out of any web app, you’re not doing it right. It’s like whack a mole or stealing candy from a sleeping baby. And authorization attacks are automatable if you have the right tools. The only interesting thing from that talk was an extension of the old file format jumble, where some file formats have headers and some have trailers, and thus you can make a valid file that is both one thing and another. They had a GIF and a JAR. Past precedents include both ELF and Win32 binaries (from back in 2001) in the one binary, the 1×1 pixel image that is also a PHP exploit (my favorite). I’m sure there’s others prior to 2001.

    Anyway, enough ranting for me. I had a good time, and I can hardly complain as I was sponsored there by my employer and thus bore nothing of the real costs of this trip.

  • Had the snip

    Well, I’ve had the snip, which apparently is surprising to most of the folks who know us.

    Both Tanya and I are pretty darn clucky. We want more kids. But there’s this huge issue we can’t get past – Tanya’s health is just not going to get any better any time soon. Her arthritis is looking like it is staying, and her meds to maintain a moderate level of activity are simply incompatible with a pregnancy. We were very lucky with Mackenzie that she wasn’t deformed or brain damaged or dependant. We can’t knowingly do that again to another child as it’s not our life we would be affecting.

    After a couple of close calls recently, where there were two terrible choices – either Tanya going back to Australia with baby girl for nine months of bed rest at her parents and 10-15 hurls a day with the associated forced weight loss, or aborting, which both Tanya and I are against. We had to make a tough decision.

    So here I am.

    It’s not as bad a pain as I thought it would be, but it certainly wasn’t without it’s scary moments.

    I’m not good with needles, and I’m sort of glad I was put under as I don’t think I could have coped with the normal process, which involves a needle to the each site to numb the skin, and then a big needle full of local to each of the testes so you can go home in some comfort before the real pain sets in. I don’t care if you’re brave or not, that’s just one big needle I could not face.

    The biggest problem so far is getting up. You can’t lift more than 15 lbs, which is about 7 kg. Baby girl currently weighs about 10 or so kg, so basically I can’t lift her. I can’t easily lift me either. So getting up and down is a painful experience.

    I’m resting comfortably. After 24 hours, the pain is manageable, and most likely I’ll be completely okay by Monday or Tuesday.

  • OWASP Guide 3.0 and Coding Guide 2009 Start

    I’ve been busy over the weekend.

    I met with Blake Turrentine at a diner near where I live. We had a good long discussion over breakfast on the future of the Guide 3.0.

    The Guide 3.0 will be about how to design apps and code securely. That’s it. Only positive controls will be discussed unless the negative controls rule right now. For example, the Services “Databases” section will contain only the following sub-sections: Best practices (use an extremely low privilege account unique to your app, use an encrypted connection, store the connection credential securely, etc), Active Record / ORM, prepared statements, stored procedures.

    The pattern in each sub-section will most likely be:

    • What to do right
    • Risk level of this control (All, Low, Medium or High risk apps)
    • Why this works (using ESAPI if it’s got something to say about this control)
    • Code snippets doing it right
    • What this prevents (links to the testing or code review guide and any publicly known attacks using this mechanism)

    There will be a “Worst Practices” sub-section containing Dynamic queries, and Stored Procedures Gotchas (discussing string concatenation, calling out to native features, and the use of exec, etc). The idea is that if there’s zero noise on bad controls, you’re more likely to do the right things, particularly if there’s supporting code.

    It should be nice and short, especially in comparison with the 2.0 version as there will be only links to testing or code review material. There’s no point in repeating that material.

    Although pen testing is considered sexy and a little bit naughty by the meejya (and thus “newsworthy” when plainly it is not), coupled those folks who consider themselves hard core l33t haxors get to go to all the nice parties with ladies of negotiable value, I think pen testing is not the best way to deal with crappy paradigms. If you’re still using dynamic queries, you have soooo much work to prove that you’re “safe”, and every few years when a new technique that exploits the root cause comes along, you’re hosed.

    However, if you had spent far less time and money to use one of the three “safe” methods above, you’ll be “safe” for most values of “safe”. We have seen zero mechanisms to attack prepared statements in the last eight years. That’s a very successful control. Therefore, testing for SQL injection is sort of pointless and we can move onto the real golden apples, like direct object references and business logic flaws.

    The Coding Top 10 will be a distilled version of the same material, but by necessity, it will concentrate only on ten items, instead of may be 200-300 items. Neil Smithline has agreed to take a shot at it, so I need to touch base with him this week.

    In both cases, I’m looking for a healthy dose of contributors as there’s no way I could do the amount of out of hours work I put into the OWASP Guide 2.0 again. Tanya would kill me for a start! If you think you can help out, please join the OWASP Guide and Top 10 mail lists, and shout out!

    Please don’t do it because you want to be invited to all the sexy parties and have ze ladies fall at your feet, or to get wealthy on the residuals. I will make this prediction right now: neither document will be feted by the press, and neither document will get much traction at the trendy conferences. Even though they will be the best things to help developers and businesses code properly ever written. Let’s make a start and see how things go.

  • Best. Daughter. Ever.

    We took Mackenzie to the pediatricians today. She did real well – even the vaccinations she only screamed for a few minutes. 

    Here’s a few very recent photos for you!

    • The first image is her sitting. By herself. At 3 and 3/4 months.
    • The second image is her out on the porch wearing her snazzy new sunnies from Rebecca.
    • The third image is her holding her own full bottle and drinking away without that much help. She’s been able to do this for a while, but we’ve not always had the camera to prove it
    For those who follow such things, she’s at the 75% percentile for height (62.5 cm tall or 1.25 rods), at the 95% percentile for weight (7.46 kg or 0.51 slugs), and around 75th percentile for head circumference (41.9 cm or 0.02 chains). 

  • Feelings of Rejection

    In other news, all my talks for OSCON were rejected again. Why did I bother? I should have paid attention my last year’s rant. Most likely, I will have to give up on submitting papers to certain open source developer’s conferences as honestly, why bother doing the work of doing the research, creating the paper and slides only to be rejected? Luckily, two of my submissions were from colleagues, so I didn’t squander a lot of resources on those talks, even though for example, I’m working on porting ESAPI to PHP, which is the subject of one of the rejected talks.

    I’ve identified the following security talks for those security folks still considering going to OSCON (although I’d recommend saving your money for OWASP USA as we already have a schedule of 45 web app sec talks in three tracks, and two full days of tutorials, including several two day courses where you’ve got an actual chance of learning something. Just saying.)

    So five talks and two three hour longer talks. Here it is in graphical format for you:

    microsoft-powerpointscreensnapz001.png

    A couple of the talks are likely to not offer that much in the way of solutions. Sadly, no Ruby, Python, administration, database, emerging topics, or people security talks. Worse, there are no Java security talks, which for an semi-incomplete track, I found sort of astounding, especially as I submitted two Java security talks and one PHP talk. The official “security” track has two three hour talks, both detailed above. Even if you look at it from the point of view of OSCON having 16 tracks, hopefully with equal time for all of the tracks assuming there was a lot of competition for speaking slots, there should be 215/16 = ~ 13.4 security talks, not 7.

    Although I am glad my friends are accepted whilst talking about security, I think OSCON needs a new program committee. This one is broken.

  • Colorado Springs

    I’m currently in Colorado Springs doing some training for a customer.

    The flight in was long – nearly 12 hours all up from the east coast, all told including delays and running to make my little rubber band plane connection. It takes only another 15 hours to make it to Australia. The puddle jumper was funny – as soon as we had finished climbing out of Denver, the hostie announced we had commenced our descent into Colorado Springs.

    It was surprisingly cold. I suppose the wind and snow should have alerted me, but the last time I was here in late August / early September, it was over 30C every day.

    I love coming here. Not only do we have a family friend (Hi Michelle! Hi Justine!) who lives here, the scenery includes Pike’s Peak dusted in snow outside my bedroom window every morning. You just can’t beat that.

    I don’t think I could live here, though. I’m used to fast paced life, and things move at a leisurely pace, commensurate with Colorado Springs’ diminutive size.

  • HttpOnly Update

    Jim asked a great question – what is the current state of the nation for HttpOnly? I’m glad he asked!

    Pass – read/write cookie protection

    • IE 7.0
    • Firefox >= 2.0.0.5
    • Firefox 3.0 beta
    • Camino 1.5.4

    Barely Pass – read only cookie protection

    • IE 6.0
    • Opera 9.50 beta

    Fail – no cookie protection

    • Safari 3.1
    • Firefox < 2.0.0.5
    • Opera 9.2.6 (currently shipping stable version)

    Coverage of HttpOnly Support

    According to my Google Analytics account, 93.6% of browsers support HttpOnly for preventing being read. The worst offender is Apple, with a marketshare of 5.3% on my heavily trafficked site. They have no support whatsoever. In fact, they’ve had a bug outstanding for some time that no one is assigned. BAD APPLE!

    Conclusion

    Most sites do not use cookies for anything other than the session ID. This is best practice. In these instances, there is NO REASON for them to read or write the cookie using JavaScript. Although there are ways around HttpOnly (some work better than others, depending on your browser), it is worthwhile for frameworks and app server vendors to send this tag automatically. Those very few folks who really need to be pwned should have the ability to turn this protection off.

  • ESAPI for PHP is go

    I’m working (slowly) on porting ESAPI to PHP. This will be great!

    So just in case I keep on having a life after hours, Jeff kindly created an ESAPI for PHP project. If you care about PHP security, come help us finish the port. It’s only 3900 lines of code, and I’ve ported like a 1000 of them already.  

    Why ESAPI? 

    Well, it’s a ready to use secure coding package. The ESAPI library is not about avoiding attacks, it’s about software engineering for web app security. ESAPI deliberately targets around 80% of security features of the average application (whatever your application is!) with the reference implementation, and for that 80% it does security 100% right so you don’t have to.

    ESAPI covers nearly the entire OWASP Top 10, and some other issues besides:

    • User object*
    • Authentication* membership management classes – we have coded createUser, and friends, login, logout (with safe session and cookie termination), disable account, generateStrongPassword, automatic password hashing including salts, etc. 
    • Access control*
    • Access Reference Maps* – direct to indirect object reference maps. No longer do you need to jump through hoops to protect primary keys, files and other things that people can trivially tamper. Instead of filename=report.pdf, you can now trivially turn this into filename=4fd8Xz
    • Encrypted configuration*. No more clear text passwords in config.php
    • Encrypted and integrity protected cookies*
    • Encrypted and integrity protected hidden fields*
    • Hard core encoding utilities*, such as HTML, JSON, XML and LDAP encodings that only do whitelisting
    • Easy to use Encryption support … with only access to SHA256 and AES other quality algorithms. No MD5 or DES here.
    • Easy to use strong random number support … no more weak random values
    • Executor* – safely call the operating system
    • Integrated intrusion detection* – security events are automatically generated and logged
    • Integrated Logging* – using log4php by default
    • CSRF token management* 
    • Thresholds* – automatically set rates for certain actions to help prevent brute forcing
    • Validation libraries* that help you do white listing by default 
    • Test suite to prove coverage and test all functionality 

    Things with a star (*) are simply missing from PHP today, which is surprising considering EVERY SINGLE web application MUST have them. This is despite 5698 functions being defined in PHP today.  

    If the PHP core folks want to talk about adopting these in PHP by default, OWASP would be more than happy to donate the code and re-license as appropriate. All PHP applications deserve this level of security.

    So, please feel free to join us.