Shibuya.XSS techtalk #7 の資料です。
![明日から使える?! PATHでXSSする技術/ Shibuya.XSS techtalk #7](https://cdn-ak-scissors.b.st-hatena.com/image/square/a7c40c35fe0d0d2fc06d4caa90dbf7ad46b8e116/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2Fd6d5cd3379a2458d90f8ac5b98c7d202%2Fslide_0.jpg%3F6053193)
Shibuya.XSS techtalk #7 の資料です。
単純ではない、最新「クロスサイトスクリプティング」事情:HTML5時代の「新しいセキュリティ・エチケット」(2)(1/3 ページ) 連載目次 皆さんこんにちは。ネットエージェントのはせがわようすけです。第1回目は、Webアプリケーションセキュリティの境界条件であるオリジンという概念について説明しました。 現在のWebブラウザーでは、同一オリジンのリソースは同じ保護範囲にあるものとし、オリジンを超えたアクセスについてはリソースの提供元が明示的に許可しない限りはアクセスできないという、「同一オリジンポリシー(Same-Origin Policy)」に従ってリソースを保護しています。 その保護範囲であるオリジンを超え、リソースにアクセスする攻撃の代表事例であるクロスサイトスクリプティング(XSS)について、今回、および次回の2回に分け、HTML5においてより高度化された攻撃と、その対策を説明しま
4. 典型的なXSSサンプルに対する「素朴な疑問」 • クッキーの値がアラートで表示されても、特に危険性はないよ うな気がする • クッキーの値はブラウザのアドオンなどでも表示できるよね • 任意のJavaScriptが実行されると言っても、ホームページ作 れば任意のJavaScriptが書けるし、見た人のブラウザで実行 されるよね… Copyright © 2013 HASH Consulting Corp. 4 5. そもそもの疑問:JavaScriptは危険か? • 実は、JavaScriptの実行自体は危険ではない • Webは、未知の(ひょっとすると悪意のある?)サイトを訪問し ても「悪いこと」が起きないように設計されている • JavaScriptの「サンドボックス」による保護 – JavaScriptからローカルファイルにアクセスできない – JavaScriptからクリップ
タイトルは出来れば関連する方に読んで欲しかったので、軽く釣り針にしました。すみません。:*) 最近はやりのヒウィッヒヒー(Twitter)でも、よく「○○ったー」みたいなサービスがばんばん登場してますね! おかげでますますツイッターが面白い感じになってて、いい流れですね! でも・・・ちょっと気になることが・・・ 最近「もうプログラマには頼らない!簡単プログラミング!」だとか・・・ 「PHPで誰でも簡単Webサービス作成!」だとか・・・ はてなブックマークのホッテントリで見かけますよね・・・ プログラミングする人が増えるのは素敵です!レッツ・プログラミングなう! なんですけど・・・ ちゃんとセキュリティのこと考えてますか・・・!? 『セキュリティ対策とか難しいし面倒くせーし、俺の適当に作ったサービスとかどうなってもイイしww』 いいんですいいんです! 別にそう思ってるならどうでもいいんです!
昨日の日記で、DK祭りで使われている脆弱性がXSSかCSRFかという問題になった。どうも、XSSとCSRFがごっちゃになっている人もいるように見受けるので、簡単な整理を試みたい。 XSSとCSRFには似た点がある。 どちらも「クロスサイト」という言葉が先頭につく なりすましのようなことが結果としてできる どちらも受動型攻撃である それに対して、もちろん違う点もある。専門家から見れば「似てるも何も、そもそも全然違うものですよ」となるのだろうが、現に混同している人がいるのだから紛らわしい点もあるのだろう。 私思うに、XSSとCSRFの決定的な違いは、以下の点ではないだろうか。 XSSは攻撃スクリプトがブラウザ上で動くが、CSRFはサーバー上で動く このため、XSSでできる悪いことは、すなわちJavaScriptでできることであって、攻撃対象のCookieを盗み出すことが典型例となる。一方、CS
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く