How do I configure an Amazon AWS Lambda function to prevent tailing the log in the response?

Question

Please see this:

http://docs.aws.amazon.com/lambda/latest/dg/API_Invoke.html

LogType

You can set this optional parameter to Tail in the request only if you specify the InvocationType parameter with value RequestResponse. In this case, AWS Lambda returns the base64-encoded last 4 KB of log data produced by your Lambda function in the x-amz-log-result header.

Valid Values: None | Tail

So this means any user with valid credentials for invoking a function can also read the logs this function emits?

If so, this is an obvious vulnerability that can give some attacker useful information regarding processing of invalid input.

How do I configure an Amazon AWS Lambda function to prevent tailing the log in the response?

Update 1

1) Regarding the comment: "If a hacker can call your Lambda function, you have more problems than seeing log files."

Not true: Lambda functions are also meant to be called directly form client code, using the SDK.

As an example, see the picture below from the book "AWS Lambda in Action":

2) Regarding the comment: "How is this a vulnerability exactly? Only someone you have provided AWS IAM credentials would be able to invoke the Lambda function."

Of course, clients do have some credentials, most of the time (for example, from having signed in to your mobile app with their Facebook account, through Amazon Cognito). Am I supposed to trust all my users?

3) Regarding the comment: "Only if you have put some secure information to be logged."

Logs may contain sensible information. I'm not talking about secure information like passwords, but simply information to help the development team debugging, or the security team finding out about attacks. Applications may log all kinds of information, including why some invalid input failed, which can help an attacker learn what is the valid input. Also, attackers can see all the information the security team is logging about their attacks. Not good. Even privacy may be at risk depending on what you log.

Update 2

It would also solve my problem if I could somehow detect the Tail parameter in the Lambda code. Then I would just fail with a "Tail now allowed" message. Unfortunately the Context object doesn't seem to contain this information.

Answer 1

You're right, not only it's a bad practice, it's obviously (as you already understood) introducing security vulnerabilities.

If you look carefully in the book you will also find this part:

which explains that in order to be more secure, the client requests should hit Amazon API gateway which will expose a clean API interface and which will call the relevant lambda-function without exposing it to the outer-world.

An example of such API is demo'ed in a previous page:

By introducing a middle-layer between the client and AWS-lambda, we take care of authentication, authorization, access and all other points of potential vulnerability.

Answer 2

This is a comment. While this should be a comment, I am sorry that I do not have yet enough stackoverflow reputation to do so.

Before commenting on this, please note that lambda Invoke may result in more than one execution of your lambda (per AWS documentation)

Invocations occur at least once in response to an event and functions must be idempotent to handle this.

As the LogType is documented as a valid option, I don't think you can prevent it in your backend. However, you need to have a workaround to handle it. I can think of

1- Generate a junk 4KB tail log (by console.log() for example). Then, the attacker will get a junk info. (incur cost only in case of attacker)

2- Use step functions. This is not only to hide the log but to overcome the problem of 'Invocations occur at least once' and have a predictable execution of your backend. It incurs cost though.

Answer 3

I think you can't configure AWS Lambda to prevent tailing the log in the response. However, you could use your own logging component instead of using the one provided by Amazon Lambda to avoid the possibility to expose them via the LogType parameter.

Otherwise, I see your point about adding complexity, but using API Gateway is the most common solution to provide the possibility to invoke Lambdas for clients applications that you do not trust.