可以欺骗event.requestContext.identity.cognitoIdentityId吗?

时间:2019-06-08 12:33:29

标签: amazon-web-services amazon-cognito acl spoofing

我正在尝试通过断言DynamoDB中其字段UserId实际上是登录的项event.requestContext.identity.cognitoIdentityId中的项来进行ACL。

但是,恐怕它可以像HTTP标头等一样被欺骗。

我的问题是,那安全吗?

2 个答案:

答案 0 :(得分:1)

否,不能以与HTTP请求标头相同的方式进行欺骗。如果请求通过作为Lambda代理集成的API网关传入,则浏览器无法执行任何操作来覆盖这些值,因为Lambda事件结构的这一部分是由API Gateway创建的,而不是从请求中复制的。注入HTTP请求的任何内容都将出现在事件结构的其他位置-不在此处。 (HTTP请求位于event.input中,它是event.requestContext的同级对象,不是父对象。)

但是再说一次...是的,在某些其他配置错误的情况下,这可能会被欺骗-例如,如果您的Lambda函数允许自己通过API Gateway部署以外的方式进行调用-那么,调用者当然可以编写与任何HTTP请求均无关的整个event结构,并使用它来调用Lambda函数。也许这太明显了,因为它是您可以从控制台测试Lambda函数的方式所隐含的,但是为了全面起见,我将其提及。使用Lambda控制台的测试功能向您的Lambda函数发送伪造的测试事件,然后Lambda函数自然会处理您发送的事件。

因此,毫不奇怪,有了粗心和过于宽泛的权限,是可以的,一切皆有可能...但是按原意在API网关后面使用,作为Lambda代理集成,我会说不。

答案 1 :(得分:0)

我已经研究了这个问题很多小时了。

我发现了这个post,作者通过以下方式从令牌中提取了userId

const userId = await services.getUserIdFromToken(event.headers.Authorization);

这似乎是处理设置userId的更安全的方法,但我看到的所有其他示例都使用event.requestContext.identity.cognitoIdentityId