Category: OWASP

  • 2009 – The Year of WebAppSec Solutions

    “He who controls the present, controls the past. He who controls the past, controls the future” – Orwell, 1984

    Looking back at the last few years, we’ve made some huge leaps at swatting at issues that bit us in back in the past, but still have not made a huge fundamental leap to controlling the future, and in particular controlling the risk from VALUE attacks, such as phishing, crime ware, and process issues (aka business logic issues).

    I’ve been interested in process issues for a long time as its the easiest way to get VALUE out of a system. One the earliest web app sec attacks was against CDNOW back in the mid 90’s. They preceded and were bigger than Amazon for a long time. Ultimately, Amazon acquired CDNOW. Why? Apparently, they had a cool front end shopping cart, a payment system and a shipping system. Sure enough, the shipping system took a bunch of hidden fields and accepted a “paid=yes” type of flag. So essentially, you could fill in the hidden fields with the CDs you wanted and skip ahead to the ship bit, and get free stuff. End of story, they’re part of Amazon today instead of the other way around. The opportunity cost of being insecure for CDNOW can be measured in billions and will continue to rise as the years go on. That one attack wasn’t the end of the business, but it set them along the path.

    So why in 2009 we do we allow 1995 era attacks to succeed? Why is this stuff not taught at University? Why are the business folks who make really bad decisions allowed to continue on doing the same old, same old, when they should know – do know – that it’s going to cost them a lot more in the long run?

    So let’s look at the lows and highs of 2008:

    Highlights of 2008:

    • PCI compliance starts to hit merchants. They still suck, but they’re unlike before, they’re now going to have to fix their stuff or go out of business
    • PCI 1.2 updated to OWASP Top 10 2007. Awesome. 
    • OWASP has a huge security summit in Portugal, deciding on future directions, and an awesome set of security conferences around the world. I think we have hit critical mass
    • OWASP Application Security Verification Standard Released

    Low lights of 2008:

    • Phishing and malware links as tracked by APWG rose to its highest level ever. 
    • Massive compromise of credit cards continues – vendors continue to flout PCI regulations and common sense.
    • SQL injection attacks launch a million malware infestations

    This basically means that attackers have been noted by the mainstream media and others as attacking VALUE through web apps, and not assets, like pwnage. They don’t care about the mechanism so much as the money. This has been my view for at least five years. I don’t care about if you control a 100,000 bot fleet – your just desserts are coming soon in your very own dawn raid. I do care if you can steal from 95,000,000 folks or defraud thousands with one e-mail.

    “How’s that working out for you?” – Dr Phil McGraw

    When we do something that is clearly not working, it is beyond time to do something different.

    Back in 2002, I was doing security architecture in web apps for some of my more forward thinking clients. I have a draft book in my OWASP folder on Web App Security Architecture I started in 2003. When I moved to the USA in 2006, security architecture was completely off the average US enterprise architect’s radar. Only today are seeing some traction in this space, and not everywhere. 

    Success stories elsewhere

    With air safety, various safety bureaus review crashes and make binding resolutions on pilots, manufacturers and airlines to remediate design issues and human factors. For example, in many cultures, a strong hierarchal society is the norm. More than a few co-pilots have sat meekly by, refusing to override their captain as they plowed straight into the ground. So the airlines were forced to change the human element in the cockpit, forcing sub-ordinates to take control when the situation warranted it.

    Air safety is a poster child for what can and should be done. From the early days when cowboys ruled the roost and many died, to today when only rail is safer per million passenger miles, air travel is one of the safest transport forms, despite being so inherently dangerous from a physics point of view (speed, height, traffic density, weather conditions, etc). We need to emulate air safety. Web application security is at the point where enforceable regulations are in their early days, like seat belts in cars were 50 years ago. 

    We can and must skip 50 years. I’m not a huge fan of heavy handed regulation as I feel it will stifle the next big thing if done wrong, but I think many languages and frameworks are settling around a few major paradigms. We can help them, and they must help their users. 

    We KNOW how to secure those meta-issues. We MUST secure those meta-issues. So here’s my 2009 Wish List:

    Education

    We have to educate those who come after us. This means getting into every CS and Software Engineering course world wide, and ensuring they have at least one mandatory security architecture / software security subject.

    All applications share exactly one feature: security. I don’t think you can be a sound practitioner unless you have at least heard about this most fundamental of issues. It’s like graduating accountants who have not completed Audit 101. It’s completely ridiculous that there’s no equivalent in most CS and software engineering degrees today. 

    I am also only going to speak at developer and architecture conferences. Speaking at security conferences is awesome and I usually get married or drunk or both, but it really doesn’t advance the state of the art. Architects and developers must get on board, and to do so requires their buy in. 

    Eliminate XSS and SQL injection

    We really need to get some basic technical things off the radar, so in 2010 and beyond we can deal with VALUE attacks. To that end, 2009 should be spent encouraging open source and vendors to fix XSS and SQL injection. We know how to fix these things. OWASP’s ESAPI has the canonicalization, input validation, and output encoding features that every application can use. Every modern framework has prepared statements or a safe(r) mechanism than dynamic statements.

    I encourage the OWASP leadership and those in leadership positions to take a stand on these two items. I call on all framework providers to make the simplest possible output mechanism XSS safe. I call on framework providers to deprecate and eliminate dynamic SQL queries, or at least make serious warnings pop up so that folks know that they should not be using those interfaces. I call on open software reporsitories to stop downloads of packages that have open CVE entries. It’s important to bubble up the importance of safe software, and we can’t do this by wishful thinking.  

    We can do this. It’s not a pipe dream. 

    Security Architecture Is a First Class Citizen

    It’s important to start putting security architecture in its place – which is every bit as important as the shiny buttons folks click or the processes businesses use to get stuff done. We cannot hope to eliminate design issues that allow VALUE attacks unless security architecture fu is strong within every organization writing software today. 

    Although history is written by the victors, we’re a long way from victory. Let’s get cracking!

  • A review of 2008

    Last year, I made the following observations / resolutions. Let’s check out how well I did:

    • Be a good dad to Mackenzie my gorgeous daughter, and a wonderful (hopefully less chubby) hubby to Tanya, my beautiful wife. 

    I think I succeeded at this one

    • Lose some weight and mean it this time. What New Year’s Resolution is complete without this one?

    Although I am lighter (149 kg down from probably ~ 155 to 160 kg), I’m not significantly lighter. I could have been close to 100 kg if I had stuck to an appropriate diabetic friendly diet and exercised more. I blame baby girl. JOKING. I’m a member of the cult again, and I have diary entries for walks and gym, so hopefully this time next year, may be I could be closer to 100 kg than I am today. 

    • Finish at least one piece of first class research in the web app sec field

    Nope. Not even close. Started a few though. And that’s the subject of my next post – what to look forward to in 2009.

  • OWASP EU Summit

    Although I am unable to attend, I hope you can attend the OWASP EU Summit, to be held next week in Portugal.

    There’s going to be lots of discussion about OWASP’s various projects, and work out futures for all of them. It’s going to be a defining event in OWASP’s existence, and I wish I could have been there.

    You can find out more about the summit here:

    http://www.owasp.org/index.php/OWASP_EU_Summit_2008

    I’ve left my run fairly late for the projects I contribute to (the OWASP Guide, Top 10, Coding Standard, etc), which is a shame, but since chairing a session requires some dedication and time, I couldn’t find folks on the ground in time to replace me. There was talk of me presenting remotely via Skype, but I haven’t followed that up, and the calendar looks very full. We’ll see if there’s a way I contribute in other ways.

    I still need fresh victims^H^H^H^H^H volunteers for the OWASP Developer Guide, Top 10 2009, and Coding Standard. Please e-mail me vanderaj @ owasp . org if you can help write a paragraph or two per day.

  • 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.

  • 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.

  • 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.

  • 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.

  • Reaching for the high hanging fruit

    My current research is mainframe security as it applies to web applications. This is where the high hanging fruit (the golden apples) lie. If you can

    a) fake or bypass authentication
    b) fake or bypass authorization
    c) spoof logging or otherwise destroy accountability
    d) interact directly or indirectly with a deeply nested service of value
    e) manipulate data to violate integrity (creation, update or delete)
    f) view data (read)

    you are most likely to pwn the high hanging fruit. It’s actually amazing to me how LITTLE information is available on securing this stuff, and how often products which are marketed as “enterprise ready” and “secure” are actually not worth running a faulty bidet let alone left in charge of multi-trillion dollar a day roles.

    Then there’s the dumb architectures which often use clear text protocols, unauthenticated transfers (often using ftp or worse), batches with no integrity and no accountability controls, and so on. This field is amazing that no one has taken the time to really learn how to do it properly. It is not 1969 any more. The days when the data center was guarded and that’s how the punch cards arrived and the tapes left no longer apply.

    However, there’s a few protocols and common transports which need some help first. I’m going to blog on those in the near term future.