我正在尝试通过断言DynamoDB中其字段UserId实际上是登录的项event.requestContext.identity.cognitoIdentityId中的项来进行ACL。
但是，恐怕它可以像HTTP标头等一样被欺骗。
我的问题是，那安全吗？
答案 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。