error log truncates important infos
rpaprocki at fearnothingproductions.net
Wed Jun 15 15:53:47 UTC 2016
If you're allowing user-generated output to be written directly to your
logs without any sort of sanitation, you've got bigger problems to worry
about :p Again, it doesn't really make sense to have your fcgi error sent
here- why can't your fcgi process log elsewhere, and leaving the nginx
error log for nginx issues?
On Wed, Jun 15, 2016 at 6:51 AM, philipp <nginx-forum at forum.nginx.org>
> Hmm I understand that limitation. But an attacker or a bad application can
> hide the important information which we need to identify the source of the
> What about limiting the fastcgi output to 1024 bytes and appending this
> with max 1024 bytes.
> client: 127.0.0.1, server: example.com, upstream:
> "fastcgi://unix:/var/run/php-fpm-example.com.sock:", host: "127.0.0.1" ,
> request: "GET / HTTP/1.1"
> [fastcgi - output max 1024][request info: client, server, upstream, host,
> request - max 1024]
> This would ensure that client, server and upstream are always provided.
> and Request can be filled with "user generated" content, so you should put
> it to the end. This would ensure that an attacker cannot hide the important
> Posted at Nginx Forum:
> nginx mailing list
> nginx at nginx.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the nginx