Browser-based attacks on WebDriver implementation

The security section of the specification does not mention the risk associated with exploiting the user browser for executing commands on the WebDriver. In practice, several implementation of WebDriver have been found to be vulnerable to CSRF attacks, DNS rebinding attacks and cross-origin/same-site request forgery attacks. In all cases, this could be used to execute arbitrary shell commands.

Relevant quote from the specification:

The remote end can include a configuration option to limit the accepted IP range allowed to connect and make requests. The default setting for this might be to limit connections to the IPv4 localhost CIDR range 127.0.0.0/8 and the IPv6 localhost address ::1. [RFC4632]

(Another security concern, is that any local user can access these services.)

These vulnerabilities are possible because of the somewhat-weak security model of WebDriver instances which do not support any form of authentication.

An implementation could mitigate these risks by:

• adding optional support for some form of HTTP-level authentication;
• validating the Content-Type header (CSRF protection);
• validating the Host header (DNS-rebinding protection);
• adding support for listening on PF_LOCAL sockets.

The WebDriver specification should probably:

• mention the risk of CSRF and DNS rebinding attacks (in the security section);
• mention the risk of attacks by local users (in the security section);
• suggest support for some HTTP-based authentication;
• explicitly allow to validate Content-Type of WebDriver requests (as a simple way to prevent CSRF attacks);
• suggest validating the Host header (in order to prevent DNS rebinding attacks).

Start with the specification's security section and the referenced remote end definition. Review the listed CSRF, DNS rebinding, cross-origin request forgery, and local-user risks; the work is done when the specification clearly documents these risks and the proposed mitigation guidance.