问题描述
使用Filesystems API在Chrome的沙盒存储中写入新文件：准备FS： window.requestFileSystem = window.requestFileSystem || window.webkitRequestFileSystem;
函数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;
默认值：
msg ='未知错误';
break;
};
console.log（'Error：'+ msg）;
}
var fileSystem;
函数onInitFs（fs）{
console.log（'Opened file system：'+ fs.name）;
fileSystem = fs;
navigator.webkitPersistentStorage.requestQuota（1024 * 1024，
function（gB）{
window.requestFileSystem（PERSISTENT，gB，onInitFs，errorHandler）;
}，函数（e）{
console.log（'Error'，e）;
}）
写入文件：
fileSystem.root.getFile（'log.txt'， {create：true}，function（fileEntry）{
//为FileEntry（log.txt）创建一个FileWriter对象
fileEntry.createWriter（function（fileWriter）{
fileWriter.onwriteend = function（e）{
console.log（'Write completed。'）;
};
fileWriter.onerror = function（e ）{
console.log（'Write failed：'+ e.toString（））;
};
//创建一个新的Blob并将其写入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 ），而不是我期望的结构。 / p>
像这样：
是否有任何技巧，任何标志Chrome的变化，以获得我所期望的？
与许多我怎么不能 _ __ _ __ ？有些问题，答案是安全。你的问题的简短答案是不。文件系统API是专门为Web客户端（例如浏览器）设计的，只能通过API 而不是从外部为开发者提供类似于文件系统的存储结构。 b Section <的API规范正好说明了您正在尝试的行为。如果客户端将原始文件存储为实际的文件名（例如FinanceReport.doc），那么受害机器上的恶意软件可以更容易地找到并利用通过文件系统API存储的敏感数据。另外，如果使用实际文件名，则可以使这些文件成为可执行文件，例如将EvilActions.exe存储在具有该名称的本地文件系统上。 （注意：某些客户端（例如Chrome）甚至不会允许您存储可执行文件）。这些是您看到文件和存储混淆的一些原因。事实上，API没有明确指定客户端应该如何存储数据，只是本地存储引发了客户端应该处理的安全问题。 我最近完成了对HTML5的全面安全评估，包括文件系统API。我向你保证，作为API和客户端的实现，如果API都成熟了，你几乎可以肯定会看到进一步的措施，阻止或至少混淆本地存储的数据，而不是从客户端访问。为了进一步提高本地存储的安全性，客户甚至可以将整个事物存储为一个大文件，类似于MS Access如何使用 I used Filesystems API to write to a new file in a sandboxed storage of Chrome: preparing the FS: writing the file: So afterwards I found a new File in the I thought that I could access the sandboxed FS as a normal mounted FS, so that I have normal File and Directories names. Instead I see some obfuscated file names ( Like this: Is it possible to access this Sandboxed FS as a normal FS, so I could manage all files as I create them in the Chrome using the FileSystems API (I mean structure and file names) or is it impossible and it stays obfuscated for the outside of the Chrome? Are there any tricks, any flag changes in Chrome to get what I expected? As with many "How come I can't ______?" sort of questions, the answer is "Security." And the short answer to your question is "no." The File System API was specifically designed solely as a method for web clients (e.g., browsers) to give developers a file system-like storage structure only through the API not from the outside. Section "4.3 Security Considerations" of the API specification addresses exactly the behavior you're attempting. If the client were to store the raw files with their actual file names (e.g., "FinanceReport.doc") then it would make things much easier for malicious software on a compromised machine to locate and exploit sensitive data stored through the File System API. Also, if the actual file name were used, then it could make those files executable, such as storing "EvilActions.exe" on the local file system with that name. (Note: Some clients, such as Chrome, won't even let you store executables.) These are some of the reasons you see the obfuscation of file and storage. In fact, the API does not explicitly specify how the client should store the data, only that local storage raises security concerns that clients should address. I recently completed a full scale security assessment of HTML5, including the File System API. I assure you that as the API and client implementation if the API both mature, you will almost certainly see further measures to block or at least obfuscate locally stored data vis-a-vis access from outside the client. To further bolster local storage security, clients may even shift toward storing the whole thing as one big file, similar to how MS Access uses a 这篇关于使用FileSystem API编写的沙箱中的所有文件可以轻松获得正常（去混淆）的访问吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！
$ b
.mdb 文件进行存储。再次，这完全取决于客户。由于您正尝试对API以外的数据/文件进行后门程序访问，并且以API中安全问题的方式进行访问，所以您现在可能使用的任何解决方案客户安全日趋成熟，明天就会失败。如果您可以为了合法目的而做到这一点，恶意软件作者可以做的只是为了恶意，客户端制造商将尽其所能来阻止这种行为。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 with the Lorem Ipsum content (reading it with a hex-editor). 00000000 instead of expected log.txt) and not the structure I expected..mdb file for storage. Again, it's entirely up to the client. Because you're attempting a sort of backdoor access to the data/files apart from the API, and doing so in an manner specifically called out as a "security concern" in the API, it's likely that any "solution" you employ today may fail tomorrow as client security matures. If you can do it for legitimate purposes, malware authors can do is for malicious purposes, and client manufacturers will do what they can to prevent that.