Then there's the question of checking to see if the data in the
envelope is consistent with data outside the envelope. A good way
to do this is to ignore the data outside the envelope and only use
the verified, enveloped data.
This is precisely the problem. But think about what "only using the
data inside the envelope" means in the context of OAuth -- stuffing
all the relevant parts of the HTTP request inside the envelope. I
admit that I'm not up to speed on the latest OAuth specs, but in
earlier versions, there were several parts of the HTTP request that
were included under the OAuth signature, so this would amount to a lot
of duplication.
The alternative is to somehow ensure that the data outside the
envelope are the same as the data inside the envelope. Which brings
us back to the two mechanisms we were talking about before for doing
that:
1. Send the enveloped data and checking that the inside matches the
outside
2. Just send the envelope (not the data) and reconstruct the data from
the request based on the outside information.
Just using a JSON token / Magic Signature object that includes all the
relevant fields requires that you do (1), which has the risk that the
recipient can skip the check. You can do (2) with a "meta-MagicSig"
where the content is included by reference (e.g., to field names) and
the actual enveloped data structure is built and verified by the
recipient.
As far as a specific attack vector, I think the idea is that a
recipient could get a request like the following (again, with made-up
syntax)...
POST /malevolent.php HTTP/1.1
Authorization: oauth { method: "GET", path: "innocuous.jpg", sig:
valid_sig }
... and based on the validity of the signature, go ahead and grant the
request.
--Richard
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
