03.05.2011 22:26, Evgeniy Khramtsov wrote:
26.02.2011 00:26, Matthew A. Miller wrote:
On Feb 25, 2011, at 08:14 , Joe Hildebrand wrote:
If the redirect comes from a trusted source (e.g. over HTTPS with a
verified
certificate) then this can work ok, although we've decided that the
BOSH
see-other-uri error is easier to control through XMLHTTPRequest,
particularly when doing CORS.
Be careful that you don't blindly accept redirects, however, or you are
trivial to man-in-the-middle attack.
If the redirect is via HTTP 3xx+cookie, then CORS already has a
solution via Access-Control-* headers. However, the XMLHttpRequest
objects in browsers don't always let you know this happened.
Maintaining the redirect then becomes the responsibility of the
browser, which may not be desirable for BOSH (I don't think it's
desirable, anyway (-: ).
If done via the "see-other-uri" BOSH error condition, then this is
definitely a concern. On the plus side, the BOSH software (whether
browser-based or stand-alone) knows a redirect is happening in this
case, so you have a better opportunity to protect yourself at the
application-level.
So what is the decision? What approach should we choose?
My thoughts:
1) <see-other-host/> is a bit different stuff, it doesn't allow you to
redirect without closing the C2S session, just because it's <stream:error/>
2) if you don't use SSL, then you are affected by MITM attack no matter
what transport you use.
3) security considerations of cookies are covered by the RFC6265. Peter
is an Area Director of the corresponding WG, so he could say more if
there are huge concerns about the topic which stops us to use
30x+Cookies, but he had no objections :)
--
Regards,
Evgeniy Khramtsov, ProcessOne.
xmpp:[email protected].
