You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@ignite.apache.org by Vladimir Ozerov <vo...@gridgain.com> on 2017/09/19 07:20:21 UTC

Exception handling in thin client: should we pass stack traces to the client?

Igniters,

We had a discussion about how to propagate error information from cluster
nodes to the client. My opinion is that we should pass a kind of vendor
code plus optional error message, if vendor code is not very specific.

Alternative idea is to pass the whole stack trace as well. I agree that
this is very useful for debugging purposes, but on the other hand IMO it
imposes security risk. By sending invalid requests to the server user might
get sensitive information about server configuration, such as it's version,
version of the underlying database, frameworks etc.. This information may
help attacker to apply some version-specific attacks. This is precise
reason why default error pages of web servers with stack traces are always
replaces with some stubs.

This is why I think we should not include stack traces.

What do you think?

Vladimir.

Re: Exception handling in thin client: should we pass stack traces to the client?

Posted by Yakov Zhdanov <yz...@apache.org>.

Fully agree. As Alex mentioned web servers support dev and prod modes. We
need to do the same and default mode should be dev with warning on startup
and ability to change in runtime.

--Yakov

Re: Exception handling in thin client: should we pass stack traces to the client?

Posted by Vladimir Ozerov <vo...@gridgain.com>.

Thanks, folks!

Excellent catch - we should not decide whether to allow it or not, but
rather make it configurable.

On Tue, Sep 19, 2017 at 10:43 AM, Alexey Goncharuk <
alexey.goncharuk@gmail.com> wrote:

> I think the protocol should allow both, and the behavior should be either
> configurable or enabled via a system property. Every web server known to me
> allows exposing this information for debugging purposes.
>
> 2017-09-19 10:20 GMT+03:00 Vladimir Ozerov <vo...@gridgain.com>:
>
> > Igniters,
> >
> > We had a discussion about how to propagate error information from cluster
> > nodes to the client. My opinion is that we should pass a kind of vendor
> > code plus optional error message, if vendor code is not very specific.
> >
> > Alternative idea is to pass the whole stack trace as well. I agree that
> > this is very useful for debugging purposes, but on the other hand IMO it
> > imposes security risk. By sending invalid requests to the server user
> might
> > get sensitive information about server configuration, such as it's
> version,
> > version of the underlying database, frameworks etc.. This information may
> > help attacker to apply some version-specific attacks. This is precise
> > reason why default error pages of web servers with stack traces are
> always
> > replaces with some stubs.
> >
> > This is why I think we should not include stack traces.
> >
> > What do you think?
> >
> > Vladimir.
> >
>

Re: Exception handling in thin client: should we pass stack traces to the client?

Posted by Alexey Goncharuk <al...@gmail.com>.

I think the protocol should allow both, and the behavior should be either
configurable or enabled via a system property. Every web server known to me
allows exposing this information for debugging purposes.

2017-09-19 10:20 GMT+03:00 Vladimir Ozerov <vo...@gridgain.com>:

> Igniters,
>
> We had a discussion about how to propagate error information from cluster
> nodes to the client. My opinion is that we should pass a kind of vendor
> code plus optional error message, if vendor code is not very specific.
>
> Alternative idea is to pass the whole stack trace as well. I agree that
> this is very useful for debugging purposes, but on the other hand IMO it
> imposes security risk. By sending invalid requests to the server user might
> get sensitive information about server configuration, such as it's version,
> version of the underlying database, frameworks etc.. This information may
> help attacker to apply some version-specific attacks. This is precise
> reason why default error pages of web servers with stack traces are always
> replaces with some stubs.
>
> This is why I think we should not include stack traces.
>
> What do you think?
>
> Vladimir.
>

Re: Exception handling in thin client: should we pass stack traces to the client?

Posted by Dmitry Pavlov <dp...@gmail.com>.

Hi Vladimir,

All of these arguments are relevant. I suggest to provide full stacktrace
at least by server option. This is also common practice on web servers.

Sincerely,
Dmitriy Pavlov

вт, 19 сент. 2017 г. в 10:20, Vladimir Ozerov <vo...@gridgain.com>:

> Igniters,
>
> We had a discussion about how to propagate error information from cluster
> nodes to the client. My opinion is that we should pass a kind of vendor
> code plus optional error message, if vendor code is not very specific.
>
> Alternative idea is to pass the whole stack trace as well. I agree that
> this is very useful for debugging purposes, but on the other hand IMO it
> imposes security risk. By sending invalid requests to the server user might
> get sensitive information about server configuration, such as it's version,
> version of the underlying database, frameworks etc.. This information may
> help attacker to apply some version-specific attacks. This is precise
> reason why default error pages of web servers with stack traces are always
> replaces with some stubs.
>
> This is why I think we should not include stack traces.
>
> What do you think?
>
> Vladimir.
>

Re[2]: Exception handling in thin client: should we pass stack traces to the client?

Posted by Zhenya Stanilovsky <ar...@mail.ru.INVALID>.


