I would say that with systems where you can actually use a scheme ("http://") as a file name (or folder, or something like that), there should be an indication that this is a file and not a URL, just for the sake of phishing protection. Even put a red strike (like you do with invalid https) on the 'fake scheme' part, just so the user will be somewhat notified.
☆PhistucK On Thu, Jan 14, 2010 at 19:15, Scott Hess <sh...@google.com> wrote: > On Thu, Jan 14, 2010 at 6:56 AM, Victor Khimenko <k...@google.com> wrote: > > On Thu, Jan 14, 2010 at 5:38 PM, Scott Hess <sh...@google.com> wrote: > >> On Thu, Jan 14, 2010 at 1:31 AM, Victor Khimenko <k...@google.com> > wrote: > >> > Consider this attack vector: URL file on Desktop. Chrome will be > started > >> > from known directory, now we need to put malicious file there. Hmm. > >> > Easy: > >> > create archive with some valuable data AND file http:/www.google.com(as > >> > we've dicussed it's valid filename on Linux and MacOS). A lot of users > >> > will > >> > just unpack it on desktop and ignore some strange folder named "http". > >> > Then > >> > they click on URL file and the data from computer is sent to some > >> > unknown > >> > direction. > >> > >> I'm not really sure where you're going, here. Why would this be any > >> different than convincing the user to click on a .html file? > > > > It's different because user is hosed when he clicks CORRECT AND VALID > file - > > at least the file which was correct and valid some time in the past. User > > DOES NOT click on the malicious http folder - he uses the same citibank > link > > he always used. It the same as difference between NULL dereference and > > uninitialized variable - in first case problem is immediately obvious, in > > the the second one between error point and disaster there are millions of > > commands so it's not easy to see the connection. > > There is no clicking, here. It's when the user launches Chrome on the > command-line with a particular file. > > Unless I misunderstand. For any programmatic system which wishes to > launch Chrome with a command-line argument, we should expect them to > be explicit (file:/...), and if they choose to pass us ambiguous > input, there's only so much we can do. I would hope that programmatic > systems aren't passing us relative command-line filenames, though, > it's hard to have one program treat relative paths consistently, > expecting two to address them with the same assumptions is madness. > > >> Chrome's various protections are based on where Chrome is getting the > >> file from, not on the shape of the URL (if you open a file named > >> "https://citibank.com", that file will NOT get the citibank.com > >> secure cookie, etc). > >> > > Of course not - but if you'll open the file https://citibank.com it > still > > can do a lot of stuff to your account. It's not the end of world, but > it's > > not a trivial matter either. There are no separate domain for file named > > http:/citibank.com and for file named ../.ssh/identity :-) Of course > there > > are other security measures which will hopefully save ../.ssh/identity > file, > > but it does not mean we are free to ignore this threat. > > As I said, if convincing me to click on a local file can result in an > attacker receiving arbitrary files from my system, then we are well > and truly screwed. > > But I don't believe that is the case currently, so I don't think it > would change anything if the file is "http:/something.com" rather than > "something.html". Yes, the user could be confused by the first URL > (though Chrome would show "file:///full/path/http:/something.com"), > but the attack surface is not changed. People load local HTML files > all the time. If doing so could trivially expose sensitive local > files like your ssh identity, then we should be talking about not > allowing local files at all, not about what types of names we should > allow. > > -scott > > -- > Chromium Developers mailing list: chromium-dev@googlegroups.com > View archives, change email options, or unsubscribe: > http://groups.google.com/group/chromium-dev >
-- Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev