1) if there is a ':' in the URI, you split the URI into scheme and
scheme-specific part.
No. The first check is is this an absolute file path. That check is done
with platform-specific logic:
#if windows
if the path matches letter:\ or \\...
#else
if the path starts with a slash
#endif
Then
I'm not sure if we reached a conclusion on this, but I don't like a
couple of aspects of the Firefox logic (assuming I understood it
correctly).
The way I would look at it, the browser always has a current context
that indicates the current base to use for relative URIs. In the case
where you are
On Mon, Jan 18, 2010 at 4:54 PM, Dirk Pranke dpra...@chromium.org wrote:
So, you then get the following algorithm:
1) if there is a ':' in the URI, you split the URI into scheme and
scheme-specific part.
2) If there is a scheme:
2.1) If the scheme is a recognized/supported one, dispatch
On Mon, Jan 18, 2010 at 7:16 PM, Peter Kasting pkast...@google.com wrote:
On Mon, Jan 18, 2010 at 4:54 PM, Dirk Pranke dpra...@chromium.org wrote:
So, you then get the following algorithm:
1) if there is a ':' in the URI, you split the URI into scheme and
scheme-specific part.
2) If there
On Thu, Jan 14, 2010 at 9:23 AM, Paweł Hajdan, Jr.
phajdan...@chromium.orgwrote:
Thanks for the responses. However, I'm not sure about the next steps.
Did you mean it's a security risk, don't do it, or the risk is
negligible, do it? How about requiring a --file switch before a
relative file
But this way will not trigger the file access code (as far as I understand),
since you will start Chrome with an http://;, which means it is a URL, so
Chrome will not open the file.
And even if they click on the file, it is a .com file, not a URL shortcut.
Or maybe I did not understand you
Sure. It's the way to exploit naive scheme (open local file, then try to
open remote one if this fails). If you distinguish local/remote using
filename only and don't involve the filesystem the scheme fails: people will
not create shortcuts which don't work! And if they worked once they'll work
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
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:
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
[BTW, don't take my argument as support for allowing relative paths on
the command-line. It's such a low-volume use-case that I'd be
perfectly fine requiring explicit fully-qualified URLs and be done
with it. If it doesn't start with a protocol, we don't open it.
99.99% of the users who even
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
On Thu, Jan 14, 2010 at 9:19 AM, Scott Hess sh...@google.com wrote:
[BTW, don't take my argument as support for allowing relative paths on
the command-line. It's such a low-volume use-case that I'd be
perfectly fine requiring explicit fully-qualified URLs and be done
with it.
:( This
On Thu, Jan 14, 2010 at 1:16 PM, Peter Kasting pkast...@google.com wrote:
On Thu, Jan 14, 2010 at 9:19 AM, Scott Hess sh...@google.com wrote:
[BTW, don't take my argument as support for allowing relative paths on
the command-line. It's such a low-volume use-case that I'd be
perfectly fine
On Thu, Jan 14, 2010 at 1:55 PM, Scott Hess sh...@google.com wrote:
If you try to open a
relative path and it doesn't work, you go Oh, right, relative path.
No, actually, what I say every time is What the heck, why did it try to
open this as a hostname? and then I laboriously navigate through
On Thu, Jan 14, 2010 at 2:05 PM, Peter Kasting pkast...@google.com wrote:
I don't think Victor's objections have merit.
(For public benefit)
Partly because you can't put ':' in a filename on Windows, which is the OS
where local files aren't resolved. On the Mac opening local files already
BTW, AFAICT on both Mac and Linux, chrome-cmd file.html opens
file:///path/to/cwd/file.html. Mac works for opening relative
http:/file.html. Since http: is not a valid filename for Windows,
I'd say making them all consistent would make sense.
On Thu, Jan 14, 2010 at 1:55 PM, Scott Hess
Michał, Chris: could you comment on security aspects and give some
recommendations?
Ben, could you comment on the user interaction / usability aspect?
We have few choices here, I'm not sure which one is preferred.
On Mon, Jan 11, 2010 at 23:23, Benjamin Smedberg bsmedb...@gmail.com wrote:
For
On Wed, Jan 13, 2010 at 8:36 AM, Evan Martin ev...@google.com wrote:
Since the proposed vulnerability is that I have cd'ed into a specially
crafted malicious directory then type out google-chrome
some-particular-url, at which point I will end up at a file:// URL
under the attacker's control,
I'm fine with the Firefox way. It seems OK for command line inputs to
require more strictly validated inputs for URLs, and to follow shell
semantics for handling files.
-Ben
On Wed, Jan 13, 2010 at 7:42 AM, Paweł Hajdan jr phajdan...@gmail.com wrote:
Michał, Chris: could you comment on security
On Wed, Jan 13, 2010 at 23:01, Chris Evans cev...@chromium.org wrote:
On Wed, Jan 13, 2010 at 8:36 AM, Evan Martin ev...@google.com wrote:
Since the proposed vulnerability is that I have cd'ed into a specially
crafted malicious directory then type out google-chrome
some-particular-url, at
For what it's worth, the way Firefox solves this is:
* Check if the file is an absolute file path
** on Windows, X:\... or \\...
** on Posix, /...
* Otherwise, it's a URL relative to the current working directory
** So index.html resolves using the URL machinery to
file:///c:/cwd/index.html
**
That's easy to answer:
Copy the code from Firefox that allows it to handle both local paths
and URLs correctly and incorporate that into Chrome.
On Jan 8, 5:15 am, Paweł Hajdan, Jr. phajdan...@chromium.org wrote:
We havehttp://crbug.com/4436, and the problem is that if you launch
chrome
I would also like to point out that this is *NOT* just for launching
chrome with index.html in the current directory.
It must work for all these cases:
C:\path\to\chrome.exe index.html
C:\path\to\chrome.exe .\index.html
C:\path\to\chrome.exe ..\index.html
C:\path\to\chrome.exe
24 matches
Mail list logo
