You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 23, 2018. It is now read-only.
The number of services that can be added per POST /service is limited to 5, but there's nothing in place to stop a malicious user from sending requests containing the same token with up to 5 new services to add to the chain. revisit-tether similarly performs no range checking when playing tethers, so one tether can cause the hub to perform a very large number of requests for a single tether.
Open the dev tools and do: $('#token').val('<tether ID>')
Choose a new image and add more services
Click Create
This could be more easily/speedily exploited with an external script, and also allows malicious users to modify other users' tethers once they are created (if, for instance, someone links a nice sequence for others to replay).
My recommendation would be for tethers to be stored in a single DB key and created in a single call, failing if they already exist, but another option would be to range-check/limit on playback, or range-check/limit on insert (adds a DB query to insert).
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
The number of services that can be added per
POST /service
is limited to 5, but there's nothing in place to stop a malicious user from sending requests containing the same token with up to 5 new services to add to the chain. revisit-tether similarly performs no range checking when playing tethers, so one tether can cause the hub to perform a very large number of requests for a single tether.To reproduce in a browser:
$('#token').val('<tether ID>')
This could be more easily/speedily exploited with an external script, and also allows malicious users to modify other users' tethers once they are created (if, for instance, someone links a nice sequence for others to replay).
My recommendation would be for tethers to be stored in a single DB key and created in a single call, failing if they already exist, but another option would be to range-check/limit on playback, or range-check/limit on insert (adds a DB query to insert).
The text was updated successfully, but these errors were encountered: