まちがった自動ログイン処理
(Last Updated On: 2018年8月20日)問題：まちがった自動ログイン処理の解答です。このブログエントリは最近作られたアプリケーションでは「問題」にしたような実装は行われていないはず、と期待していたのですがあっさり期待を破られたのでブログに書きました。このブログの方が詳しく書いていますけが「Webアプリセキュリティ対策入門」にも正しい自動ログイン処理を書いています。 参考：自動ログイン以外に2要素認証も重要です。「今すぐできる、Webサイトへの2要素認証導入」こちらもどうぞ。HMACを利用した安全なAPIキーの送受信も参考にどうぞ。 間違った自動ログイン処理の問題点 まず間違った自動ログイン処理を実装しているコードの基本的な問題点を一つ一つ順番にリストアップします。 クッキーにランダム文字列以外の値を設定している クッキーにユーザ名が保存されている クッキーにパスワードが保
PHP本体でタイミング攻撃を防御できるようになります
(Last Updated On: 2021年3月25日) PHP 5.6からタイミング攻撃に対する対策が導入されます。メジャーなアプリケーションはタイミング攻撃対策が導入されていますが、PHP 5.6から簡単に対策できるようになります。 タイミングセーフな文字列比較関数はhash_equalsとして実装されました。 http://php.net/manual/es/function.hash-equals.php タイミング攻撃とは タイミング攻撃とは、コンピュータが動作する時間の違いを測って攻撃する、サイドチャネル攻撃（副作用攻撃）と呼ばれる攻撃手法の１つです。HTTPSの圧縮の副作用を利用したサイドチャネル攻撃が有名です。 コンピュータの動作時間、温度、音、電子ノイズ、電力使用量など、アルゴリズム自体の脆弱性を攻撃するのではなく副産物を利用する攻撃方法でサイドチャネル攻撃の一種です。
徳丸さんのブログに対するコメント
(Last Updated On: 2018年8月4日)最初、書いた時はユーザーが一人だけと頭にあったので思いっきり誤解していました。確かに複数ユーザーの場合は真正性に問題があります。修正版の差分をアーカイブを更新しておきました。 本題のブログはこちらです。 書籍『Webアプリケーションセキュリティ対策入門』のCSRF脆弱性 トークンの有効範囲は? トークンがDBに保存される場合、トークンの有効範囲が気になるところです。大垣本および第二版のソースを見ると、トークンを保存するテーブルの定義は以下の通りです。 CREATE TABLE form_id (sha1 TEXT PRIMARY KEY, created TEXT NOT NULL) sha1がトークン、createdが生成日時を保持します。 シンプルな構造ですが、これだとトークンは、ユーザーやセッションを超えて、アプリケーション全体
入力バリデーションがセキュリティ対策かどうかは、”どうでもいい”！？
(Last Updated On: 2018年8月8日)徳丸さんとの議論は終わっている いるので議論することはありません。しかし、 ここが変だよ、グローバルスタンダードの脆弱性対策～入力値の考え方～ というおかしなスライドが目に入ったのでコメントしておきます。今現在で2万近くのビュー回数もあると放っておけません。 ”セキュリティ専門家”という肩書を持つ方が非論理的／非科学的な独自のセキュリティ理論を展開されるようでは、誤解してしまった開発者がセキュアでないコードを書いてしまいます。どのように非論理的／非科学的なのか簡単にコメントします。 問題のスライド 問題のスライドはこちらです。 色々あるのですが、特にp27です。 それ（入力バリデーション）が「セキュリティ対策」かどうかは、”どうでもいい” とセキュリティ専門家としては論外の主張をされています。因みに私もOWASPの考え方に基本的に大賛
ほぼ全てのインジェクション攻撃を無効化／防止する入力バリデーション 〜 ただし出力対策も必須です 〜
(Last Updated On: 2019年2月18日)入力バリデーションはセキュリティ対策として最も重要なセキュリティ対策です。なぜセキュリティ対策であるのか？を理解していない方も見かけますが「ほぼ全てのインジェクション攻撃を無効化／防止する入力バリデーション」の効果と拡張方法を見れば解るのではないでしょうか？ ソフトウェア開発者が知っておくべきセキュリティの定義／標準／ガイドで紹介しているセキュリティガイドラインでは入力バリデーションが最も重要なセキュリティ対策であるとしています。 厳格な入力バリデーションを行うと、開発者が意識しなくても、非常に多くの脆弱性を利用した攻撃を防止できます。今回は比較的緩い入力バリデーション関数でも、ほとんどのインジェクション攻撃を防止できることを紹介します。 重要：セキュア／防御的プログラミングでは入力と出力のセキュリティ対策は”独立”した対策です。ど
今すぐできる、Webサイトへの2要素認証導入
(Last Updated On: 2018年8月14日)Google、Facebook、Amazon(AWS)、Githubなど、大手Webサービス会社が2要素認証を取り入れてしばらく経っています。自分のWebサイトでも2要素認証を導入したい！と思ったことは無いですか？ 簡単に可能です！ パスワード認証だけではもう安全とは言えません。ぜひ2要素認証を自分のサービス／プロダクトに導入してください。 2要素認証とは？ 2要素認証（2 Factor Authentication）とはパスワードとは別の認証コードを利用してユーザーを認証する方式です。2段階認証（2 Step Authentication）と呼ばれることもあります。複数の認証要素を利用して認証するので多要素認証（Multi Factor Authentication） とも呼ばれています。AWSでは2要素認証をMFAと呼んでいます
PHP7で追加される整数型、浮動小数点型タイプヒントの問題点
(Last Updated On: 2018年8月13日)PHP7では整数型、浮動小数点型、配列型のタイプヒントが追加されます。データ型をより厳格に取り扱うようになるのは良い事ですが、データ型を変換してしまうため問題となる場合もあります。 データ型は指定した型に変換すればよい、という単純な物ではありません。私はデータ型を変換しない方のRFCを支持していました。残念ながらこちらのRFCでなく、問題が多い方のRFCが採用されることになりました。 参考 PHP7のタイプヒントの使い方 タイプヒントとは？ そもそもタイプヒントを使ったことが無い方も多いと思います。PHPはオブジェクトのクラスを「タイプヒント」として指定することが従来から可能でした。例えば、 function (MyClass $obj) { // Do something } のようにタイプヒントとして”MyClass”を指定し、
徳丸浩氏との長年の議論に終止符 – 論理的／体系的セキュリティとそれ以外
(Last Updated On: 2018年8月4日)私が長年徳丸さんと議論していることをご存知の方も多いと思います。徳丸さんがなぜ論理的に矛盾する主張、明らかにセキュリティ標準規格／ベストプラクティスに反する主張を繰り返えしたのか、その理由が判明しました。それと同時に長年の議論に終止符が打たれ、徳丸さんの考えを完全に理解することができたと思われます。 徳丸さんがセキュリティ対策製品であるWAF（Web Application Firewall）を販売／推奨しつつ、アプリケーション側のファイアーウォールと言える「入力バリデーション」を「セキュリティ対策ではない」と主張されるのは、ジョブセキュリティやステスルマーケティングの類ではないのか？と思えるほどでした。アプリケーションがバリデーションしなければしないほどWAFの有効性は上がり、WAFが売れるでしょう。「WAFはセキュリティ対策」「ア
なぜRubyと違い、PHPの正規表現で^$の利用は致命的な問題ではないのか？
(Last Updated On: 2018年8月13日)Rubyデフォルトの正規表現では^は行の先頭、$は改行を含む行末にマッチします。PHPのPCREとmbregexでは^はデータの先頭、$は改行を含む行末にマッチします。 この仕様の違いはデータのバリデーションに大きく影響します。 参考： PHPer向け、Ruby/Railsの落とし穴 の続きの解説になります。こちらのエントリもどうぞ。 なぜ^と$が行の先頭と行の末尾にマッチするのか？ そもそも正規表現はテキスト検索を行うステートマシーンとして設計されました。通常テキストには改行があります。特定の行に一致するかどうかテストするように設計するのが自然です。この為、正規表現の^と$は行の先頭と末尾にマッチするように設計されたと考えられます。 正規表現をバリデーションに利用することは可能です。しかし、そもそもは正規表現に一致する「テキスト」
PHP 5.4から配列定義は超簡単に、そして落とし穴も – yohgaki's blog
(Last Updated On: 2018年8月13日)PHP 5.4 Advent Calender 2011用のエントリです。（まだ空きがあるので是非どうぞ） このエントリを書いているのは11/23です。初めの方から重いネタだと後の方が苦労する（？）ので軽い話です。 PHP 5.3までの動作 現時点ではPHP Manualの配列のページには記載されていませんが、配列の定義が簡略化されます。まず現状の配列の定義方法は <?php $a = array('foo'=>123, 'bar'=>456, 789); var_dump($a); こんな感じですね。これを実行すると $ ../php-src-5.4/php arr.php array(3) { ["foo"]=> int(123) ["bar"]=> int(456) [0]=> int(789) } このような出力になります。
セキュリティ対策を行うべき部分 – 自分が作っている部分
(Last Updated On: 2018年8月8日)アプリケーション開発者がセキュリティ対策を行うべき部分とはどこか?当たり前ですがアプリケーションです。アプリケーションとは広い意味でのアプリケーションです。Webアプリの場合もあれば、ライブラリやモジュールであったり、フレームワークであったり、言語やサーバの場合もあります。 すべてのアプリケーション開発者が同じような意識を持ち、アプリケーションが安全に動作するようの作る責任はアプリケーションにあると責任感を持って開発すべき、と言いたいところですが実際には難しいです。 例えば、開発を始めたばかりの初心者であれば無理があります。どう作れば安全か、危険か、判断する基準がないからです。経験を積んだ開発者でも自分が作った事もない様なプラットフォーム上でどのように作れば安全か判断できません。 何故、セキュリティが分かり辛いのか?その一つ理由が「セ
セキュリティ専門家でも間違える！文字エンコーディング問題は難しいのか?
(Last Updated On: 2018年8月13日)一見徳丸さんのブログは分かりやすいように思えますが、それは単純な実験により分かりやすいように見えるだけで複数の間違いがあります。 その間違いとは 意図の取り違い – 誤読 言語の仕様と実装の理解不足 HTTPやPHP仕様の理解不足 セキュリティ対策をすべき場所の理解不足 です。(※0) 徳丸さんは非常勤とは言え、国の出先機関の研究員であるし、その出先機関は職務放棄とも言える文書（「例えば、PHPを使用しない」と勧める文書）を公開している(いた?)のでしっかり反論しておく必用がありますね。IPAのあの文書は職務放棄と言える文書だと思っています。これについても後で意見を述べます。 意図の取り違い – 誤読 最初の間違いは私のブログのエントリ「何故かあたり前にならない文字エンコーディングバリデーション」に対する理解です。特にPHPユーザに
何故かあたり前にならない文字エンコーディングバリデーション
(Last Updated On: 2018年8月8日)私が4年前（2005年）に「Webアプリセキュリティ対策入門」を執筆していた時には、既に壊れた文字エンコーディングなどの不正な文字エンコーディングを利用したJavaScriptインジェクションやSQLインジェクション攻撃は比較的広く知られていました。この問題は当時のスラッシュドットジャパンでも取り上げられていました。/.で取り上げられたので、そこら中のWebサイトとユーザが被害に合うのでは？とヒヤヒヤしたので良く覚えています。 不正な文字エンコーディングを利用した攻撃は、文字エンコーディングを厳格に取り扱い、文字エンコーディングをバリデーションすれば無くなります。これを怠ると、システムのどこで問題が発生するか予想できなくなります。つまり、いい加減に文字エンコーディングを取り扱うと安全なシステムは作れないのです。 参考：エンジニア向けに
書評：Ajaxセキュリティ
(Last Updated On: 2018年8月14日)これは随分前に献本して頂いた本です。Amazonで調べるまで知りませんでした。5000円を超える本なのですね。（英語版は忘れてましたが$50です）しかし、その価値はあります。 実はこの本の原書を先に購入して読んでいました。原書／訳書ともに非常に良い本だと思います。 この本はAjaxセキュリティを理解する為に必要なAjaxアプリケーションの概要から説明しています。読者によってはこのような解説は不必要だ、と感じる方もいるとは思います。しかし、これからAjaxアプリケーションを作ろうとする開発者の為には必要不可欠な解説です。このような構成は、あまり好まれない(?)ようですが、私は必要かつ適切な構成だと思います。本当に不必要な方は読み飛ばせば良いだけです。 Ajaxセキュリティではない従来のWebアプリケーションセキュリティについても、一通
PHP4.4.9のセキュリティ状態
(Last Updated On: 2018年8月13日)PHP4のサポートは2008/8/8を持って終了しました。サポート終了に合わせて、最後のPHP4リリースとなる4.4.9がリリースされています。サポートが終了していますが、稼動中のPHPの半分はまだPHP4であるとる統計情報もあり、まだまだ現役です。 PHPプロジェクトのサポート終了したため、PHP 4.4.9のセキュリティ脆弱性はCVEなどでも報告されなくなりました。この為、普通にセキュリティ情報を収集していてもPHP4.4.9に対する脆弱性情報は入手できません。 PHP4セキュリティ保守サービスではPHP 4にも対応しています。サポートしている脆弱性の概要は、弊社のお知らせをご覧下さい。 まだまだ、SQLインジェクションが無くなっていない事は非常に残念です。PHP4で作られたWebアプリケーションはSJISやEUCを文字エンコー
現行版のPHPに任意メモリ参照バグ – 攻撃コード付き
(Last Updated On: 2018年8月13日)随分前から共有型Webホスティングサービスでは安全性を確保できないので、安全性を重視するサイト(ECなど)は最低限でも仮想ホスト型の共有サービスを利用すべきである、と言っています。 今回のエントリはPHPをApacheモジュールで共有型ホスティングサービスを利用しているユーザに影響します。SSLを利用している場合は秘密鍵を盗まれます。このバグはPHP 5.2.8でも修正されていません。当然ですがPHP 4.4.9でも修正されていません。 Milw0rmのアドバイザリ http://www.milw0rm.com/exploits/7646 には、そのまま使える、任意のアドレスのデータを参照するコードまで付いています。秘密鍵を盗むことは簡単です。 誤解してはならない事ですが、これはPHPに限った問題ではありません。PHPでは度々このよ
Flashの0day脆弱性を利用した攻撃が蔓延
(Last Updated On: 2008年6月4日)追記：この件、どうも0dayでなく既知の脆弱性の問題だったということで決着しているようです。情報ありがとうございます。ただ、このブログにアクセスしている方でもgoogle analyticsによると脆弱性の無いバージョンだと分かるFlashを利用している方がたったの16.6%です。前のバージョン(9.0.115)の利用者は31.78%です。残りのユーザもほとんどが危険なFlash Playerを利用していると思われます。かなり有効な攻撃であることには変わりないようです。Flash Playerは時々アップデートがある、と教えてくれますがあまり役立たないので自分で脆弱性情報を収集してバージョンチェックする方が良いです。 とりあえず9.0.124.0であれば大丈夫なようです。 http://www.adobe.com/jp/support
誤ったWAFの使い方 – 国連でも
(Last Updated On: 2018年8月8日)WAF(Web Application Firewall)とは、通常のレイヤー2や3（IP, TCP/UDP）レベルのファイアーウォールよりもさらに上のレベルのアプリケーション層のファイアーウォールです。アプリケーションはレイヤー7とも言われ、ネットワークスイッチなどではアプリケーションの中身まで参照してスイッチングするスイッチはレイヤー7スイッチと呼ばれてきましたが、ファイアーウォールではレイヤー7ファイアーウォールと呼ばれる事は少なく、WAFと呼ばれる事が多いです。 WAFの目的は名前からも明白です。Webアプリケーションを脅威から守るために利用されます。WAFはWebアプリケーションをセキュリティ上の脅威から守る事ができますが、昔レイヤー2/3のファイアーウォールの能力が誇大に広告され、誤った認識で利用されていたように、WAFの
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
