Category Archives: PHP

ESAPI for PHP – first tests passed

I’ve been working on the essentials for OWASP ESAPI, and now it passes its first set of unit tests, in this case a 1:1 mapping of the ESAPI exceptions test class.
PHP ESAPI Exception Test Suite pass

This is the first set of classes that fully passes a set of tests that is exactly equivalent to the J2EE trunk SVN. Yes, it’s one test, but it tests the exceptions thrown by every single one of the Exception classes.

This is key as ESAPI throws a lot of ESAPI exceptions when things go south. In addition to ESAPI exceptions, the PHP port will also throw SPL exceptions, such as InvalidArgument and so on as it makes sense to do so.

To get this far, I’ve had to hand hack the Authenticator, User, Logger, and Intrusion Detection classes – currently no errors are sent out by ESAPI for PHP, but give me a bit of time and it will happen. String Utilities is also partially there. Authenticator is interesting as it actually does generate strong passwords, and actually reads from the resources directory for the user’s file and decodes it into an array. However, some of these behaviors are hard wired to allow more of the Milestone 1 classes to pass tests, rather than be part of the Milestone 3 build.

I’ve started work on the RandomAccessReferenceMap class. It’s almost there; but unfortunately, I’ve got to go to bed as it’s 2 AM. It’s so close I can smell it. Once done, that class is a close relative of the IntegerReferenceAccessMap, and so there are likely to be two valid and useful ESAPI for PHP classes done soon. I’ll see if I can finish it and check it in before I have to go to work on Monday.

ESAPI for PHP

Last night, I spoke to the phpMELB folks for an hour on ESAPI for PHP.

The talk went well, and they taped it. When the video appears, I will link to it.

More importantly, I worked on ESAPI for a couple of hours after returning last night, and finally have something to show everyone! ESAPI for PHP almost passes some tests:

ESAPI for PHP build 1

This means that folks can start cutting code as the test framework and the main framework are fully stubbed out and ready to go.

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.

On injections

A fair number of years ago, I had the “pleasure” of reviewing an application written in ASP. Unfortunately, it had over 2000 SQL injections. I do not know what happened to the company, which produced legal case management software, but it would have taken a great deal of work to re-engineer the code to be safe. Why then, some six years later are injections still all the rage?

Injections, are to put it in the simplest possible terms, are the simple result of intermingling instructions with potentially hostile user supplied data. This paradigm, although powerful, has failed. As Dr Phil says, “how’s that working for ya?”

So we have to move on. Luckily, this post is not all bad.

HTML injections

It’s becoming increasingly hard to ensure that output is properly encoded, especially as I18N becomes more popular. Will encoding data to be XSS safe be viewable to non-US readers? Hard to say. I’ve been working with Benjamin Field (or more precisely, I farmed out) the re-implementing the Microsoft AntiXSS library API to PHP. This is nearly done. Once it is ready, we’ll make it available.

However, I’m still worried as it’s not the simplest, default way to output. When the simplest way to output is wrong from a security stand point, mistakes will be made.

SQL injections

Seriously, we have the technology to stop these today. Both strongly typed parameterized queries (a.k.a bound statements) and most forms of ORMs and Active Record systems are SQL injection resistant. Stored procedures are mostly safe, but are at risk if a certain lack of care is demonstrated.

LDAP injections

Want to be someone else? It’s easy today. This is the great unexploited attack vector for *serious* applications. Toy apps don’t use LDAP, so most researchers do not concentrate on it. But you betchya that most large orgs and govt types have signed up for the “SSO magic bullet” and landed themselves with a LDAP shaped white elephant. They may not be even aware that they are running LDAP. It’s certainly not made clear in many of the marketing materials. How do architects who have never coded understand the risks?

Today’s LDAP code are eerily reminiscent of the SQL days of yore. Here’s a typical LDAP login method (I have worse, but for this I’ve borrowed from php.net’s manual page):


$ds = ldap_connect($ldaphost, $ldapport) or die(“Could not connect to $ldaphost”);

