2

我使用 Filesystems API 写入 Chrome 沙盒存储中的新文件：

准备FS：

window.requestFileSystem  = window.requestFileSystem || window.webkitRequestFileSystem;

function errorHandler(e) {
  var msg = '';

  switch (e.code) {
    case FileError.QUOTA_EXCEEDED_ERR:
      msg = 'QUOTA_EXCEEDED_ERR';
      break;
    case FileError.NOT_FOUND_ERR:
      msg = 'NOT_FOUND_ERR';
      break;
    case FileError.SECURITY_ERR:
      msg = 'SECURITY_ERR';
      break;
    case FileError.INVALID_MODIFICATION_ERR:
      msg = 'INVALID_MODIFICATION_ERR';
      break;
    case FileError.INVALID_STATE_ERR:
      msg = 'INVALID_STATE_ERR';
      break;
    default:
      msg = 'Unknown Error';
      break;
  };

  console.log('Error: ' + msg);
}

var fileSystem;

function onInitFs(fs) {
  console.log('Opened file system: ' + fs.name);
  fileSystem = fs;
}

navigator.webkitPersistentStorage.requestQuota(1024*1024, 
  function(gB){
    window.requestFileSystem(PERSISTENT, gB, onInitFs, errorHandler);
  }, function(e){
    console.log('Error', e);
})

写文件：

fileSystem.root.getFile('log.txt', {create: true}, function(fileEntry) {

    // Create a FileWriter object for our FileEntry (log.txt).
    fileEntry.createWriter(function(fileWriter) {

      fileWriter.onwriteend = function(e) {
        console.log('Write completed.');
      };

      fileWriter.onerror = function(e) {
        console.log('Write failed: ' + e.toString());
      };

      // Create a new Blob and write it to log.txt.
      var blob = new Blob(['Lorem Ipsum'], {type: 'text/plain'});

      fileWriter.write(blob);

    }, errorHandler);

}, errorHandler);

所以后来我在./ChromeFolder/FileSystem/003/p/00/00000000内容中找到了一个新文件Lorem Ipsum（用十六进制编辑器读取它）。

混淆文件名

我认为我可以像普通挂载的 FS 一样访问沙盒 FS，这样我就有了普通的文件和目录名称。相反，我看到了一些混淆的文件名（00000000而不是预期的log.txt），而不是我预期的结构。

像这样：

预期图片

是否可以像普通 FS 一样访问这个沙盒 FS，所以我可以在使用 FileSystems API（我的意思是结构和文件名）在 Chrome 中创建它们时管理所有文件，或者它是不可能的并且它在外部保持混淆铬？

是否有任何技巧，Chrome 中的任何标志更改以达到我的预期？

4

1 回答 1

2

与许多“我怎么不能_ __ _ __？”一样 诸如此类的问题，答案是“安全性”。对您的问题的简短回答是“不”。文件系统 API 专门设计为 Web 客户端（例如浏览器）的一种方法，仅通过 API而不是从外部为开发人员提供类似文件系统的存储结构。

API 规范的“ 4.3 安全注意事项”部分准确地解决了您正在尝试的行为。如果客户端使用其实际文件名（例如“FinanceReport.doc”）存储原始文件，那么受感染机器上的恶意软件将更容易定位和利用通过文件系统 API 存储的敏感数据。此外，如果使用了实际文件名，那么它可以使这些文件可执行，例如使用该名称将“EvilActions.exe”存储在本地文件系统上。（注意：某些客户端，例如 Chrome，甚至不允许您存储可执行文件。）这些是您看到文件和存储混淆的一些原因。实际上，API 并没有明确指定如何客户端应该存储数据，只有本地存储会引起客户端应该解决的安全问题。

我最近完成了对 HTML5 的全面安全评估，包括文件系统 API。我向您保证，如果 API 和客户端实现都成熟，您几乎肯定会看到进一步的措施来阻止或至少混淆本地存储的数据，以防止来自客户端外部的访问。为了进一步加强本地存储的安全性，客户端甚至可能转向将整个内容存储为一个大文件，类似于 MS Access 如何使用.mdb用于存储的文件。同样，这完全取决于客户。因为您正在尝试对 API 之外的数据/文件进行某种后门访问，并且以一种在 API 中被特别称为“安全问题”的方式进行，所以您今天使用的任何“解决方案”都可能随着客户端安全性的成熟，明天就会失败。如果您可以出于合法目的这样做，恶意软件作者可以这样做是出于恶意目的，而客户端制造商将尽其所能防止这种情况发生。

于 2013-10-09T19:42:09.050 回答