Closed ekkards closed 6 years ago
Yes. I believe you are correct. This video and app is the ABSOLUTE BEST example I've found for marrying Cognito Federated Identities and Cognito User Pools, but it still has some gaps. But it has way fewer gaps that others (e.g. https://github.com/ionic-team/ionic2-starter-aws).
In the spacefinder app, methods that use Cognito User Pools Authorizer or the Custom Authorizer have no way to know if the user ID from Cognito Federated Identities goes with the claim.
From memory, here's what I did to fix it in my app:
Hi there- To comment on this further, for the sake of time and due to this being a prototype reference app, we did send the userID through the payload without validating it. However, the much better way to do this, which would prevent spoofing is to have the effective IAM policy of the user (either from the IAM role assumed with Cognito Federated Identities or from the IAM policy returned by a custom authorizer with API Gateway) have only allow the user to invoke API operations on their particular user ID as a path parameter. For example, /users/userIdGuid and /users/userIdGuid/*. You can use either the identity ID from Cognito User Pools via an IAM policy variable as we have setup in our IAM policy, or if you're exclusively using Cognito User Pools with Custom Authorizers, use the unique subscriber ID of the user in the user pool.
Then, in the code of your function to do any modifications related to a user, pull the user ID out of the path parameter rather than the body, which is already being enforced via the execution policy so if the function code can even be invoked, you know that the path parameter sent through is that of the valid, actual user (unless an admin is calling operations and you've given them more broad permissions).
Hope this helps clarify a more secure method of validating the user ID. I think this is perhaps the most simple approach to solve this problem and prevent spoofing.
I was trying to follow the identity flow, but somehow it either disappeared or I lost track.
When booking a location, the userId is sent as part of the body request, as your video shows at https://youtu.be/n4hsWVXCuVI?list=PLhr1KZpdzukdAg4bXtTfICuFeZFC_H2Xq&t=2191 This looks dangerous, as the user could be able to insert some other userId, not his own.
Apparently, authorizer.js does receive the real userId,
const pId = payload.sub;
does not use this for restricting permissions, but passes it alongpolicy.principalId = this.principalId;
The booking.js just takes the values as they come and does not check for identity.
I would assume, if a user managed to insert a wrong userId the data would be entered incorrectly into the database.
Do you agree? If yes, what would be the best way to prevent it?