security bug in PHP-server-1.1

[Niels Berkers]

Norman Rasmussen wrote:
> On 4/11/07, Niels Berkers <niels at quotar.com> wrote:
>> Norman Rasmussen wrote:
> 
>>> Agreed!  You never know when someone might find a way to inject unsafe
>>> data into your database.  It's much safer to escape it as you output
>>> it.  (Also you might output it in different places, requiring
>>> different escaping)
> 
>> Sorry ... can't believe im reading this. Any software security
>> specialist would disagree.
> 
> Huh? Sorry your response confuses me.
> 
> You can't escape data (for output) when it arrives because you could
> output it in any form.  (You only need to escape it as you add it to
> the database, if you're database layer doesn't support parameters (or
> some other escaping mechanism)).  You need to escape the data as you
> display it _in the display module_- so that you know how to escape it.
> 
In my opinion security goes in front of any action. This is how i design 
server-platforms and websites. So as soon as unknown data enters a 
system it has to be cleaned and cleared. Since i don't want to output a 
potential danger in any form, there is no need to keep it in a potential 
hazardous state. (The cleaning process as described is always reversible 
BTW.) If you know for sure you need some opening in the code eg. to 
allow html-tags you make an exception.

> If you only escape data as it enters the system, then you can't trust
> that there won't be a loophole somewhere that allows unescaped data to
> enter the database - that would be displayed to the user on a normal
> page (it's impossible to secure all incoming points).
> 
In general there are less places where stuff enters the system than it 
is represented. So this will give a better security that only escaping 
the output. In security you work with layers of trust. The futher 
unclean data can penetrate your system the less secure your application 
becomes... this allways goes. eg. inet -> dsl provider -> gateway + 
firewall -> PC + firewall -> virusscanner -> appliction to manage 
passwords


> If you escape as you render data (including if you have to - dynamic
> sql - yegh).  Then you escape data everywhere you display it.  So you
> remain in control of _all_ the points in the system where data is
> rendered to the user, and can ensure that it's safe.
> 
> I really hope you misread my statement, and that you don't think that
> output escaping is not worth it, and that input escaping is the
> be-all-and-end-all.
> 
im not saying output escaping is not worth it, but is the end of the 
line in securing a webserver and the application it's serving. And in 
most of the cases the template builders are not the ones that have the 
best knowlegde of systems / programming language. So one of the most 
difficult tasks, is put in the hands of those less likely to have the 
best solution.

br,

Niels