cat slave diary

ESAPI for PHP is go

Written by

Andrew van der Stock

in

, ,

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.

Comments

5 responses to “ESAPI for PHP is go”

  1. Laura Thomson Avatar
    Laura Thomson

    Hey Andrew,

    This is a great idea, but I have to nitpick a few things in your post and I have a few questions.

    You quote “5698 functions being defined in PHP today” – that’s what’s in the manual on the website, but the vast majority of those are included in extensions, and are not part of the core of PHP and hence not “in PHP by default”. The general direction is to have *less* of this stuff in by default.

    Most of the stuff you have above strikes me as framework level code rather than core language level code at least in terms of the PHP philosophy, which means that an extension or framework (by which I mean a set of PHP classes) is the right way to do it. I assume your ESAPI port is pure PHP, in which case it wouldn’t be included in those PHP functions anyway (all written in C).

    Anyhow, I quibble.

    A few questions:
    1. A number of these features are already implemented in various places (for example, the hash extension, enabled by default, includes SHA256 etc, user objects and auth management in every PHP framework) – do you have any comments on those approaches/ implementations? What if anything are you reusing/building on?

    2. Wouldn’t at least some of this stuff be better implemented as an extension (crypto, random numbers)?

    3. What’s the licensing?

    4. How would people sign up to contribute?

    Cheers

    Laura

  2. Laura Thomson Avatar
    Laura Thomson

    PS The name confused me. I clicked through wondering if this was something like ISAPI or NSAPI 😉

  3. vanderaj Avatar
    vanderaj

    Laura,

    Good points all.

    I know many of the API are not always available or compiled in by default. However, after so many years and after so many thousand API’s, why do none of them provide core application services such as authentication, access control, strong data validation, structured logging, and so on? These are not optional for any application of any size.

    I have been on the end of “Hey, PHP is a language not a framework”, but PHP the language has only 72 reserved statements (as of PHP 6), and a bunch of syntactic sugar like all languages.

    Every single PHP app has a unique authentication mechanism, a unique access control mechanism (if it exists), a unique validation approach, a unique logging mechanism (if it exists), … the list goes on. A dev on a Code Ignitor project has just as much ramp up time to learn about ZF or CakePHP as a newbie to PHP. Coding projects for PHP is hampered by unnecessary duplication of effort. In UltimaBB, the code amounts to 4500 lines of support structure, that I really shouldn’t have needed to write. More to the point, I only found out the other day that it allowed guests to post as a user if they supplied a bad password (really!). That bug has existed for nearly six years.

    In the .NET world, the vast majority of apps use the .NET standard approach to these issues. A developer moving from one product to another will be immediately familiar with the way the new app works for authentication, authorization, input validation, and so on. Same with J2EE, which although a bit more lassez faire, still only has a handful of approaches, most of which are very similar.

    However, ranting is not why I am doing ESAPI for PHP. I’m here to help.

    1. A number of these features are already implemented in various places (for example, the hash extension, enabled by default, includes SHA256 etc, user objects and auth management in every PHP framework) – do you have any comments on those approaches/ implementations? What if anything are you reusing/building on?

    My goal is to leverage native PHP objects, classes, exceptions, SPL, and built in functions as much as possible. The idea is to provide a work-alike ESAPI amongst all platforms, but under the hood, we use the best possible coding approach for the underlying platform. I am aiming to have no dependencies with a default PHP 5.2.x compile, and to work out of the box on Fedora Core 8, XAMPP, and FreeBSD. That way, I can be assured ESAPI for PHP will run on pretty much any hoster’s *AMP stack.

    ESAPI started life as a J2EE helper, and in some cases, doing what is simple in PHP (session ID regeneration, or crypto) is actually much more difficult than it needs to be for J2EE, and vice versa. I am porting all the ESAPI classes not because PHP needs them, but for completeness. Sort of like why PHP has sprintf() when it has a native and faster way of doing that. The PHP version of ESAPI will be simpler in some cases than the J2EE version. However, where J2EE’s User object is literally setters and getters for the most part, there will be a lot more code for the PHP version as there’s no intrinsic support for the idea of users, access control, etc.

    Win some, lose some.

    2. Wouldn’t at least some of this stuff be better implemented as an extension (crypto, random numbers)?

    Actually, looking through what PHP 5.2 has available by default, I don’t think we’ll need to do that. The only thing that we would have liked is a way to do J2EE filters, but I think I have a solution for that, too, and again it comes from the way PHP works rather than trying to port a foreign idea to a platform that doesn’t need it.

    3. What’s the licensing?

    Currently LGPL, but I’m sure we can negotiate! 🙂

    4. How would people sign up to contribute?

    I’d suggest joining the ESAPI mail list:

    https://lists.owasp.org/mailman/listinfo/owasp-esapi

    and talk over what they have in mind. There’s lots of things we *could* do in ESAPI, but Jeff has deliberately shied away from doing more than about 80% of the stuff you’d find in the OWASP Guide 3.0. We don’t want to be a kitchen sink that kills performance or changes the way your code works today (other than ripping out old / bad code and using ESAPI instead).

    We use Google Code with SVN. Anyone can check out the source anonymously. I’m sure active contributors will get check in privileges.

  4. onelittlewindow » Blog Archive » OWASP Enterprise Security API

    […] Jeff said that there is a .net implementation that is underway and near completion, and there is a php implementation that is just being begun, but is being headed by Andrew van der Stock (also of OWASP fame), and Andrew is putting a lot of […]

  5. Andy Avatar
    Andy

    Hi Andrew,

    Great work with ESAPI!

    Something to add though. In my opinion, I think ESAPI is doing too much. It should just simply be classes to aid existing framework with validation and encoding and that’s it.

    I can’t really figure out the naming conventions. Folder named Reference, Codec, etc is not self explanatory at all.

    Clear documentation on how to actually use/load the classes should be added at this stage.

    Anyway hope this project can mature soon. 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *

More posts