error log truncates important infos

[Robert Paprocki]

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>
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 at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20160615/f872bc53/attachment.html>