if ($ds) {
$username = “some_user”;
$upasswd = “secret”;
$binddn = “uid=$username,ou=people,dc=yourdomain,dc=com”;
$ldapbind = ldap_bind($ds, $binddn, $upasswd);

if ($ldapbind) {
print “Congratulations! $username is authenticated.”;
}
else {
print “Nice try, kid. Better luck next time!”;}
}

Yes, not only can you choose your location within the ldap tree, you can also do XSS if you’re clever.

XML

Don’t even get me started. Creating uninjectable XML functionality is a PhD in itself, and once it’s done, I doubt the resulting XML would be anywhere near as useful as it is today.

Injections will continue to occur to why the USA still has pennies and $1 bills: they didn’t remove the old form from circulation. This is the only solution: ensure the safer solution is available by default (and is the easiest method to use), and remove the old unsafe methods. Make it HARD or IMPOSSIBLE to do it badly.

Top 10 2007 is done

The document is a complete re-write from scratch, and is totally up to date. It’s 34 pages of goodness wrapped in a shiny new document format. Essentially it’s over all bar the shouting… which comes next! :-)

The document will be uploaded to our Wiki in the next week (post-board approval). If you want your review points or changes to be included, you will need to be on the Top 10 mail list to make the suggestions or changes. To join the OWASP Top 10 mail list (it’s free!), go here:

OWASP Top 10 Mail man interface

I am particularly interested in hearing from people in the

  • PCI DSS arena
  • Department of Homeland Security
  • NIST
  • - Your nation’s equivalent of the above two if you are outside of the USA
  • If your organization has previously adopted the OWASP Top 10 2004
  • Vendors in the WAF, automated code review, and other automated tool arena (yes, we finally discuss if these automated controls are likely to work, but as we don’t know about every product, the more advice we can get the better)
  • Frameworks, particularly the PHP team, J2EE / Struts / JSF / Hibernate / Sun / BEA, JBoss, etc, and of course Microsoft’s folks in the .NET team

The last two bullet points are REALLY important as we make some stringent suggestions about how best to code to avoid the Top 10 weaknesses and we want to ensure that it really is the best advice. If you can’t be seen contributing publicly, feel free to e-mail me… vanderaj (at) owasp.org.

UPDATE >> Here it is!

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

Andrew

The usual suspects and what to do about them

I’ve been busy on the Top 10 2007 with Dave Wichers and Jeff Williams. I’m very close to finalizing a draft release right now. This process made me think, how can we eliminate these issues? Why should every developer have to learn how to fix the same problem? We know On some frameworks, some classes of application programming error are history. Obviously, we’re not going to be able to fix business process or logic issues, but I’d prefer people working on that than wasting time searching mountains of code looking for every last vulnerability.

So over the next week or so, whilst I’m traveling and theoretically have more time (i.e. less TiVo!), I’ll pump out what’s wrong with the current model, and propose how it might be fixed. Permanently.

Some of my recommendations will be hard to swallow, but the alternative (“same old, same old”) has failed, and failed miserably for years. It’s time for something new, or in the case where it works real well on another framework, let’s adopt their ideas and maybe even improve on it a bit. Up first is our old friend XSS.

XSS

xss-table001.png

The table shows just how wrong the old way (PHP) is. I made the number up in the difficulty column, arbitrarily setting it to 10 / 10 for the weakest solution, and then thinking carefully about what would be required in the other platforms to come to the same desired point: a safe application. In this round, J2EE using any of of the common presentation layers wins hands down. Sure, you can do bad things in J2EE and .NET, but the important thing is that it is not the default. You have to work at being insecure. But when you need to be, those frameworks allow you to be as insecure as the next guy.

Given the likelihood that a PHP developer is no better or worse than a J2EE or .NET developer, the PHP application requires more care and thought to get right. This means, in the entire universe of webapps (regardless of language), a larger percentage of PHP applications will have XSS issues than other frameworks.

What’s needed to get it right?

