search

ctnadovich / randowizard

Randonneuring.org web application
GNU Affero General Public License v3.0
0 stars 1 forks source link

Add auth signature to future_events #26

Closed ctnadovich closed 4 months ago

ctnadovich commented 4 months ago

future_events needs an authentication signature so that app can know the data is authentic for that region. Perhaps plaintext could be the region number, minimum_app_version, a timestamp or nonce, and a hash of the event_list data.

ctnadovich commented 4 months ago

A nonce provided by the app is probably the best way, but this would require an additional parameter on the request. If the server adds a salt/nonce, a malicious URL could replay it. This doesn't quite allow the evil doer to alter parameters themselves, but they could play back previously recorded data with that had (more maliciously desirable) parameters than the current data.

ctnadovich commented 4 months ago

There is now an optional additional parameter on the future_events request that allows the app to provide a nonce. The returned future_events object now has a 'signature' element at the top level that is the SHA-256 hash of the plaintext "$club_acp_code-$nonce-$minimum_app_version-$event_list_hash-$secret", where the event_list_hash is the SHA-256 of json_encode($event_list); This should allow the secure inclusion of event/control app settings in the future_events data. For example, the control-proximity could be specified for controls without fear that riders would maliciously exploit this capability. It also locks down the existing vulnerabilty that would allow riders to alter control location/style. Of course, support in the app is necessary for this feature to be effective. Old versions of the app ignore the signature.