第01回まっちゃ４４５勉強会に参加してきました - hnwの日記
題名の通りですが、「まっちゃ４４５勉強会」に参加してきました。場所は京急蒲田そばのPiOです。 これは、「まっちゃ１３９勉強会」というセキュリティの勉強会が大阪で定期開催されているんですが、それが東京に進出してきたものです。最初に参加者の自己紹介タイムがあったんですが、聞いていると「いままで始発で大阪に行ってたのが東京で開催してくれると助かる」みたいな人が何人もいて、熱心な人がたくさんいるなあ、と思いました。 勉強会本体は13:00からだったんですが、朝10:30からLTの枠があって、「XSS脆弱性に対しXHRを用いた攻撃」という題名で僕も15分ほど喋りました。内容としては「XSSに対してXHRを使えば夢が広がりんぐ」ということで、あんまり他の人が主張してるのを見た事が無いので新ネタかもしれないけど、とりあえずセキュリティ界隈の人に斬ってもらおうと思って喋ってみました。 資料: http:
セキュリティホール memo DNSキャッシュポイゾニング
》 犯行予告を自分で通報するサイト「予告.if」登場 (gigazine, 7/31)。うーん、予告.in、そんなことになってたのか。 Satoru.net もなんだか……。 関連: 犯行予告を共有するサイト「予告.in」はもう限界に達している (gigazine, 7/31) 》 “情報化時代”に追いつけるか？ 審議が進む「新常用漢字表（仮）」 第2部 新常用漢字表と文字コード規格 第3回 互換漢字という「例外」 (Internet Watch, 7/28) 第4回 互換漢字をめぐる非漢字圏諸国との「波風」 (Internet Watch, 7/29) 》 北京の大気汚染、劇的改善は困難か 「良」でも注意が必要 (産経 MSN, 7/31)、緊急大気汚染対策、北京五輪開幕に向け発表 (CNN, 7/31)。本当にひどいみたいですね。 》 規律違反の喫煙原因、横須賀配備予定の米原子力空母の
Cookieを利用したセッション維持(Sticky)の問題点
ロードバランサーの機能のうち、セッション維持は重要な役割な一つです。セッション維持を実現するための方法としては主に4つあります。 ソースIPアドレス利用 Cookie利用 SSL Session ID利用 URL利用 一番手軽なのはソースIPアドレスを利用する方法なのですが、NAT(Network Address Translation)環境では全てのマシンが同じIPアドレスに見えてしまうのでこの方法が使えない場合も多いと思います。そんなわけで私はこれまでCookieを利用する方法をよく使っていました。しかし最近になってCookieを利用したセッション維持が失敗するケースが増えてきました。それはなぜでしょうか？ Cookieを利用する方法の問題点 Cookieを利用したロードバランスでは、セッション情報をCookieに書き込みます。ところでCookieの仕様をRFC2965で確認してみると
2008-01-18 - hoshikuzu | star_dust dairy - about UTF-7 XSS Cheat Sheet
おくればせながら下記を拝見しました。 UTF-7 XSS Cheat Sheet Specify charset clearly (HTTP header is recommended) Don't place the text attacker can control before <meta> Specify recognizable charset name by browser. 上記のような対策を必要とするサイトでは放置しておけばUTF-7系のXSS以外でもXSSの危険性は存在しうると思われます。ですので… あと、ヤマガタさんの反応を読みながら思ったんですが、一般的なXSS対策で「<」「>」などを「<」「>」にエスケープするように、機械的に「+」を「+」にエスケープしてやれば、万が一のときでもUTF-7によるXSSを防げるような気もしたんですけど、あまり深く
サイト脆弱性をチェックしよう！--第8回：セッション管理における脆弱性
印刷する メールで送る テキスト HTML 電子書籍 PDF ダウンロード テキスト 電子書籍 PDF クリップした記事をMyページから読むことができます 前回は、情報漏えいにつながる可能性の高い脆弱性について説明した。今回は、セッション管理における脆弱性について説明していく。 推測可能なセッションID HTTPはステートレスなプロトコルであるため、複数の画面遷移を行うアプリケーションでは、セッション管理機能を開発者が作成する必要がある。このセッション管理機能は、以下のようにセッション識別情報（セッションID）を用いて、現在のアプリケーションの状態を把握する。 1. セッションIDは、ログインなどのタイミングでサーバ側で作成され、ブラウザに送信されます。 2. ブラウザはサーバから受け取ったセッションIDをリクエストに含めて、サーバに送信します。 3. サーバは、ブラウザから受け取ったセッ
クロスサイトスクリプティング(XSS)とCSRFの違い早分かり - ockeghem(徳丸浩)の日記
昨日の日記で、DK祭りで使われている脆弱性がXSSかCSRFかという問題になった。どうも、XSSとCSRFがごっちゃになっている人もいるように見受けるので、簡単な整理を試みたい。 XSSとCSRFには似た点がある。 どちらも「クロスサイト」という言葉が先頭につく なりすましのようなことが結果としてできる どちらも受動型攻撃である それに対して、もちろん違う点もある。専門家から見れば「似てるも何も、そもそも全然違うものですよ」となるのだろうが、現に混同している人がいるのだから紛らわしい点もあるのだろう。 私思うに、XSSとCSRFの決定的な違いは、以下の点ではないだろうか。 XSSは攻撃スクリプトがブラウザ上で動くが、CSRFはサーバー上で動く このため、XSSでできる悪いことは、すなわちJavaScriptでできることであって、攻撃対象のCookieを盗み出すことが典型例となる。一方、CS
hiddenのあまりにも馬鹿げた使い方 - ockeghem's blog
これは面白い yohei-y:weblog: ステートレスとは何か では、ステートレスな場合はどうなのか。 客: こんにちは 店員: いらっしゃいませ。○○バーガーへようこそ 客: ハンバーガーセットをお願いします 店員: サイドメニューは何になさいますか? 客: ハンバーガーセットをポテトでお願いします 店員: ドリンクは何になさいますか? 客: ハンバーガーセットをポテトとジンジャーエールでお願いします 店員: +50円でドリンクをLサイズにできますがいかがですか? 客: ハンバーガーセットをポテトとジンジャーエール(M)でお願いします 店員: 以上でよろしいですか? 客: ハンバーガーセットをポテトとジンジャーエール(M)でお願いします。以上 店員: かしこまりました 引用元には明記されていないが、客の延々とした繰り返し部分は、ホストからhiddenフィールドで渡されてきたものを返し
ウノウラボ Unoh Labs: 5分でできるウェブサーバのセキュリティ向上施策
こんにちは、naoya です。 先日、ウノウが公開しているサービスの中にいくつかの脆弱性が見つかったため、社内で「脆弱性発見大会」を開催しました。この大会は、二人一チームに分かれてウノウが公開している各サービスの脆弱性を見つけることを目的とした大会です。結果は、いくつか各サービスに脆弱性が見つかり、すぐに修正することができました。 僕のチームは、ウノウのホームページやラボブログなど細かいサービスを担当しました。その中で、いくつかのウェブサーバにセキュリティ上あまい設定がありました。 今日は、ウェブサーバのセキュリティ向上のための設定方法についてエントリします。なお、ウェブサーバはApache 2.2系を前提としています。 サーバ情報の表示しない ウェブサーバ(Apache)で、404などのエラーページを表示したとき、ヘッダやページの下にApacheやOSのバージョンが表示されます。こういっ
「サニタイズ言うなキャンペーン」私の解釈
高木浩光さんの「サニタイズ言うなキャンペーン」 という言葉自体はずいぶん前から存在したのだが、 続・「サニタイズ言うなキャンペーン」とはにて高木さん自身がいくつも誤解の例を挙げているように、 そしてまた最近も 駄目な技術文書の見分け方 その1にて「まだわからんのかね」と言われているように、 「わかりにくい」概念なんだろうとは思う。 そこで、僭越ながら、「サニタイズ言うなキャンペーン」について、 私なりの解釈を書いてみようと思う。 もっともこれが正解であるという保証はないのだが、 間違っていたらどなたかツッコミいただけることを期待しています(_o_) そもそも何のせいで「エスケープ」しなければならないのか たとえば住所氏名を登録させるWebアプリケーションは珍しいものではないと思う。 そこで、私が「Taro&Jiro's castle サウスポール」 とかいう恥ずかしい名前のマンション(?)
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
