Re: Origin (was: Re: XHR LC Draft Feedback)
On Sat, Jun 21, 2008 at 6:51 PM, Bjoern Hoehrmann [EMAIL PROTECTED] wrote: The stated goal was to balance easy protection against session riding attacks without compromising privacy too much. Allowing session riding via some sites but not others is something that cannot be done securely today without major effort as whatever information is used to tell good requests apart from bad requests may either be absent or faked. The Origin header is hard to fake because XHR2 doesn't allow it to be set across domains and XHR1 is for same-origin requests only. A supporting browser will not omit the Origin header for POST request. In situations were no origin is appropriate (say from for a data URL), a supporting browser will send the value null. Consider a site like Facebook or Slashdot that uses a number of subdomains (e.g., stanford.facebook.com or it.slashdot.org). It is entirely reasonable for the site to POST requests between these origins. Sending Pragma: cross-site doesn't let the site use this feature to defend against CSRF, but sending Origin: http://it.slashdot.org; does. That'll remain so until any browser that does not set the header can be blocked. There are three cases: 1) Origin header missing: This is a non-supporting browser. Fall back to existing CSRF defenses. 2) Origin header has a trusted value: Accept the request. 3) Origin header has an untrusted value: Reject the request. This is the behavior of the ModSecurity rule earlier in this thread. Users of supporting browsers get enhanced CSRF protection. Attackers cannot forge the Origin header in cross-origin requests in today's browsers. Site can use the header immediately, without having to wait for non-supporting browsers to become unused. I would hope that at that point, other means of cross site and document communication are more attractive to developers than what is currently not affected by same-origin restrictions, and hope that new ways of by- passing the same-origin restrictions will not rely on the Origin header alone, so I don't think there is any real advantage. Perhaps I'm missing something? Not all web sites are contained within a single origin. This feature is not intended to enable cross-origin communication via POST requests. The feature is intended to make it easy for site developers, or web application firewall vendors, to defend against CSRF attacks. Adam
Re: ISSUE-4 (SpecContent): Should specifications decide what counts as content for transfer? [Progress Events]
Bjoern Hoehrmann wrote: * Jonas Sicking wrote: It makes no sense to me to for HTTP say that the total number of bytes should include HTTP headers. It would be similar to including the TCP headers in the IP packets IMHO. There is a big difference here, an application might not have meaningful access to the latter, but would necessarily have meaningful access to the former (even if only to the next hop). I don't see how ability to get hold of one or another makes a difference in determining whether it's the right or the wrong data. There is lots of data available that would be the wrong data, that doesn't change the fact that it's the wrong data. The consequence of not in- cluding headers would be, e.g., that on HEAD requests you would seem to never make any progress. Yes, I agree that this is somewhat unfortunate. Though in reality I doubt that it will matter much since headers are usually small enough that you don't really need progress reports on them. / Jonas
Re: Opting in to cookies - proposal
Bjoern Hoehrmann wrote: * Jonas Sicking wrote: First off, as before, when I talk about cookies in this mail I really mean cookies + digest auth headers + any other headers that carry the users credentials to a site. I don't quite see why you would mix these. Is there anywhere where I can read up on the use cases for an extra feature to enable the transmission of cookies if not included by default? Especially for users credentials in cookies it is difficult to imagine real world applications that would depend on or at least greatly benefit from such a feature. I'm not quite following what you are asking here. My proposal is about giving a site the ability to enable two modes of Access-Control: 1. Allow a third-party site to read the data on this resource, and/or perform unsafe methods in HTTP requests to this resource. When these requests are sent any cookie and/or auth headers (for the resource) are included in the request, just as if had been a same-site XHR request. 2. Same as above, but requests never include cookies or auth headers are never included. In the spec currently only mode 1 is possible. I suggest that we make mode 2 possible as well. I guess you can call it opting out of cookies as well... / Jonas
Re: ISSUE-5 (Unexpanded Entities): Wording for the Treatment of Unexpanded Entity References and Entity Replacement Markup [Element Traversal]
On Sun, 22 Jun 2008 00:18:45 +0200, Bjoern Hoehrmann [EMAIL PROTECTED] wrote: Anne's proposed solution is not valid either, except when applied to DOM Core, rescinding EntityReference nodes alltogether, as the issue is about how to implement this interface if you do have EntityReference nodes in the tree (or want your code to work whether or not you do). My proposal is indeed to fix DOM Core. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: IRC logging
On Sat, Jun 21, 2008 at 4:34 PM, Bjoern Hoehrmann [EMAIL PROTECTED] wrote: Unfortunately no, but so far it's the best we've got available to us. It's always possible to fill in any gaps from other's personal IRC logs; it's quite simple for Krijn to insert them if someone sends them to him. Many would regard this as serious breach of protocol, unless the people whose conversations have been logged in the logger bot's absence approve of that explicitly for the occasion for various reasons; unreasonable as that may seem. It does seem quite unreasonable. Why do you think it would be a serious breach of protocol? Which protocol? Making approval of logging contingent on the presence of the bot in channel seems rather arbitrary. Why not just say that approval for logging is implicit for anyone present in the channel, at any time? If the decision is made to log the channel, I don't see why it should matter whether it is logged directly to the web by the bot, or via someone else's private logs which are later published (e.g. if the bot is offline due to network issues). Gavin
[XHR] Request charset is limited to UTF-8 for x-www-form-urlencoded data
Hi!
In the current spec
(http://www.w3.org/TR/2008/WD-XMLHttpRequest-20080415/) I do not see
the possibility to POST application/x-www-form-urlencoded data with
charset other than UTF-8. I think this is limiting factor, which
should be avoided. UTF-8 is good versatile encoding but it is not
always practical to use it. When developing sites in Russian, for
example, we mainly use windows-1251 encoding, UTF-8 is rarely used as
it doubles network traffic.
The spec says:
data is a DOMString
Encode data using UTF-8 for transmission.
If a Content-Type header is set using setRequestHeader() set the charset
parameter of that header to UTF-8.
In my practice application/x-www-form-urlencoded data usually comes
from custom javascript encoding function (as DOMString). When sending
it to server over XHR I use setRequestHeader('Content-type',
'application/x-www-form-urlencoded; charset=windows-1251'). This
informs the server of the correct encoding. This all worked well until
FF3 followed the spec.
I think when the user explicitly sets charset with setRequestHeader()
the browser should not override that. UTF-8 should be used only as
default.
Regards,
Yaroslav Stavnichiy
