PHP code audits

Comments

Comments are closed.

Minimal useful information, obsessed with register_globals, talk added nothing to slides. What about Codesniffer? Prepared stmts?

Seemed fixated on register globals and didn't cover other non security code review issues (perhaps I didn't read the overview well?)

Some of the example questions weren't answerable without additional knowledge which we couldn't have.

Meh.

Not the best talk on code analysis, but it did raise some interesting points. There are ways to automatically find injection points in a code base. See this talk from PHPUK2008 for more info. http://www.phplondon.org/conference/2008/media/docs/stefan_esser_php_binary_analysis.pdf

Not too much information. Mostly about register globals.
The speaker could have covered more security issues.

Decent talk, but all about register_globals. The speaker could have covered more aspects in his talk.

The process of going over the code review was good information, but as other commenters have mentioned, surely no-one really uses register globals any more?

And as for building SQL statements in PHP - can we all move on to stored procedures now?

There was potential here, but the examples could have done with being more relevant.

The process of going over the code review was good information, but as other commenters have mentioned, surely no-one really uses register globals any more?

And as for building SQL statements in PHP - can we all move on to stored procedures now?

There was potential here, but the examples could have done with being more relevant.

Was a good insight on how to go about selling a code auditing service as a company or indiviual, structurally, but content was a bit thin and out of date.

It was interesting from a business angle: "here's how I go into an organisation and perform a code audit". If Damien had focused on that side of things and not on the attack vectors themselves I think it would have been better. I'd like to hear more talks where the presenter is explaining the behind-the-scenes aspects of their job or business.

Asking the audience to find the bugs just didn't work. No one wants to raise their hand and risk looking like an idiot in front of their peers.

I agree with rjharrison on the point - a number of times I lent across to my colleague and pointed out the problem with the code (and was correct), but wasn't prepared to put it forwards in case I did look like an idiot (happens all too often).

Saying that, it was a fair talk. Yes, the timing was off - from the quick look of the slides Damien skipped, I think he was going to cover some more good points - going to see if I can't get a copy of the slides from him, but it has given me the motivation to go back and get my department rolling with a code audit, even if I didn't learn a huge amount, so I'll take it!

I thought it was a good example of the work involved in a code audit. Useful, but not as information packed as I was hoping for.

A good show of the work that is involved on doing a security audit. Though because time was running short I think the full potential got lost. As being a pentester myself I still see register global or an emulation of it on a regular base (as people are commenting it isn’t used anymore). To increase effectiveness of the talk I think its wiser to focus on one point. Either the audit itself or the business involved to doing one (process/project steps). A tip 2 do a black box test quickly with a tool are Netsparker and Acunetix. There are a few others as well its worth taking a look at them to see if they are useful in the setup of a pentest. Though as always there are false positives.