Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Don't send non-Thrift exception messages to client #187

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

markdoliner-doma
Copy link

BACKGROUND

Two kinds of exceptions can be thrown by a handler processing a Thrift request:

  • Those that are defined as exceptions in a .thrift file. The server serializes them and sends them to the client. Clients should expect them to happen from time to time and should handle them gracefully.
  • Non-Thrift exceptions: when the server experiences an unhandled error and an exception not defined in a .thrift file is throw out of the handler function. The server has catch-all exception handling that returns a TApplicationException to the client containing the message from the exception.

THIS CHANGE

Stop sending the exception message to the client. I think this is a bad idea from a security standpoint. Random exceptions raised by the server could potentially contain sensitive info like passwords. One hopes this never happens, of course, but we have no control over the code people write. It's not reasonable default behavior to send those messages to clients. The client could be untrusted or the transport could be insecure.

It could be argued that a flag should be added to enable the server to send these messages to clients. I think that's a reasonable thing to do (but I don't plan to do it).

I updated both the Apache code and the thrift-server code, and the tests for both.

Here's the diff of a ping function generated for thrift-server before and after this change:

--- before	2020-07-26 22:06:27.000000000 -0400
+++ after	2020-07-26 22:06:19.000000000 -0400
@@ -1,23 +1,23 @@
     public process_ping(requestId: number, input: thrift.TProtocol, output: thrift.TProtocol, context: Context): Promise<Buffer> {
         return new Promise<string>((resolve, reject): void => {
             try {
                 input.readMessageEnd();
                 resolve(this._handler.ping(context));
             }
             catch (err) {
                 reject(err);
             }
         }).then((data: string): Buffer => {
             const result: IPing__ResultArgs = { success: data };
             output.writeMessageBegin("ping", thrift.MessageType.REPLY, requestId);
             Ping__ResultCodec.encode(result, output);
             output.writeMessageEnd();
             return output.flush();
         }).catch((err: Error): Buffer => {
-            const result: thrift.TApplicationException = new thrift.TApplicationException(thrift.TApplicationExceptionType.UNKNOWN, err.message);
+            const result: thrift.TApplicationException = new thrift.TApplicationException(thrift.TApplicationExceptionType.UNKNOWN, "The server experienced an unexpected exception while processing the request.");
             output.writeMessageBegin("ping", thrift.MessageType.EXCEPTION, requestId);
             thrift.TApplicationExceptionCodec.encode(result, output);
             output.writeMessageEnd();
             return output.flush();
         });
     }

BACKGROUND

Two kinds of exceptions can be thrown by a handler processing a Thrift request:

- Those that are defined as `exceptions` in a .thrift file. The server serializes them and sends them to the client. Clients should expect them to happen from time to time and should handle them gracefully.
- Non-Thrift exceptions: when the server experiences an unhandled error and an exception not defined in a .thrift file is throw out of the handler function. The server has catch-all exception handling that returns a `TApplicationException` to the client containing the message from the exception.

THIS CHANGE

Stop sending the exception message to the client. I think this is a bad idea from a security standpoint. Random exceptions raised by the server could potentially contain sensitive info like passwords. One hopes this never happens, of course, but we have no control over the code people write. It's not reasonable default behavior to send those messages to clients. The client could be untrusted or the transport could be insecure.

It could be argued that a flag should be added to enable the server to send these messages to clients. I think that's a reasonable thing to do (but I don't plan to do it).

I updated both the Apache code and the thrift-server code, and the tests for both.

Here's the diff of a `ping` function generated for thrift-server before and after this change:
```
--- before	2020-07-26 22:06:27.000000000 -0400
+++ after	2020-07-26 22:06:19.000000000 -0400
@@ -1,23 +1,23 @@
     public process_ping(requestId: number, input: thrift.TProtocol, output: thrift.TProtocol, context: Context): Promise<Buffer> {
         return new Promise<string>((resolve, reject): void => {
             try {
                 input.readMessageEnd();
                 resolve(this._handler.ping(context));
             }
             catch (err) {
                 reject(err);
             }
         }).then((data: string): Buffer => {
             const result: IPing__ResultArgs = { success: data };
             output.writeMessageBegin("ping", thrift.MessageType.REPLY, requestId);
             Ping__ResultCodec.encode(result, output);
             output.writeMessageEnd();
             return output.flush();
         }).catch((err: Error): Buffer => {
-            const result: thrift.TApplicationException = new thrift.TApplicationException(thrift.TApplicationExceptionType.UNKNOWN, err.message);
+            const result: thrift.TApplicationException = new thrift.TApplicationException(thrift.TApplicationExceptionType.UNKNOWN, "The server experienced an unexpected exception while processing the request.");
             output.writeMessageBegin("ping", thrift.MessageType.EXCEPTION, requestId);
             thrift.TApplicationExceptionCodec.encode(result, output);
             output.writeMessageEnd();
             return output.flush();
         });
     }
```
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant