My Softbankのログイン画面には絵合わせパズルがついてくる 参照: My Softbankからログインボタンを押す 参照: 髙島屋オンラインのログイン画面には、モグラタタキがついてくる

0-9: Web 25th Anniversary | HTML5とか勉強会に行ってきました。 会場で村井 純先生とお話する機会があったので、噂に聞いてた「日本のDNS root serverがmなのはmuraiの頭文字がmだから」という話がほんとうか質問してきました。 答えは「本当はjが用意されてたんだけど、いろいろあって先にjが先に決まってしまったので、残ってる中からmuraiの頭文字からmに決まった」とのことでした。 質問できてよかった。

髙島屋オンラインのログイン画面には、モグラタタキがついてくる。 参照: https://www.takashimaya.co.jp/customer/TKPC10010Init.do

徳丸本こと、拙著「体系的に学ぶ安全なWebアプリケーションの作り方: 脆弱性が生まれる原理と対策の実践」ですが、Kindleにてお読みいただけるようになりました。 購入はこちらから。 Kindle版と言っても「固定レイアウト型」と言われるもので、フォントの変更や検索はできません。Amazonの販売ページには以下の注意書きがあります。 ※※※この電子書籍は固定レイアウト型で配信されております。固定レイアウト型はフォントサイズの変更、本文の検索、その他が出来ません。必ず無料サンプルで見え方、操作性等をご確認の上でご購入ください。※※※ さっそく私も購入してみました。出先なので、iPhone5の画面のキャプチャですが、さすがにiPhoneではムリゲーという感じです。購入を検討される際は、商品ページ右側の「今すぐサンプルを送信」を使って、サンプルを確認いただくことをお勧めします。 以下はKindl

大垣さんは、かねてより「バリデーションは重要なセキュリティ対策である」という持論を持っておられます。そして、それは「世界の常識」と指摘されています。 「入力バリデーションはセキュリティ対策である」は世界の常識です。少なくとも大多数の世界のセキュリティ専門家は「入力バリデーションはセキュリティ対策」は常識だと考えています。 第45回 入力バリデーションはセキュリティ対策 ：なぜPHPアプリにセキュリティホールが多いのか?より引用 私は「バリデーションはセキュリティ対策とは言えない」と思っているのですが、実は「世界の常識」という点に異論があるわけではなくて、話は逆なのです。「従来からバリデーションはセキュリティ対策としてとらえられてきて『世界の常識』となっているが、実はそれはおかしいのではないか?」という問題提起をしているのです。なので、「世界の常識だろ」と言われても、それでは反論になっていま

スタックオーバーフロー対策をする場合、関数の入口でチェックすれば大抵対策可能なんだけど、それだと対策漏れの可能性があるから、例えば、strcpyの代わりにstrncpyあるいはもっと高機能な文字列関数を使うことが当然になってきました。 これは、入口でのチェックだと漏れやすいから、脆弱性が発生するその箇所で対策するという考え方にシフトしているのだと私は考えます。 Webアプリケーションの場合も同様で、XSSやSQLインジェクションの対策は、脆弱性の発生する箇所、すなわち、HTMLの生成とか、SQLの呼び出しの時点で行います。いや、これらは「セキュリティ対策」ではなく、全ての文字を扱うために必要なエスケープ処理に過ぎないので、例がよくないですね。例えば、パストラバーサル脆弱性対処のためのファイル名の確認は、ファイルをオープンする直前（ファイル名を使う直前）に行うべきだ、という考え方です。 スタ

今日Yahoo!知恵袋で以下の記事を読みました。 質問 トラッキングの拒否（Do Not Track）って設定しておいた方が良いんでしょか。 説明読んでも今ひとつ分からないんですが、ただｳｪｰﾌﾞ追跡と留まり時間、広告の類のこと？ 再度アクセスする時にトラッキングの拒否を設定していると面倒臭いんでしょうか？ ベストアンサーに選ばれた回答 ブラウザで、トラッキングクッキーを拒否する設定ですね。 トラッキングクッキーは名前の通り、ブラウザでの操作、すなわち、サイトの何処をクリックしたか、どんなサイト・ページを見たといった、ネットでの行動を監視・追跡をする為のモノです。 【中略】 トラッキングされるのがイヤ、気持ち悪いと考えるならば、トラッキングの拒否（Do Not Track）の設定をONとすれば、ブラウザ側で適時、トラッキングクッキー（と思われるモノ）を拒否してくれるかと。【後略】 http

お客さまの情報は安全です お客さまの安全のため、PayPal は、お客さまの銀行口座番号や、クレジットカード番号を全桁再入力していただく場合は必ず、事前にその番号の少なくとも「下2桁」を提示します。この数字によってお客さまは、PayPalがお客さまの番号全桁をすでに知っており、残りの数字の再入力をお願いしていることがわかります。カード番号の少なくとも下2桁を表示することによってお客さまの番号を知っていることを証明せずに、確認と称して番号を聞いてくるウェブサイトやメールには十分ご注意ください。 paypalのパスワードリセット手順のヘルプより なるほどねぇ

