Don't forget that you have different dynamic typing rules to battle with depending on whether you're doing a regular json query (BSON type rules) or whether or not you're doing something javascript-ey (like collection.mapReduce, where you get Javascript type rules).

Example (code is probably wrong; I'm working off memory and haven't touched Mongo in nearly a year):

db.collection.insert({foobar: "1"});

db.collection.find({foobar: 1}); //no results

db.collection.mapReduce(function(){
if (this.foobar == 1) emit(1, this.foobar); //works
}, /* rest of reduce function + crap here */);

For extra fun, throw PHP into the mix and marvel at how your integer properties get silently turned into strings whenever they pass into a html form and then get rewritten to the database!

I think OpenSSL might be a special case here. By an odd coincidence I was watching the OpenBSD devs talks on LibreSSL yesterday and they actually covered backporting fixes from OpenSSL.

http://www.openbsd.org/papers/eurobsdcon2014-libressl.html - See the section title "apply the brakes". (for those interested, the slides here are from this video: https://www.youtube.com/watch?v=WFMYeMNCcSY)

My overall impression is that the OpenSSL developers don't really make peoples lives easy when it comes to backporting security fixes because they'll be bundled with a heap of other, poorly tested crap at the same time. This isn't helped by the quality of their code.

Dammit, forgot to mention a point.

I was going to also say that your approach also doesn't really fix "how do I escape this?" and just foists the responsibility on the developer. Sooner or later every developer is going to have a bad day and get it wrong. The developer might fix the HTML Injection, but didn't realise the value is passed to an attribute like onclick and needs to be escaped for Javascript as well.

There is a reason I specified templates there. Templates act as a way to separate your output into stuff that is safe (stuff you wrote) which doesn't need escaping, and stuff that's come from somewhere else that does need escaping. The templates are effectively doing the same job as binding values in an SQL query; separating the stream into things that should be escaped and things that should not be escaped.

No amount of escaping, automated or otherwise, is going to be able to save you in the situation you proposed, because you have definitely safe content mixed in with potentially unsafe content. Deciding what parts of the stream should/should not be escaped is effectively a halting problem. However, if what parts need escaping is specified via something like templates (where it's actually harder to do what you're suggesting than use them as intended) then you change the problem into "How should I escape these bits"? The use of templates effectively makes this separation into an opt-out process rather than an opt-in one.

The argument I was trying to make with my straw man example above is that the question of how to actually escape them correctly, in an opt-out kind of way, while possible, is needlessly complicated and cannot be done elegantly or without considerable performance degradation. And this is just a natural result of how we have lots of languages with different escaping rules that can all nest within each other.

I think doing this in your framework is every bit as ugly as the insanity I suggested and actually supports my argument. I can only think of two ways to do this in popular server-side languages:

