だいぶ間があいてしまいましたが、本年1月31日に開催された、第04回まっちゃ445勉強会目覚まし勉強会におけるライトニングトークの資料を公開します。 UnicodeによるXSSとSQLインジェクションの可能性View more presentations from ockeghem.
XSSで何ができるか? cookie情報、formの送信内容を盗む、偽の情報を見せる 「信頼出来ないWebサイト」でのXSSはそもそも無意味 信頼してほしいならXSSくらい直せ イントラだったら関係ない? むしろイントラ内の方が盗みたい情報がいっぱいある JSONによる秘密情報の漏洩 JSON Hijacking Object.prototype.__defineSetter_で特定プロパティが設定されたら何らかの処理を行うようにする。 JSONをHTMLとして読み込むと上記のコードが入る。 対策 先頭にwhile(1);をつけて、JavaScriptとして実行出来ないようにする(Googleがやった) POSTのみ許可 XHRで特定のリクエストヘッダをつけるようにする レスポンスヘッダにcharsetを指定する charsetにUTF-7を指定すると、きちんとエスケープされているJSON
昨日の日記で、DK祭りで使われている脆弱性がXSSかCSRFかという問題になった。どうも、XSSとCSRFがごっちゃになっている人もいるように見受けるので、簡単な整理を試みたい。 XSSとCSRFには似た点がある。 どちらも「クロスサイト」という言葉が先頭につく なりすましのようなことが結果としてできる どちらも受動型攻撃である それに対して、もちろん違う点もある。専門家から見れば「似てるも何も、そもそも全然違うものですよ」となるのだろうが、現に混同している人がいるのだから紛らわしい点もあるのだろう。 私思うに、XSSとCSRFの決定的な違いは、以下の点ではないだろうか。 XSSは攻撃スクリプトがブラウザ上で動くが、CSRFはサーバー上で動く このため、XSSでできる悪いことは、すなわちJavaScriptでできることであって、攻撃対象のCookieを盗み出すことが典型例となる。一方、CS
jbeef曰く、"本家に「Cross Site Scripting Discovered in Google」というストーリが掲載された。 これは、Web Application Security Consortiumが主宰するメーリングリストに投稿された記事を伝えるもの。その記事によると、Google.comにXSS(クロスサイトスクリプティング)脆弱性が見つかり、発見者が11月15日にGoogleに連絡したところ、12月1日に修正されたという。この脆弱性の原因と対策は以下の通り。" (つづく...) "まず、Googleの404 Not Foundのページはこの例のように、リクエストされたURLのパス名を画面に表示するようになっている。ここで、そのパス名にHTMLのタグを構成する文字「<」「>」が含まれている場合、Googleは、これをきちんと「<」「>」にエスケープして出
「クロスサイト・スクリプティング(XSS)脆弱性を悪用された場合の被害例としては『Cookieを盗まれる』ことがよく挙げられる。しかし,実際にはもっと深刻な被害を受ける恐れがある。管理者や開発者はその危険性を十分に認識して,対策を施す必要がある」――。京セラコミュニケーションシステムのセキュリティ事業部 副事業部長である徳丸浩氏は11月10日,ITproの取材に対して,XSS脆弱性の脅威を強調した。 さまざまなWebサイト(Webアプリケーション)において,XSS脆弱性が相次いで見つかっている。その背景には,開発者などの認識不足があると徳丸氏は指摘する。「適切に対策を施すには,XSS脆弱性のリスクを把握する必要がある」(徳丸氏)。しかしながら,実際には,XSS脆弱性のリスクを過小評価しているケースが少なくないという。 例えば,「(自分たちが運営している)携帯電話向けサイトでは(携帯電話上で
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く