HTML5で開発するときのセキュリティリスク 55
ストーリー by hylom
よりセキュリティは複雑に 部門より
よりセキュリティは複雑に 部門より
あるAnonymous Coward 曰く、
HTML5はブラウザベースのアプリを簡単に作成できるなど便利な反面、セキュリティ的な見地から見るとリスクも大きいとの声が挙がっている（darkREADING、本家/.）。
HTML5では大容量のデータを保存するために、Webブラウザ側のストレージやデータベースにデータを保存する機構が用意されている。これはオフラインで利用できるアプリケーションを作るのに便利だが、いっぽうで攻撃者が保存されたデータを取得して外部サーバーにアップしたり、ローカルに置いたデータを改変する、といった危険性も考えられる。
またもう一つのリスクとして、サードパーティ製のコードの中に含まれている潜在的な脆弱性が上げられる。これまでJavaScriptは、読み込まれたドメインからしかリソースを要求できないようになっていたが、HTML5ではCORS（Cross-Origin Resource Sharing）というメカニズムが追加され、指定したルールにおいてHTMLを読み込んだサーバー以外からもコードやリソースの読み込みが可能になった。開発者はアクセス制御やCORSを使用可能にした状態ではワイルドカードを使用しないなど、厳格な利用ポリシーを定めて運用すべきだとしている。
目の見えない人には不便だよね (スコア:1)
読み上げソフトが使いやすいような配慮も忘れないで欲しい
開発のリスクっていうより (スコア:0)
HTML5対応ブラウザを使うことのリスクをコントロールすべき。
クラックされて困るのはウェブサイトを開発した人より
そのPCのユーザなんだから。
Re: (スコア:0)
CSPがあるじゃない
Re: (スコア:0)
XSSはHTML5対応関係ないんだが……
ブラウザゲーム (スコア:0)
実際ブラウザゲームってチートしやすいよね。
流石にパラメータの直接改変なんかは難しくても、Chromeだけで単純作業の自動化とかは数十分で書ける。
ガチャ課金的なゲームであれば、重課金者が上位目指すために10万円とかかけて自動でアイテム浪費しても、サーバが落ちない限りまあ問題ない、とか、そういう判断なんだろうか。
オンラインの有料クイズゲームなんかが出ないのもその辺と関係ありそう。
Re: (スコア:0)
セキュリティとチートは別の問題
Re: (スコア:0)
そんな労力かけて儲かるの？
Re:ブラウザゲーム (スコア:1)
一回コード書いたらほっとくだけでちっちゃいサイフが増える増える。
#というイメージ？
Re: (スコア:0)
大して儲からなくてもいいんでしょ。最低限食っていければ。
アプリケーションとコンテンツ (スコア:0)
セキュリティリスク的なものは、特に感じてはいないのだけど、アプリケーションのようなリッチすぎるサイトの開発は自重してほしいですね。
最低限、コンテンツはjavascriptとiframe無効にしても閲覧できるように設計してほしいです。
せっかくcssでいろんな事できるようになっているのにjavascript頼りすぎ。
Re:アプリケーションとコンテンツ (スコア:2)
「アプリケーションのようなリッチすぎるサイトの開発は自重してほしい」
「最低限、コンテンツはjavascriptとiframe無効にしても閲覧できるように設計してほしい」
これってたとえば、「Google Mapのようなリッチなオンライン地図の開発は自重してほしい」、「最低限、昔ながらの↑↓←→ボタンが画面の上下左右に並んでいて、地図スクロールの際はそれをクリックしてページ遷移させて使う、というニーズにも対応してほしい」、ということなのでしょうか。
# それは受け入れがたい/面倒臭いな…。
静的コンテンツしかないようなサイトで妙に凝ったことはしないでくれ、ということならもちろん賛成なのですが。
Re: (スコア:0)
そういうのはアプリとして配布すりゃいーじゃん。webは静的ページだけにしようぜ。
Re:アプリケーションとコンテンツ (スコア:2)
そそ、親コメントのAC氏の主張はそんな感じに読めますね。Webは静的なコンテンツと、あとはせいぜいごく基本的な入力フォームを使う（静的コンテンツを探し出す）検索ツールのようなもののみ。
と、いうことは：
- 地図、たとえば Google Map は、地図用のアプリをインストールして使わせる。サーバとのやり取りはHTMLではなく、地図専用に設計されたマークアップランゲージ（またはバイナリ画像）を使う。地図はハイパーテキストと関係ないのだから、HTMLの拡張で対応するのは美しくない。
- Facebook や Twitter といった SNS も、SNS毎に用意された専用のアプリをインストールして使う。サーバとのやり取りはHTMLでなく、各SNS向けに設計されたマークアップランゲージ（または単なるプレーンテキスト的ななにか）を使う。HTMLの拡張で対応するのは ... （以下略）
- Youtube などの動画サイトも ... （以下略）
- Trac などのタスクトラッカーも ... （まあこれは静的コンテンツの範疇に近いので Script無効でもそこそこ使えそうですが、select要素の動的な変更が不可、ちょっとした更新でもページ遷移）
なるほど、それぞれ専用に設計されたアプリとデータを使い、ブラウザに妙な機能を持たせない、HTMLに妙な拡張をさせない、という点では確かにエレガントかも。
ただ、それによって発生するデメリット（インストールの手間やセキュリティリスク、バグなどのアップデート対応、Webブラウザという単一の基盤とURIによって多種のデータを統一的に扱えなくなる利便性の喪失などなど）を上回るメリットって、エレガントであるという点以外には何があるのでしょう？
Re: (スコア:0)
静的ページだけである必要性がない
ただ時代の流れに逆らいたい発言にしか見えない
Re: (スコア:0)
いまこそGopherを活用するべきだな。
Re:アプリケーションとコンテンツ (スコア:1)
開発者としては最低限JavaScriptやiframeは有効にしていただきたいのですが。
それとも開発版のブラウザでフラグを有効にして使って貰えますか？
それを皆がしてくれるのならJS使わずできることが多少は増えるのですが。
あとHTML5ファイリーのAPIの多くはJSが絡んでいてこれから減る方向にはいきません。
これからはWebComponentsやMVCの考え方でJSがますます必須になってきます。
そもそもWebの有り様が変わってきているのです。
W3CのHTML5仕様策定完了発表によると、
「HTML5は～～デバイス機能へのアクセスを行うクロスプラットフォームアプリケーションに対応するフルプログラミング環境です」
となっています。
今やWebサイトは見るものから使うものになってきており、Webコンテンツは立派なアプリケーションなのです。
Re: (スコア:0)
ドキュメントとアプリケーションの概念は本当に切り分けて整理して欲しかった。
アプリケーション環境を「HTML」を拡張して実現する発想は、今でも筋が悪いと思っている。
Re: (スコア:0)
XHTMLでさえあれだったのに、そんなもの誰も使わないですしおすし。
Re: (スコア:0)
ですがマルチプラットフォームのアプリケーション環境としてはHTML以上に適するものはないかと。
また、HTML5ではリッチになるだけではなく、セマンティクスやユーザビリティを向上させる仕様も含まれています。
例えばルビの標準化、また、他のトピックで挙がっていますが、
「読み上げソフトが使いやすいような配慮」の仕様も策定されています。
HTML5は無秩序に機能を増やしているわけではありません。
むしろ、今まで無秩序だった独自機能や概念をきちんと標準化するのが役目です。
ですから、心配するようなことはないと思いますよ。
Re: (スコア:0)
HTMLはドキュメントのための仕様であったはずで、UIを意識して作られたものではありません。
UIを記述する目的では、HTMLタグの大半は冗長ですし、そもそも目的に合っていません。
HTMLの本来の目的を意識して適正に書かれたドキュメントは、そのHTMLに含まれる見出しや表の情報を
適切に抽出したり、ドキュメント内の内の特定要素を一意に取り出したりできる、有意義なデータソースとなります。
ドキュメントに動的に変化する要素は原則不要で、JavaScriptは無効か、強い制限を掛ける運用で問題無いでしょう。
このドキュメントは、現状のWebブラウザよりもかなりシンプルな実装で、
Re: (スコア:0)
HTML5みたいなのはあっていいと思うけど、構造化されたドキュメントが欲しい場合もたくさんありますね
プログラムとデータが一体化しているメリットもあるけどデメリットも確実にあって替えがきかないことが多い
Re: (スコア:0)
＞＞HTMLはドキュメントのための仕様であったはずで、UIを意識して作られたものではありません。
ですがそのような使われ方をされるようWebが変化してきたので、HTMLも変わったのです。
UIを記述する目的では、HTMLタグの大半は冗長ですし、そもそも目的に合っていません。
いいえ、例えばmeter要素やprogress要素、そしてinputの拡張等、UIが作りやすいようになっています。
＞HTMLの本来の目的を意識して適正に書かれたドキュメントは、そのHTMLに含まれる見出しや表の情報を
適切に抽出したり、ドキュメント内の内の特定要素を一意に取り出したりできる、有意義なデータソースとなり
Re: (スコア:0)
世界は変わっていくものです。それを受け入れるかどうかはあなたの問題です。
そうですね、私個人としては、現状のHTML5の方向性は非常に残念なものと言わざるを得ません。
複数組織の思惑が絡む標準化という作業において、削ぎ落とし方向の仕様の洗練化は大変困難なものなのだろうと推察します。
Re: (スコア:0)
ネタニマジレスカコワルイ
Re: (スコア:0)
あなたの様な主張、例えば仕様はミニマムであるべきだと主張する人は沢山います。
しかしそれでも、これだけ普及したWebで、大きな新しい仕様を最初から絞って取り決めることは現実的ではないのです。
そういう仕様は実際に搭載して長くテストしてみないと良し悪しが見えてこないこともあります。
結局はニーズですから、使われる仕様が生き残り、使われない仕様は淘汰されるのが健全だと思います。
それにWebは今やブラウザだけのためのものではなく、
様々な機器、環境向けのアプリケーション環境です。
今はまだまだ削ぎ落とす段階ではありません。圧倒的に機能が足りないですし、模索の段階なのです。
残念と言いますが、
このようなやり方のほうが最終的に多くの意見や実情に揉まれた良い仕様ができます。
HTML5は「生きている仕様」であり、それがもっともよい今流の洗練化の方法なのです。
Re: (スコア:0)
ミニマムは良いと思っていますが、本論はアプリとドキュメントの分割です。
開発者が苦労しない、ユーザーの利便性を損なわない、セキュリティ問題が発生しづらい、
そんな素敵な仕様にまとまる事を期待しますよ。
Re: (スコア:0)
分離する必要がない
頭かたいんじゃない？
Re: (スコア:0)
メリットの問題です。
Re: (スコア:0)
メリット？
誰かさんの違和感がなくなるってことでしょそれ
Re: (スコア:0)
css も 過去に cssxss 問題がありましたし、リッチになればなるほど、
ブラウザや書き手によるリスクは高まるのではないでしょうか？
見た目の制御にjsを無駄遣いするなというのは同意です。
Re: (スコア:0)
もうJS無効を連呼する時代では無いでしょう
Re: (スコア:0)
> もうJS無効を連呼する時代では無いでしょう
提供側の意識とユーザー側の意識によるんじゃない？
何も知らないユーザーに「JSは安全」と言ったり「JSのリスクを語らない」のは、提供側の怠慢だと私は思う。
「JSは安全と言う」と書いてて、「原発安全」を思い出した。
「原発安全」なら、「JS」なんてもう安全すぎて話にならないなぁ（笑）。JSの安全性だのにかかずりあってるIT業界の人間って、原発村の人と違って、みんなまじめなのね。
Re:アプリケーションとコンテンツ (スコア:1)
例えばXSSは本質的にJSの問題でも無駄遣いした結果でもありません。
コードが埋め込まれることが問題で、別にJSじゃなくてもかなり危険な穴なのです。
代わりにSVG（画像）が埋め込まれた場合でも、accesskey属性を使ってキー入力を盗んだりも技術的に可能です。
そのような驚くべきテクニックはいくつもあります。
けして「JSのリスク」と考えてはいけません。サイト設計のリスクです。
JSやその他の仕様に欠陥があるのではなく、拙いサイトを作った時にできる穴なのです。
こういったサイトの脆弱性は「JSのリスク」と多くのユーザーと提供者に誤解されていることが一番の問題なんですよ。
そのようなリスクを緩和するためにいくつかの方法がありますが、その中でも強力なのがCSPです。
これを適切に設定することで、穴ができてしまうことを防げます。
多くのブラウザでv1.0が使用出来るようになってきました。
これからはサイト設計者、ユーザーが正しいセキュリティの高め方を知るべきだと思います。
１０年前のイメージを引きずって、JS云々言ってるようじゃいけません。
Re: (スコア:0)
動作時に当てにする値がブラウザ側＊＊のみ＊＊に存在するタイミングが有る場合、
ページの脆弱性チェックでAランクの問題となると思います。
CSPもそれなのでは無いでしょうか？もちろん趣旨としてはポリシーなので積極的に
脆弱性とはならないでしょうけど。
Re: (スコア:0)
CSPは制限をかけて、ページの想定外の振る舞いを規制することで、
XSS等の陥りやすい脆弱性を緩和するためのものです。
CSPを使うのであれば、自分もそれに違反する書き方はできませんから、
必然的にコードもクリーンになります。
Re: (スコア:0)
javascriptは必須になってきてるから無効はちょっと厳しいけど、iframeはなくてもいいかもとは思う。
５０歩ゆずってiframeはありでも、frameはもう完全に廃止でいいと思うんだ。
CSSでいろいろできるようにはなってるけど、多くのシェアを持ってるIEが糞な状態なのでまだ満足に使えない部分も多い。
全ブラウザがanimationあたりを完全サポートしてからが本番な気がします。
# IE9以下は切り捨ててもいいでしょうか？
Re: (スコア:0)
iframeがないと動画サイトの動画を埋め込むこともできません（Flashなら方法はありますが）
また、埋め込み「ツイート」ボタンや「いいね」ボタン、「＋１」ボタン等はiframeで実装されています
ちなみにframeはHTML5では廃止されています
ただし、ブラウザはサポートし続けないといけないとされています
Re: (スコア:0)
> iframeがないと動画サイトの動画を埋め込むこともできません（Flashなら方法はありますが）
> また、埋め込み「ツイート」ボタンや「いいね」ボタン、「＋１」ボタン等はiframeで実装されています
いらないなあ・・・
Re: (スコア:0)
要らないのならOFFにすればいいさ
Re: (スコア:0)
ボタンがiframeなのは知ってるけど、それならそれも script でいいんじゃない？動画もね。document.write()でもして。
その一部だけ外部っていうのが気持ち悪い。
Re: (スコア:0)
iframeにしないとああいったボタンは実現できません。
なぜならログインが必要だからです。
また、埋め込んだサイトが勝手にボタンを押せては意味がありません。
よってiframeを使う以外ありえないのです。
動画も、例えばYouTubeなら独自の評価ボタンやらUIがあります
ニコニコ動画ならコメントを流さないといけません
また再生後のオススメ動画を取得したりする為に通信が必要です、
通信はセキュリティ上の都合でドメインを跨いでできないよう制限されているので、
これもまたiframeでしか実現できません
その他のコンテンツでも同じです
HTML5 (スコア:0)
HTML5 アプリの具体例と
開発方法を分かりやすく書いたサイト、本を教えて下さい。
そもそもシェア増やしてるの？
Re: (スコア:0)
具体的は難しいですね。
そもそもHTML5というのはWeb2.0みたいな最近のWebの勢いを表す曖昧なキーワードとして使われてますから。
また「アプリ」という単語についても同様です。
最低作った人がこれはHTML5アプリだと言えばなんでもそうなるんだと思います。
もっとちゃんとしたのだと、やっぱり新しく標準化された機能を使ってあるべきですかね。
例えはcanvasを使ったり、offlineStorageを使ったりした、インタラクティブなものなら立派なWebアプリだと思います。
もう少し違った視点だと、WebSocketなどを使って、ユーザー感がリアルタイムに関われるサイトが、
従来のサイトとは
Re: (スコア:0)
アプリとまではいかないデモ段階ですが
http://www.chromeexperiments.com/ [chromeexperiments.com]
いろいろ集まってます。ウェブ(html5)でここまでできるようになるんだぁ！とは感じられます。
なにかキラーアプリじゃないですが、ヒットアプリが出ると一気に増えそうな気がします。
JavascriptがGoogleMapsやAjaxで一気に広がったように。それ以前は、Javascriptが認知はされてても、そこまで活用はされてなかったように思う。
Googleの貢献が大きい。
このタイミング！！ (スコア:0)
FirefoxOS/Taizenへのネガティブキャンペーンと見た。
Re: (スコア:0)
そもそもパッケージングアプリなので、XSS等は起こりにくいですし。
多くのパッケージングアプリではCSPが必須なので心配は要りません。
HTML5もだけど、 (スコア:0)
HTTPS（HTTP）ポートもセキュリティリスクになっているよね。
何でもかんでも詰め込むのが悪い。
Re: (スコア:0)
リスクがないものなんてない
何事もトレードオフ
セキュリティを高めるもっとも賢いトレードオフは勉強すること
Re: (スコア:0)
別に詰め込むのが便利だから詰め込んだんじゃなくて、
セキュリティ対策で他のポートが簡単に使えなくなったから
みんなHTTP使うようになった。
ポートで制限なんて安直な方法を採用したのが悪い。
Re: (スコア:0)
この手のアホは、いくらでも出てくるな。
>WEBサービスを提供している会社がデータ盗聴してんだから
それ盗聴っていうか？
サービス提供会社と通信したら、そこにデータが行くことは当然だろ？
行かないと考える方が無理あるだろ？
>そのWEBサービスを使うこと自体がセキュリティホール。
セキュリティホールって言葉の使い方を間違ってる。
多分言いたいのは「リスク」だろう。
>まだ、G使って機密情報を公開してるの？
どこで公開されてるの？
G社の社員が閲覧できるって意味なら、それは単なるアーカイブであって、「公開」じゃないだろう。