SSL/TLSライブラリの正しい使い方（もしくは、コモンネームの検証について）
スマホアプリの市場拡大に伴い、直接SSL/TLSライブラリを使用するプログラムを書く機会も増えてきている今日この頃かと思います。 SSL/TLSライブラリを使う際には、接続確立時にサーバの認証を正しく行う必要があります。具体的には、クライアントプログラムで以下の２種類の検証を行うことになります。 SSL/TLSライブラリがサーバの証明書の検証に成功したこと サーバの証明書に含まれるコモンネーム注1が接続しようとしたサーバと同一であること 前者については、OpenSSLの場合はSSL_CTX_set_verifyの引数にSSL_VERIFY_PEERを指定するなどして、ライブラリ側で処理を行わせることが可能です（証明書の検証に失敗した場合はSSL_connectがエラーを返します）。 一方、後者についてはSSL/TLSライブラリによって差があり、検証機能を有効にするために特別な呼出が必要だっ
セッションアダプションに対する私の見解
先にエントリ「セッションアダプションがなくてもセッションフィクセイション攻撃は可能」に対して、大垣(@yohgaki)さんから、「セッションフィクセイションはアダプション脆弱性修正で防御可能」というブログエントリで反論をいただきました。 大垣さんのエントリは長いのですが、反論のポイントは、以下の2点だと思いました。 徳丸のPoC（概念実証コード）では、セッションDBが分かれていないが、現実のレンタルサーバー等はセッションDBが分かれているので、攻撃はできないセッションには有効期間があり、セッションアダプションがない場合は、有効期間の過ぎたセッションIDが送信されても、セッションIDは再生成される。だから攻撃はできない以下、上記に反論します。 セッションDBは元々関係ないセッションフィクセイション攻撃において、セッションを扱うのは、攻撃対象のサーバーだけです。大垣さんは、セッションフィクセイ
My docomoはパスワードのコピペを禁止するな - ただのにっき(2012-11-11)
■ My docomoはパスワードのコピペを禁止するな 今回SoftBankからdocomoにMNPしたので請求書の確認なんかをするのにWebサイトに登録しないといけないなと思って、My docomoにユーザ登録をした。携帯との紐付けにワンタイムパスワードをSMSで送ってきたりして、ほぼPCだけで完結する手順はまぁまぁわかりやすかったのだけど、パスワードを決めるところで途方に暮れてしまった。 8～20文字の英数記号と書いてあるので、いつものようにKeePass Password Safeで最大文字数・文字種のパスワードを生成し、さぁ入力、という段になってこれである: もうね、これでセキュリティが高まると思ってるんだとしたら大間違いだってことにそろそろ気づけよ。こんなこと言われたら、短くて入力しやすい文字種のパスワードしか作らないに決まってるだろ。この仕様を決めたのが発注者か開発者か知らんけ
「管理者パスワードは何日ごとに変更すればよいか」に関する質疑応答 - ockeghem's blog
昨日Webサイトを守るためのセキュリティ講習会の講師を担当しました。講習会の終了後、受講生から「管理者パスワードの定期的変更」に関する質問がありました。備忘の為、質疑内容を以下に記録します。 Q1:上位ポリシーにて、管理者パスワードは定期的に変更するように義務づけられているが、何日毎に変更するのが正しいのか。最近の専門家の見解をお伺いしたい A1:専門家の見解は分かれているとお答えしました 現在の主流はパスワードを定期的に変更するべしという考え方ですが、それに異論を持つ人もいて、私もその一人です。 一般ユーザのパスワードとは異なり、管理者パスワードは、業務の必要上複数の人が知っている状況があります。その状況では、「定期的に変更」するのではなく、管理者パスワードを知っている人が、他業務に異動、あるいは退職するタイミングで遅滞なく変更するべきです。そうしないと、「管理者でなくなった人が管理者パ
何が正しいのかを考える際は、正しさの基準が必要 - ockeghem's blog
大垣さんの寄稿記事「第44回 セキュリティ対策が確実に実施されない2つの理由：なぜPHPアプリにセキュリティホールが多いのか?｜gihyo.jp … 技術評論社」のまとめにて、『最後に「何が正しいのか？」常に考えるようにしてください』と書かれています。この部分は、私への反論のようですので、このエントリで返答したいと思います。 大垣さんの主張 先にも述べたように、大垣さんはこのエントリの「まとめ」として以下のように書かれています。 最後に「何が正しいのか？」常に考えるようにしてください。 http://gihyo.jp/dev/serial/01/php-security/0044?page=2 この主張自体には私も大賛成です。大垣さんの記事は以下のように続きます。 例えば，SQL文を作成する場合にリテラル（パラメータ）を文字列としてエスケープすると浮動小数点型のデータが正しく処理されないデ
DNS Rebinding問題の所在 | 水無月ばけらのえび日記
公開: 2010年2月15日23時40分頃 「かんたんログイン手法の脆弱性に対する責任は誰にあるのか (www.tokumaru.org)」。細かいところに反応しますが……。 「問題」という言葉のニュアンスが微妙なところですが、これはちょっと違和感があります。少なくともWebアプリケーション側の「不具合」ではないように思いますし、実際のところはこんな感じではないでしょうか。 iモードブラウザ2.0対応のdocomo端末は、DNS Rebindingの攻撃に対して脆弱である。端末の問題であるため端末側で対応することが望ましいが、名前解決はdocomoのゲートウェイ側で行われる場合があり、端末側では対応が難しい。docomoのゲートウェイの問題についてはdocomo側で対応することが望ましいが、問題の性質上、対応が難しい (参考: Re:「docomoケータイのDNS Rebinding問題、
ケータイの流儀を常識と思いこむのは危険 | 水無月ばけらのえび日記
公開: 2009年8月6日14時10分頃 「やはり退化していた日本のWeb開発者「ニコニコ動画×iPhone OS」の場合 (takagi-hiromitsu.jp)」。 iPhone・iPod Touch用の「ニコニコ動画」アプリのサーバ側実装が脆弱だったというお話。iPhoneやiPod Touchの端末製造番号 (UDID) は秘密情報ではない上に詐称可能なのですが、そのUDIDに依存した認証を行っていたため、他人のUDIDが分かると、その人の非公開マイリストなどが見られてしまう……ということのようで。現在は修正されているようです。 脆弱性の話としては、認証方法の不備という単純な話なのですが、むしろ周辺の反応が興味深いですね。いちばん面白いと思ったのがこのブックマークコメント。 ツッコミがたくさん入っていますが、「流儀が違う」というのは、実は全くその通りなのですね。端末固有IDによる
ソフトウエア作りに必要なセキュリティ - 極楽せきゅあブログ
よくある意見として、「何でこんなことも知らないのか」「勉強不足」「開発者はもっとセキュリティに気をつけるべき」というのがあるけど、何年も前からそうやって言い続けているのに変わってこない現状を見るにつけ、もっと違うアプローチが必要な気がして仕方が無いわけです。 例えばフレームワークとか、そういうものが良いんじゃね？と言っているのは、実装しなければいけないセキュリティの中にも、人が覚えて工夫して実装する必要があるものと、環境やソフトウエアがサポートできるものがあると思うからなんだよねー。Webアプリ方面で言えばエスケープなんてもっと機械化できそうだし、その一方でセッション管理は機械化するには複雑っぽいし、その他方面ではバッファオーバーフローとかは機械的に防御する手立てがけっこうありそうだしね。セキュリティってひとくくりで言われて、すべてかゼロか的な言い方されることが多いけど、機械的に対策できる
届出件数と被害件数は関係ない | 水無月ばけらのえび日記
DNSキャッシュポイズニングの脆弱性の影響範囲の広さと脅威は深刻です。IPAの2008年度第3四半期のソフトウェアなどの脆弱性関連情報に関する届出状況を見ると、国内でもわずか1カ月で273件の被害があり、その傾向が見られます。 以上、私はこう見た、Black Hat Japan 2008（前編）日本から世界へ広がれ、セキュリティエンジニアの輪 より いやいや、それはあくまで脆弱性関連情報の届出件数ですから。この制度は、脆弱性を発見した人が攻撃を未然に防ぐべく届け出るもので、実際に被害に遭った人が届け出るものではありません。ほとんどの場合、被害が出る前に修正される事になると思われます。つまり、この届出件数と被害件数は関係ないということです。 XSSなんかは届出は多いのですが、被害はそれほど報告されていないですね。 DNSがヤバイというのはそうだと思うのですが、このデータを持ってきて「実際に被
神戸デジタル・ラボの「セルフチェックかんたん5」は試すな危険 - ockeghem's blog
株式会社神戸デジタル・ラボが公表している「セルフチェックかんたん5」がWebアプリケーションセキュリティの一部専門家の間で話題になっている。 mi1kmanさん経由。 神戸デジタル・ラボさんの Webセキュリティ診断の販促ページ。 色々と言いたいことはありますが、一番は、「Webサイトセキュリティチェックリスト」の7ページ目：【中略】の部分ですかね。 手元の IE7/Firefox3 で試してみた限りでは、「http://int21h.jp/../」にアクセスした場合、ブラウザから出るリクエストの時点で「GET / HTTP/1.1」になっていました。（ブラウザが勝手に訂正してくれるので、GET /../ HTTP/1.1 のようなリクエストが送信されることは無さそう。） はたして“何らかのエラーメッセージ”が表示されることはあるのでしょうか…。(^-^; http://yamagata.
XSS: 今こそXSS対策についてまとめよう - 徳丸浩の日記(2008-08-22)
_今こそXSS対策についてまとめよう 沢出水（さわ いずみ）さんからトラックバックを頂戴した。 元々はホワイトリスト方式の優位は神話というエントリでホワイトリストはどう作る?を引用(批判)した事が発端の模様です。 一見真っ向対決しているようなので興味深く読ませていただいたのですが、正直、両者の主張の違いがわかりません。 どちらもXSS等インジェクション系の対策としてはアプリケーションで入力値が正しい形式の範囲内かチェックし、出力時に必要なエスケープ処理を行う、という結論に思えるんですけど… [ホワイトリストとブラックリストより引用] ご指摘の通りで、XSS対策は入り口でのバリデーションと表示(HTML組み立て)時のエスケープだ。しかし、元ブログの主題はホワイトリストとブラックリストの比較なので、「ただ、表面的に文章を追っただけでは『何をホワイトリストと呼ぶのか』という部分がだいぶ違う印象を
「ストリートビュー問題」をセキュリティ観点から整理する
■ 「ストリートビュー問題」をセキュリティ観点から整理する ※以下の文章はブルース・シュナイアー『 セキュリティはなぜやぶられたのか』の受け売りなので、未読の人はとっとと買って読んだ方がよっぽどためになります。 要約 Googleマップの「ストリートビュー」機能に関する議論の多くは、これをプライバシー問題として捉えているが、ほとんど議論がかみ合っていないばかりか、なぜかみ合っていないのか当人たちもわかっていない。この問題をセキュリティの観点から捉えなおすと、守るべき資産価値やリスクの算出方法が個人個人の主観をよりどころにしていることがわかり、なぜ議論がかみ合わないのかが明らかになり、ネットでの議論よりも有効なアクションが見えてくる。 セキュリティとは 『セキュリティはなぜやぶられたのか』によれば、人生はセキュリティの連続である。旅行に使う交通機関を選ぶのもセキュリティだし、賞味期限切れ牛乳
SSL/TLSと信用 | 水無月ばけらのえび日記
本家コメントでは、「SSLは暗号化のためだけにあるのではなく、「信用」という大事な役割も果たしているため、Seldon氏の主張では証明書発行の存在意義を否定してしまうことにならないか？」という意見や、「ユーザビリティの観点からいえばひどい仕様だ」といった意見が寄せられているが、/.Jerの皆はどのように考えるだろうか？ 「信用」という言葉は誤解と混乱の元かもしれません。「信用できないサイト」と言われると、信用できない人が運営しているサイトであるというように言われている感じがしますが、SSL/TLSはそういう意味での「信用」とは無関係です。 証明書の警告が出ている状態というのは、「アクセスしようとしているサイトが本物かどうか確認できない」という状態です。https://example.com/ にアクセスしようとしたとき、通信相手が本当に example.com なのか、それとも examp
Firefox 3のSSL対応方針、どう思う？ (スラッシュドット・ジャパン) - TenForward
本家記事は読んでないので，日本語の紹介とコメントだけを読んだ感想です．私には何が問題なのかイマイチ分からないのですが，それが日本語の方だけ読んでいるから，だったらスミマセン． Firefox 3では、自己署名されたSSL証明書や承認されていないベンダー（新興のものや非営利のベンダーなど）によって署名されたSSL証明書を使用しているサイトに接続しようとすると、警告が発せられる。この警告が発せられない状態にするには、サイトはFirefox認証のベンダーに有料の証明書を発行してもらう必要がある。 http://slashdot.jp/security/article.pl?sid=08/08/06/0237247 元々 Firefox 2 であろうが，1 であろうが，発せられてましたよね．多分，あの「エラー画面としか思えない」画面が，とてもこれ以上先に進もうと思えない厳しい言葉で警告される，事を
徳丸浩の日記 - そろそろSQLエスケープに関して一言いっとくか - SQLのエスケープ再考
補足 この記事は旧徳丸浩の日記からの転載です。元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2。 備忘のため転載いたしますが、この記事は2007年11月26日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり 本稿ではSQLインジェクション対策として、SQLのエスケープ処理の方法について検討する。 最近SQLインジェクション攻撃が猛威を振るっていることもあり、SQLインジェクションに対する解説記事が増えてきたようだが、対策方法については十分に書かれていないように感じる。非常に稀なケースの対応が不十分だと言っているのではない。ごく基本的なことが十分書かれていないと思うのだ。 SQLインジェクション対策には二通りある。バインド機構を使うものと、SQLのエスケープによるものだ。このうち、SQLのエスケープについて、十分
プライバシー不感症 - rna fragments
そんなに大切な個人情報をたくさん扱ってるサイトなんてどれだけあるかな。 みんなそういうサービスつくってるの？ なんかすごいね。 ぼくの使っている範囲だと、本当にまずいのは銀行と証券とカード会社のような、お金のからむサービスくらいだよ。 セキュリティ過敏症 (ぼくはまちちゃん！(Hatena)) こういうことを言うはまちちゃんは僕に言わせればプライバシー不感症。 何が「大切な個人情報」かなんて君が決めることじゃない。本人が決めることだ。なぜなら君はその人の事情なんて知らないからだ。 人それぞれに事情があって、一見どうでもいいようなことでも本人は知られたくないという情報はあるんだ。単に知られたくないって気持ちだけの問題じゃなくて実害があることだってある。そんなの想像できない? だからこそ本人の判断にまかせなきゃいけないんだ。他人にはわからないことなんだから。 自由主義神経症 だからセキュリティ
Matzにっき(2008-01-29): PHP使いの反論
<< 2008/01/ 1 1. 年賀状 2. ゴビウス 3. [Ruby] ZSFA -- Rails Is A Ghetto 2 1. 新年会 3 4 1. The Mythical 5% 5 6 7 8 1. [言語] Substroke Design Dump 2. [言語] A programming language cannot be better without being unintuitive 3. [OSS] McAfee throws some FUD at the GPL - The INQUIRER 9 1. [言語] Well, I'm Back: String Theory 2. [言語] StringRepresentations - The Larceny Project - Trac 10 1. [Ruby] マルチVMでRubyを並列化、サンと東大が
「我々は過去の教訓を生かしきれていない」，米Fortify Softwareセキュリティ担当者
「アプリケーションの脆弱性を突く代表例は二つある。一つはバッファ・オーバーフロー，もう一つはクロスサイト・スクリプティング（XSS）だ。ともに10年近く前から指摘されているにもかかわらず，我々は過去の教訓を生かしきれていない」。10月26日，東京で開催されたセキュリティ関連のイベント「Black Hat Japan 2007 Briefings」で，アプリケーションの脆弱性対策ソフトウエアを開発する米Fortify SoftwareのJacob West氏（写真）はこう主張する。West氏は，同社セキュリティ研究グループの責任者を務めている。 バッファ・オーバーフローは，設定したサイズ以上のデータをバッファに大量に送り込んで，管理者権限を取得すること。XSSは，悪意のある文字列を埋め込んでWebサイトなどを乗っ取ることをいう。なぜ，こうした脆弱性の問題を解決できないのか。West氏は，We
入力値検証について(2): アプリケーションの先頭で行う入力値検証は業務要件により行うべし - 徳丸浩の日記(2007-09-09)
_ アプリケーションの先頭で行う入力値検証は業務要件により行うべし 前回のエントリ徳丸浩の日記 - そろそろ入力値検証に関して一言いっとくか - Webアプリケーション脆弱性対策としての入力値検証についての内容をもう少し突っ込んでみたい。 このエントリは、幸いにも何人かの人たちの建設的なコメントをいただくことができた。それにより、私自身の考えを整理し、深めることができたように思う。 T.Teradaの日記 - 2007-09-08 "週"記(2007-09-07) 今回は、入力値検証の中でも、特にアプリケーションの先頭で行う入力値検証として何をすべきかということに焦点を絞って議論を進めたいと思う。 その前に、まずHTTPの復習から。 HTTPリクエストは申請書にたとえると理解しやすい この日記の読者の多くは先刻ご存知だと思うが、HTTPは非常にシンプルなプロトコルである。WebサーバはHT
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
re: PHP - ls@usada’s Backyard