• A lot of very ugly and slow reflection (and TBH, I'm not entirely sure about this one)
• Implementing your own types and forbidding use of your language's standard library and built in types (how would your framework copy information regarding tainted-ness of a value from one to another if you created it using a standard library substring function that only understand the standard string objects/scalars?).

It could be done pretty cleanly as a static analysis tool. It's just that if it was a static analysis tool it wouldn't actually fix the problem as it wouldn't be able to catch all cases (because halting problem). It would certainly be a very useful heuristic and lower the overall number of XSS vulnerabilities in peoples applications, but it wouldn't actually make them impossible in the same way as binding values to a query makes SQL Injection impossible.

TLDR: We are doomed to have to be eternally vigilant about XSS. Frameworks that have opt-out XSS protection only handle the common case which means we still have to worry about the uncommon cases because correctly handling those is too painful.

While I agree with the kernel of your post - that safe behaviour should be opt-out rather than opt-in - unfortunately I disagree that it's even remotely practical to do this properly in the cesspool of standards and programming languages used in modern web development.

Don't get me wrong; I know frameworks like Ruby on Rails make html escaping opt-out rather than opt-in and this is a good thing. It's just that XSS isn't just about HTML. There's different escaping rules for:

• Contents of a DOM Text Node (< needs to be changed to &lt)
• Contents of a HTML attribute (" needs to be changed to &quot;)
• Contents of a src/href HTML attribute (as above, but also needs URI encoding)
• Contents of a Javascript string (" to \" or ' to \' depending on how the string was opened, plus line breaks need to be stripped and you need to handle the new string template stuff in the newer ECMA standards)
• Contents of a Style tag (one, many or all of the above depending on where in the CSS its going)

(And that's not even starting on things all the inline XML formats you can have in XHTML, SVG and other things I know next to nothing about)

On top of all this, all these contexts can nest within each other, so you need to apply all of the appropriate escaping in the correct order or it doesn't work.

So a call to your particular framework's equivalent of htmlspecialcharacters just doesn't cut it, unfortunately. The only way I can see to handle all this securely and automatically is to actually parse your templates and keep track of each context that is entered/exited and apply appropriate, nested escaping rules. This is awful and slow.

Even if you took a heavy handed approach like above to fixing this, you'd STILL be screwed because web browsers attempt to "fix" broken HTML and CSS. So they can do (and in the case of IE have done) stupid things like turn a backtick (`) or a left single quote (‘) into a normal single quote (').

I think that you goading someone into hacking your websites and then claiming that they are secure when they can't is actually quite disingenuous here. To be perfectly honest, from your post history I believe you have some vested interest in this banshee framework you keep linking to.

I did actually have a quick look at your websites and they don't actually present a lot of attack surface to work with. The only user input that's used is some id parameters from what I can see. It's utterly trivial to secure such a tiny attack surface, so I doubt there's anything much to be worked with unless you really screwed up.

However, having such little attack surface also implies that there's little reason for PHP to be there at all. You could very easily replace everything with an offline static site generator and just serve html pages. This completely removes all attack surface from your sites and lowers your server requirements.

Do you have any more complicated websites to look at? Something that actually accepts user input from people that haven't been pre-vetted would be ideal. In my experience, PHP's warts really start to show when you need to start exposing the ability to persist things to random people on the internet.

Also is your PHP up to date on those sites? There's some rather nasty CVEs against PHP itself that don't give a damn about your code or framework.

Thinking about this a bit more, I've come to the conclusion that the PHP devs may have been correct to add the mysql_real_escape_string function instead of changing mysql_escape_string to invoke MySQLs mysql_real_escape_string (although not necessarily using their crappy name for it).

There's actually a subtle difference in the expectations of the real_escape variant; it requires an active MySQL connection to be open in order to work, which the older escape function does not. It's not exactly common to try and escape a query when you don't have a connection open to push it down, but I can imagine that there's possibly some weird scenarios where this distinction is important. For example, you could be pushing the queries onto some kind of job queue to be executed asynchronously by another process (don't ask me why you would do this over just pushing the query parameters onto the queue and having the worker build the query itself). This change would break that workflow.

To be fair to PHP here, the mysql_escape_string vs mysql_real_escape_string is mostly MySQLs fault (watch http://www.youtube.com/watch?v... if you want an insight into how screwed up MySQLs development was). It's one of their old C libraries that added the mysql_real_escape_string function.

PHP is not entirely blameless on this front; back in the early days of PHP Rasmus Lerdorf (PHP's creator - read and weep) thought the best way to design an API is to just expose PHP's internal libraries' headers to PHP code, consistency be damned. That's how we got mysql_real_escape_string; Rasmus was just following past form.

PHP has had SQL injection licked for at least the past 10 years (literally every database driver except the deprecated mysql_* one supports binding values to a query), it's just that all of the tutorials are utter, utter garbage and STILL use mysql_* functions.

mysql_* is dead as of PHP 7 (which is pretty imminent now), thank god.

It comes from the top down. Try running PHP's own tests some time. You'll be utterly unsurprised by the result. They're also written in PHP, which I feel is perhaps something of a design flaw.