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-fo...@forum.nginx.org> wrote: > 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 > problem. > > What about limiting the fastcgi output to 1024 bytes and appending this > info > 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. > Host > 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 > fields. > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?2,267568,267592#msg-267592 > > _______________________________________________ > nginx mailing list > nginx@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx >
_______________________________________________ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx
