Security and Architecture #73
Replies: 3 comments 2 replies
-
We apply CORS on the server though so I'm not too sure how this is "just to protect browsers" maybe if you could explain that better. It would be cool as well if you could make a demo of this exploit but if not I can probably find one online. Other than that I mostly agree with what's been said :) |
Beta Was this translation helpful? Give feedback.
-
Just a brief summary on yesterday:
Tested using python as you requested: We shouldn't be able to create a congregation this way (especially without auth or empty data) and it shouldn't be returning a 201: '{"congregation":{"ID":0,"CreatedAt":"0001-01-01T00:00:00Z","UpdatedAt":"0001-01-01T00:00:00Z","DeletedAt":null,"id":0,"signature":"e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855","name":"","address":"","lat":"","lon":"","phoneNumbers":null,"users":null}}' On that note, I also noticed it's accepting empty data. Because I believe the Go structs just use eeach type's zero-values to fill it out automatically for some reason because it tries to write the request's body to the struct pointer (Go's zero values will come into play because the dto's required data types are not marked as pointers because only then they can be nil values). So in essence, if a Go struct field is not a pointer, it will be marked as it's zero value (for strings it is "", for integers 0, etc.) otherwise it can be nil for pointer fields. Like: type SomeDto struct {
value int
} If i pass the struct pointer to request body, and Now consider this: type SomeDto struct {
value *int
}
So now we need to make sure the DTOs are required when validating endpoint request DTOs. Then we can stop someone from creating random 0 value'd objects in the database. So notes to recap:
Just notes for both of us to keep in mind. |
Beta Was this translation helpful? Give feedback.
-
Just found code example using |
Beta Was this translation helpful? Give feedback.
-
Just some notes and my thoughts regarding security and our current arch.
People can potentially programmatically access our endpoints. To limit this, we have CORS. But there are ways to bypass them, one way I can think of is setting up a proxy. But CORS doesn't even cover server-to-server comms, just to protect browsers. So in theory, someone could just programmatically call our endpoints like that.
Some thoughts I had:
Although JWTs can be stored by a script someone makes, at least we will eradicate most of the chances the 'bad actor' has of abusing our API by ensuring they have limited API privileges with an RBAC system.
Sorry if this may seem overkill lol but imo it's better if we do the easy stuff now so that it doesn't get too difficult to refactor later. After writing the background functionality, we can literally just slip in
middleware.Authenticate()
before the actual handler. Easy!Thoughts?
@j-koziel
Beta Was this translation helpful? Give feedback.
All reactions