Disqus - Latest Comments for padraicbrady

Re: Can Fox News break its fatal embrace with irrelvance and Republican party?

Pádraic Brady — Sun, 10 Feb 2013 07:14:08 -0000

Yes, the Irish do not want or need a right wing crazy person. We're a socialist nation. Socialist as in the dictionary definition, not the never-mentioned "communist" meaning that morons like Hannity assign to the term. Is redefining words a common task in politics? Socialism. Imminence. What next?

Re: websec.io - Password Hashing with Zend\Crypt

Pádraic Brady — Mon, 21 Jan 2013 14:14:46 -0000

Nice article. Just to emphasise to readers, once again, the point of password hashing is not to maximise performance but to do the opposite - make it prohibitively expensive for attackers to calculate rainbow tables against which they can compare the password hash. The slower a hashing algorithm is (within reason :P), and the longer your password is, the better!

Re: Getting Ahead In Security By Watching The Neighbours

Pádraic Brady — Sat, 19 Jan 2013 19:14:01 -0000

No special protocol needed - all the major frameworks or apps (like Wordpress) should have a security advisory outlet through a mailing list or RSS feed (by tag). From there it's simply a matter of some detective work to understand how PHP frameworks/apps/libs could be similarly compromised and then searching for those weaknesses. People really underestimate the grep (or other search functionality) approach to auditing. It's simple, effective and doesn't require specialised tools. You can also use backtraces or simple tracing tools like generating a cachegrind file to trace function calls. None of these options are expensive or prohibitively time consuming.

Re: PHP Security: Default Vulnerabilities, Security Omissions and Framing Programmers?

Pádraic Brady — Tue, 28 Aug 2012 13:31:56 -0000

@Nick Rawe While I completely agree that a focus is clearly needed on the developers who need to educate themselves AND have viable sources of education (see my comments re PHP Security books and the PHP Manual), PHP isn't in the clear from all blame. The only viable means of performing HTTPS requests correctly is to verify peers. Browsers are crucified for anything less and backend ops also handling user data have no business exposing users for the sake of being lazy and not using a cert PEM file. This and the other examples I use don't number in the hundreds - they are a handful of specific cases that appear to have a significant impact in the wild where a) PHP is insecure by default and b) its documentation of the vulnerability is non-existent for all useful purposes - the double whammy.

Re: PHP Security: Default Vulnerabilities, Security Omissions and Framing Programmers?

Pádraic Brady — Mon, 27 Aug 2012 03:28:12 -0000

While magic_quotes was a form of Secure By Design, you have to remember that that particular example was flawed from the beginning. That doesn't reflect on the principle, only on our poor understanding of security way back then. PHP being a language seems irrelevant though. Why should being a "language" excuse one from being insecure out of the box? And if I were a foreman on a building project, would I not hold the brick builder liable for their crappy product and either a) dump them as a supplier or b) sue them for the damages that result from using their insecure bricks? What if the brick supplier accidentally on purpose forgot to tell the foreman that their bricks were insecure?

Re: Automatic Output Escaping In PHP And The Real Future Of Preventing Cross-Site Scripting (XSS)

Pádraic Brady — Tue, 19 Jun 2012 18:40:33 -0000

Feel free to submit a Module for Latte ;).

Re: Automatic Output Escaping In PHP And The Real Future Of Preventing Cross-Site Scripting (XSS)

Pádraic Brady — Tue, 19 Jun 2012 10:57:33 -0000

Not without flaws I thought. Not too familiar with XHP but remember it used basic htmlspecialchars() calls, with no optional params set, somewhere in the lib - non UTF-8 in PHP 5.3, etc.

Re: Automatic Output Escaping In PHP And The Real Future Of Preventing Cross-Site Scripting (XSS)

Pádraic Brady — Mon, 18 Jun 2012 14:08:07 -0000

Fine, Latte is a perfect Context-Aware Escaper so long as:
a. You only use UTF-8
b. You never use innerHTML in Javascript
c. ???

