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