3 ms·
The exploit requires > fastcgi_split_path_info ^(.+?\.php)(/.*)$; If I'm not using this feature of PHP, what can I put in this config value to prevent the e
by jstanley 7y ago
The exploit requires
> fastcgi_split_path_info ^(.+?\.php)(/.*)$;
If I'm not using this feature of PHP, what can I put in this config value to prevent the exploit from working?
- tyingq 7y agoI don't think you can fix it there, because you probably need stuff like /foo.php?key=value to work. (Edit: not quite...see comment below) The try_files config mentioned on the page mitigates the issue.
- makomk 7y agoI don't think this line is required to make foo.php?key=value to work, because the query parameters aren't treated as part of the path. It's for URLs like foo.php/bar where you have some path after the PHP file that's passed to the script - this was supported out the box by Apache mod_php and there's a fair amount of code out there that relies on it. (Generally because cleaner methods of feeding a set of paths to one PHP script require server configuration that may not be available on cheap shared web hosting.)
- tomclancy 7y ago>There must be a PATH_INFO variable assignment via statement fastcgi_param PATH_INFO $fastcgi_path_info;. At first, we thought it is always present in the fastcgi_params file, but it's not true. This is also precondition, and fortunately it's not included in standard fastcgi_params files.