Yesterday I've discovered an "interesting" implication of using user input inside var_export() and print_r() functions. To those who have never used the two, a brief overview of their functionality. The var_export() function takes a variable and represents the data found within as a valid PHP string. By default this string is dumped to screen, but if you want you can have it be returned as a string, by passing a 2nd optional parameter as boolean TRUE. For example if you wanted to put an array creation code into a file, you'd do something like this:
PHP:
<?php
file_put_contents("my_file", var_export($array, 1));
?>
The print_r() function is similar in function, except the returned data is intended for debugging and not storage. As with var_export() by passing a 2nd optional parameter you can force the data to be returned as a string rather then dumped to screen.
Herein lies the problem, when it comes to storing the data, this is done by enabling output buffering of the content without a set buffer size limit. Consequently, by forcing the function to generate a massive string it is possible to launch a denial of service attack aimed at exhausting both processor and memory.
Continue reading "Security Implications of var_export/print_r"
