search

w3c-ccg / did-method-web

DRAFT: did:web Decentralized Identifier Method Specification
https://w3c-ccg.github.io/did-method-web/
Other
32 stars 17 forks source link

Deny off-domain redirects #55

Open msporny opened 2 years ago

msporny commented 2 years ago

It has been proposed that DID Web resolution follows HTTP redirects. If this is true, then there are security implications for blindly following re-directs. For example, if a redirect sends you off of the original domain then it allows an attacker to compromise a site merely by controlling the redirect rules rather than placing a file on the site. If we don't allow redirects off of the original domain, it makes it difficult to move a DID Web ID to a different domain in the future. There are trade-offs each way.

One solution to the problem is to restrict redirects for now until we have more experience for redirecting off of the original domain (we may choose to never do this).

One potential algorithm would be:

  1. Do not allow re-directs.

Another potential algorithm would be:

  1. When resolving a DID Web URL, store the original request URL.
  2. Allow re-directions up to N times (to prevent redirect loops). For each re-direct, ensure that the domain does not change, this includes ensuring port numbers don't change (you can't go from port 80 to port 8080).
  3. The final resolved DID Web DID Document must contain an id field that matches the initial canonicalized DID Web URL (see issue #54).

I haven't put a great deal of thought into all the attack vectors for redirects yet, just trying to propose something that can be refined in this issue.

gribneau commented 2 years ago

-1 on following HTTP 3xx redirects.

Returning any 3xx redirect response requires server configuration. An internal rewrite can be accomplished with similar effort, and does not require the client to make another request to a new target URL.