I'll let you guys fill out the rest of the alphabet and post it in Nette's documentation. Argument remains the same - automatic escapers are not perfect and cannot be blindly trusted. You need a Human at the wheel to identify all these exceptions.

Re: Automatic Output Escaping In PHP And The Real Future Of Preventing Cross-Site Scripting (XSS)

Pádraic Brady — Mon, 18 Jun 2012 13:09:59 -0000

You're welcome. My consultancy invoice is in the mail. Please ensure prompt payment of my exorbitant fees ;).

Re: Automatic Output Escaping In PHP And The Real Future Of Preventing Cross-Site Scripting (XSS)

Pádraic Brady — Mon, 18 Jun 2012 13:07:59 -0000

There's nothing messed up in my head and I didn't pick this bad habit up from other frameworks. The use of innerHTML is perfectly valid Javascript and can legally be used inside a HTML script tag. Latte, like all template engines, cannot control how a user writes HTML and Javascript which is why such simple cases, while you may not like them, still need to properly recognised and escaped.

Or Nette could add this to a list of exceptional cases that Latte does not cover, i.e. inform your users of Latte's deficiencies so they don't have to guess what it doesn't quite cover?

Re: Automatic Output Escaping In PHP And The Real Future Of Preventing Cross-Site Scripting (XSS)

Pádraic Brady — Sun, 17 Jun 2012 17:39:03 -0000

You sort of missed the point - there are no perfect automatic escaping tools. They get you so far - the rest is up to using your brain.

Re: A Hitchhiker’s Guide to Cross-Site Scripting (XSS) in PHP (Part 1): How Not To Use Htmlspecialchars() For Output Escaping

Pádraic Brady — Tue, 13 Mar 2012 17:58:17 -0000

Good point, htmlentities() has the exact same weakness and it also doesn't support UTF-7. As for the reddit plebes, they can go bite me ;). The TL;DR for this has been circulating for years and is still regularly ignored.

Re: Regex HTML Sanitisation: Off With Its Head!

Pádraic Brady — Sat, 19 Mar 2011 08:18:21 -0000

The HTML is often set at source - e.g. RSS content and HTML emails. At that point, it needs to be filtered and not escaped. Also, you should use htmlspecialchars() if using UTF-8 (htmlentities() will escape lots of stuff in that encoding that is unnecessary).

Re: Open Letter to Gareth Heyes: Regex HTML Sanitisation Doesn’t Work

Pádraic Brady — Fri, 18 Mar 2011 16:37:43 -0000

Hi Ron. Well, it was intended to have a hint of humour. Only a hint though ;). Good to see you on the blog!

Re: Open Letter to Gareth Heyes: Regex HTML Sanitisation Doesn’t Work

Pádraic Brady — Fri, 18 Mar 2011 13:52:37 -0000

Fixed - no disrespect was intended. If it really were disrespect to mispell a name, there are a lot of people I need to chase down for omitting the fáda over the first A in my name ;).

Re: Superfeedr Blog : 10 Feed Publishing Best Practices

Pádraic Brady — Wed, 27 Jan 2010 20:06:14 -0000

"Don’t use RSS and ATOM" - assume you meant don't use both at the same time ;). Another tip at a technical level is to serve them with their correct MIME type - Apache may not do so by default (it'll use the generic application/xml instead). Most languages let you set the right one using a Content-Type header, and rewrite rules have the "T" directive to force the right MIME type (need to use AddType beforehand so these are obeyed, e.g. AddType application/atom+xml .xml).

Re: Ubuntu: nginx+php-cgi on a socket - till's blog

Pádraic Brady — Sat, 01 Aug 2009 07:52:58 -0000

Nginx rocks...;). I still use Nginx+Apache+PHP a lot too. Great post for those looking into the topic for PHP specifically. I know people are using php-fpm but not everyone wants to be patching PHP and getting stuck with that maintenance on every PHP update.