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
Currently, the rule allowing the deletion of protected channels is just based on the host part of the request being "localhost". This is technically exploitable by a remote request if the host header is explicitly set.
If the intention is to truly require the client to be local to a hub node, there are numerous ways to test for that. One would be to require that the "REMOTE_ADDR" header be "127.0.0.1". There might be better options for this, too, or some other easy to use http ACL library out there that would allow a simple rule like this now, and more complex ones later if we ever need to actually manage remote access to editing protected channels.
The text was updated successfully, but these errors were encountered:
Currently, the rule allowing the deletion of protected channels is just based on the host part of the request being "localhost". This is technically exploitable by a remote request if the host header is explicitly set.
If the intention is to truly require the client to be local to a hub node, there are numerous ways to test for that. One would be to require that the "REMOTE_ADDR" header be "127.0.0.1". There might be better options for this, too, or some other easy to use http ACL library out there that would allow a simple rule like this now, and more complex ones later if we ever need to actually manage remote access to editing protected channels.
The text was updated successfully, but these errors were encountered: