Re: Origin enables XSS to escalate to XSRF (was: security issue with XMLHttpRequest API compatibility)
On Mon, Jun 8, 2009 at 10:24 AM, Tyler Close tyler.cl...@gmail.com wrote: On Sun, Jun 7, 2009 at 4:18 PM, Mark S. Millererig...@google.com wrote: On Sun, Jun 7, 2009 at 3:28 PM, Adam Barth w...@adambarth.com wrote: Yeah, I can see that as being useful. I encourage you to propose a new API that does this. The Origin-header-as-CSRF-defense already provides for this possibility. Is there something specific you'd like me to change in the I-D to support this new API? Yes. I will take you up on this invitation. Thanks! For CORS http://www.w3.org/TR/access-control/, and other parts of web-apps, I think the above agreement is the important take-away from this discussion. For sites with advertising, or other third-party widgets, it would be nice to have a way for code to issue network requests without impersonating the hosting page's Origin. First, I agree with Tyler that this agreement together with the agreement just now with Anne are the important take aways. These agreements do not depend on the outcome of the remaining XSS issue Adam and I are debating. I suggest that discussion of how to turn these agreements into specs continue on the XHR without user credentials thread. Those interested in what upcoming specifications should say, rather than how many vulnerabilities can dance on an XSS, can stop reading now. I suggest that the debate about XSS risks continue here under the original subject line since it describes the remaining issue we're still debating. On Sun, Jun 7, 2009 at 11:18 PM, Adam Barth w...@adambarth.com wrote: On Sun, Jun 7, 2009 at 6:24 PM, Mark S. Miller erig...@google.com wrote: On Sun, Jun 7, 2009 at 4:29 PM, Adam Barth w...@adambarth.com wrote: Right, but once the attacker has XSSed site A, the attacker learns the secret token necessary to issue the next request in the chain to site A regardless of the method. Recall that this is in response to On Sun, Jun 7, 2009 at 2:53 PM, Mark S. Miller erig...@google.com wrote: If servers at A don't freely hand out such tokens in response to guessable GET requests, So, if servers at A don't do this, how does the attacker, having XSSes site A, learn the secret token necessary to issue the next request? The same way the user does: by generating a click event on whatever DOM element leads to the next page. Under any system which presents ambient origin credentials to authorize access, whether http auth info, cookies, or identiied Origin headers, an XSS against page X on origin A can abuse all that user's authority associated with *origin A*. In a pure secret token based system, an XSS against page X on origin A can abuse all the authority held by *page X* -- the authority authorized by the secret tokens that page X knows and all authority reachable by guessable traversal from X starting from knowledge of these tokens. If A's website is structured according to both RESTful and POLA (Principle of Least Authority), then most of A's pages will hold less much less authority than the authority associated with A as a whole. This argument is exactly parallel to the Solitaire criticism of conventional ACL-oriented OSes http://video.google.com/videoplay?docid=-7961423532989255419. Just as a desktop Solitaire appication does not need the authority to delete your files, a web Solitaire game running on gaming site A does not need authority to delete all the other games (or whatever) you have in progress at that website. Just as a conventional OS grants Solitaire this authority it does not need, conventional web credential systems grant to the web Solitaire game all your authority at that site/origin. If either Solitaire has an exploitable vulnerability, then the attacker can abuse this excess authority. However, if either Solitaire -- the application or the web page -- only holds the authority it needs to perform its legitimate job, then if it has an exploitable vulnerability, the attacker can only abuse that limited authority. caveats Unfortunately, just as processes running on the same account on a conventional OS can mess with each other, so can frames running as the same origin. The limits to Solitaire's abuse potential above includes the authority of other A-origin frames running at the same time as Solitaire. This makes it difficult to reason about precisely how much these measures help; but it is still clear that they would often help a great deal depending on the users habits. Of course, only a handful of people -- all of whom you and I probably know -- operate sites as pure secret token based with no ambient credentials whatsoever. Any transitional strategy has to accomodate some kind of login, where the login page makes a transition from a page with little authority (itself) to a page holding all of that user's authority at that origin (say, that user's home page at that origin). In order for all the rest of this hypothetical reduction of XSS vulnerability to pay off, we need
Re: Origin enables XSS to escalate to XSRF (was: security issue with XMLHttpRequest API compatibility)
The below doesn't appear to be a technical criticism of Origin-as-CSRF-defense but rather a recommendation for a certain design pattern for building web applications. That design pattern seems useful. You might consider building a framework a la Rails that makes it easy for developer to adopt this design pattern. (Perhaps that's what the Waterken server is?) I've included some comments inline. On Mon, Jun 8, 2009 at 11:05 PM, Mark S. Millererig...@google.com wrote: Under any system which presents ambient origin credentials to authorize access, whether http auth info, cookies, or identiied Origin headers, an XSS against page X on origin A can abuse all that user's authority associated with *origin A*. In a pure secret token based system, an XSS against page X on origin A can abuse all the authority held by *page X* -- the authority authorized by the secret tokens that page X knows and all authority reachable by guessable traversal from X starting from knowledge of these tokens. If A's website is structured according to both RESTful and POLA (Principle of Least Authority), then most of A's pages will hold less much less authority than the authority associated with A as a whole. This argument is exactly parallel to the Solitaire criticism of conventional ACL-oriented OSes http://video.google.com/videoplay?docid=-7961423532989255419. Just as a desktop Solitaire appication does not need the authority to delete your files, a web Solitaire game running on gaming site A does not need authority to delete all the other games (or whatever) you have in progress at that website. Just as a conventional OS grants Solitaire this authority it does not need, conventional web credential systems grant to the web Solitaire game all your authority at that site/origin. If either Solitaire has an exploitable vulnerability, then the attacker can abuse this excess authority. However, if either Solitaire -- the application or the web page -- only holds the authority it needs to perform its legitimate job, then if it has an exploitable vulnerability, the attacker can only abuse that limited authority. caveats Unfortunately, just as processes running on the same account on a conventional OS can mess with each other, so can frames running as the same origin. Yes. The limits to Solitaire's abuse potential above includes the authority of other A-origin frames running at the same time as Solitaire. This makes it difficult to reason about precisely how much these measures help; but it is still clear that they would often help a great deal depending on the users habits. It's unclear what user habits you have in mind. In general, relying on the user to behave a certain way is a recipe for insecurity. Of course, only a handful of people -- all of whom you and I probably know -- operate sites as pure secret token based with no ambient credentials whatsoever. Any transitional strategy has to accomodate some kind of login, where the login page makes a transition from a page with little authority (itself) to a page holding all of that user's authority at that origin (say, that user's home page at that origin). In order for all the rest of this hypothetical reduction of XSS vulnerability to pay off, we need merely run the login page itself at an origin other than A, in order to protect itself from an XSS on an application page at A. Only the transitions within A and out of A must be pure secret token based. The transitions into A can be by other means separately protected. I'm not sure this is correct. Suppose I know a stored XSS attack on page X of origin A. The user visits page X. Now, you agree that I own page X and all its descendants in the capability lattice. However, I claim I own all of origin A. Here's my plan for owning an arbitrary page Y. 1) The user visits page X. I now am running script in origin A. I call window.open(http://boring.com/;, foobar). 2) The user decides they don't like boring.com and navigate back to A in that new window. 3) The user visits page Y. 4) I call window.open(javascript:[evil script], foobar) 5) The browser notices that X and Y are from the same origin and runs my evil script in page Y. 6) I own page Y. I don't see how moving the login page off-domain helps. If the XSS vulnerability in question is on the user's A home page, then we haven't gained anything. But there will be some distribution of vulnerabilities across pages, and most of the site's pages should carry far less authority. /caveats I am not advocating that people use the above techniques by themselves to ameliorate their XSS vulnerabilities. Better to fix the XSS problem with technologies like Caja. But neither do I expect immediate pervasive adoption of Caja or of pure secret token systems. Which is one reason I see the Origin-as-CSRF-defense as being useful. The point here is simply that this is a practical scenario, both simpler and more secure than
Re: CSRF: alternative solutions
Hi Giovanni, On Mon, Jun 8, 2009 at 6:52 AM, Giovanni Campagnascampa.giova...@gmail.com wrote: As I understand from various discussions here and from articles around, I've learned that CSRF is a security leak which involves: 1) user visites http://www.mybank.com/login 2) the server sends a cookie, call it MyBankSID, with the login information 3) user visites http://www.dangerous.com/ within the expiration time of cookie 4) the user clickes a link (or sends a form) to http://www.mybank.com/pay?to=hacker 5) the browser sends MyBankSID cookie, which grants access to user's bank account 6) money goes from the user to the attacker This is a good description of a CSRF attack. There are some other variations that might be worth considering. For example, sometimes it is profitable for attacker to forge cross-site requests to http://www.mybank.com/login and thereby cause the user to be logged into mybank.com as the attacker. In addition to cookies, we could be concerned about HTTP authentication, IP-based authentication, and other authentication schemes. Solution #5 is possible, but requires a new header that proxies or firewalls may strip and current UAs don't send. In addition, it is possible that it will have the same flaws as Referer (which is very similar to Origin), like browser not sending it from https origins. We can hope to improve on the Referer header. In particular, the Origin header is sent from HTTPS origins to HTTP URLs. This is safe because the Origin header (unlike the Referer header) leaks only the host name of the HTTPS origin (not the path and query string), and the host name is already leaked via DNS. Also, I'm not sure how it would interact with manual entering of URIs, like emails or IMs which say: paste this into your browser address bar Two points here. First, these send GET requests, and you've already hypothesized (below) that the site doesn't make state-changing actions on GET requests. Second, if we wanted to send the Origin header for these requests, we can send the value Origin: null, which means that the browser doesn't know where the request came from. The site is then free to reject (or accept) the request. Then we have solution #4. This may hurt web apps that currently require sensitive cross-site requests, but I'm not sure that there are any, and they could work with automatic redirection to a login page. Architechturally, assuming that the UAs keeps authentication info and automatically sends it is a bad idea that we should not encourage, and so designing web services that require this. There have been a number of academic papers that have explored this approach. This has some really strange behavior. For example, when I follow a hyperlink from a web site to my Twitter feed, I no longer appear logged in. In general, you keep having to re-type your password all the time because you're no longer logged in. Some folks have explored heuristics for when to send cookies. For example, if you type something in the location bar, they'll send the cookies because they think the request came from you (and not from attacker.com). I can try to dig up a few citations, if you like. In general, this approach isn't able to prevent login CSRF because login CSRF doesn't depend on the browser sending cookies to the server. Lastly, solution #5 doesn't require any change in the security model I presume you mean 4. :) or in deployed web apps. The annonyance to the user could be avoided with something like remember this choice. Yet, the user interface must make very clear where the traversal started, where it will end, and what information the UAs will send authomatically. This is the solution I prefer I'm not sure what UI you have in mind here. In general, we should be careful about relying on the user to make correct security decisions. I hope that this will start a positive discussion, that could maybe improve existing and proposed CSRF prevention techniques. Me too. :) Adam
Re: XHR without user credentials
On Tue, 09 Jun 2009 03:39:19 +0200, Mark S. Miller erig...@google.com wrote: This use-case was the motivation for ADsafe, though any of the JavaScript sanitizers would do. Without some such sanitization technology, it remains unsafe to load untrusted ads directly on your page. Adam and I are still arguing fine points of just how unsafe, but there's no question that the answer is at least too unsafe. With GuestXMLHttpRequest, such sanitized ads could be allowed to call home safely without being able to impersonate their containing page's origin. Why can such ads not be embedded using a seamless sandboxed iframe from HTML5? -- Anne van Kesteren http://annevankesteren.nl/
RE: [widgets] What does it mean to have an unavailable API
Yes, that was the design. If requestFeature() is introduced, feature is basically useless. Not necessarily. There can be different security aspects for both. The basic idea is to make requestFeature() also to be a feature. Thanks. Marcin Hanclik ACCESS Systems Germany GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com -Original Message- From: marcosscace...@gmail.com [mailto:marcosscace...@gmail.com] On Behalf Of Marcos Caceres Sent: Monday, June 08, 2009 8:34 PM To: Jonas Sicking Cc: Marcin Hanclik; Scott Wilson; Henri Sivonen; public-webapps Subject: Re: [widgets] What does it mean to have an unavailable API 2009/6/2 Jonas Sicking jo...@sicking.cc: On Tue, Jun 2, 2009 at 7:28 AM, Marcin Hanclik marcin.hanc...@access-company.com wrote: Hi Scott, In BONDI we have discussed the (has/request)Feature() for some time. http://bondi.omtp.org/1.0/security/BONDI_Architecture_and_Security_v1.0.pdf, section 4.3 A few points for further discussion: 1. feature (at least in BONDI) is an abstract thing, not just one function. So hasFeature() is simply optimized checking procedure. If you check for a feature and discover that it is available, you may/should/must assume that a set of functions is available. Otherwise, you have to check each function individually and basically you cannot assume that if one functions is available, then the other is as well. 2. requestFeature() adds dynamism to the Website content. Widgets express their dependency statically by feature. http://bondi.omtp.org/1.0/security/BONDI_Architecture_and_Security_Appendices_v1.0.pdf B.2 specifies more details. Doesn't the requestFeature() make at least the security benefits of feature moot? In Another thread Marcos stated that one of the benefits of feature was that if a widget gets exploited, the exploited code couldn't get access to any features that the widget hadn't enabled using feature. However this does not seem to be true if the exploited code could simply call requestFeature() first, and then use the feature. Yes, that was the design. If requestFeature() is introduced, feature is basically useless. -- Marcos Caceres http://datadriven.com.au Access Systems Germany GmbH Essener Strasse 5 | D-46047 Oberhausen HRB 13548 Amtsgericht Duisburg Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda www.access-company.com CONFIDENTIALITY NOTICE This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited. If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.
RE: [widgets] What does it mean to have an unavailable API
Ok, that makes sense; but I have serious doubts anyone will implement that. Why? You mean because it would not sell, because it is bad by design or any other reason? Marcin Hanclik ACCESS Systems Germany GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com -Original Message- From: marcosscace...@gmail.com [mailto:marcosscace...@gmail.com] On Behalf Of Marcos Caceres Sent: Monday, June 08, 2009 8:34 PM To: Marcin Hanclik Cc: Scott Wilson; Henri Sivonen; public-webapps Subject: Re: [widgets] What does it mean to have an unavailable API 2009/6/3 Marcin Hanclik marcin.hanc...@access-company.com: Hi Scott, I can see the UC for requestFeature, though its not something we'd ever expect to use - we'd stick to just static feature declarations, as we have no way of injecting scripts into instances after they've already launched. There is an ongoing debate about requestFeature(). BONDI spec is approaching both widgets and websites and basically requestFeature() is planned to be primarily used only by websites. Ok, that makes sense; but I have serious doubts anyone will implement that. -- Marcos Caceres http://datadriven.com.au Access Systems Germany GmbH Essener Strasse 5 | D-46047 Oberhausen HRB 13548 Amtsgericht Duisburg Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda www.access-company.com CONFIDENTIALITY NOTICE This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited. If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.
RE: [widgets] PC Last Call comments, 7
Step 7 ... 10. For each element in the elements list, if the element is one of the following: A description element: If this is not the first description element encountered, then the user agent must ignore the element and its child nodes. Stop processing this element ... My point is: This sentence: If this is not the first description element encountered, then the user agent must ignore the element and its child nodes. Is descriptive. Whereas this sentence: Stop processing this element ... is imperative following the mode from: For each element in the elements list, if the element is one of the following: A description element: So I would just align the text to be either descriptive or all imperative for consitency. Thanks. Marcin Hanclik ACCESS Systems Germany GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Marcos Caceres Sent: Monday, June 08, 2009 8:34 PM To: Marcin Hanclik Cc: public-webapps Subject: Re: [widgets] PC Last Call comments, 7 Hi Marcin, I missed the following: … ignore this element/attribute. Stop processing this element … Here, better linking to the preceding “if” could add clarity. A “.” (dot) and imperative mode may result in misunderstanding (there are many instances of this case). Can you clarify what you mean here? Access Systems Germany GmbH Essener Strasse 5 | D-46047 Oberhausen HRB 13548 Amtsgericht Duisburg Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda www.access-company.com CONFIDENTIALITY NOTICE This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited. If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.
Re: [widgets] What does it mean to have an unavailable API
2009/6/9 Anne van Kesteren ann...@opera.com: On Tue, 09 Jun 2009 01:38:14 +0200, Marcos Caceres marc...@opera.com wrote: On 6/8/09 11:20 PM, Anne van Kesteren wrote: On Mon, 08 Jun 2009 20:34:19 +0200, Marcos Caceresmarc...@opera.com wrote: Yes, that was the design. If requestFeature() is introduced,feature is basically useless. Now I'm confused. hehe, join the club:) But seriously, requestFeature() is some BONDI thing so we should not be discussing it here. Web Apps does not specify this anywhere: It has no bearing on the work Web Apps is doing and should not be discussed in the context of Widgets or within this working group. It may, however, become a topic of discussion for DAP in the future; but, again, it has absolutely nothing to do with W3C widgets. You said it might influence whether or not feature stays in the specification so it seems it does have something to do with W3C widgets. And if that is indeed the effect of requestFeature(), removing feature seems like the best course of action. Like I said, as far as WebApps is concerned requestFeature() does not exists. What I meant was the requestFeature() undermines feature without addressing the security issues. -- Marcos Caceres http://datadriven.com.au
Re: [widgets] What does it mean to have an unavailable API
On Tue, 09 Jun 2009 11:32:49 +0200, Marcos Caceres marc...@opera.com wrote: Like I said, as far as WebApps is concerned requestFeature() does not exists. What I meant was the requestFeature() undermines feature without addressing the security issues. I'm getting more and more confused. You claim you do not understand requestFeature(). You claim requestFeature() makes feature useless. You claim requestFeature() is irrelevant with respect to feature. And now you claim requestFeature() is less secure than feature. I do not get at all the feeling that this feature is ready for standardization. -- Anne van Kesteren http://annevankesteren.nl/
Re: CSRF: alternative solutions
2009/6/9 Adam Barth w...@adambarth.com: Hi Giovanni, On Mon, Jun 8, 2009 at 6:52 AM, Giovanni Campagnascampa.giova...@gmail.com wrote: As I understand from various discussions here and from articles around, I've learned that CSRF is a security leak which involves: 1) user visites http://www.mybank.com/login 2) the server sends a cookie, call it MyBankSID, with the login information 3) user visites http://www.dangerous.com/ within the expiration time of cookie 4) the user clickes a link (or sends a form) to http://www.mybank.com/pay?to=hacker 5) the browser sends MyBankSID cookie, which grants access to user's bank account 6) money goes from the user to the attacker This is a good description of a CSRF attack. There are some other variations that might be worth considering. For example, sometimes it is profitable for attacker to forge cross-site requests to http://www.mybank.com/login and thereby cause the user to be logged into mybank.com as the attacker. In addition to cookies, we could be concerned about HTTP authentication, IP-based authentication, and other authentication schemes. 1) I cannot understand what advantages has the attacker into logging the user with attacker's credentials. I expect that the user will notice the different account used (for example in the web app interface) 2) I used cookies in the example, but any state information automatically sent is usable Solution #5 is possible, but requires a new header that proxies or firewalls may strip and current UAs don't send. In addition, it is possible that it will have the same flaws as Referer (which is very similar to Origin), like browser not sending it from https origins. We can hope to improve on the Referer header. In particular, the Origin header is sent from HTTPS origins to HTTP URLs. This is safe because the Origin header (unlike the Referer header) leaks only the host name of the HTTPS origin (not the path and query string), and the host name is already leaked via DNS. This is one flaw, which can be corrected into Referer (dropping the query, making path /). The other is firewall and proxies stripping it: if they remove Referer, it is possible that they will strip Origin as well. Also, I'm not sure how it would interact with manual entering of URIs, like emails or IMs which say: paste this into your browser address bar Two points here. First, these send GET requests, and you've already hypothesized (below) that the site doesn't make state-changing actions on GET requests. Second, if we wanted to send the Origin header for these requests, we can send the value Origin: null, which means that the browser doesn't know where the request came from. The site is then free to reject (or accept) the request. Agreed on both (but we should define exactly what Origin:nully and Origin:empty mean and when both must be used) Then we have solution #4. This may hurt web apps that currently require sensitive cross-site requests, but I'm not sure that there are any, and they could work with automatic redirection to a login page. Architechturally, assuming that the UAs keeps authentication info and automatically sends it is a bad idea that we should not encourage, and so designing web services that require this. There have been a number of academic papers that have explored this approach. This has some really strange behavior. For example, when I follow a hyperlink from a web site to my Twitter feed, I no longer appear logged in. In general, you keep having to re-type your password all the time because you're no longer logged in. We can restrict this only to non-safe requests. Some folks have explored heuristics for when to send cookies. For example, if you type something in the location bar, they'll send the cookies because they think the request came from you (and not from attacker.com). I can try to dig up a few citations, if you like. It may be useful for the discussion, thanks. In general, this approach isn't able to prevent login CSRF because login CSRF doesn't depend on the browser sending cookies to the server. Lastly, solution #5 doesn't require any change in the security model I presume you mean 4. :) Yes, #4, sorry. or in deployed web apps. The annonyance to the user could be avoided with something like remember this choice. Yet, the user interface must make very clear where the traversal started, where it will end, and what information the UAs will send authomatically. This is the solution I prefer I'm not sure what UI you have in mind here. In general, we should be careful about relying on the user to make correct security decisions. 1) | This website, Title of malicious page, at | | http://www.dangerous.com/index.html | | tried to perform a POST request to | | http://www.mybank.com/pay?to=attacker| | A similar site was
Re: [widgets] What does it mean to have an unavailable API
On 6/9/09 11:58 AM, Anne van Kesteren wrote: On Tue, 09 Jun 2009 11:32:49 +0200, Marcos Caceresmarc...@opera.com wrote: Like I said, as far as WebApps is concerned requestFeature() does not exists. What I meant was the requestFeature() underminesfeature without addressing the security issues. I'm getting more and more confused. You claim you do not understand requestFeature(). You claim requestFeature() makesfeature useless. You claim requestFeature() is irrelevant with respect tofeature. And now you claim requestFeature() is less secure thanfeature. I do not get at all the feeling that this feature is ready for standardization. How about instead of taking little fragments of conversations out of context you actually go and read the two specs? I don't see how you can assess the how ready for standardization anything is based on the conversation we have been having here. That's just trolling. Until you go and read both specs and make comments against the specs, I'm not continuing this discussion.
[webstorage] Ambiguous Requirement for Key Ordering
Hi, The spec states [1]: The key(n) method must return the name of the nth key in the list. The order of keys is user-agent defined, but must be consistent within an object between changes to the number of keys. (Thus, adding or removing a key may change the order of the keys, but merely changing the value of an existing key must not.) There is an ambiguity that can make that paragraph self-contradictory, depending on how the phrase [the order] must be consistent within an object between changes to the number of keys.. The ambiguity appears to be caused by the use of the word between in that context. I initially interpreted that as meaning that the order must remain consistent when the number of keys changes. But then this interpretation is contradicted by the parenthetical sentence following it. Please clarify. [1] http://dev.w3.org/html5/webstorage/#dom-storage-key -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [widgets] What does it mean to have an unavailable API
On Tue, Jun 9, 2009 at 10:19 AM, Marcin Hanclikmarcin.hanc...@access-company.com wrote: Ok, that makes sense; but I have serious doubts anyone will implement that. Why? You mean because it would not sell, because it is bad by design or any other reason? It's a bad design, IMO. However, we will discuss this as part of DAP. -- Marcos Caceres http://datadriven.com.au
to www-dom Re: [DOM3Events] Use cases for Mutation Events
Hi, just a reminder that DOM3 discussion should be on the www-dom list. Please follow up there. (I have forwarded a collated version of this thread to that list.) cheers Chaals On Thu, 04 Jun 2009 12:52:39 +0200, Sergey Ilinsky casto...@yahoo.co.uk wrote: Hi, For me it is not clear at all what are the use cases for DOM Mutations Events on web pages (so maybe simply dropping their implementation would be an option?). If the group could first identify the use cases for Mutation Events on the web pages, then: a) it would become clear to everyone whether the progress is needed b) creating proposals on progress would become easier, a proposal would have to satisfy these use case to prove its viability Other thoughts: 1) If I am the author to the scripts that modify document, then I am indeed aware of what gets changed. If I am not the author, I shall then not have been notified on the change. The use cases such as debugger do not count here - it would be possible to offer required APIs (such as DOM Mutation Events) to them only, without needing the API to populate on the page. And this is not a sucrifice to run page 50% slower caused by the Mutation Events turned on on behalf of a debugger, right? 2) I can see Mutation Events as the extension point that enables implementation of the technologies that are not available in the browser. However this is not a normal usecase that web browsers are here to face. Sergey/ -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
RE: [WebIDL] module in ECMAScript
Hi Cameron,
I am sorry for responding that late, but my mail client wrongly classified your
message and I realized of its existence right now :)
What is the issue with constants?
We would like to have this constant
bondi.camera.Camera.NIGHT_MODE
to be only accessible as above.
Camera and Camera.NIGHT_MODE should be undefined.
I think it would be better just to state how modules map to particular
ECMAScript properties and values.
OK.
Here is a proposal then, by example. The following IDL:
[ESNamespace]
module bondi {
module pim {
interface Blah { };
};
};
module dom {
interface Node { };
};
module gfx {
[ESNamespace]
module geom {
interface Point { };
};
};
[ESNamespace, Prefix=com::example]
module fs {
interface File { };
};
would cause the following properties to exist:
window.bondi – “namespace object” for ::bondi
In BONDI we did not foresee that.
We would like bondi to be the root.
window.bondi.pim – namespace object for ::bonid::pim
window.bondi.pim.Blah – interface object for ::bondi::pim::Blah
window.Node – interface object for ::dom::Node
window.geom – namespace object for ::gfx::geom
window.geom.Point – interface object for ::gfx::geom::Point
window.com – implied namespace object
window.com.example – implied namespace object
window.com.example.fs – namespace object for ::fs
window.com.example.fs.File – interface object for ::fs::File
Properties whose values are namespace objects would be { DontDelete,
DontEnum } for consistency with properties for interface objects.
The [ESNamespace] name is a strawman. Please suggest a nicer name if
you can think of one.
It seems ok as it is.
With the above, there’d be no way of “turning off” mapping of a module
to a namespace object if an ancestor module had [ESNamespace] on it.
I’m not sure about the usefulness of the [Prefix] bit, but I’m just
copying the same behaviour that exists in the Java binding.
In BONDI we would like to add new submodules to the bondi module.
So probably [Prefix=bondi] would help us to extend this namespace.
I’m open to adding a feature that would map modules to ECMAScript
objects as above.
OK.
I don’t think this should be the default, since at
the moment it’s definitely the norm to place all interface objects on
the global object.
I think it would be good to know whether the changes you want to make will be
persistent, since e.g. BONDI spec would like to reference WebIDL spec.
Thanks.
Kind regards,
Marcin
Marcin Hanclik
ACCESS Systems Germany GmbH
Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465
Mobile: +49-163-8290-646
E-Mail: marcin.hanc...@access-company.com
-Original Message-
From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On
Behalf Of Cameron McCormack
Sent: Monday, June 01, 2009 4:20 AM
To: public-webapps
Subject: Re: [WebIDL] module in ECMAScript
Hi Marcin.
Marcin Hanclik:
In BONDI WebIDL we implicitly assumed that module definition is
mapped to the interface naming. Thus bondi.filesystem.* is available
without explicit creation of the filesystem property of the
bondi object. This implicit creation of property may result from
the definition of submodules, as in [3]. However, this is just an
incorrect interpretation of the WebIDL for ECMAScript that resembles
bindings of WebIDL in Java [7]. The WebIDL module has no meaning in
ECMAScript [8]:
In the Java language binding, the name of the Java package is derived
by taking the prefixed name and replacing occurrences of :: with .
(see section 5.3). The ECMAScript language binding does not have a
namespacing mechanism, and thus does not use a module's prefixed name.
[9] says that:
For every interface that is not declared with the [NoInterfaceObject]
extended attribute, a corresponding property MUST exist on the
ECMAScript global object whose name is the identifier of the
interface. The value of this property is an object called the
interface object, which provides access to the constants and
operations defined on the interface.
Indeed.
In BONDI, however, we do not want the interfaces to be available under
the global object. This is visible also from the sample code for
constant usage [10]:
try {
// gets current night mode
var night_mode = camera.getFeatureValue(bondi.camera.Camera.NIGHT_MODE);
// Switch on nightmode
camera.setFeatureValue(bondi.camera.Camera.NIGHT_MODE, true);
}
catch(e) {
alert(e);
}
OK.
…
Subclassing in Gears may resemble module in module definitions in
WebIDL, but frankly speaking I did not find anywhere an example of
module in module binding in ECMAScript.
Right, while it’s common in some Javascript toolkits, like dojo, this
naming scheme isn’t used by standard DOM interfaces.
In HTML5 the interfaces are available under the global object and
interfaces are available as properties to create hierarchical
structures. E.g.
Questions on AE spec
Title: Questions on AE spec Here are a couple of potentially easy questions on the Widgets 1.0: APIs and Events spec: 5.15 The openURL() Method Does the appropriate protocol handler mean an external application (e.g. browser for http://) is invoked, or can the handler be the widget user agent itself (e.g. the method is similar to XHR, i.e. returns results as data objects)? It would be good to clarify what this means and give examples. 5.17 The showNotification() Method Re The showNotification() method accepts three arguments: ... The second argument is a DOMString containing an informative message to be displayed to the end-user. Is this a simple text string, or can it include any markup/style? Best regards, Bryan Sullivan |ATT
Re: CSRF: alternative solutions
On Tue, Jun 9, 2009 at 5:33 AM, Giovanni Campagnascampa.giova...@gmail.com wrote: 1) I cannot understand what advantages has the attacker into logging the user with attacker's credentials. I expect that the user will notice the different account used (for example in the web app interface) I recommend reading http://www.adambarth.com/papers/2008/barth-jackson-mitchell-b.pdf for examples of why this is often sufficient for the attacker to perform misdeeds. We can hope to improve on the Referer header. In particular, the Origin header is sent from HTTPS origins to HTTP URLs. This is safe because the Origin header (unlike the Referer header) leaks only the host name of the HTTPS origin (not the path and query string), and the host name is already leaked via DNS. This is one flaw, which can be corrected into Referer (dropping the query, making path /). The other is firewall and proxies stripping it: if they remove Referer, it is possible that they will strip Origin as well. Change the Referer is a delicate matter. Dropping the patch, query, etc, impacts other uses of the Referer header. For compatibility, it's much safer to introduce a new header. Because of some subtle design decisions, proxies that strip the Origin header (were they to come into existence) would harm only their clients, as opposed to the situation with the Referer header where these proxies prevent everyone from deriving CSRF mitigation benefits from the Referer header. I encourage you to read the paper referenced above for an explanation of why this is the case. Agreed on both (but we should define exactly what Origin:nully and Origin:empty mean and when both must be used) This is defined here: http://tools.ietf.org/html/draft-abarth-origin-00 Some folks have explored heuristics for when to send cookies. For example, if you type something in the location bar, they'll send the cookies because they think the request came from you (and not from attacker.com). I can try to dig up a few citations, if you like. It may be useful for the discussion, thanks. Here's one example: http://www.cs.purdue.edu/homes/ninghui/papers/csrf_fc09.pdf I'm not sure what UI you have in mind here. In general, we should be careful about relying on the user to make correct security decisions. 1) | This website, Title of malicious page, at | | http://www.dangerous.com/index.html | | tried to perform a POST request to | | http://www.mybank.com/pay?to=attacker | | A similar site was last seen as | | My bank account - userId - Transaction Confirm | | | | This request includes authentication info, and | | thus may involve processing not desired on the | | behalf of the user (for example sending an email) | | | | ((Allow)) ((Deny)) | | | | ( ) Always for these origins only | | ( ) Always from www.dangerous.com | | ( ) Always to www.mybank.com | | ( ) Only this time | We could evaluate the usability of this UI with a user study, but I suspect users won't understand the consequences of this decision. More likely user will click allow to get there work done. It's hard enough to get users not to click through warnings that say this site will install malicious software on your machine. 2) On the contrary, it is the user the only person who knows if it clicked intentionally, and wanted to perform a cross-site request. Perhaps, but we might be better off with a solution that doesn't require the user to make a security decision. Adam
Re: XHR without user credentials
On Tue, Jun 9, 2009 at 12:54 AM, Anne van Kesterenann...@opera.com wrote: On Tue, 09 Jun 2009 03:39:19 +0200, Mark S. Miller erig...@google.com wrote: This use-case was the motivation for ADsafe, though any of the JavaScript sanitizers would do. Without some such sanitization technology, it remains unsafe to load untrusted ads directly on your page. Adam and I are still arguing fine points of just how unsafe, but there's no question that the answer is at least too unsafe. With GuestXMLHttpRequest, such sanitized ads could be allowed to call home safely without being able to impersonate their containing page's origin. Why can such ads not be embedded using a seamless sandboxed iframe from HTML5? I think there are two main reasons: 1. ADsafe, Caja and others provide finer grained control over what the widget can do. 2. All ads/widgets are fetched by the same HTTP request that fetches the containing page. The overhead of a separate iframe per ad/widget was too much for the expected use-cases. --Tyler -- Waterken News: Capability security on the Web http://waterken.sourceforge.net/recent.html
Re: [widgets] What does it mean to have an unavailable API
Making a static declaration of a feature to indicate to the UA which APIs to make available to a widget is already used in existing widget and gadget implementations; requestFeature() isn't. For example, here is the definition used by Google, and implemented in Shindig: Gadget Features. A list of all gadget features that are either required for the gadget to operate, or may optionally be utilized if available. Gadget features are the primary extensibility mechanism employed by gadgets. They often direct a gadget server to make new JavaScript APIs available to rendering code, but may also manipulate the gadget's contents, for example to add extended syntax. Examples of gadget features include OpenSocial (provides gadgets with a rich set of social APIs), dynamic-height (enables gadgets to resize themselves to an appropriate height), and tabs (a UI library facilitating tabular navigation). We use a similar definition in relation to Widgets. We specifically use feature for indicating to the UA to make shared state handling available and active, and plan to use it to indicate whether we should provide oAuth capability for a given widget. If this element were not in the specification, we'd have to create an extension that did the same thing anyway. The BONDI requirement is to dynamically add APIs once a Widget has already been instantiated. This may not suit some implementations. For example, our implementation has no way of dynamically injecting APIs into a Widget instance while it is already running; if BONDI wishes to require this capability of implementations this is not in the scope for Widgets. Currently the Widget AE spec makes no claim that Widget UAs must be able to dynamically load additional functionality on request. If a given UA implemented BONDI and a Widget chooses to use its requestFeature() method, then in that instance for that Widget, feature may be redundant. However, for Widgets not created specifically for BONDI that are used in a BONDI UA, this is not an issue; feature works fine and is not affected by the existance of the BONDI getFeature() extension. Also for UAs that support Widgets but not BONDI extensions, it is not an issue that the extension exists. Personally I don't really see a good UC for requestFeature(), but its proposed as a BONDI extension and not a W3C Widgets AE feature, so I support Marcos' position that we let it be. S On 9 Jun 2009, at 10:58, Anne van Kesteren wrote: On Tue, 09 Jun 2009 11:32:49 +0200, Marcos Caceres marc...@opera.com wrote: Like I said, as far as WebApps is concerned requestFeature() does not exists. What I meant was the requestFeature() undermines feature without addressing the security issues. I'm getting more and more confused. You claim you do not understand requestFeature(). You claim requestFeature() makes feature useless. You claim requestFeature() is irrelevant with respect to feature. And now you claim requestFeature() is less secure than feature. I do not get at all the feeling that this feature is ready for standardization. -- Anne van Kesteren http://annevankesteren.nl/ smime.p7s Description: S/MIME cryptographic signature
Re: XHR without user credentials
On Tue, Jun 9, 2009 at 9:29 AM, Adam Barthw...@adambarth.com wrote: On Tue, Jun 9, 2009 at 9:19 AM, Tyler Closetyler.cl...@gmail.com wrote: On Tue, Jun 9, 2009 at 12:22 AM, Adam Barthw...@adambarth.com wrote: Please send Origin: null in these cases. The problem with omitting the origin header is that the server can't tell if the request comes from a legacy client or if the header was removed in transit. For the GuestXMLHttpRequest scenario, why should the server distinguish between these two cases? In one case, the request is coming from the non-guest part of the page in a legacy browser. And so isn't using GuestXMLHttpRequest. In the other case, the request is coming from the guest part of the page in a supporting browser. And so is using GuestXMLHttpRequest. Isn't the whole point of this feature to be able to distinguish guest and non-guest? So requests from XMLHttpRequest have an Origin header, and requests from GuestXMLHttpRequest don't. The server should treat requests coming from GuestXMLHttpRequest as bits arriving from an unknown client (ie: a guest), and so only authorize them based on information explicitly included in the request. --Tyler -- Waterken News: Capability security on the Web http://waterken.sourceforge.net/recent.html
Re: CSRF: alternative solutions
2009/6/9 Adam Barth w...@adambarth.com: On Tue, Jun 9, 2009 at 5:33 AM, Giovanni Campagnascampa.giova...@gmail.com wrote: 1) I cannot understand what advantages has the attacker into logging the user with attacker's credentials. I expect that the user will notice the different account used (for example in the web app interface) I recommend reading http://www.adambarth.com/papers/2008/barth-jackson-mitchell-b.pdf for examples of why this is often sufficient for the attacker to perform misdeeds. I read it, and I must say that it is worse than I expected, but I believe that most harm of login CSRF would be reduced if the user was always informed of its present credentials. In other words, every page should show visibly You are logged as XXX. This solves the PayPal problem for example, and may solve the Search History problem (by saying All your searches are being logged to XXX.) We can hope to improve on the Referer header. In particular, the Origin header is sent from HTTPS origins to HTTP URLs. This is safe because the Origin header (unlike the Referer header) leaks only the host name of the HTTPS origin (not the path and query string), and the host name is already leaked via DNS. This is one flaw, which can be corrected into Referer (dropping the query, making path /). The other is firewall and proxies stripping it: if they remove Referer, it is possible that they will strip Origin as well. Change the Referer is a delicate matter. Dropping the patch, query, etc, impacts other uses of the Referer header. For compatibility, it's much safer to introduce a new header. Because of some subtle design decisions, proxies that strip the Origin header (were they to come into existence) would harm only their clients, as opposed to the situation with the Referer header where these proxies prevent everyone from deriving CSRF mitigation benefits from the Referer header. I encourage you to read the paper referenced above for an explanation of why this is the case. I meant to change only for the cases that browsers currently don't send Referer (ie from data and ftp URIs). They could send Referer with scheme://host:port/ or send a null Referer. In both case we don't change the current semantics and we're backward compatible (because if the server used to assume nothing and just live without it, it would skip it) Agreed on both (but we should define exactly what Origin:null and Origin:empty mean and when both must be used) This is defined here: http://tools.ietf.org/html/draft-abarth-origin-00 Ok. Some folks have explored heuristics for when to send cookies. For example, if you type something in the location bar, they'll send the cookies because they think the request came from you (and not from attacker.com). I can try to dig up a few citations, if you like. It may be useful for the discussion, thanks. Here's one example: http://www.cs.purdue.edu/homes/ninghui/papers/csrf_fc09.pdf That document was quite interesting, and also showed a case in which both Origin and secret tokens fail. Anyway, it showed that heuristics do work to determine if requests are intended or not, and in the latter case the browser may strip authentication info or just ask the user. I'm not sure what UI you have in mind here. In general, we should be careful about relying on the user to make correct security decisions. 1) | This website, Title of malicious page, at | | http://www.dangerous.com/index.html | | tried to perform a POST request to | | http://www.mybank.com/pay?to=attacker | | A similar site was last seen as | | My bank account - userId - Transaction Confirm | | | | This request includes authentication info, and | | thus may involve processing not desired on the | | behalf of the user (for example sending an email) | | | | ((Allow)) ((Deny)) | | | | ( ) Always for these origins only | | ( ) Always from www.dangerous.com | | ( ) Always to www.mybank.com | | ( ) Only this time | We could evaluate the usability of this UI with a user study, but I suspect users won't understand the consequences of this decision. More likely user will click allow to get there work done. It's hard enough to get users not to click through warnings that say this site will install malicious software on your machine. This depends on what exactly the text will be in the dialog and the relative frequency of legitimate requests over all cross-site request (ie the frequency of
Re: CSRF: alternative solutions
On Tue, Jun 9, 2009 at 9:55 AM, Giovanni Campagnascampa.giova...@gmail.com wrote: 2009/6/9 Adam Barth w...@adambarth.com: I recommend reading http://www.adambarth.com/papers/2008/barth-jackson-mitchell-b.pdf for examples of why this is often sufficient for the attacker to perform misdeeds. I read it, and I must say that it is worse than I expected, but I believe that most harm of login CSRF would be reduced if the user was always informed of its present credentials. In other words, every page should show visibly You are logged as XXX. This solves the PayPal problem for example, and may solve the Search History problem (by saying All your searches are being logged to XXX.) Informing the user doesn't help if the login CSRF leads to XSS because the attacker can just re-write that part of the page. I meant to change only for the cases that browsers currently don't send Referer (ie from data and ftp URIs). They could send Referer with scheme://host:port/ or send a null Referer. In both case we don't change the current semantics and we're backward compatible (because if the server used to assume nothing and just live without it, it would skip it) This is being discussed in the HTTP working group. The current proposal is to recommend that user agents send the string about:blank when they don't have a better idea of what Referer to send (e.g., for requests generated from data URLs). If you're interested in this idea, I'd encourage you to get involved with the discussion there. http://www.cs.purdue.edu/homes/ninghui/papers/csrf_fc09.pdf That document was quite interesting, and also showed a case in which both Origin and secret tokens fail. Anyway, it showed that heuristics do work to determine if requests are intended or not, and in the latter case the browser may strip authentication info or just ask the user. I'm glad you enjoyed the paper. I'm not sure what UI you have in mind here. In general, we should be careful about relying on the user to make correct security decisions. 1) | This website, Title of malicious page, at | | http://www.dangerous.com/index.html | | tried to perform a POST request to | | http://www.mybank.com/pay?to=attacker | | A similar site was last seen as | | My bank account - userId - Transaction Confirm | | | | This request includes authentication info, and | | thus may involve processing not desired on the | | behalf of the user (for example sending an email) | | | | ((Allow)) ((Deny)) | | | | ( ) Always for these origins only | | ( ) Always from www.dangerous.com | | ( ) Always to www.mybank.com | | ( ) Only this time | We could evaluate the usability of this UI with a user study, but I suspect users won't understand the consequences of this decision. More likely user will click allow to get there work done. It's hard enough to get users not to click through warnings that say this site will install malicious software on your machine. This depends on what exactly the text will be in the dialog and the relative frequency of legitimate requests over all cross-site request (ie the frequency of Allows). I guess that many user will see the dialog just a few times, and yet they will be protected, because they will have clicked Always from this site, that they have discovered to be safe. Yes. There are all good things to evaluate: A) False positives (i.e., how often the warning appears when there is no attack). B) False negative (i.e., how often an attack fails to trigger the warning). C) Usability (i.e., whether user actually make effective security decisions when prompted with this warning). I'd encourage you study all three of these questions and present your findings to this working group. Perhaps, but we might be better off with a solution that doesn't require the user to make a security decision. I don't agree with you. I think that ours are two completely different points to see security, and I'm not sure they're compatible. This is a largely empirical question that we can have a more informed discussion about once you gather data on (A), (B), and (C). Adam
Re: XHR without user credentials
On Tue, Jun 9, 2009 at 9:38 AM, Tyler Closetyler.cl...@gmail.com wrote: On Tue, Jun 9, 2009 at 9:29 AM, Adam Barthw...@adambarth.com wrote: Isn't the whole point of this feature to be able to distinguish guest and non-guest? So requests from XMLHttpRequest have an Origin header, and requests from GuestXMLHttpRequest don't. The server should treat requests coming from GuestXMLHttpRequest as bits arriving from an unknown client (ie: a guest), and so only authorize them based on information explicitly included in the request. Given an HTTP request, what algorithm should the server use to determine whether the request was generated by GuestXMLHttpRequest? Adam
Re: WebSocket question
On Fri, 5 Jun 2009, Ben Dodson wrote: I was wondering if binary data would somehow be supported in the upcoming websockets? The protocol has been written to support it, but it will probably not be supported in the first version of the API, since, as Anne mentions, there isn't solid support for it in the underlying platform yet. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: XHR without user credentials
On Tue, Jun 9, 2009 at 11:19 AM, Adam Barthw...@adambarth.com wrote: On Tue, Jun 9, 2009 at 9:38 AM, Tyler Closetyler.cl...@gmail.com wrote: On Tue, Jun 9, 2009 at 9:29 AM, Adam Barthw...@adambarth.com wrote: Isn't the whole point of this feature to be able to distinguish guest and non-guest? So requests from XMLHttpRequest have an Origin header, and requests from GuestXMLHttpRequest don't. The server should treat requests coming from GuestXMLHttpRequest as bits arriving from an unknown client (ie: a guest), and so only authorize them based on information explicitly included in the request. Given an HTTP request, what algorithm should the server use to determine whether the request was generated by GuestXMLHttpRequest? That's not the question the server wants to answer. The question is: How should the server treat any cookies (or other browser added credentials) in the request. 1) There is an Origin header: Treat any user credentials as indicated by the CORS spec for XMLHttpRequest. 2) There is no Origin header: a) request from legacy browser: If there are credentials in the request, use these as indicated by whatever CSRF defense you are using. b) request from non-browser client: If there are credentials in the request, the client has direct knowledge of them. They did not come from the browser's ambient environment. c) request from GuestXMLHttpRequest: There are no credentials in the request. The sub-cases of 2) collapse into: Treat any credentials in the request as you do today, guarded by whatever CSRF defenses you use. From the perspective of your Origin work, requests from GuestXMLHttpRequest are like requests from a non-browser client, and so don't have a reliable Origin header value. --Tyler -- Waterken News: Capability security on the Web http://waterken.sourceforge.net/recent.html
Re: XHR without user credentials
Thanks Tyler. I understand your use case now. I don't see the harm in sending Origin: null, so I haven't changed the I-D, which requires a (possibly null) Origin header in some cases. Adam On Tue, Jun 9, 2009 at 11:50 AM, Tyler Closetyler.cl...@gmail.com wrote: On Tue, Jun 9, 2009 at 11:19 AM, Adam Barthw...@adambarth.com wrote: On Tue, Jun 9, 2009 at 9:38 AM, Tyler Closetyler.cl...@gmail.com wrote: On Tue, Jun 9, 2009 at 9:29 AM, Adam Barthw...@adambarth.com wrote: Isn't the whole point of this feature to be able to distinguish guest and non-guest? So requests from XMLHttpRequest have an Origin header, and requests from GuestXMLHttpRequest don't. The server should treat requests coming from GuestXMLHttpRequest as bits arriving from an unknown client (ie: a guest), and so only authorize them based on information explicitly included in the request. Given an HTTP request, what algorithm should the server use to determine whether the request was generated by GuestXMLHttpRequest? That's not the question the server wants to answer. The question is: How should the server treat any cookies (or other browser added credentials) in the request. 1) There is an Origin header: Treat any user credentials as indicated by the CORS spec for XMLHttpRequest. 2) There is no Origin header: a) request from legacy browser: If there are credentials in the request, use these as indicated by whatever CSRF defense you are using. b) request from non-browser client: If there are credentials in the request, the client has direct knowledge of them. They did not come from the browser's ambient environment. c) request from GuestXMLHttpRequest: There are no credentials in the request. The sub-cases of 2) collapse into: Treat any credentials in the request as you do today, guarded by whatever CSRF defenses you use. From the perspective of your Origin work, requests from GuestXMLHttpRequest are like requests from a non-browser client, and so don't have a reliable Origin header value. --Tyler -- Waterken News: Capability security on the Web http://waterken.sourceforge.net/recent.html
Re: XHR without user credentials
On Tue, 09 Jun 2009 18:38:47 +0200, Tyler Close tyler.cl...@gmail.com wrote: So requests from XMLHttpRequest have an Origin header, and requests from GuestXMLHttpRequest don't. The server should treat requests coming from GuestXMLHttpRequest as bits arriving from an unknown client (ie: a guest), and so only authorize them based on information explicitly included in the request. FWIW, I think we need a little more motivation for GuestXMLHttpRequest. It seems to me that a seamless sandboxed iframe addresses the use case brought forward and does so better (and more complete) than adding a new constructor for XMLHttpRequest. -- Anne van Kesteren http://annevankesteren.nl/
Re: XHR without user credentials
On Tue, Jun 9, 2009 at 12:09 PM, Anne van Kesterenann...@opera.com wrote: On Tue, 09 Jun 2009 18:38:47 +0200, Tyler Close tyler.cl...@gmail.com wrote: So requests from XMLHttpRequest have an Origin header, and requests from GuestXMLHttpRequest don't. The server should treat requests coming from GuestXMLHttpRequest as bits arriving from an unknown client (ie: a guest), and so only authorize them based on information explicitly included in the request. FWIW, I think we need a little more motivation for GuestXMLHttpRequest. It seems to me that a seamless sandboxed iframe addresses the use case brought forward and does so better (and more complete) than adding a new constructor for XMLHttpRequest. Could you provide a code example that shows how to send an XHR request to the same Origin without credentials using the HTML5 iframe element? --Tyler -- Waterken News: Capability security on the Web http://waterken.sourceforge.net/recent.html
Re: XHR without user credentials
On Tue, 09 Jun 2009 21:15:18 +0200, Tyler Close tyler.cl...@gmail.com wrote: Could you provide a code example that shows how to send an XHR request to the same Origin without credentials using the HTML5 iframe element? iframe sandbox=allow-scripts src=.../iframe where ... is some page that does an XMLHttpRequest to the a page that is same origin with the page that contains the iframe. (The page being fetched will have to specify Access-Control-Allow-Origin:* as the request is coming from a unique origin by virtue of the sandbox attribute. The request will include an Origin header but the value will always be null.) Also, if the document= or some such attribute is introduced the code will no longer have to be on a separate page. -- Anne van Kesteren http://annevankesteren.nl/
Redirect and Origin
The Origin I-D says the following about redirects: If a user agent issues an HTTP request in reaction to an HTTP redirect, the Origin header MUST contain the same value as the Origin header in the HTTP request that generated the redirect. So if a page from Victim origin sends a request to Attacker origin which is redirected to a URL at Victim origin, the server at Victim origin receives a request with user credentials for Victim origin and an Origin header value for Victim origin. The Origin I-D says: don't do that at the end of section 6; meaning there's no way to send a request to another origin unless you have complete trust for it. That seems rather restrictive. Is there really no way to send a request to another origin without being vulnerable? Wasn't that the whole point of creating a mechanism to replace JSON-P? --Tyler
Re: Redirect and Origin
On Tue, Jun 9, 2009 at 2:05 PM, Adam Barthw...@adambarth.com wrote: On Tue, Jun 9, 2009 at 1:47 PM, Tyler Closetyler.cl...@gmail.com wrote: So if a page from Victim origin sends a request to Attacker origin which is redirected to a URL at Victim origin, the server at Victim origin receives a request with user credentials for Victim origin and an Origin header value for Victim origin. That's correct. Notice that the victim site will need to generate a POST request to the attacker. The attacker is not able to change the POST data. Also, this sequence generates a warning dialog on Firefox. The attack does not work in Safari because redirects always generate GET requests. The Origin I-D says: don't do that at the end of section 6; meaning there's no way to send a request to another origin unless you have complete trust for it. You can send a GET request. That seems rather restrictive. Is there really no way to send a request to another origin without being vulnerable? Yes. It's the price we pay for using the same header name as CORS. If we decide to mint a new header (which is similar, but not quite identical to Origin-for-CORS), then we can improve on this point. Wasn't that the whole point of creating a mechanism to replace JSON-P? The Origin header is not a mechanism to replace JSON-P. The Origin-header-as-CSRF-defense is meant to mitigate CSRF vulnerabilities. I had thought CORS, by it's use of Origin, was meant to be a safe replacement for JSON-P. I think both the Origin I-D and the CORS spec should state in their front sections that they are only to be relied upon for messaging between mutually trusting sites. That's a very different security model than I had initially assumed. --Tyler -- Waterken News: Capability security on the Web http://waterken.sourceforge.net/recent.html
Re: Redirect and Origin
On Tue, Jun 9, 2009 at 2:52 PM, Adam Barthw...@adambarth.com wrote: On Tue, Jun 9, 2009 at 2:20 PM, Tyler Closetyler.cl...@gmail.com wrote: I had thought CORS, by it's use of Origin, was meant to be a safe replacement for JSON-P. Can you explain again how the attack works for Origin-header-for-CORS? Keep in mind that the response is delivered to the original requester, who should be accurately identified by the Origin header (even through redirects). But the side-effects of the request still happen. The attacker can cause mutation of server-side state belonging to the victim user. I believe the scenario in the first email works as described in CORS. I don't see anything in the CORS redirect steps that changes the Origin processing from what is described in your I-D. http://www.w3.org/TR/access-control/#redirect-steps These documents really need to state that they are only addressing messaging between mutually trusting sites. --Tyler -- Waterken News: Capability security on the Web http://waterken.sourceforge.net/recent.html
Re: Redirect and Origin
On Tue, Jun 9, 2009 at 3:05 PM, Tyler Closetyler.cl...@gmail.com wrote: On Tue, Jun 9, 2009 at 2:52 PM, Adam Barthw...@adambarth.com wrote: On Tue, Jun 9, 2009 at 2:20 PM, Tyler Closetyler.cl...@gmail.com wrote: I had thought CORS, by it's use of Origin, was meant to be a safe replacement for JSON-P. Can you explain again how the attack works for Origin-header-for-CORS? Keep in mind that the response is delivered to the original requester, who should be accurately identified by the Origin header (even through redirects). But the side-effects of the request still happen. The attacker can cause mutation of server-side state belonging to the victim user. I believe the scenario in the first email works as described in CORS. I don't see anything in the CORS redirect steps that changes the Origin processing from what is described in your I-D. http://www.w3.org/TR/access-control/#redirect-steps These documents really need to state that they are only addressing messaging between mutually trusting sites. Hmm.. there does indeed seem to be a problem here. If site A issues a DELETE request to site B, using XHR and CORS, and site B redirects that request back to site A, then A will in effect perform a DELETE request on itself. At least assuming that A is configured to trust itself, which I think many sites will do. I'm in general not a big fan of the redirect model in CORS, but this one especially seems like a problem. One solution would be to include the full redirect chain (or change the Origin to 'null') if redirecting across servers with a non-safe HTTP method. / Jonas
Re: Redirect and Origin
On Tue, Jun 9, 2009 at 3:40 PM, Jonas Sickingjo...@sicking.cc wrote: I'm in general not a big fan of the redirect model in CORS, but this one especially seems like a problem. One solution would be to include the full redirect chain (or change the Origin to 'null') if redirecting across servers with a non-safe HTTP method. Either of these are fine with me. I'll update the Origin-for-CSRF-defense draft to match whatever CORS would like to do here. Adam
Re: WebStorage feedback
On Tue, 19 May 2009, João Eiras wrote: How is this different from making two mutations per mutation event, or calling postMessage() twice for each invokation of the 'message' event, or loading two new iframes every time an iframe's 'load' event fires? It's quite different because in those cases, the events or actions are all limited to one single runtime, which means all these actions are queued. A sane user agent can share a part of its cpu time between all the active runtimes, and keeping the other documents usable while one fork bombs itself with events, being the leftover problem the amount of memory needed. With storage events, the user agent must send events to unrelated runtimes, which can escalate immensely, therefore filling all the other runtimes' event queues with the superfluous events. If the user agent has no protection against this, then the user will be forced to close the whole browser, and not just the webpage that is misbehaving. Even if we posit a system where there are unrelated runtimes that can communicate in this way, within each runtime the user agent can apply the same protections. Furthermore, since runtimes can now communicate anyway (e.g. using shared workers), I really don't see which this is an unusual problem. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
