2.00 KB, text/plain
811 bytes, patch
|Details | Diff | Splinter Review|
4.41 KB, text/plain
Dup of bug 5704?
Assignee: saari → sfraser
Component: General → OS Integration
QA Contact: winnie → petersen
Greg: yes, but this would be for chimera.
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: chrispetersen → os.integration
Target Milestone: Camino1.1 → Camino1.2
CCing Mike (cause he wasn't on here), Ian, and Nick, along with myself (as potential reviewers). Thanks a bunch for looking at this, Daniel. cl
Remove tabs and fix whitespace.
Attachment #226350 - Attachment is obsolete: true
Fix tabs and whitespace.
Attachment #226351 - Attachment is obsolete: true
Attachment #226349 - Attachment is obsolete: true
Attachment #226360 - Attachment is obsolete: true
Attachment #227017 - Flags: review-
Remove superfluous comments and target the BrowserWindowController instead of BrowserWrapper.
Exactly the same as previous submission but change a conditional test to be of form "!condition" instead of "conditon == nil".
once it's on your machine, what's to keep an applescript from zipping up local files and emailing them to a random address? I don't see how we can prevent something already on the machine from stealing data.
So Outlook shouldn't have any protection against viruses that are already on the machine, and use it to fire off gobs of spam? I agree that we need to be careful about the implementation of this, though I'm not sure if we should specifically prohibit things like form submit (even if we could).
(In reply to comment #26) > I don't think your example would be possible for the following reasons: > > 1) The patch provided cannot return text back to AS > 2) AFAIK, there is no way to invoke Keychain without using native obj-c code 1) is only a temporary drawback, presumably, and isn't necessary anyway. There are all kinds of ways it could be used once available in the JS context--screenshots of an alert(password), setting the document.location to the URL of a CGI passing the password, etc. 2) is irrelevant; Camino does it for you. Let me try to make the steps more clear: -PasswordStealer.app tells Camino to open Slashdot.org -PasswordStealer.app waits until it's finished loading. -Meanwhile Camino loads Slashdot.org, finds that I have a keychain entry for it, and fills in my username and password, all automagically, as it always does -PasswordStealer extracts the value of the password field via JS, and does something nefarious with it. Now repeat with a bank, or some other site you really care about. It will be possible, and it will be possible precisely because it will run in the context of an existing page (where Camino has helpfully filled in a value from the keychain). Yes, there is the argument that if you have a malicious local app you are sunk anyway, but the entire point of the Keychain's access control system is to prevent one local app from accessing the secure data of another app when it's not authorized to do so. Isn't that the whole point of using the Keychain instead of storing website passwords in a flat file?
this bug (secretly) asks for parity with MacIE or NS4's applescript supprt. I seem to recall being able to get the entire page contents from applescript in those older browsers. Can someone check their dictonaries? If so, users are already soaking in this problem...
Users are only soaking in it if they currently store all their passwords in NS4 or IE too, which I doubt is the case for most people. I don't think Camino should emulate MacIE security holes any more than Firefox should emulate WinIE security holes. Is there any way to run these scripts in a slightly different security context that would disallow things like reading the value of password fields? (Frankly, the fact that I can go to a window with a bulleted-out password field and type some JS in the location bar and be shown the password feels like a problem too--there's a reason you can't "copy" from password fields.)
Attachment #227024 - Flags: review? → review?(stuart.morgan)
Attachment #227024 - Flags: review?(stuart.morgan)
(In reply to Stuart Morgan from comment #36) > (Frankly, the fact that I can go to a window with a bulleted-out > password field and type some JS in the location bar and be shown the > password feels like a problem too--there's a reason you can't "copy" from > password fields.) http://hints.macworld.com/article.php?story=20120926103722471 :P There's apparently a whole market for Safari and Chrome extensions that do that automatically :P
You need to log in before you can comment on or make changes to this bug.