Re: Resolution for ver_export()/addslashes() encoding based script execution attack?
Hi Stas,
On Wed, Feb 26, 2014 at 8:52 PM, Stas Malyshev <[email protected]>wrote:
> > The situation around var_export() is a bit more complicated.
> > var_export() is used to create application configuration, cache data
> > etc. so one might expect the PHP which created that to be able to read
> > that, again. Doing this isn't easy, though, as it makes the generated
> > file non-portable.
>
> Are you suggesting if var_export generates the data it may not be
> readable by standard PHP? Or by PHP running with specific
> script_encoding like SJIS? If the latter, I think var_export to generate
> valid SJIS data is hard to achieve, since SJIS is not ASCII-compatible.
I think you've mailed this before reading my mail to you.
PHP supports SJIS and the like. Escape functions should provide safe
escaping like databases. The only way to solve this issue is encoding aware
escape which databases adopted years ago. I'm proposing known vulnerability
with known method to fix.
BTW, users who do not have to worry about this are not affected by proposed
change.
Regards,
--
Yasuo Ohgaki
[email protected]
Thread (20 messages)