Is there any problem if I require_once a file at top of every php page?

[Jacques1]

You asked whether your approach is inferior, I gave you an honest answer. If you're forced to make bad decisions due to crazy policies, that's up to you.

 

The inner workings of Twig escaping are explained in the documentation, the source code is on GitHub. There is no single PHP function you can replace it with, because escaping depends on the context (simple HTML, URLs within HTML, inline CSS, inline JavaScript, ...). When you use htmlspecialchars(), the only safe context is simple HTML. Outside of that, you're wide open to XSS attacks.

 

 

 

[...] in the rare case they need something intentionally unescaped [...]

 

What? Using unescaped values is the standard case. The only time you use escaped values is when you output them.

[thinsoldier]

What, what?

 

We're talking about escaping values for output in views. Within the view file most of the time you want the escaped value for output.

Edited March 17, 2017 by thinsoldier

[Jacques1]

I'm starting to think you have no idea what a (non-crazy) template even looks like.

 

Templates have loops, conditionals, function calls. All of those require the original values, and, no, this shouldn't require decoding gymnastics. What you describe sounds like the terrible Magic Quotes all over again.

[thinsoldier]

I guess it's just my specific projects then. I can't think of much logic we do in the view that involves anything more than booleans, integers, isset() and !empty() which would not be affected by running them through htmlspecialchars. If I'm doing a foreach loop it's almost certainly because I want to echo the contents of the array in which case I'd want all the values in the array to be escaped.

 

I'm not arguing with you. You're poking holes in my system so I'm just checking to see if I'm covered or not. Yes, anything less than "just use twig" is moronic but like I said, in 12 years I've only been allowed to use 2 external php libraries (neither of which were chosen by me), I don't have a choice in the matter.

Edited March 17, 2017 by thinsoldier

[thinsoldier]

Magic Quotes

 

The problem with magic quotes is relying on it to escape values before concatenating them into an sql string and running it on your database.

 

We're talking about escaping any html or css that might have gotten into our db already or in the values returned to form inputs after an unsuccessful submission to prevent them from actually affecting the page's html or css and preventing any JS from executing.

[Jacques1]

The problem of Magic Quotes is that they're applied to the input rather than the output, and they're a dumb one-size-fits-all strategy. Both is also true for your approach, even when it's not quite as wrong (because you at least keep the original values).

 

I understand that you're limited to bad options. The question is whether you've actually picked the least bad option. Your approach is simultaneously confusing and simplistic, so I expect to see a lot of the problems people had in the early 2000s with Magic Quotes: running around with escaped values when you actually need the original ones, running around with the default strategy when you actually need a different one.

 

If the templates are in fact maintained by (competent) programmers, you should consider replacing the primitive htmlspecialchars()-everything approach with a set of different escape functions for the different contexts. You can catch obvious mistakes (i. e. output values that haven't been escaped at all) with a tainting analysis during development.

 

And regardless of the approach, you should use Content Security Policy as a second line of defense against XSS -- unless the pages are cluttered with inline JavaScript/CSS or there's yet another crazy policy.