1

Background

I initially wanted to create documentation for my applications as simple local html files on disk. To serve this purpose documentation was thought to be organized as follow:

doc
├── index.html
└── resources
    ├── includes
    │   ├── part1.html
    │   ├── part2.html
    │   └── part3.html
    └── scripts
        ├── makedoc.js
        └── jquery-3.1.1.min.js

So that documentation could simply open in default web-browser when clicking on index.html (or via mean of open command in my application). And index.html was just thought as a container to help breaking-up documentation in smaller partxx.html pieces:

<!DOCTYPE html>
<html>
<head>
  <script src="./resources/scripts/makedoc.js"></script>
  <script src="./resources/scripts/jquery-3.1.1.min.js"></script>
  <script>$(document).ready(function() { replaceBodyParts(); }</script>   
</head>
<body>
  <div replaceWith="./resources/includes/part1.html"></div>
  <div replaceWith="./resources/includes/part1.html"></div>
  <div replaceWith="./resources/includes/part3.html"></div>
</body>

Just using replaceBodyParts and jQuery to replace div with real content + auto-numbering sections, etc...

Problem

When opening documentation in Firefox (version 49.0.2), there is no issue, great! ... When opening documentation in Chrome (version54.0.2840.71 m), I get the following error:

Cross origin requests are only supported for protocol schemes: http, data, chrome, chrome-extension, https, chrome-extension-resource

Question

After reading other threads about this I clearly understand security concerns about accessing local file system from external domain. My question is more why it works in firefox and no in chrome (even recent releases):

  • Does this mean Firefox is more clever to understand that index.html being opened locally, there is no cross-origin issue ?
  • Or does this mean Firefox is less secured on that point than Chrome ?

NB: I'm not interested in solutions like instantiating local web-server, or change chrome settings. This is local documentation that user should be able to open simply (even it forces them to use firefox rather than chrome to read it - or if it forces me to abandon the idea of splitting documentation is small parts -).

Community
  • 1
  • 1
CitizenInsane
  • 4,755
  • 1
  • 25
  • 56

1 Answers1

2

Firefox is clearly less secured, it deliberately allows something that Chome locks down. (Specifically, Firefox allows a script running in an HTML page to read a local file when the HTML file is also a local file AND in the same or higher directory on the user's filesystem. Chrome just has a blanket ban on reading from the filesystem.).

Whether that is something that should be secured is largely a matter of opinion about the relative merits of convenience and functionality Vs the likelyhood of someone managing to engineer a situation where it can be exploited.

The developers of Firefox and Chrome clearly have different opinions on that front.

Quentin
  • 914,110
  • 126
  • 1,211
  • 1,335
  • So you clearly means that here firefox is not making special `cross-origin` by-pass by detecting that initial url is `file://c:/.../doc/index.html` ... this would mean to me that even mounted in a server firefox would still allow to make get request on my local file system .. oO ? – CitizenInsane Oct 26 '16 at 14:19
  • @CitizenInsane — What? No. I thought your question was "Why are Firefox and Chrome rules different?" not "What is the difference between Firefox and Chrome rules?" (Added some explanation to the answer) – Quentin Oct 26 '16 at 14:21
  • Thanks for the clarifications in your answer that Firefox only allows this when everything is local ... I can't see any situation in this case where this could be a security issue that can be exploited, but maybe just making blanket ban is just better to really avoid by-passes that could turn to be wrong in other situations. – CitizenInsane Oct 26 '16 at 14:29
  • 1
    Want access to things in someone's Download folder? Point them at a URL with an HTML document and `content-disposition: attachment` and assume they'll click on the downloaded file. Want access to things elsewhere on the disk? Just needs some social engineering to get them to move it. It's an HTML file. It must be safe, right? – Quentin Oct 26 '16 at 14:32
  • Hummm .... I see ... Thanks for this example for where this could be used. – CitizenInsane Oct 26 '16 at 14:35