Re: [whatwg] Proposal: Write-only submittable form-associated controls.
On Thu, Oct 16, 2014 at 4:28 PM, Eduardo' Vela Nava e...@google.com wrote: Well, it doesn't today. But maybe you mean in the future. You're right, sorry. I was thinking of blob-based workers. Maybe we should do the same for frames? But the point is that there are many ways to exfiltrate, these are just the first thing that comes to mind but others like input pattern also are an info leak, and I mean, these are just ideas coming up the top of my mind, the browser wasn't designed to solve this problem and it's dubious if it's really feasible to do so without reinventing a lot of things. http://mikewest.github.io/credentialmanagement/writeonly/#input-behavior outlines a few mechanisms, and potential resolutions. `pattern`, for instance, is addressed by blocking input validation on the form field. As you suggest, I'm sure there are more mechanisms. I don't think there are infinite mechanisms, however, and I'm fairly certain that we could address those that exist. I wasn't clear: the server still needs to accept a bare username/password pair, as it's not the case that users only log in a) using a password manager, b) on a machine that's syncing. As long as that's the case, I don't see how tying passwords to a cookie makes password theft less problematic. The user would just have to type the full password (including the extra cookie-random value that the password manager backed up). The caveat of course is that the user has to write this suffix somewhere, but that is what makes the password strong anyway. I don't think asking users to remember a password and a random value is tenable. And anyway, to be clear, this is just a discussion on an alternate design that has the same properties and is significantly easier to implement for both, authors and UAs, but it's by no means the only solution. My point is that there are probably simpler solutions that have similar security guarantees. I'll reassert that this proposal is simpler for authors (11 character opt-in) and users (no change) than the scheme you just outlined. It's more complex for browser vendors, but that's fine and expected, as we're way down at the bottom of the priority heap. -- Mike West mk...@google.com Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91 Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Graham Law, Christine Elizabeth Flores (Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
Re: [whatwg] Proposal: Write-only submittable form-associated controls.
I would be happy to be proven wrong, but it's unlikely the amount of effort this will incur will be worth the small number of sites that will use it (large sites probably won't, and small sites, as usual, won't even know about it's existence). In addition, it's going to be such a fragile security control that I suspect will be the next XSS Auditor in terms of a bypass is always 1 hour away.
Re: [whatwg] Proposal: Write-only submittable form-associated controls.
On Wed, Oct 15, 2014 at 6:27 PM, Michal Zalewski lcam...@coredump.cx wrote: So I might have started this on the wrong foot Naah. Your criticism is a) not unexpected, and b) totally accurate. I hopefully believe that you're overstating the negatives, and underestimating the positives, but that's kinda your job. :) Also, I did a poor job of making my actual desire clear; I should have focused more on the problem, and less on the proposed solution. I'll try to be more general going forward: In a nutshell, Chrome's non-browser processes are corrupted significantly more often than it's browser process. Reducing their ability to request credential data seems like a straightforward win. In order to do that without breaking valid use-cases, we need a signal from the page that it's not intending to touch the value. This signal is conceptually similar to CSP's broader I'm not going to use eval(). or I'm not going to use XHR. statements, and would allow password managers to flag credentials as writeonly, similar to how we flag cookies as httponly today. writeonly is only one way to provide this signal. Its advantage is simplicity: existing sign-in forms can add this attribute today without changing anything else at all in their flow. 1) XSS stealing the passwords / CC numbers entered by the user manually? This is probably not possible with this proposal; the evil payload may construct a form where the writeonly attribute is not set. Yup. That's not a scenario that this proposal improves in the slightest. If the user is typing something into a corrupted page, attackers can read that something in a number of ways. 2) XSS stealing the passwords entered by the password manager? To do this, I feel that we need a taint-tracking system coupled with a password manager that remembers that some passwords can go only into writeonly fields, and which URLs and methods they need to be submitted to. This is the scenario I'm focusing on. We already track much of the form's context in Chrome's password manager in order to determine which credential to insert into a given form. I imagine other password manager do likewise. We're not using that data in this way yet, but it's certainly a direction I'd like to explore. The CSP solution + blocking GET feels like a crutch that won't work in practice; (Restricting browser's autofill of password and credit card data to POST is probably something we should do regardless of this proposal.) my main concern is that writing site-wide policies is hard as-is, and that the likelihood of well-scoped per-page policies, especially with path granularity, is low. On the web at large, yes. For particular form fields that we know to be interesting, maybe no. I just tried Google, Facebook, and PayPal's sign-in forms: none touched the password field before sending it out on the wire. Allowing them to assert that they're not going to, and to protect users' saved credentials based upon that assertion, seems like a reasonable goal. But if we go the CSP route, breaking writeonly fields if form targets are not policed may be the best we can do. Also note that there's no reason that the password manager couldn't mark form fields as writeonly when inserting known-to-be-writeonly credentials (or simply refuse to autofill into a read/write field). We don't have to rely on the field being pre-protected if we know that it asserted certain things in the past when we saved the credential in question. Both CSP and the inline attribute could be treated as persistent signaling mechanisms, conceptually similar to httponly or HSTS, which mitigates some of the risk you're pointing to here. (Also note that my attack #3 will work simply if XSRF tokens are user- but not action-bound, which is a common pattern.) I also expect many other corner cases to crop up when others look at the implementations later on. Granted. 3) Regular compromised renderers / malware stealing the data manually entered or automatically populated by the browser? Not doable. Assuming that we ever send the information to the renderer, granted. I'd like to avoid doing that by, for example, sending a nonce to the renderer, and replacing that nonce in the browser process before sending the request out onto the network. 4) Future Chrome origin-bound sandboxed renderers stealing the data manually entered by the user? Probably not doable, by analogy with #1. Granted. Data the user types into a page is always readable, one way or another. 5) Future Chrome origin-bound sandboxed renderers stealing the data auto-populated by the password manager? Feels like for this, we need taint tracking; otherwise, the renderer can ask for the password under false pretenses, perhaps after loading a sub-page with different or no CSP rules. Consider that we can use this signal to flag the _credential_ as writeonly. We don't have to rely on the form _always_ being so flagged. We could try giving the renderer a
Re: [whatwg] Proposal: Write-only submittable form-associated controls.
On Thu, Oct 16, 2014 at 1:31 AM, Eduardo' Vela Nava e...@google.com wrote: Yea the keyup/down/press restrictions are definitely not useful, at least for password protection since the user has clearly no way to know if the field is safe or not. I'd disagree that they're useless, but they're certainly not a robust defense against an attacker reading information that you type into a form. The tainting is never gonna work reliably and consistently as Michal hinted (say, a blob: URL would run in the same origin but not be bound to CSP which could be used to exfiltrate the data). The tainting problem is simplified by focusing on the part I care about: autofill. The dependency on CSP also makes this a bit aspirational. I can agree that the login form could be CSP protected but the whole origin is not as likely. Specially for connect- and form-. As noted in a previous response, I see these concerns as somewhat mitigated by tagging the credential as writeonly in a way that would prevent autofill into a read/write form. And even that might be insufficient (its a common practice to echo back typed passwords when the user doesn't answer a captcha or has it wrong, for example - a same-origin XHR will leak the password). As I think you'd agree, those pages are already shooting themselves in the foot. You're correct that this proposal doesn't solve their problems, but that's not a unique disadvantage of the proposal. :) There are other solutions that seem more likely to work to solve the problem of password managers (something like a synced channelId, for example, or even FIDO style solutions). This proposal seems to try to achieve a mixture of just replacing canary values at the network layer based on destination with an httpOnly-style model for user-supplied data. 1. Password managers aren't the problem. Especially when used to generate even vaguely secure password, they make authentication on the web significantly less insecure than it would otherwise be. 2. The various proposals on http://www.browserauth.net/ like channel-bound cookies (which I think you're referring to above?) can solve cookie theft. They don't solve password theft. If we have a password manager and are gonna ask authors to modify their site, we should just use it to transfer real credentials, not passwords.. Passwords need to die anyway. You ding CSP as a bit aspirational, and then propose killing passwords. *cough* :) As long as modify their site means type 11 characters into your site's template and not rewrite your authentication stack from the ground up using technologies you've never heard of, I think it's something we can reasonably ask of authors. The central advantage of the writeonly proposal is that it's a trivial drop-in change. It's certainly not the real revolution in authentication that we desperately need on the web, but that's a feature, not a bug. :) -mike -- Mike West mk...@google.com Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91 Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Graham Law, Christine Elizabeth Flores (Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
Re: [whatwg] Proposal: Write-only submittable form-associated controls.
1. How are keyup/down/press restrictions useful for password protection? Actually they seem more useful for CSRF instead. 2. How is the tainting problem simplified by focusing on write only? 3. How is tagging the credential as write-only help with the secure deployment of a site-wide CSP policy? 4. Why are sites that echo passwords in password fields shooting themselves in the foot? Also, since it seems I didn't explain myself correctly with what I meant with Channel ID, I'll explain it differently. Imagine if the password manager, instead of just syncing passwords around also moved an httpOnly cookie. And whenever it detects the password going by it appends the httpOnly cookie. If the server detects such cookie in the request it concatenates it after the password and uses that as the auth credential. On the server, this only requires a one line change (adding he cookie at the end if present), on the client the APIs already exist. Same can be done with Channel ID with the further advantage that the OBC can't be copied. The advantage of the cookie approach is that it can be morphed and generated more easily. Also, as a point of reference we've redone authentication many more times in a lot less time with a lot less resources than deployed CSP across all of Google. So yes, it's easier.
Re: [whatwg] Proposal: Write-only submittable form-associated controls.
On Thu, Oct 16, 2014 at 10:36 AM, Eduardo' Vela Nava e...@google.com wrote: 1. How are keyup/down/press restrictions useful for password protection? Actually they seem more useful for CSRF instead. These events are some of the many ways in which the data being typed into a particular field is exposed to script. If we're going to call the field writeonly, we need to lock those down. That said, they only protect that particular field: attackers can easily bypass this restriction by doing more work (overlaying a new form, etc). How are they useful for CSRF? I don't see the link. 2. How is the tainting problem simplified by focusing on write only? Focusing on autofill means that we're moving the flag up to the credential, so we can ensure that the browser only autofills into writeonly form fields. To your specific example, it means we don't have to care about blobs in iframes, because (I'm pretty sure...) we don't autofill blobs in iframes. 3. How is tagging the credential as write-only help with the secure deployment of a site-wide CSP policy? It doesn't. The two are completely unrelated. My point was simply that if we tag a credential as writeonly, we wouldn't fill it into a form that lacked the writeonly flag in a page that lacked the writeonly CSP. Solving CSP deployment isn't a precondition of this scheme. 4. Why are sites that echo passwords in password fields shooting themselves in the foot? Echoing sensitive data in a place where an injected XHR can read it is a general problem. This proposal doesn't make that worse. Imagine if the password manager, instead of just syncing passwords around also moved an httpOnly cookie. And whenever it detects the password going by it appends the httpOnly cookie. If the server detects such cookie in the request it concatenates it after the password and uses that as the auth credential. On the server, this only requires a one line change (adding he cookie at the end if present), on the client the APIs already exist. Same can be done with Channel ID with the further advantage that the OBC can't be copied. The advantage of the cookie approach is that it can be morphed and generated more easily. Sounds like a great way of hardening sign-in. It's not clear to me how that negates the problem of password theft, as I'd still need to be able to sign in on my friend's computer when I accidentally spill coke on my laptop, right? Also, as a point of reference we've redone authentication many more times in a lot less time with a lot less resources than deployed CSP across all of Google. So yes, it's easier. That surprises me. Still, I suspect both are significantly more work than adding an attribute to a form field. -- Mike West mk...@google.com Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91 Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Graham Law, Christine Elizabeth Flores (Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
Re: [whatwg] Proposal: Write-only submittable form-associated controls.
On Thu, Oct 16, 2014 at 11:59 AM, Mike West mk...@google.com wrote: On Thu, Oct 16, 2014 at 10:36 AM, Eduardo' Vela Nava e...@google.com wrote: 1. How are keyup/down/press restrictions useful for password protection? Actually they seem more useful for CSRF instead. These events are some of the many ways in which the data being typed into a particular field is exposed to script. If we're going to call the field writeonly, we need to lock those down. That said, they only protect that particular field: attackers can easily bypass this restriction by doing more work (overlaying a new form, etc). OK, so it's just being locked down out of a formality, but has no security purpose. Sure, so it's not useful for any security purposes. How are they useful for CSRF? I don't see the link. Let's not go into it. But if you lock down an origin as described in the spec, and send a FormData via XHR then one could authenticate an action came as a result of a user action. Anyway, I shouldn't have said that, the solution is incomplete since value= prefilling would also have to be disabled for that to work. 2. How is the tainting problem simplified by focusing on write only? Focusing on autofill means that we're moving the flag up to the credential, so we can ensure that the browser only autofills into writeonly form fields. To your specific example, it means we don't have to care about blobs in iframes, because (I'm pretty sure...) we don't autofill blobs in iframes. The blob: URL would simply steal the FormData from the other page (it's same origin), and submit it via XHR to another origin.. 3. How is tagging the credential as write-only help with the secure deployment of a site-wide CSP policy? It doesn't. The two are completely unrelated. My point was simply that if we tag a credential as writeonly, we wouldn't fill it into a form that lacked the writeonly flag in a page that lacked the writeonly CSP. Solving CSP deployment isn't a precondition of this scheme. I see, so it wouldn't be sufficient to make a field writeonly, you would also need to declare that in the CSP. The whole website would have to have connect-src policies stricly restricting the exfiltration of data from the domain. Is there any (relevant/important) website where locking down connect-src for the whole origin is possible or feasible? Or are we assuming every website has their login form in a unique origin? (Are you expecting to have per-page suborigins implemented before this is feasible?). 4. Why are sites that echo passwords in password fields shooting themselves in the foot? Echoing sensitive data in a place where an injected XHR can read it is a general problem. This proposal doesn't make that worse. Sensitive data is echoed in places where XHRs can read all the time. Your email, your authentication credentials (OAuth, etc), your bank statements. This isn't a general problem. Imagine if the password manager, instead of just syncing passwords around also moved an httpOnly cookie. And whenever it detects the password going by it appends the httpOnly cookie. If the server detects such cookie in the request it concatenates it after the password and uses that as the auth credential. On the server, this only requires a one line change (adding he cookie at the end if present), on the client the APIs already exist. Same can be done with Channel ID with the further advantage that the OBC can't be copied. The advantage of the cookie approach is that it can be morphed and generated more easily. Sounds like a great way of hardening sign-in. It's not clear to me how that negates the problem of password theft, as I'd still need to be able to sign in on my friend's computer when I accidentally spill coke on my laptop, right? How is the password manager able to sync your password to your friend's computer? Also, as a point of reference we've redone authentication many more times in a lot less time with a lot less resources than deployed CSP across all of Google. So yes, it's easier. That surprises me. Still, I suspect both are significantly more work than adding an attribute to a form field. -- Mike West mk...@google.com Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91 Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Graham Law, Christine Elizabeth Flores (Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
Re: [whatwg] Proposal: Write-only submittable form-associated controls.
On Thu, Oct 16, 2014 at 12:16 PM, Eduardo' Vela Nava e...@google.com wrote: On Thu, Oct 16, 2014 at 11:59 AM, Mike West mk...@google.com wrote: On Thu, Oct 16, 2014 at 10:36 AM, Eduardo' Vela Nava e...@google.com wrote: OK, so it's just being locked down out of a formality, but has no security purpose. Sure, so it's not useful for any security purposes. Well, no. It doesn't solve the problem, but it introduces a hurdle. Making an attacker do more work is good. 2. How is the tainting problem simplified by focusing on write only? Focusing on autofill means that we're moving the flag up to the credential, so we can ensure that the browser only autofills into writeonly form fields. To your specific example, it means we don't have to care about blobs in iframes, because (I'm pretty sure...) we don't autofill blobs in iframes. The blob: URL would simply steal the FormData from the other page (it's same origin), and submit it via XHR to another origin.. Ah, that's clever! However: blobs inherit the CSP of their parent frame, so the same mitigations apply. Moreover, if we're doing the network-stack replacement thing, and we know details about the credential, then we can refuse to do the replacement in the browser process if the destination doesn't match the details we have stored for the credential, CSP or not. 3. How is tagging the credential as write-only help with the secure deployment of a site-wide CSP policy? It doesn't. The two are completely unrelated. My point was simply that if we tag a credential as writeonly, we wouldn't fill it into a form that lacked the writeonly flag in a page that lacked the writeonly CSP. Solving CSP deployment isn't a precondition of this scheme. I see, so it wouldn't be sufficient to make a field writeonly, you would also need to declare that in the CSP. Let me rephrase: if we tag a credential as writeonly, we wouldn't fill it into a form field that wasn't writeonly. Form fields are tagged writeonly either by virtue of an inlined attribute, or a CSP on the page. Either individually signals to the browser that the site does not intend to make programmatic use of the field's value. We wouldn't need both in order to decide when to tag a credential as writeonly. The whole website would have to have connect-src policies stricly restricting the exfiltration of data from the domain. Is there any (relevant/important) website where locking down connect-src for the whole origin is possible or feasible? Or are we assuming every website has their login form in a unique origin? (Are you expecting to have per-page suborigins implemented before this is feasible?). 4. Why are sites that echo passwords in password fields shooting themselves in the foot? Echoing sensitive data in a place where an injected XHR can read it is a general problem. This proposal doesn't make that worse. Sensitive data is echoed in places where XHRs can read all the time. Your email, your authentication credentials (OAuth, etc), your bank statements. This isn't a general problem. It is a general problem, given the attack vector you're proposing: if I can inject a same-origin XHR, I can read sensitive data. That includes passwords, if the passwords are echo'd out in the page's contents. I'm agreeing with you that writeonly doesn't solve this problem. I'd suggest that sites themselves could solve it by echoing a nonce rather than the original password, but that's obviously up to them and not something we could spec. Sounds like a great way of hardening sign-in. It's not clear to me how that negates the problem of password theft, as I'd still need to be able to sign in on my friend's computer when I accidentally spill coke on my laptop, right? How is the password manager able to sync your password to your friend's computer? I wasn't clear: the server still needs to accept a bare username/password pair, as it's not the case that users only log in a) using a password manager, b) on a machine that's syncing. As long as that's the case, I don't see how tying passwords to a cookie makes password theft less problematic. -- Mike West mk...@google.com Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91 Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Graham Law, Christine Elizabeth Flores (Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
Re: [whatwg] Proposal: Write-only submittable form-associated controls.
On Thu, Oct 16, 2014 at 3:07 PM, Mike West mk...@google.com wrote: On Thu, Oct 16, 2014 at 12:16 PM, Eduardo' Vela Nava e...@google.com wrote: On Thu, Oct 16, 2014 at 11:59 AM, Mike West mk...@google.com wrote: On Thu, Oct 16, 2014 at 10:36 AM, Eduardo' Vela Nava e...@google.com wrote: OK, so it's just being locked down out of a formality, but has no security purpose. Sure, so it's not useful for any security purposes. Well, no. It doesn't solve the problem, but it introduces a hurdle. Making an attacker do more work is good. 2. How is the tainting problem simplified by focusing on write only? Focusing on autofill means that we're moving the flag up to the credential, so we can ensure that the browser only autofills into writeonly form fields. To your specific example, it means we don't have to care about blobs in iframes, because (I'm pretty sure...) we don't autofill blobs in iframes. The blob: URL would simply steal the FormData from the other page (it's same origin), and submit it via XHR to another origin.. Ah, that's clever! However: blobs inherit the CSP of their parent frame, so the same mitigations apply. Well, it doesn't today. But maybe you mean in the future. But the point is that there are many ways to exfiltrate, these are just the first thing that comes to mind but others like input pattern also are an info leak, and I mean, these are just ideas coming up the top of my mind, the browser wasn't designed to solve this problem and it's dubious if it's really feasible to do so without reinventing a lot of things. Moreover, if we're doing the network-stack replacement thing, and we know details about the credential, then we can refuse to do the replacement in the browser process if the destination doesn't match the details we have stored for the credential, CSP or not. 3. How is tagging the credential as write-only help with the secure deployment of a site-wide CSP policy? It doesn't. The two are completely unrelated. My point was simply that if we tag a credential as writeonly, we wouldn't fill it into a form that lacked the writeonly flag in a page that lacked the writeonly CSP. Solving CSP deployment isn't a precondition of this scheme. I see, so it wouldn't be sufficient to make a field writeonly, you would also need to declare that in the CSP. Let me rephrase: if we tag a credential as writeonly, we wouldn't fill it into a form field that wasn't writeonly. Form fields are tagged writeonly either by virtue of an inlined attribute, or a CSP on the page. Either individually signals to the browser that the site does not intend to make programmatic use of the field's value. We wouldn't need both in order to decide when to tag a credential as writeonly. The whole website would have to have connect-src policies stricly restricting the exfiltration of data from the domain. Is there any (relevant/important) website where locking down connect-src for the whole origin is possible or feasible? Or are we assuming every website has their login form in a unique origin? (Are you expecting to have per-page suborigins implemented before this is feasible?). 4. Why are sites that echo passwords in password fields shooting themselves in the foot? Echoing sensitive data in a place where an injected XHR can read it is a general problem. This proposal doesn't make that worse. Sensitive data is echoed in places where XHRs can read all the time. Your email, your authentication credentials (OAuth, etc), your bank statements. This isn't a general problem. It is a general problem, given the attack vector you're proposing: if I can inject a same-origin XHR, I can read sensitive data. That includes passwords, if the passwords are echo'd out in the page's contents. I'm agreeing with you that writeonly doesn't solve this problem. I'd suggest that sites themselves could solve it by echoing a nonce rather than the original password, but that's obviously up to them and not something we could spec. Sounds like a great way of hardening sign-in. It's not clear to me how that negates the problem of password theft, as I'd still need to be able to sign in on my friend's computer when I accidentally spill coke on my laptop, right? How is the password manager able to sync your password to your friend's computer? I wasn't clear: the server still needs to accept a bare username/password pair, as it's not the case that users only log in a) using a password manager, b) on a machine that's syncing. As long as that's the case, I don't see how tying passwords to a cookie makes password theft less problematic. The user would just have to type the full password (including the extra cookie-random value that the password manager backed up). The caveat of course is that the user has to write this suffix somewhere, but that is what makes the password strong anyway. And anyway, to be clear, this is just a discussion on an alternate design
Re: [whatwg] Proposal: Write-only submittable form-associated controls.
Yes. Two things about service workers: 1. If you can spin up a service worker, the site is already very much in trouble. 2. I have handwavey ideas about ensuring that the FormData object which would be readable via the Request object in the service worker would retain the opaque flag. The spec strawman hints at that, but I haven't done the work to find all the places to monkey-patch. -mike -- Mike West mk...@google.com Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91 Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Graham Law, Christine Elizabeth Flores (Sorry; I'm legally required to add this exciting detail to emails. Bleh.) On Wed, Oct 15, 2014 at 4:25 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 10/15/14, 10:15 AM, Mike West wrote: `FormData` objects created from forms including these writeonly elements would be opaque. You could use them to submit an XHR request, but you couldn't read the values directly from script. If you're at the point where you can run script on the page, can't you spin up a service worker that would capture the data in that XHR? -Boris
Re: [whatwg] Proposal: Write-only submittable form-associated controls.
input writeonly type=password I think that one huge problem with this is that the attacker will have many other, indirect ways to get the value even if you protect direct access to the field. Two most obvious options include: 1) Change the action value for the form to point to evil.com, where evil.com is in attacker's control, 2) Change the action of the form to GET while keeping the same method, let it submit, and then examine location.search. 3) Change the action value of the form and the name of the password field so that the posted data is interpreted by the server as an attempt to, say, post a comment. I worry that there's actually more, and that a lot of nasty taint tracking heuristics would be required to make it go away. /mz
Re: [whatwg] Proposal: Write-only submittable form-associated controls.
Good feedback, Michal. Thanks! On Wed, Oct 15, 2014 at 4:41 PM, Michal Zalewski lcam...@coredump.cx wrote: input writeonly type=password I think that one huge problem with this is that the attacker will have many other, indirect ways to get the value even if you protect direct access to the field. Two most obvious options include: Note that there are two types of attacker I care about: 1. XSS. You've outlined some (of the probably many) ways to bypass the kinds of protection I'd like to build here. Let's discuss below. 2. Renderer flaws. Currently, if someone can corrupt Chrome's renderer process, she can request any and all passwords from the password store by pretending to be various origins. If we can mark certain credentials as writeonly, we know we never have to send them to the renderer, and that any such requests could be ignored. This is similar to what (I hope) we're doing with `httponly` cookies (though I haven't checked, it seems like an obvious optimization). 1) Change the action value for the form to point to evil.com, where evil.com is in attacker's control, I hope that this is mitigated by the `form-action` CSP directive, which allows the site to control the valid endpoints for form submission, and `connect-src`, which allows the same for XHR, EventSource, WebSockets, etc. 2) Change the action of the form to GET while keeping the same method, let it submit, and then examine location.search. Good idea. One way of avoid this would be to lock all forms with writeonly data and XHR with opaque FormData to the POST method. That's probably what we'd like folks to be doing anyway in order to keep potentially interesting information out of server logs and browser history. 3) Change the action value of the form and the name of the password field so that the posted data is interpreted by the server as an attempt to, say, post a comment. Again, mitigated (but by no means avoided) by path restrictions on the `form-action` CSP directive. I worry that there's actually more, and that a lot of nasty taint tracking heuristics would be required to make it go away. That's something I'd like to avoid, insofar as possible. I think it's likely unavoidable to have some sort of opaque flag on request objects in order to do the right thing with regard to ServiceWorkers, but since we already track opaqueness for responses, I hope that's not an overly burdensome taint to track. -mike -- Mike West mk...@google.com Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91 Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Graham Law, Christine Elizabeth Flores (Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
Re: [whatwg] Proposal: Write-only submittable form-associated controls.
1) Change the action value for the form to point to evil.com, where evil.com is in attacker's control, I hope that this is mitigated by the `form-action` CSP directive, which allows the site to control the valid endpoints for form submission, and `connect-src`, which allows the same for XHR, EventSource, WebSockets, etc. 3) Change the action value of the form and the name of the password field so that the posted data is interpreted by the server as an attempt to, say, post a comment. Again, mitigated (but by no means avoided) by path restrictions on the `form-action` CSP directive. Fair enough - although I worry that the likelihood of people using this in conjunction with tightly-scoped per-document CSP (versus the far more likely scenario of just having a minimal XSS-preventing site-wide or app-wide policy that will definitely not mitigate #3 and probably do nothing for #1) are pretty slim. We're effectively adding a mechanism that works well only if you remember about a fairly counterintuitive gotcha, which realistically means that it won't be used correctly something like 90%+ of the time. Cheers, /mz
Re: [whatwg] Proposal: Write-only submittable form-associated controls.
Fair enough - although I worry that the likelihood of people using this in conjunction with tightly-scoped per-document CSP (versus the far more likely scenario of just having a minimal XSS-preventing site-wide or app-wide policy that will definitely not mitigate #3 and probably do nothing for #1) are pretty slim. In fact, the XSS-preventing part is probably a stretch. Facebook and Twitter are often mentioned as the two most significant customers for CSP, but both use unsafe-inline and unsafe-eval. On top of that, note that #3 is not defeated by origin-scoped rules - you need to specify full paths. Honestly, if we're creating a mechanism that implies that a degree of protection is provided for password fields, we should either make it work on its own, *or* at the very minimum require a CSP with form-action specified, and otherwise warn or better yet, break fields flagged as writeonly. /mz
Re: [whatwg] Proposal: Write-only submittable form-associated controls.
On Wed, Oct 15, 2014 at 5:16 PM, Michal Zalewski lcam...@coredump.cx wrote: Fair enough - although I worry that the likelihood of people using this in conjunction with tightly-scoped per-document CSP (versus the far more likely scenario of just having a minimal XSS-preventing site-wide or app-wide policy that will definitely not mitigate #3 and probably do nothing for #1) are pretty slim. In fact, the XSS-preventing part is probably a stretch. Facebook and Twitter are often mentioned as the two most significant customers for CSP, but both use unsafe-inline and unsafe-eval. True. Because both have huge legacy systems built on inlining JavaScript. That's an architectural change that is really truly difficult in aggregate. The same is not the case for login forms. Or credit-card forms, for that matter. The only sites that wouldn't be able to implement something like this without significant effort are those who do client-side encryption (well, encryption) of the sensitive data before passing it on to the server. On top of that, note that #3 is not defeated by origin-scoped rules - you need to specify full paths. You're correct. I mentioned that. :) #3 also relies on the site having a comment form, or some other mechanism of publicly reflecting POST data to the world without a CSRF. Lots of sites have that sort of mechanism, sure, but I don't think that even a majority of high-value sites do. Honestly, if we're creating a mechanism that implies that a degree of protection is provided for password fields, we should either make it work on its own Do you have suggestions for what on its own might look like? , *or* at the very minimum require a CSP with form-action specified, and otherwise warn or better yet, break fields flagged as writeonly. Sure. Doing one or both is probably pretty reasonable. :) -mike
Re: [whatwg] Proposal: Write-only submittable form-associated controls.
For the XSS attacker, couldn't they just use `theInput.removeAttribute(writeonly); alert(theInput.value);`? Or is this some kind of new un-removable attribute?
Re: [whatwg] Proposal: Write-only submittable form-associated controls.
- Would one be able to validate the password field (eg, to detect an empty password)? Is HTML5 validation allowed on a writeonly field. - Could a cross-domain XHR be made? Could FormData from such a field be limited to the same domain. - Something that could be interesting is if the password field only exposed an encrypted or hashed value. For example, it'd be pretty awesome if a website could put a public key and say when a user types in a password here, encrypt it with the public key before sending to the server. This could prevent an attacker from ever seeing the plain text password. Today you could do this with JS, but it would prevent one from using the writeonly attribute. On Wed, Oct 15, 2014 at 4:15 PM, Mike West mk...@google.com wrote: # Problem A user’s credentials are valuable, and are often the key target of phishing and content injection attacks. If a content injection attack can trick a user's credential manager into autofilling her credentials, then the user’s credentials will be available to the attacker directly via DOM APIs or indirectly via form submission to a malicious endpoint. The latter risk can be mitigated via the Content Security Policy `form-action` directive, but the former is a real problem. If passwords are a simple value accessor away, users are at risk. ## Proposal We could mitigate this latter risk by allowing sites to opt-in to denying DOM access to an element's content. If JavaScript can't grab the value, then script injection attacks have a much more difficult time exfiltrating interesting data. This might be as simple as adding a writeonly attribute to submittable elements: input writeonly type=password This would throw an `InvalidStateError` on `value*` accessors, bar the element from constraint validation, block `keydown`, `keyup`, `keypress` events, and probably other things I haven't considered yet. `FormData` objects created from forms including these writeonly elements would be opaque. You could use them to submit an XHR request, but you couldn't read the values directly from script. This state could also be controlled via a Content Security Policy directive which would set writeonly state for some arbitrary set of submittable elements, perhaps based on autocomplete attribute values. Perhaps: Content-Security-Policy: form-writeonly cc-number cc-csc ... current-password new-password ## Spec Suggestions I've strawmanned out the monkey-patching this would require of XHR, Fetch, and HTML in a bit of detail at https://mikewest.github.io/credentialmanagement/writeonly/, and there was a short-lived public-webapps thread at http://lists.w3.org/Archives/Public/public-webapps/2014JulSep/0165.html (and a shorter-lived discussion at http://specifiction.org/t/write-only-input-fields/598). ## Implementer Interest I'd like to implement pieces of this in Chrome to harden our password manager; if we can use this state as a heuristic to mark particular credentials as writeonly, we can keep them out of the renderer process entirely, which would be a nice win for security. I've also talked about it tangentially with Anne and Jonas at Mozilla (the former in relation to Fetch, the latter in relation to a proposed Credential Management API). Neither jumped on it as the best thing ever, but they were both more than marginally supportive. Thanks! -- Mike West mk...@google.com Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91 Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Graham Law, Christine Elizabeth Flores (Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
Re: [whatwg] Proposal: Write-only submittable form-associated controls.
So I might have started this on the wrong foot, but let's consider the broader threat model. What do we want to protect against? 1) XSS stealing the passwords / CC numbers entered by the user manually? This is probably not possible with this proposal; the evil payload may construct a form where the writeonly attribute is not set. 2) XSS stealing the passwords entered by the password manager? To do this, I feel that we need a taint-tracking system coupled with a password manager that remembers that some passwords can go only into writeonly fields, and which URLs and methods they need to be submitted to. The CSP solution + blocking GET feels like a crutch that won't work in practice; my main concern is that writing site-wide policies is hard as-is, and that the likelihood of well-scoped per-page policies, especially with path granularity, is low. But if we go the CSP route, breaking writeonly fields if form targets are not policed may be the best we can do. (Also note that my attack #3 will work simply if XSRF tokens are user- but not action-bound, which is a common pattern.) I also expect many other corner cases to crop up when others look at the implementations later on. 3) Regular compromised renderers / malware stealing the data manually entered or automatically populated by the browser? Not doable. 4) Future Chrome origin-bound sandboxed renderers stealing the data manually entered by the user? Probably not doable, by analogy with #1. 5) Future Chrome origin-bound sandboxed renderers stealing the data auto-populated by the password manager? Feels like for this, we need taint tracking; otherwise, the renderer can ask for the password under false pretenses, perhaps after loading a sub-page with different or no CSP rules. We could try giving the renderer a token that is converted to a password on an ongoing request by the network stack, but there is no way to confirm that the request is being made to the right destination and in good faith. ... The reason why I was previously skeptical of proposals of write-only fields is pretty much because the threat model is so complicated and the solutions are so fragile - but maybe I'm in the wrong on this. /mz
Re: [whatwg] Proposal: Write-only submittable form-associated controls.
On Wed, Oct 15, 2014 at 5:59 PM, Domenic Denicola dome...@domenicdenicola.com wrote: For the XSS attacker, couldn't they just use `theInput.removeAttribute(writeonly); alert(theInput.value);`? Or is this some kind of new un-removable attribute? The strawman suggests setting a flag on the element, and doesn't suggest a way of unsetting that flag. This is conceptually similar to iframe@sandbox's effect on the document loaded into the frame. -- Mike West mk...@google.com Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91 Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Graham Law, Christine Elizabeth Flores (Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
Re: [whatwg] Proposal: Write-only submittable form-associated controls.
On Wed, Oct 15, 2014 at 6:10 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: Nothing in-band will work, because the attacker can replace arbitrary amounts of the page if they're loaded as an in-page script. It's gotta be *temporally* isolated - either something out-of-band like a response header, or something that has no effect by the time scripts run, like a meta that is only read during initial parsing. Yes. Hence the CSP directive portion of the proposal. The inline attribute is useful for the specific password manager case I'm concentrating on, as it gives us a clear indication that the site doesn't intend to do wacky manipulation of its credentials on the fly. We can use this to determine how and when the password manager (or credit card autofill, or whatever) ought to refuse to expose information to the renderer. -- Mike West mk...@google.com Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91 Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Graham Law, Christine Elizabeth Flores (Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
Re: [whatwg] Proposal: Write-only submittable form-associated controls.
Yea the keyup/down/press restrictions are definitely not useful, at least for password protection since the user has clearly no way to know if the field is safe or not. The tainting is never gonna work reliably and consistently as Michal hinted (say, a blob: URL would run in the same origin but not be bound to CSP which could be used to exfiltrate the data). The dependency on CSP also makes this a bit aspirational. I can agree that the login form could be CSP protected but the whole origin is not as likely. Specially for connect- and form-. And even that might be insufficient (its a common practice to echo back typed passwords when the user doesnt answer a captcha or has it wrong, for example - a same-origin XHR will leak the password). There are other solutions that seem more likely to work to solve the problem of password managers (something like a synced channelId, for example, or even FIDO style solutions). This proposal seems to try to achieve a mixture of just replacing canary values at the network layer based on destination with an httpOnly-style model for user-supplied data. If we have a password manager and are gonna ask authors to modify their site, we should just use it to transfer real credentials, not passwords.. Passwords need to die anyway.
Re: [whatwg] Proposal: Write-only submittable form-associated controls.
On 2014-10-15 18:10, Tab Atkins Jr. wrote: On Wed, Oct 15, 2014 at 8:59 AM, Domenic Denicola dome...@domenicdenicola.com wrote: For the XSS attacker, couldn't they just use `theInput.removeAttribute(writeonly); alert(theInput.value);`? Or is this some kind of new un-removable attribute? Doesn't matter if it is or not - the attacker can still always just remove the input and put a fresh one in. Nothing in-band will work, because the attacker can replace arbitrary amounts of the page if they're loaded as an in-page script. It's gotta be *temporally* isolated - either something out-of-band like a response header, or something that has no effect by the time scripts run, like a meta that is only read during initial parsing. ~TJ There is also legitimate needs for being able to edit the password field from a script. I have a custom login system (that is currently in public use) that takes the password, does a HMAC on it (plus a salt and some time limited info). This allows login in without having to send the password in the clear. It's not as secure as https but it's better than plaintext. A writeonly password field would have to be optional only or my code would break. And I'm not the only one. SpiderOak.com also uses this method (they use bcrypt on the password to ensure that SpiderOak has Zero-Knowledge). Any limitations on form manipulations should be based on same origin limitations instead, such that only a javascript with the same origin as the html with the form can read/write/manipulate the form. -- Roger Rescator Hågensen. Freelancer - http://www.EmSai.net/
