Re: CORS Background slides

On Wed, Nov 4, 2009 at 5:57 PM, Maciej Stachowiak <mjs@apple.com> wrote:
> 5) I would summarize the tradeoff between this mechanism for a simple
> cross-site communication scenario vs. the CORS way to do it as follows:
>
>    a) In the CORS-based protocol, if you change the scenario in a way that
> violates the DBAD discipline, you may introduce a CSRF-like vulnerability.
> In other words, making a programming error that violates DBAD can introduce
> a vulnerability into the system.
>
>    b) In the GuestXHR-based protocol, if you make a programming error in
> generating or maintaining the confidentiality of the shared secret, you may
> introduce a CSRF-like vulnerability.

Just to clarify the terminology, if the shared secret leaked, the
resulting attack would not be CSRF-like, but rather would be a direct
use of a stolen secret key. The situation is analogous to an attacker
somehow reading the victim site's cookies in solution a), and then
making direct use of them. In a CSRF-like attack, the attacker never
obtains direct knowledge of a secret key, but instead causes a deputy
to issue requests on behalf of the attacker.

> 6) Combining the shared secret mechanism with the Origin/Cookie mechanism
> increases overall security of the solution. Then you have to make *both* an
> error in violating DBAD and in management of the shared secret to create a
> vulnerability. Making only one of these mistakes will not introduce a
> CSRF-like vulnerability. Thus, running the proposed protocol over XHR2+CORS
> provides defense in depth relative to the GuextXHR-based solution.
>
>
> Combining 5 and 6, the risk of programming errors with CORS-only solutions
> has to be weighed against the risk of programming errors in shared-secret
> solutions plus the loss of the ability to create defense in depth by
> combining Origin/Cookie checks with a shared secret.

I'm still unclear on how you intend to provide defense in depth by
using Origin. You are right that there's more that can be done to
reduce the risk of programming with shared-secrets though. A lot can
be done without any browser support. For example, see the security
model for my web_send JavaScript library:

http://waterken.sourceforge.net/web_send/#securityModel

In this library, shared secrets are held in URLs, which are in turn
only exposed to JavaScript code as opaque objects. Since the
JavaScript code never gets direct access to the shared secrets, it is
unable to accidentally, or even maliciously, leak the secrets. There's
no need to study this library for the purposes of this discussion. It
just provides an example of how programming with shared secrets can be
made pleasant and safe.

--Tyler

-- 
"Waterken News: Capability security on the Web"
http://waterken.sourceforge.net/recent.html

Received on Monday, 9 November 2009 18:37:11 UTC