Thanks ! now its clear for me, ones more want to repeat my position — sending exceptions to the client side looks like bad design, because exceptions its about unhealthy system recognition from administrator side, not from client of course, but looks like for now it`s more informative than existing decision. 
 
>>
>> Alexey.
>>
>> This option should be on the server side, so server administrator can
>> disable stack trace for all clients.
>> Correct?
>>
>Yes, correct.
>

Re: Exception handling in thin client: should we pass stack traces to the client?

Posted by Alexey Goncharuk <al...@gmail.com>.

>
> Alexey.
>
> This option should be on the server side, so server administrator can
> disable stack trace for all clients.
> Correct?
>

Yes, correct.

Re: Exception handling in thin client: should we pass stack traces to the client?

Posted by Nikolay Izhikov <ni...@apache.org>.

Alexey.

This option should be on the server side, so server administrator can disable stack trace for all clients.
Correct?

> 25 авг. 2020 г., в 12:47, Alexey Goncharuk <al...@gmail.com> написал(а):
> 
> Zhenya,
> 
> Stacktraces are considered to be able to expose sensitive information about
> code, see [1]. So as previously, I agree with Pavel that we should have an
> option to disable this behavior.
> 
> [1]
> https://wiki.sei.cmu.edu/confluence/display/java/ERR01-J.+Do+not+allow+exceptions+to+expose+sensitive+information

Re: Exception handling in thin client: should we pass stack traces to the client?

Posted by Alexey Goncharuk <al...@gmail.com>.

Zhenya,

Stacktraces are considered to be able to expose sensitive information about
code, see [1]. So as previously, I agree with Pavel that we should have an
option to disable this behavior.

[1]
https://wiki.sei.cmu.edu/confluence/display/java/ERR01-J.+Do+not+allow+exceptions+to+expose+sensitive+information

Re: Exception handling in thin client: should we pass stack traces to the client?

Posted by Pavel Tupitsyn <pt...@apache.org>.

I think this behavior should be configurable.
We can have it on by default, but have a setting to disable, e.g.:
ThinClientConfiguration.excludeErrorStackTraces

On Fri, Aug 21, 2020 at 9:54 AM Zhenya Stanilovsky
<ar...@mail.ru.invalid> wrote:

>
> Guys, does anyone else bothers about it ?)
> Ones more — i really not sure that all exceptions have been thrown from
> server side have informative message visible from client side, if client
> would receive full stack trace from server side it would reduce additional
> efforts from cluster administrator side, in one case i agree here — this is
> not pretty a bit.
> If no quorum would be here — ok, i fill a ticket for optionally enable
> such behavior, as was discussed earlier, and leave the current one as it is.
> thanks !
> >Hi,
> >
> >I agree with Zhenya, that a stack from server side will be able to help in
> >investigation of issues, but it really confused in production environment.
> >I see all participants tell the same.
> >
> >Pavel, do you mean this behavior should be switching by configuration?
> >
> >On Thu, Aug 20, 2020 at 5:00 PM Pavel Tupitsyn < ptupitsyn@apache.org >
> wrote:
> >
> >> Link to the original discussion:
> >>
> >>
> >>
> http://apache-ignite-developers.2346864.n4.nabble.com/Exception-handling-in-thin-client-should-we-pass-stack-traces-to-the-client-td22392.html
> >>
> >> On Thu, Aug 20, 2020 at 4:46 PM Zhenya Stanilovsky
> >> < arzamas123@mail.ru.invalid > wrote:
> >>
> >> >
> >> > I want to resurrect this discussion, i don`t understand what sensitive
> >> > information you are talking about ?
> >> > Can you show some examples or something else ? I never listen that
> thread
> >> > dumps belong to sensitive info.
> >> > I believe that one linear error can`t help user to recognize problem
> and
> >> > logs from server side can be simple unreachable or logging disabled at
> >> all.
> >> > So i suggest to request full thread dump in case of server side error
> >> > occurred.
> >> >
> >> > what do you think ?
> >> >
> >> >
> >> > >Igniters,
> >> > >
> >> > >We had a discussion about how to propagate error information from
> >> cluster
> >> > >nodes to the client. My opinion is that we should pass a kind of
> vendor
> >> > >code plus optional error message, if vendor code is not very
> specific.
> >> > >
> >> > >Alternative idea is to pass the whole stack trace as well. I agree
> that
> >> > >this is very useful for debugging purposes, but on the other hand
> IMO it
> >> > >imposes security risk. By sending invalid requests to the server user
> >> > might
> >> > >get sensitive information about server configuration, such as it's
> >> > version,
> >> > >version of the underlying database, frameworks etc.. This information
> >> may
> >> > >help attacker to apply some version-specific attacks. This is precise
> >> > >reason why default error pages of web servers with stack traces are
> >> always
> >> > >replaces with some stubs.
> >> > >
> >> > >This is why I think we should not include stack traces.
> >> > >
> >> > >What do you think?
> >> > >
> >> > >Vladimir.
> >> >
> >> >
> >> >
> >> >
> >>
> >
> >--
> >Vladislav Pyatkov
> >
>
>
>
>