Ibuildings blog

afbeelding van relaxnow

A PHP Developers look back at OWASP AppSec.eu 2013

  • 16-04-2014
  • 0

Note: This post has unfortunately been in limbo for some time. Fortunately good WebAppSec content doesn't age that fast and also a 2014 edition of AppSec.EU is coming up, check it out here: 2014.appsec.eu. The following is for those that want to know what the experience is like for a PHP developer with an interest in security.

 

"So tell me, why do you use PHP, really?"

I'm sitting at the conference dinner, in the cargo room of the Cap San Diego in Hamburg Germany, supposedly the 'largest cargo ship seaworthy museum in the world'. Across from me is a German student and OWASP volunteer. We've been talking for a while now, he looks forward to a future in pentesting so he volunteered to help with OWASP AppSec Research 2013. AppSec is a conference for Application Security, hosted by the Open Web Application Security Project (OWASP). Sometimes they add 'Research' to it to encourage researchers to come and speak.

'Sigh. Here we go again' I think as I hear conversation around us stop, people listening in.

Whatever reputation PHP has with other software engineers, it's even worse with the IT security crowd.

So I tell him that we know PHP doesn't have the prettiest syntax on the block. And its history certainly isn't unblemished. But nowadays it is perfectly possible to create a modern maintainable secure web application with PHP.
I tell him that whatever he may have heard about language capabilities is probably based on outdated information. PHP has proper OOP capabilities, namespaces, lambda functions, traits, generators, fully featured IDEs with autocompletion and modern frameworks with techniques like Dependency Injection.
I tell him that even so, PHPs greatest feature is probably also what it get's damned for the most: its ease of getting started. We often take over from entrepreneurs that are not formally trained software engineers, but nevertheless have created successful businesses using PHP. Software is easier to refactor than a business model or customer base.
I even get backup from a senior Oracle software engineer sitting next to me.
He tells me he likes Python.
Yes, it does have nice syntax.

Despite the PHP bashing (trust me, it wasn't just the attendees) one of the best features of AppSecEU was the variety of attendees.  I met software engineers, CTOs, system administrators, students and many, many pentesters.
Another great feature is the location. Hosted in the Emporio business center, much of the conference took place on the 23rd floor, which gives a beautiful view of lovely Hamburg.

But most of all I was there for the content of course. There was lots of it, ranging from theoretical to practical and from obscure to relevant for every day use.
Below are some of the talks I thought were most interesting for PHP developers:

 

Rooting your internals: Inter-Protocol Exploitation, custom shellcode and BeEF

 

I'd never heard of BeEF before:

BeEF is short for The Browser Exploitation Framework. It is a penetration testing tool that focuses on the web browser.
http://beefproject.com

BeEF is what bad guys would inject if they found XSS and then wait for people to come by and do things like:

  • Getting their internal IP address
  • Ask the user for their facebook credentials
  • Fake a Flash update window to get the user to install something.
  • Or try to use an exploit to take over their machine.

Fun stuff! Scary to see in general.

The speaker showed how to use BeEF to use the browser to exploit an IMAP server (by POSTing specially crafted data to a different port).

Hope you don't derive your security from IP whitelisting...

 

Precision Timing - Attacking browser privacy with SVG and CSS

 

Jaw-dropping.

Want to know if someone is logged into GMail? Why not measure the time it takes for their browser to load up gmail.com.

Want to know if someone has visited your competitors website? Why not time browser repaints.

Want to read data from some external page? Why not load it up in SVG and apply some expensive filters, timing them to see if the filter has to do something or not.

See it to believe it.

 

From the trenches: Real-World Agile SDLC

 

Security within Agile can be done, it can be done well and it can be done without dedicating full-time employees on the security side to the effort.
- Chris Eng, Vice President of Research for Veracode

Lessons learned from applying a Secure Development LifeCycle to several Scrum teams working on a single product.
Biggest lesson was probably what keeps coming up time and time again, Security should be considered at design time. Before user stories are estimated they should have been augmented with the relevant security details.
Next lesson was that Security is not something that only 1 person can do, it needs to be 'embedded' in the team.

Worth checking out if you want to learn more about Agile SDLCs.

 

RESTful security and Securing a modern JavaScript based single page web application

 

Did you know that the Tesla Model S has a REST API?
Some lessons from this talk:
  • Define your API in a contract, don't just blindly map properties to and from JSON, or you may allow someone to update your last_changed_at field. Or view your password hash.
  • If you're dealing with XML, make sure to prevent the XML eXternal Entities attack, Chris Cornut has a good article on this.
  • Watch out what you're caching! Varnish can quickly make a local XSS into a persistent XSS.
  • Use appropriate content-type headers on output (like application/json for your JSON) or your API may be loaded as HTML.
  • Check for the appropriate content-type headers on input. If you don't you might have a CSRF vulnerability.

 

The innerHTML Apocalypse - How mXSS attacks change everything we believed to know so far

 

Tricking innerHTML into accepting non-malicious HTML and outputting malicious HTML.
Useful to see if you're using WYSIWYG editors and/or innerHTML with user supplied data.
 

The innerHTML Apocalypse - How mXSS attacks change everything we believed to know so far by Dr.-Ing Mario Heiderich from Web Rebels Conference on Vimeo.

 

Javascript libraries (in)security: A showcase of reckless uses and unwitting misuses

 

Stefano Di Paola introduced the concept of a (Application Security) 'Sink':
A sink can be described as a function or method that is potentially dangerous when it's (unexpectedly) called or if one of its arguments, coming from an untrusted input, is not correctly escaped according to the layer the function is going to communicate to.
A well known example was the /e modifier in preg_replace (finally gone in PHP 5.5, yay!). Meaning that if an attacker could control the input to preg_replace he/she could execute arbitrary code.
Stefano goes to show how jQuery() or $() and jQuery.ajax are sinks and you should make sure no unvalidated input goes to them.

 

Other

 

 

Conclusion

 

OWASP AppSec.EU 13 was one of the best conferences I have personally attended. The people and the content were excellent and the organizers kept everything running smoothly. If you're in web development in Europe, interested in security and have only one conference to attend this year... attend the DPC14.
Okay, so we won't get mad if you skip the tutorials on Thursday to attend 2014.appsec.eu first.

    Leave a reply