Javascript 操作本地文件API?

本来要下班了，但是看到这个令人震惊的消息，不得不上来写今天的第三篇blog

新闻原文：



引用自cnbeta的新闻：
FileReader 对象并不需要特别的权限，但出于显然的安全考虑，直接使用文件路径进行访问是不允许的，必须结合常规的 HTML file 对象，用户点击浏览之后，选择本地文件，JavaScript 再通过 DOM 引用该文件并进行操作，这个机制使得该 API 相对安全一些，因为任何本地文件的获取都需要用户的人工参与。

以下例子使用该 API 打开一个本地文件并将文件内容显示在一个 div 容器中，我们甚至可以在 div 上加上 contentEditable 属性，用户可以直接编辑文件的内容，不过，该 API 并没有提供将文件内容写回本地文件的方法，因此你编辑的内容无法保存。 

  
    
    
  
  

    
HTML File Reader Test


    
Select a file:
    
    Load
    


    

    Bold
    Italic
    Underline
    


    

  

注意上面我加粗的部分，这段API有两个特点：
1. 每一步都有用户参与
2. 只能读，不能写

这样设计都是出于安全的考虑，但是我需要说的是，仅仅这样做是远远不够的！

我相信出于安全考虑，在读文件的时候还会禁止读一些操作系统文件内容，或者是只允许读某些目录下的文件内容，但是黑客总能找到各种方法去把风险放大到极限。

之前就曾经出过利用html和javascript遍历目录、文件的漏洞（还有尚未公布的），也曾经出过仅利用javascript就能偷偷把文件上传到黑客网站的漏洞（已经patch的）。但是这个新的操作文件的API一出来，无疑将提供新的 attack surface。

而浏览器安全模型的一个重要思想------ 隔离， 不论是sandbox，还是别的什么技术，都会因此受到挑战。

我闭上眼睛，就想到了各种shellcode利用javascript API操作本地文件，想到了各种XSS trick，想到了clickjacking可能诱使用户错误的点击、选择文件，然后把文件偷走。。。。。。。。

当然，新的功能能够给应用带来更多的优点，我们应该鼓励创新，但是在创新的同时，一定要好好做安全，否则就会成为悲剧。今天还看到个文章，里面讲到 IE6 是有史以来造成最大、最多安全问题的软件。IE6 好吗？在当时来说当然好，但是由于当时对安全认识的不足，还是付出了很惨重的代价。

再次强调，我并非反对这个API，而是强调安全是使用的前提，在安全的基础上，才能更好的使用这个特性。
（最近有些人看我文章老是不认真看完，然后断章取义的发表一些不恰当的看法，所以我不得不多强调几次我的观点。）