JavaScriptからローカルファイルシステムへのアクセスを可能にするFile API、標準化へ一 66
ストーリー by hylom
夢は広がる 部門より
夢は広がる 部門より
hmmm 曰く、
JavaScriptからローカルファイルシステムへのアクセスを可能にするFile APIに関する仕様のドラフト文書が、Web標準規格を策定するW3Cに提出されたそうだ（Ars Technicaの記事、ドラフト文書）。
File APIを利用することで、たとえばローカルのテキストファイルを読み込んでテキストエリアにその内容を入力する、といった処理がクライアントサイドだけで実装できるようになる。また、セキュリティ的な問題を発生させないよう、フォームの<input type="file">要素でユーザーが指定したファイルのみにアクセスできるような制限が課せられているとのこと。
JavaScriptの可能性が大きく広がるのは歓迎できるが、セキュリティ面が考慮されているといってもちょっと怖い面があるのも否めない。あとはIEの対応ですかね……。
まあ、大丈夫だとは思うけど (スコア:2, 参考になる)
httpのputだけと違う(けど操作は変らない)とかが気にはなりますがねー。
1.デフォルト値とかスクリプトでの操作はできないけど、運用まで含めて穴はない?
2.普通のアップロードのページに悪意あるスクリプトが仕込まれて、XMLHTTPRequestみたいなクロスドメインなデータ転送で漏れたりとかしない?(ページ遷移自体は普通なので、気付かれにくくなるかなとか)
3.レンダラとECMAScriptVMが密の場合はいいけど、疎な作りの時にファイルデータのやりとりが穴にならない?(ここは特にただの空想でこう思っただけ)
# 打ち決めのパスを弱めのスタック汚染みたいな方法で埋めこんで、File PATHが指定された状態にできたりとかしたら、悪さできちゃうなとか
みたいな、素人的には気になる所が色々。
# まー昨今の状況でそれを許すようなAPIにはしないとは思いますけど。
M-FalconSky (暑いか寒い)
誰がファイルを指定するの? (スコア:1)
s/クライアント再度/クライアントサイド/
>また、セキュリティ的な問題を発生させないよう、要素で指定したファイルのみにアクセスできるような制限が課せられているとのこと。
指定ファイル以外アクセスできないのはいいですが,"誰が"指定するでしょうか?
"要素で指定した"とあるとJavascriptまたはHTMLを書いた人と解釈できるんですが.
Re: (スコア:0)
ぜひとも<input type="file">がどういった挙動をするか
ご自身でHTMLを書いて確認してみてくださいな。
#shiba氏はinputタグをそのまま張った上に、プレビューを見なかったのですかね。
Re: (スコア:0)
inputだから基本的にはユーザーが「参照」のダイアログとかで入力するのでしょうが…
valueで初期値を指定できないように、またJavaScript等のサイト側のコードが
自分で設定できないように実装するんでしょうねぇ。
勝手に指定できる仕様だったら本当に夢がひろがりんぐですがｗ
Re:誰がファイルを指定するの? (スコア:1, 参考になる)
valueにJavaScriptからパスを流しこもうとしてもうまくいかないので大丈夫ですよ。
というか、それができたらこのFile APIが存在しなかったとしても
JavaScriptを使って簡単に無理やりファイルを送信させることができちゃいます。
セキュリティに不安 (スコア:1)
初心者の人にそれが危険かどうか判別できるのでしょうか。
便利そうだからぜひ実装してほしいが最低限デフォルトOFFを希望。
Re: (スコア:0)
<input type="file">のフォームを置いて、現状でも同じことができますけど?
File APIで何が従来より危険になるのか説明してもらわないと説得力ありませんね。
Re: (スコア:0)
Re:セキュリティに不安 (スコア:1, 参考になる)
やれたとして、dataスキーマを使って結果を返すことになるでしょうから、
さほど現状と変わらない気がします。
あと
>キュリティ的な問..(略)..指定したファイルのみにアクセスできるような制限が課せられているとのこと
とあると、今やってないけどこの機能がつくからそういう制限が付くみたいに読めちゃうのもしかた無いかも…
Re:セキュリティに不安 (スコア:1)
Re:セキュリティに不安 (スコア:1)
Java（JavaScriptではない）の場合、java.policyで通常はアプレットからのファイルI/Oは制限されているので問題ないと思います。
＃読めないのは当然としても、出所不明のファイルにアクセス権与えたのなら、与えた人が悪いだけです
神社でC#.NET
Re: (スコア:0)
#Javaじゃなくて、JavaScriptだとあれほど...。
Re: (スコア:0)
<input type="file">をHTMLに直書きしなくても、JavaScriptで生成してそのソースは
> Javaでやられたらよめねー
な人にはわからないようにいくらでも難読化できます。
# JavaじゃなくてJavaScriptだろ、というのは既出だから繰り返さない
> 以上バカでゴメンね
分かってるなら最初から的外れなコメントをしなければいいのに。
利便性より危険性 (スコア:1)
デフォルトでOFF できればUACみたいなの希望です
＃アンチウイルスソフトでブロックするのが常識、とかいう未来は嫌ですね
Re:利便性より危険性 (スコア:2, すばらしい洞察)
<input type="file"> →[POST]→ サーバ →[XHTRなど]→ クライアントサイドスクリプト
サーバを経由しないで取得できるようになるだけで、出来ることは増えていません。
<input type="file"> →[FileReader]→ クライアントサイドスクリプト
むしろサーバにアップロードされずクライアントサイドで完結する分だけセキュアな感じがします。
それにJSのバグによるセキュリティホールを気にするなら、JSの実行自体をUAC的なものでブロックすべきでしょう。File APIだけではなく。
Re: (スコア:0)
ですね。
「JavaScriptでファイル読み込み＝危険」といった脊髄反射的な書き込みが散見されますが、
よくよく考えれば、必ずしも危険になるわけではないことが分かります。
アップロードファイルのサイズ制限なんかはよくある要件(現状のJavaScriptでは不可能)ですし、
ファイル内容の簡易チェックなんかもクライアント側で事前に実施することでユーザの利便性向上も期待できます。
最近はFlashを使ったファイルアップロードが増えてますが、JavaScriptで同様のことができるようになるかな。
Re: (スコア:0)
だから、File APIで何がより危険になるんですか?
なんだか変な勘違いしている人が多すぎるのですが、今までももしユーザーが<input type="file">にファイルを指定したら、それを勝手にJavaScriptでアップロードすることはできました。
> もう嫌な予感というか予測しか出てこないです
ちゃんと理由を説明できないならそういうのは杞憂とか妄想と言います。
Re:利便性より危険性 (スコア:2)
<input type="file"> に指定したファイルだけとはいえ、ローカルファイルへの
アクセスをするAPIを追加するのだから、その部分にバグが入り込むと、
指定していないローカルファイルでもアクセスされてしまうかもしれないって
ことじゃないのかな。
Re:利便性より危険性 (スコア:1, 参考になる)
> その部分にバグが入り込むと、
> 指定していないローカルファイルでもアクセスされて
その後どうするんですか? それが最終的にどこか知らないサーバーに送信されるから危険なんでしょう? 何度も言っている通り、それならFile APIを使わなくてもすでに可能です。<input type="file">に指定していないファイルを突っ込んで送信できてしまうというバグは現に今までにも存在しました。
で、JavaScriptからアクセスされることの何が問題なのですか? alertを禁止したドコモと同類の発想ですか?
Re: (スコア:0)
徳丸浩の日記 - i-mode2.0セキュリティの検討 - 携帯JavaScriptとXSSの組み合わせによる「かんたんログイン」なりすましの可能性 [tokumaru.org]
携帯についてはこんな話があるそうだ。
そもそもFile APIだけ見て擁護してるコメントと
JavaScriptそのものを危険視していてさらに要因が増えることを懸念しているコメントと
意見がかみ合ってない
フィッシング詐欺を効率化 (スコア:1)
旧来なら取得したファイルをサーバで解析することが必要でしたが、
File APIの登場によりクライアントでのファイル解析が可能になります。
これによりサーバリソースを大幅に削減し、コストパフォーマンスを向上させることができます。
マリオネット詐欺とでも名付けようか
Re: (スコア:0)
「このページでは、JavaScriptによってファイルを読み取るので、
外部に情報が漏洩する事はありません」といった詐欺広告文句で、
なんらかプライベートなファイルに対してJavaScriptで処理させる。
その後（当然、なんらかの処理をした後に画面が遷移する）のページで、
HIDDEN属性でファイルの（さらに言えば、JavaScript処理の中で、暗号化するなど）
内容を保持したまま、次にだれもが押しそうなボタンが、実はHIDDEN情報を外部サーバに
送信するフォームボタンになっているとか。
今までなら、まずJavaScriptでファイルを処理できないので詐欺広告はうてない。
次に、ファイルストリームを暗号化して、途中経路（IDSやIPS、最近ではクレジットカード番号に似た
番号の外部送信をみつけるような機器もありますね）で見つかる事無く、送信できる。
Re: (スコア:0)
そんなに難しいことをしなくても、サーバに情報を送るだけなら1ピクセルの透明画像貼り付ければOKですよ。
POST以外でも情報を送る事は可能です。分割すれば大容量にも対応できます。HTTPSならさらに安全です。
昔から色々な所で使われてる技術です。え？ブロックされている？じゃ、2ピクセルで。
Re:利便性より危険性 (スコア:1, すばらしい洞察)
ドラフトが公開されているのに予想とか…… まず読んだらどうですか？
Re: (スコア:0)
このスレでは、新しいFile APIがある世界と、今までのそれがない世界を比べて、セキュリティがどうこうって議論をすんなら、そりゃ有益だろうさ。
でも現実には、手でHTML書いたこともないような素人以下のニワカが溢れて、File APIがない状態でのセキュリティがどうこうって話しかできてない。そしてその話してる本人はFile APIについての話に参加してるつもりになってる。笑うしかないね。
もうここは文系バカの遊び場でしかないと思ってあきらめるしかないのかね。
予想通りのコメントがちらほら (スコア:1, 興味深い)
<input type="file">の挙動を知らない人達が騒いでいるのね。
この要素のvalueは初期値指定やJavascriptでのセットができないというのに…。
そんなことよりも<input type="file">属性への
ファイルのドラッグ&ドロップでパスを入力してくれるのを標準で対応してほしい。
PC素人にアップロードファイルを選択させるの大変なんだよね。
Re: (スコア:0)
それはW3Cではなくブラウザ開発者の仕事じゃあないの？
ますますオフになる (スコア:1, すばらしい洞察)
ますますJavaScriptオフでの運用が広がる
そしてたかがリンクを開くためだけにJavaScriptが使用されていてクリックしても反応がない糞サイトが増える
賛成の気持ち (スコア:1)
画像ファイルを投稿させるようなページで、サムネールなどを画像から（ユーザ自身で）切り出させたい場合、一度サーバに送ってからじゃないとダメですし。（その後キャンセルされたりしたときのロールバックもめんどい...）
# ユーザ側からしても、ファイル選択->送信->画像切り出し->送信 ってよりも、ファイル選択->切り出し->送信のほうがわかりやすい
multipart でなく、他のフォームデータと一括してサーバに POST 送信できれば、そこら辺の処理も簡略化できそう。
セキュリティとユーザビリティのトレードオフなんだろうけど、「ユーザが送信に同意した」ファイルに関しては（そのファイルをローカルに書き戻したりしない限り）いじらせても大丈夫なんじゃないだろうか。
ん？ 俺、今何か言った？
Re:賛成の気持ち (スコア:1, 参考になる)
これはまさに
> 画像ファイルを投稿させるようなページで
使うことを想定して作られたAPIです。その種のサイトの一部では、file: URLで投稿前に画像をプレビューする機能を提供しているのですが、Firefoxではhttp:なページからfile: URLの参照が禁止されているとか、input type="file"から読み出してもファイルのフルパスを知ることができなくなる [mozilla.org]とか、バージョンが上がるにつれて制限が強化されていったので、そういうことができません。そのためサーバへ送信する前のプレビューを実現するための機能がほしいと要望されていたのです。
File APIが実装されれば、canvasと組み合わせることでそういう機能を実現できます。というわけで、Firefoxが3.6で真っ先に実装する予定です。
Re:賛成の気持ち (スコア:1)
どちらにせよ Firefox だけが実装しても他のブラウザが追随しない限り、制作側としてその機能は使えないんですけどね... よしんば IE が実装することになっても、実際使用できるまでそのバージョンが世間に広まるまで何年かかることやら。
ん？ 俺、今何か言った？
ＩＥ独自拡張 (スコア:1)
したら、当然のことのようにセキュリティホールを実装し、
PCのファイルを消しまくるサイトが氾濫するに1000M$
Re:ＩＥ独自拡張 (スコア:1, 参考になる)
あるある
仕様じゃなくて実装が不安なんだよねー。
Re:ＩＥ独自拡張 (スコア:1, 参考になる)
調査では、最もバグが多いブラウザはFirefox、その次がSafari。
ベンダーではAdobeが最も多い。
Firefox 3.6β4 (スコア:1, 参考になる)
Firefox 3.6β4でサポートされている [itmedia.co.jp]そうです。
# それだけなのでAC。
typo (スコア:0)
○ 標準化へ─
Re:typo (スコア:1)
標準化へ一歩、かもしれんですよ?
もはや病気 (スコア:0)
ブラウザで何でもかんでもやろうとするのをやめろと言いたい
Re: (スコア:0)
私の気持ちを代弁してくれたのでお礼にCromeOSマシンを送ります。
Re: (スコア:0)
おい、誰か座布団もって来い！
全然危険が無いとはいえないのでは？ (スコア:0)
Re: (スコア:0)
読み込みしかないみたいだけど。
Re: (スコア:0)
読み込み処理 → バッファオーバーフロー
なんて余裕でありえる
W3Cはブラウザがどう実装するかなんて
関係ないからな
Re: (スコア:0)
そんなこといったら画像を大量に開いたり巨大な画像を読んでも同じじゃん。
そもそも読み込むファイルは操作する人が自分で指定するんだぜ？
クラッシュするほど巨大なファイルを自分で選んだなら自業自得。
あまりに知性を疑う言いがかりだと思わないか？
Re: (スコア:0)
POSTならまだしもJavascriptで処理すんだろ？
ただでさえ富豪的処理なのに
Re: (スコア:0)
>読み込み処理 → バッファオーバーフロー
それはローカルファイルに限った話じゃないだろ。何を言ってるんだ？
File APIが決まったなら (スコア:0)
トロイが勝手にファイルアップする1手段になりそう (スコア:0)
すでにいくつかの手段はあるんですが、操作の容易さではJSが一番でしょうね
トロイがマクロでアップした重要ファイルをサーバーサイドで書き換えてPC内部に戻せば
ユーザーには手が出せないレベルまでPCを乗っ取ることも可能になりそうです
Re: (スコア:0)
んなことできるわけないだろ。先にドラフトを読めよ。
JNLP API (スコア:0)
どちらも設計思想としては、ユーザが明示的に指定したファイルのみを読み書き可能とすることで、ユーザが知らないところでファイルが壊されたり、不正プログラムを入れられたり、情報を盗み見られたりすることを防止しようというところですかね。
それと、ユーザにファイルを選ばせることで、プログラムによってファイルの中身を見られたり書き換えられたりすることを実感させ、警戒感を持たせようという狙いもあるのかな。
公開鍵証明書の確認ダイアログや署名なしプログラムの警告ダイアログと、どっちがいいのかという観点もあるかもしれませんね。