Re: Resolution for ver_export()/addslashes() encoding based script execution attack?
Hi!
> PHP supports SJIS and the like. Escape functions should provide safe
> escaping like databases. The only way to solve this issue is encoding
You are making global claims which sound plausible on surface, but when
you put them in context, it gets much more complicated. PHP supports
SJIS, yes - just as it supports any other existing encoding. That does
not mean every scenario possible is automatically working or can be made
to work consistently. Specifically, SJIS encoding is not compatible with
ASCII encoding, which means same function with same parameters would not
work, moreover - choosing parameters which would work in every situation
may be quite problematic.
> aware escape which databases adopted years ago. I'm proposing known
> vulnerability with known method to fix.
Encoding-aware inside PHP means different thing than inside the
database. The database has only one encoding within the session and
doesn't have to deal with anything else. PHP has much more to deal with,
especially in scenarios you are proposing - where you are writing out
PHP scripts to be executed later. Your solution assumes one set of
environment settings and will break in another, current solution works
in one set of environment settings and will break in another. So I'm not
sure we'll be making much of an improvement there by switching set of
cases where it will break.
> BTW, users who do not have to worry about this are not affected by
> proposed change.
That is not the reason to accept the change. It is a necessary, but not
a sufficient condition for acceptance.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Thread (20 messages)