With PHP, there’s no real solution other than … a very ballsy decision to make PHP 6 XSS safe by default. PHP 6 is Unicode. Let’s make the Unicode output functions XSS safe by default, and output a E_STRICT warning when apps use print or echo. Obviously, there will need to be a way to output HTML dynamically, but this is the corner case, not the default. Let’s make the devs who need REAL html do the hard work, rather than make all devs do the hardwork, everywhere.

With .NET, all controls need to be XSS safe by default and have an encoding property, and it should be set to true by default. Enough are properly done right now to protect the usual newbie programmer, but it’s wrong to assume that even advanced devs will remember to encode everything. Where a value is stuck into a field that is likely to be displayed without encoding, a warning should show in the debugger.

With J2EE, the java compilation step should issue a warning when the old style <%= … %> is used un-nested. <%= … %> is required to put values into messages and bean:write to do useful work. But if it’s just on its lonesome, that’s XSS right there.

Tomorrow: Injections…

WebAppSec Past and Future

All the cool kids get the press for the wrong reasons. It’s much easier to destroy than to create. Therefore, my 2006 and 2007 lists will only highlight those things which I think have helped create safer web apps, not made it harder for us to protect against them.

2006 Highlights

  • IE 7.0 released. Seriously. Prevents many phishing attacks, reduces the damage through low privilege browsing, and stops some forms of XSS (including the recent Adobe PDF problem). Firefox and Apple could learn a few things from Microsoft.
  • Publication of Ajax Security guidelines by many folks (including me)
  • PCI updated their guidelines to encourage vendors to take CC handling seriously, mandating code reviews by 2008
  • Folks who are normally hidden started blogging, such as this PCI DSS blog and this
  • OWASP Testing Guide gets off the ground in a big way. When this is released (soon!), normal folks will have a way to review existing code properly.
  • OWASP Autumn of Code starts, funding approximately nine projects (8 were chosen and we funded another as it is strategic to OWASP’s mission). Many projects are nearly finished! This has been extremely successful and we will be doing it again in 2007
  • Encoding gets a fresh look: OWASP Encoding library and Microsoft’s revamped AntiXSS library which takes the refreshing approach of deny all crap and let through known good.

2007 Projections

It’s going to be a very busy year for vendors in this space, such as my new employer, Aspect Security. With PCI compliance coming through the works, folks writing PHP apps finally grokking that they need code reviews and pen tests, it’s going to be a bumper year.

Things that I think will make a difference or need more research:

  • Protections against malicious XSS. This will almost certainly focus attention on Javascript implementations
  • Better browser protections for users. All browsers need to look at IE 7.0 and think of that as a starting point. You hearing me Firefox and Safari / webkit devs?
  • Research into safe I18N methods and prevention. This is an almost completely green field today, and needs serious researchers
  • Working on safer API for free form protocols such as XML and LDAP which are essentially utterly injectable today
  • Work with the PHP group to get them to make PHP 6 safe by default. They have an excellent opportunity and a huge responsibility to not screw up
  • Open source web app sec training for open source languages such as PHP and Ruby is direly needed. Lots of information out there, but how to publish to this audience? Extremely challenging
  • Projects utilizing the latest fads (Spring, Ruby, Ajax, etc) MUST catch up with the latest in webappsec trends or they WILL fail. It is not enough to adopt the latest and greatest fad and think it’s secure. It’s not.
  • Folks like Gunnar Petersen are getting the secure SOA message out there. This baby’s time was several years ago, but I think in 2007 large organizations will finally start realizing that hooking up web services to 30+ year old Cobol is an insane proposition without a dose of security
  • REST will be put to rest, as it is insecure and cannot made to be so… without looking an awful lot like WS-*. At which point you may as well use WS-* and be done with it. SSL != secure.
  • A lot greater focus will have to be paid to business logic security. Code scanners and app scanners CANNOT find this stuff, and yet it is the raison d’etre for the web apps. Securing business logic requires hard graft, and a great deal of focus in the architecture and business requirements phase. Hopefully, OWASP will be working on secure architecture, business requirements and design resources this year.

