CSRF脆弱性対策 - monjudoh’s diary
CSRF対策のtokenはセッションIDで良い セキュリティ的にワンタイムトークン>セッションIDではない。 という話が、この辺の記事に書かれています。 高木浩光＠自宅の日記 - クロスサイトリクエストフォージェリ（CSRF）の正しい対策方法 高木浩光＠自宅の日記 - CSRF対策に「ワンタイムトークン」方式を推奨しない理由, hiddenパラメタは漏れやすいのか？ 肝はこういう事のようです tokenは外部のサイトから知り難い(実質知り得ない)ものでないといけない セッションIDはcookieに格納される document.cookieは自ドメインのものと親ドメインのものしか見れない→外部サイトで動かすJavaScriptからは参照できない セッションIDは『暗号学的に安全な擬似乱数生成系で生成されているはず』(引用) 推測も事実上できない 補足すると、セッションIDを使用したCSRF対
昨日騒ぎになったTwitterのXSS脆弱性によって実際に受けそうな被害とその対策 - monjudoh’s diary
何が出来るのか どんな脆弱性かの詳細はこちらを参照2010 年 9 月 21 日現在のツイッターのバグ(脆弱性)について 外部JavaScriptを読み込むコードを仕込めたので、 どんなJavaScriptでも実行できる状態でした。 以下、JavaScriptの実行によってTwitter上で出来る事。 セッションハイジャック JavaScriptからcookieを参照できるのでログイン状態のセッションIDも参照できます。 また、任意のJavaScriptが実行できる以上、参照したセッションIDを攻撃者のサーバ等に送信することも出来ます。 攻撃者は奪ったセッションIDをcookieに設定すれば、被害者のアカウントでtweet,direct messageの閲覧・送信が出来ます。 確認してみたところ、ログイン状態のセッションIDはログアウトしても無効にはなりません。 設定→パスワードからパスワ
XSSの攻撃手法いろいろ - うなの日記
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
XSS (Cross Site Scripting) Cheat Sheet
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とセキュリティリスクと正しい脆弱性報告のあり方 - 最速転職研究会
適当 XSSがある=なんでもやり放題ではない ブログサービスなど自由にHTMLをかけるようなサービスでは、害が及ばないように表示を丸ごと別のドメインに分けていたり、あるいは別ドメインのIFRAME内で実行したりしているのが普通です。個人情報を預かってるサイトは、重要個人情報についてはHTTPSじゃないと参照できなかったり、そもそも表示しなかったり(パスワードやカード番号等)、決済用のパスワードや暗証番号を入れないと操作できなかったりする。 参考までに http://blog.bulknews.net/mt/archives/001274.html (2004年のアメブロ脆弱性の話) http://d.hatena.ne.jp/yamaz/20090114 (信頼できないデータを取り扱うドメインを分ける話) 管理用と別ドメインに分けたにも関わらず、script実行できることに対してDISられ
XSSとセキュリティリスク - ぼくはまちちゃん！
こんにちはこんにちは！！ 今日、はてなの人気記事を見ていてこんな記事がありました…！ ちゃんとセキュリティのこと考えてますか･･･！？ 『セキュリティ対策とか難しいし面倒くせーし、俺の適当に作ったサービスとかどうなってもイイしｗｗ』 いいんですいいんです！ 別にそう思ってるならどうでもいいんです！ でもそんなプログラムをWeb上で公開すんじゃねーよボケと。 PHPで誰でも簡単Webサービス製作！でなんか作って公開した奴ちょっと来い - 甘味志向＠はてな ふむふむ、PHPで簡単につくっちゃうのは良いけど、 公開するのなら、ちゃんとセキュリティホールなくしてからにしましょうね って記事ですね！ でもぼくは、この記事を読んでも… なぜXSSがいけないのか 結局よくわかりませんでした…。 いちおうXSS脆弱性があるとダメな理由として、下のようなことが書かれてあったんだけど… フォームに入力したHT
PHPで誰でも簡単Webサービス製作！でなんか作って公開した奴ちょっと来い - 甘味志向＠はてな
タイトルは出来れば関連する方に読んで欲しかったので、軽く釣り針にしました。すみません。:*) 最近はやりのヒウィッヒヒー（Twitter）でも、よく「○○ったー」みたいなサービスがばんばん登場してますね！ おかげでますますツイッターが面白い感じになってて、いい流れですね！ でも･･･ちょっと気になることが･･･ 最近「もうプログラマには頼らない！簡単プログラミング！」だとか･･･ 「PHPで誰でも簡単Webサービス作成！」だとか･･･ はてなブックマークのホッテントリで見かけますよね･･･ プログラミングする人が増えるのは素敵です！レッツ･プログラミングなう！ なんですけど･･･ ちゃんとセキュリティのこと考えてますか･･･！？ 『セキュリティ対策とか難しいし面倒くせーし、俺の適当に作ったサービスとかどうなってもイイしｗｗ』 いいんですいいんです！ 別にそう思ってるならどうでもいいんです！
第1回 UTF-7によるクロスサイトスクリプティング攻撃［前編］ | gihyo.jp
みなさん、はじめまして。はせがわようすけと申します。 最近、文字コードと関連したセキュリティの話題を目にすることが増えてきました。文字コードを利用した攻撃は技術的に未開拓ということもあり、参考となる情報がなかなか見当たりません。この連載では、文字コードを利用した攻撃やそれに対する対策について正しい知識を解説していきます。 文字コードとセキュリティが関連するもっとも大きな点は、やはり文字列の比較でしょう。「危険な文字列の検出」「安全な文字列であることの確認」といった文字列の比較は、セキュリティを考えるうえで避けて通れない処理だと思います。 文字列の比較においては、単純にバイト列を比較するだけでは不十分で、文字列がメモリ上でどのようなバイト列として格納されているのか（このルールを符号化方式あるいは文字エンコーディングと言います）に注意しなければならないこともあるでしょう。攻撃者は巧みに文字
Paros使ってみた - Do You PHP はてブロ
プロキシ型脆弱性スキャナの1つであるParosを使ってみました。 We wrote a program called "Paros" for people who need to evaluate the security of their web applications. It is free of charge and completely written in Java. Through Paros's proxy nature, all HTTP and HTTPS data between server and client, including cookies and form fields, can be intercepted and modified. Parosがチェックする内容は、ユーザーガイドによると以下の通りです。 HTTP PUT allowed - chec
［さらに気になる］JSONの守り方
XSSにCSRFにSQLインジェクションにディレクトリトラバーサル……Webアプリケーションのプログラマが知っておくべき脆弱性はいっぱいあります。そこで本連載では、そのようなメジャーなもの“以外”も掘り下げていきます （編集部） 次は、JSONにおけるセキュリティ対策 皆さんこんにちは、はせがわようすけです。第4回「［気になる］JSONPの守り方」はJSONPについて説明しましたので、今回は「JSON」についてもセキュリティ上注意すべき点について説明します。 JSONは、XMLHttpRequestで受け取り、JavaScript上でevalするという使い方が一般的です。 まずはサーバ側から送られる情報と、クライアント側での処理、それぞれの内容を見ておきましょう。 ［サーバ側］ HTTP/1.1 200 OK Content-Type: application/json; charset=
第3回 US-ASCIIによるクロスサイトスクリプティング | gihyo.jp
今回は、US-ASCIIによるクロスサイトスクリプティング(XSS)という話題について紹介します。 前回までで説明したUTF-7によるXSSと同様に、攻撃者はUS-ASCIIという文字コードを巧みに利用することで、IEを対象にXSSを発生させることができます。US-ASCIIによるXSSは、UTF-7によるXSSと類似点も多いため、前回までの説明も併せて読んでおくとよいでしょう。 US-ASCIIによるXSSについても先に対策を書いてしまうと、UTF-7のときと同様にHTTPレスポンスヘッダにて Content-Type: text/html; charset=UTF-8 Content-Type: text/html; charset=Shift_JIS Content-Type: text/html; charset=EUC-JP のいずれかを出力するという原則を守ることで、完全に攻撃
世間の認識と脅威レベルのギャップ――XSSは本当に危ないか？
皆さんこんにちは、川口です。コラムの第6回「IPSは“魔法の箱”か」でまっちゃ１３９で講演をしたお話を書きましたが、今度は関東でやっている「まっちゃ４４５」にお招きいただき、お話ししてきました。 まっちゃ４４５は募集開始から定員が埋まるまでがとても速く、今まで参加したことがなかったのですが、今回は運良く（？）講師側ということでキャンセル待ちにならずに参加することができました。ロックオンの福田さんがオープンソースのECサイト構築システム「EC-CUBE」に脆弱（ぜいじゃく）性が発見された際のインシデントハンドリングのお話をされていました。EC-CUBEにSQLインジェクションとクロスサイトスクリプティング（以下、XSS）が発見されたあとの対応のお話です。JSOCで日々インシデントにかかわっているいる自分としてはとても興味深い内容でした。 日本のエンジニアのセキュリティ意識は過剰？ 今回のよう
第5回 クロスサイト・スクリプティング対策も忘れずに
最近問題となっているWebサイトの改ざんは，サイトの改ざん自体が目的ではなく，改ざんされたコードを参照した一般ユーザーを危険なサイトに誘導して，マルウエアを導入することを最終的な目的としている。この目的のため，HTMLのIFRAME要素やSCRIPT要素が利用される場合が多い。 先に説明したように，SQLインジェクションのぜい弱性を利用してデータベースの内容を，これら要素を使った内容に書き換えることが可能な場合がある。それでも，その内容をそのまま表示するかどうかはサイトの作りによって異なる。 一般的にデータベース中の「<」などの特殊記号をそのまま表示するとクロスサイト・スクリプティングのぜい弱性（XSS）の原因となるので，表示の際にこれらの文字をエスケープすることが行われる（図1）。 現実には多くのサイトにおいて，SQLインジェクションによって挿入されたIFRAME要素やSCRIPT要素が
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
とくまるひろしのSession Fixation攻撃入門 - ockeghem's blog