発表資料は以下のとおり。春山様はじめECナビの皆様、ありがとうございました。 XSSに強いウェブサイトを作る – テンプレートエンジンの選定基準とスニペットの生成手法View more presentations from kazuho.
発表資料は以下のとおり。春山様はじめECナビの皆様、ありがとうございました。 XSSに強いウェブサイトを作る – テンプレートエンジンの選定基準とスニペットの生成手法View more presentations from kazuho.
CSRF対策のtokenはセッションIDで良い セキュリティ的にワンタイムトークン>セッションIDではない。 という話が、この辺の記事に書かれています。 高木浩光@自宅の日記 - クロスサイトリクエストフォージェリ(CSRF)の正しい対策方法 高木浩光@自宅の日記 - CSRF対策に「ワンタイムトークン」方式を推奨しない理由, hiddenパラメタは漏れやすいのか? 肝はこういう事のようです tokenは外部のサイトから知り難い(実質知り得ない)ものでないといけない セッションIDはcookieに格納される document.cookieは自ドメインのものと親ドメインのものしか見れない→外部サイトで動かすJavaScriptからは参照できない セッションIDは『暗号学的に安全な擬似乱数生成系で生成されているはず』(引用) 推測も事実上できない 補足すると、セッションIDを使用したCSRF対
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
昨日の Twitter の XSS 騒ぎは、まだ皆さんの記憶に新しいことと思います。いい機会なので、ツイートのような構造化テキストのエスケープ手法について触れておきたいと思います。 Twitter のメッセージは、単なる平文(プレインテキスト)ではなく、「@英数字」のような他のユーザーへの言及と「http://〜」のような URL を自動的にハイパーリンク化する構造化テキストです。 このような複数のルールをもつ構造化テキストを HTML 化する際には、どのようなコードを書けばいいのでしょう? まず「@〜」をリンク化してから、URL をリンク化すればいいのでしょうか? それだと、@〜 のをリンク化した A HREF タグの中の URL がさらにリンク化されていまいますね。 では、URL をリンク化してから @〜 をリンク化すればいいのでしょうか? それだと、@ を含む URL があった場合に
先日、なかなか強烈なXSS攻撃手法が公開されていました。 DNSへの問い合わせ結果にJavaScriptを埋め込んでしまおうというものです。 SkullSecurity: Stuffing Javascript into DNS names DarkReading: Researcher Details New Class Of Cross-Site Scripting Attack nCircle: Meta-Information Cross Site Scripting (PDF) 自動生成されるWebページ中に、DNSによる名前解決結果がエスケープされない状態で含まれていると、JavaScriptが実行されてしまうという仕掛けです。 「hogehoge.example.com」が本来ならば「198.1.100.3」というようなIPアドレスが結果として返るところを、DNSに細工を行っ
NTTドコモとソフトバンクモバイルは、フィーチャーフォン(いわゆるガラケー)にてJavaScriptの対応を始めています。JavaScriptに対応すると、クロスサイト・スクリプティング(XSS)脆弱性の懸念が高まりますが、両社は独自の手法によりXSS対策をしている(しようとしている)挙動が観測されましたので報告します。この内容は、オレ標準JavaScript勉強会でネタとして使ったものです。 NTTドコモに学ぶ「XSS対策」まず、サンプルとして以下のようなXSS脆弱なスクリプトを用意します。 <?php session_start(); ?> <body> こんにちは<?php echo $_GET['p']; ?>さん </body>これを以下のURLで起動すると、IE7では下図のような表示になります。 []http://example.com/xss01.php?p=山田<scrip
html5securityのサイトに、XSSの各種攻撃手法がまとめられているのを発見せり!ということで、個人的に「お!」と思った攻撃をサンプルつきでご紹介します。 1. CSS Expression IE7以前には「CSS Expressions」という拡張機能があり、CSS内でJavaScriptを実行できたりします。 <div style="color:expression(alert('XSS'));">a</div> 確認 @IT -[柔軟すぎる]IEのCSS解釈で起こるXSS で詳しく解説されていますが、CSSの解釈が柔軟なことともあいまって自前で無害化するのはなかなか困難。以下のようなコードでもスクリプトが実行されてしまいます。 <div style="color:expr/* コメントの挿入 */ession(alert('XSS'));">a</div> 確認 <div s
今回は、「先行バイトの埋め込み」という攻撃方法について紹介します。 ご存じのとおり、ほとんどの符号化方式(文字エンコーディング)においては、ひらがなや漢字などASCII以外のほとんどの文字は、1文字が複数バイトにて構成されています。たとえば、ひらがなの「あ」は、Shift_JISにおいては0x82 0xA0という2バイト、UTF-8においては0xE3 0x81 0x82という3バイトで表現されます。 攻撃者がマルチバイト文字の先行バイト部分だけを与えることにより、本来存在している後続の文字を無効にしてしまうのが、今回紹介する「先行バイトの埋め込み」という攻撃方法です。 先行バイト埋め込みの具体例 では、具体的な例を見ていきましょう。 たとえば、Shift_JISで書かれたHTMLとして、次のようなものがあったとします。 name: <input type=text value="" />
XSS (Cross Site Scripting) Cheat Sheet Esp: for filter evasion By RSnake Note from the author: XSS is Cross Site Scripting. If you don't know how XSS (Cross Site Scripting) works, this page probably won't help you. This page is for people who already understand the basics of XSS attacks but want a deep understanding of the nuances regarding filter evasion. This page will also not show you how to
適当 XSSがある=なんでもやり放題ではない ブログサービスなど自由にHTMLをかけるようなサービスでは、害が及ばないように表示を丸ごと別のドメインに分けていたり、あるいは別ドメインのIFRAME内で実行したりしているのが普通です。個人情報を預かってるサイトは、重要個人情報についてはHTTPSじゃないと参照できなかったり、そもそも表示しなかったり(パスワードやカード番号等)、決済用のパスワードや暗証番号を入れないと操作できなかったりする。 参考までに http://blog.bulknews.net/mt/archives/001274.html (2004年のアメブロ脆弱性の話) http://d.hatena.ne.jp/yamaz/20090114 (信頼できないデータを取り扱うドメインを分ける話) 管理用と別ドメインに分けたにも関わらず、script実行できることに対してDISられ
以下のページに関連して、htmlspecialchars() を使用している場合でも XSS が可能かどうか少し調べてみました。 http://www.tokumaru.org/d/20090930.html その結果、いくつかのブラウザで文字エンコーディングに Shift_JIS を使用していた場合、XSS が可能なことを確認しました。 テストコードは以下の通りです。リンクにマウスポインタを乗せると埋め込んだ Javascript が実行されます。 <?php $_GET['a1'] = "\xf0"; // \xf0 - \xfc で可能 $_GET['a2'] = " href=dummy onmouseover=alert(document.title) dummy=dummy"; header( "Content-Type:text/html; charset=Shift_JIS
クロスサイトスクリプティング(英: cross-site scripting)とは、Webアプリケーションの脆弱性[1]もしくはそれを利用した攻撃。脆弱性をツリー型に分類するCWEではこの攻撃を不適切な入力確認 (CWE-20) によるインジェクション (CWE-74) のひとつとして分類している (CWE-79)[2]。略称はXSS。かつてはCSSという略称も使われていたが、Cascading Style Sheetsと紛らわしいのでこの略称はあまり使われなくなった[1]。 「クロスサイト(サイト横断)」という名称は歴史的なもので、初期に発見されたXSSでは脆弱性のあるサイトと攻撃者のサイトを「サイト横断的」に利用して攻撃を実行することから名づけられたものだが[3][4]、XSSの定義は新しいタイプの攻撃が見つかるたびに拡張され、サイト横断的なものでなくともXSSと呼ぶようになった[3]
PHPはWebシステムの中で広く使われているポピュラーなスクリプト言語だ。だが、手軽に習得し、開発が行えるとあって成果物のレベルが様々であり、中にはセキュリティ上問題のあるコードが多数存在することがある。そうしたセキュリティ上の問題を解決する手法やフレームワークもあるが、ごく簡単なシステムでは使われることがないだろう。 SQLのコードを精査し、問題の発見につなげる そのようなものを放置しておくと、いつ何時問題がわき上がるか分からない。そうした不安を取り除くためにもPixyを使ってみよう。 今回紹介するオープンソース・ソフトウェアはPixy、XSS、SQLインジェクションを発見するスキャナソフトウェアだ。 最初に断っておくと実際試してみたところでは100%の解決にはつながらなさそうなのでご注意いただきたい。PixyはJavaで作られたソフトウェアで、PHPファイルを指定して実行するとソースフ
みなさん、はじめまして。はせがわようすけと申します。 最近、文字コードと関連したセキュリティの話題を目にすることが増えてきました。文字コードを利用した攻撃は技術的に未開拓ということもあり、参考となる情報がなかなか見当たりません。この連載では、文字コードを利用した攻撃やそれに対する対策について正しい知識を解説していきます。 文字コードとセキュリティが関連するもっとも大きな点は、やはり文字列の比較でしょう。「危険な文字列の検出」「安全な文字列であることの確認」といった文字列の比較は、セキュリティを考えるうえで避けて通れない処理だと思います。 文字列の比較においては、単純にバイト列を比較するだけでは不十分で、文字列がメモリ上でどのようなバイト列として格納されているのか(このルールを符号化方式あるいは文字エンコーディングと言います)に注意しなければならないこともあるでしょう。攻撃者は巧みに文字
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く