However, it’s going to be a annus horribulous for folks who cannot or will not undergo PCI compliance. PCI compliance is mandatory in 2008, and doing brain dead stuff like storing credit card details will mean many smaller CC gateways and providers will have to shut down, leaving only the big providers. This will mean higher processing fees and less competition. However, the reality is that the financial and identity theft losses from non-compliant places outweigh the benefits from letting them live. I’m happy to pay a little extra and know that my details are reasonably safe from unsavory types.

It’s not opinion, Richard

For the second time, I helped SANS compile their Top 20. I don’t know about the other sections, C1 is primarily my section. As always, there will be knockers. However, I was a bit surprised about one contrarian, the normally interesting and challenging Richard Bejtlich. Richard writes:


As far as the nature of the list goes, it’s important to realize that it’s based on a bunch of people’s opinions.

Actually, no. My section is based upon hard core data from MITRE, as will the forthcoming OWASP Top 10.

MITRE web app sec data

The only entry which I forced into SANS Top 20 is CSRF because it’s REALLY important to fix over the next 12 months. We only get so many chances to speak to this particular audience and CSRF deserves attention. The OWASP Top 10 also has CSRF. Remote File include, which affects PHP more than most, is EXTREMELY heavily attacked. It’s actually the primary attack vector for PHP stacks. It belongs in the list. My mum can discover XSS – it belongs in there. SQL injection can be found via automated means and this is the worst bit – we have methods to utterly avoid it – if only devs would stop using vulnerable API! rdbms_query() should simply not be supported in future PHP releases. And ditto for other languages and frameworks.

Worse still, Richard misses the forest completely when he says that “… it’s called an ‘attack targets’ document, since there’s nothing inherently ‘vulnerable’ about …”. It doesn’t really matter if it’s a weakness, action item, vulnerability or attack. If it’s something you should know about, it belongs in there. Like phishing, like webappsec, and so on. Don’t play semantics when people are at risk. That’s the job of cigarette and oil companies.

It’s basically impossible to find out how much certain types of attacks net criminals, or how much pain identity theft victims suffer, or how much a life is worth when an attack takes out vulnerable biomedical equipment. I’d rather have my blog spammed by hundreds of scripts than one single skilled and motivated attacker take over the host this blog resides on due to security defects in WP. A simple numerical attack number is useless. A simple $$$ figure is going to be wrong and misleading. It’s impossible to *rate* attacks.

We must do it via vulnerabilities discovered, and I’ve done that.

So for us, MITRE data is as good as it’s going to get, and I’ve used that for the top 4, plus one item which is going to be the major form of weakness/vulnerability/attack as folks work out how horrible it is to use CSRF resistant software, and it’s going to get worse when Ajax enabled apps do *everything* via XHR, rather than just a subset of their functionality.

Rohit did a great job herding many, many cats. I really wanted 10 things in there for developers to check and do as web app sec vulnerabilities are now the Top 11 or so attacks. But SANS is a system administration resource, and thus they turned the focus around for system administrators. Fair enough. That’s why we have links to OWASP for those folks who need it.

For Richard to state that the SANS document is my opinion, I don’t think so. I concentrated heavily on fact. In other related news, the OWASP Top 10 is nearing that happy point when it will need peer reviewing. If you’re interested, come join the Top 10 mail list at OWASP.

ps. that graph above although it is the MITRE data does not indicate the Top 10 headings. We’ve got something special for you all! :)

SANS Top 20

The SANS Top 20 2006 update has been posted.

SANS Top 20 2006

I helped write the C1 Web App Sec section:
C1. Web Applications

We’re working on the updated OWASP Top 10 2007 which interlinks with that. It’s an interesting experience writing something like this for a completely different audience than web developers. As it’s coding issues, the SANS folks wanted things like configuration changes which system administrators could change and improve the security. But that’s not what this section is about.

Hopefully, next year, we can get more focus on the changes organizations who write or buy code can do to improve their security. In the near term, when it’s done, check the OWASP Top 10 2007. It’s very cool and has CSRF in it!