4 ms·
In principle, it seems like this could be mitigated by some changes to the language. Has anyone tried this? E.g.: Strings have a dirty flag. Literal strings
by thisrod 10y ago
In principle, it seems like this could be mitigated by some changes to the language. Has anyone tried this? E.g.:
Strings have a dirty flag. Literal strings are initially clean, CGI variables are dirty, argv and file/socket input might be configurable.
Function parameters can be declared evaluated. Passing a dirty string as an evaluated argument fails with extreme prejudice. The database primitives enforce this. Maybe sockets have an evaluated flag too, and only clean strings can be written to an evaluated socket.
The string primitives propagate dirty flags: clean and dirty concatenate to dirty, and so on.
There is an obfuscated way for pdo->prepare to make dirty strings clean, and a special circle of hell for anyone who mentions that in user documentation.
- DCoder 10y agoPerl has such a feature, it's called "taint mode" [1], it marks all variables receiving external data as "tainted" and disallows their usage in sensitive contexts. PHP has an inactive proposal to implement it as well [2]. [1] http://perldoc.perl.org/perlsec.html#Taint-mode http://perldoc.perl.org/perlsec.html#Taint-mode [2] https://wiki.php.net/rfc/taint https://wiki.php.net/rfc/taint
- chriswarbo 10y agoAt a previous job we used custom patches for the PHP interpreter which implemented just such a "dirty flag", among other things. It would also die if you sanitised a clean string, since that indicates that the sanitising logic is dodgy.