昨日、こんなニュースが飛び込んできました。 パスワード盗む新手口＝ネット銀の不正送金－被害、最悪ペース・警察庁 インターネットバンキング利用者の口座から無断で現金を送金する事件で、パスワードを盗む新しい手口による被害が多発していることが２４日、警察庁への取材で分かった。不正送金を防ぐため内容を毎回変えている「ワンタイムパスワード」を、犯人がコンピューターウイルスで入手したとみられる。 今年確認された不正送金の被害は９０００万円を超えた。昨年の約４８００万円を上回り、過去最悪だった２０１１年の約３億８００万円と同じペースとなっている。（2013/04/24-21:38） 時事ドットコム：パスワード盗む新手口＝ネット銀の不正送金－被害、最悪ペース・警察庁より引用 『「ワンタイムパスワード」を、犯人がコンピューターウイルスで入手』だと? 最初は、いよいよ本格的なMITB(Man in the B

脆弱性には2種類あります。 一般的に要求される最低限のセキュリティ水準を満たさない場合アプリケーション要件として規定しているセキュリティ機能が、要件を満たしていない場合たとえば、パスワードリセットするのに、(a)秘密の質問に対する答えを知っている、(b)あらかじめ登録したメールへの送信文を読める、の両方が必要という要件に対して、実際には片方だけでリセットできたとすると、「アプリケーションの要件を満たさない」という意味では脆弱性ですが、一般的な要求水準は満たしているので、「一般的には許容されるレベルだが、本来のセキュリティ機能を満足していない」という意味で「軽微な脆弱性」となります。 一方、個人情報入力フォームがSSL暗号化していない場合、「最低限の水準」を満たしていないとはいえないので一般的には脆弱性ではありませんが、プライバシーポリシー等に「個人情報は暗号化して送信されます」などと書いて

本日早朝に、Evernoteが外部からの攻撃を受けて、ユーザ名、メールアドレス、パスワードハッシュ値（ソルト付きハッシュ）にアクセスされたという報告（セキュリティ関連のお知らせ：Evernoteでのパスワード再設定のお願い）がありました。 Evernoteのユーザは、このお知らせの指示にしたがい、パスワードをリセットしましょう。問題は、Evernoteのコンテンツ（ノート）にアクセスされたかどうかですが、Evernote社では、以下のように、ノートにはアクセスされた形跡はないと主張しています。 弊社セキュリティ調査の結果、Evernote に保存されているコンテンツが外部からアクセス・変更・消失された形跡は確認されませんでした。また、Evernote プレミアムおよび Evernote Business のお客様の決済情報がアクセスされた形跡も確認されていませんのでご安心ください。 一応こ

MSDNフォーラムで表記の質問を見かけました。同フォーラムの活動実績がないせいか、回答にリンクを貼ると拒否されましたので、こちらに回答します。 ここからが質問なのですが、プログラムの実装が完了したあと、脆弱性が潜んでいないかをチェックする必要があるのですが、脆弱性を検出するツールなどがありましたら教えてください。できれば、無償で使える物で、環境にあまり依存しないもの(Windows Serverのバージョンや、DBMSの種類に依存しないもの）がよいです。 Webアプリの脆弱性を検出するツールはありますか？ 以下、回答です。 ご要望の条件をすべて満たすツールは、おそらくないと思います。 少し古いエントリになりますが、以下のブログにWebアプリケーションの脆弱性を調べるツールがまとめられています。 サーバ/Webアプリケーション脆弱性チェックツールの個人的まとめ（フリー/有償） 良い物は高価、

前に、「なりすまし犯行予告に悪用可能なWebアプリケーション脆弱性」というエントリで、なりすまし犯行予告に開くよう可能なWebアプリケーションへの攻撃手法として以下の5種類を挙げましたが、このテーマに関して、日経Linux2013年1月号に「“誤認逮捕”から利用者を守るWebサイト構築法」という記事を書きました。 CSRFXSSHTTPヘッダインジェクションクリックジャッキングDNSリバインディング今回の寄稿では、上記の原理と対策について書いています。紙の雑誌となりますが、よろしければお読み頂ければと思います。 また、この記事のコラムとしてTorの解説があります。編集部からは当初、徳丸自身が書くか、誰か適当な方を紹介して欲しいという要求でしたが、迷うことなく北河拓士さん(@kitagawa_takuji)に寄稿を打診したところ、快諾をいただきました。このコラム「暗号化の“皮”を重ねて匿名性

PHPの本家サイトでflockの説明を読んでいたら、以下の変更履歴に気がつきました。 5.3.2 ファイルのリソースハンドルを閉じたときにロックを自動的に解放する機能が削除されました。 ロックの解放は、常に手動で行わなければなりません。 http://php.net/manual/ja/function.flock.php ところがネットの解説を見ると、ロック開放はflock($fp, LOCK_UN); ではなく、fcloseでやれとしている解説が結構あります。 (4)fcloseの前にflock解除するな … fcloseの前にflock(ファイルポインタ, LOCK_UN) する人は実に多いのですが、これははっきりと間違いだと断言します @ITのPHPの記事が突っ込みどころ満載 - 暴言満載 LOCK_UNは普通は使われない。ロック開放はfclose()関数でやるのが鉄則。 http

紙の本について、かつてこう書きました。 本を手にとって最初に思うことは、その大部さである。いまどき、箱入り、ハードカバーで494ページもあり、ずしりとした手ごたえを感じる。日常のリファレンスや満員電車のお供にするのであれば、もっと軽薄短小であって欲しいと思うところだが、本書の場合そうではない。その理由は後述する。 【中略】 繰り返すが、本書は初心者向けの解説では決してなく、上級者が自身の楽しみに読むのが正しいと思う。であれば、箱入りであるとかハードカバーであることは決してデメリットではない。楽しい読み物として末永く楽しむべき本には、それにふさわしい体裁があるというものである。 書評 - ウェブアプリケーションセキュリティより こう書いたものの、やはり手元で「あれ、これはどうだっけ」と調べるには、電子書籍だと便利ですね。それに、紙の本が4,830円であるのに対して、Kindle版は2,800

マイナビさんの「”加害企業”にならないためのWEBセキュリティセミナー ～6月の事件はこうして起こった、その手法と対策～」で講演することになりましたのでお知らせします。 日時：2012年10月18日（木曜日） 13時～16時40分（徳丸の出番は13:00～13:50） 場所：マイナビパレスサイドビル 東コア9FマイナビルームA（東京都千代田区） 費用：無料（申し込みはこちら） 講演タイトル：Webサイトを巡る攻防、変わらぬ原理と今必要な対策とは また、最後のセッションでは、NTTデータ先端技術の辻 伸弘さん(@ntsuji)さんが、「what is anonymous」 と題して講演されます。辻さんのanonymousのお話、楽しみですね。私は邪魔にならないように、攻撃の代表的なパターンとデモをお見せしようと思っています。 いわゆるセキュリティのCIA、すなわち機密性、完全性、可用性が破ら

徳丸本こと、拙著「体系的に学ぶ安全なWebアプリケーションの作り方: 脆弱性が生まれる原理と対策の実践」ですが、Google Playからお買い求めいただけるようになりました。 購入はこちらから。 購入ページはこんな感じ。 Google Playの電子書籍は、PDFから画像化されているようで、以下のように「スキャンしたページだけで構成されています。小さな画面にはおすすめできません。」という注意書きが表示されます。 さっそく私も購入して読んでみました。下の画像の、左はGoogle Nexus7、右はGALAXY NEXUS SC-04Dです。 PCからは、下のようにブラウザで閲覧することになります。 既に、徳丸本の電子書籍は、ブックパブからDRMフリーのPDFが購入でき、価格はGoogle Playとブックパブ共に2,800円です。ブックパブでの購入はこちら。 どっちがお勧めかと言うと、正直

追記:より詳細の報告を公開しましたのでそちらを参照下さい CGI版PHPにリモートからスクリプト実行を許す脆弱性(CVE-2012-1823)　追記終わり。 昨日のメモでは、CVE-2012-1823の対処をFastCGIかmod_phpに移行するとしていたが、CGIのまま暫定対処する方法を以下に公開する。 PHPの設定が以下と想定する。 AddHandler application/x-httpd-php5 .php Action application/x-httpd-php5 /cgi-bin/php-cgi php-cgiを呼び出すラッパー(/cgi-bin/php-wrapper)を以下のように記述する。実行権限を付与すること。php-cgiにパラメータを渡さないところがポイント。 #!/bin/sh exec /usr/local/bin/php-cgi PHPの設定を以下のよ

追記:より詳細の報告を公開しましたのでそちらを参照下さい CGI版PHPにリモートからスクリプト実行を許す脆弱性(CVE-2012-1823)　追記終わり。 【概要】 PHP5.4.2で修正された脆弱性だが、直っていない。CGI版のみが影響を受ける。mod_phpやFastCGIによるPHP実行の場合影響なしとされる。 【影響】 ・PHPの実行時オプションが外部から指定されるその結果として以下の影響がある ・リモートのスクリプト実行(影響甚大) ・PHPソースの表示 【影響を受けるサイト】 ・PHPをCGIとして実行しているサイト（FastCGIは大丈夫らしい） 【回避策】 ・PHP本家の改修リリース(5.4.2など)は不十分な対策（PHP5.4.2でもリモートコード実行できることを確認済み） ・mod_rewriteによる回避策も不十分らしいが情報不足 ・FastCGIまたはmod_ph