マイナンバーのチェックデジット確認
(Last Updated On: 2018年8月13日)マイナンバーのチェックデジットを確認する必要があったのでPHP関数を作りました。 個人番号 マイナンバー（個人番号）のチェックデジットの計算式は法律に記載されています。 第五条 令第八条の総務省令で定める算式は、次に掲げる算式とする。 算式 １１―（ｎ＝１（シグマ）１１（Ｐｎ×Ｑｎ））を１１で除した余り） ただし、（ｎ＝１（シグマ）１１（Ｐｎ×Ｑｎ））を１１で除した余り≦１の場合は、０とする。 算式の符号 Ｐｎ 個人番号を構成する検査用数字以外の十一桁の番号の最下位の桁を１桁目としたときのｎ桁目の数字 Ｑｎ １≦ｎ≦６のとき ｎ＋１ ７≦ｎ≦１１のとき ｎ―５ <?php // 個人用マイナンバーのチェックデジットを計算し確認。（注：法人用は異る） // アルゴリズムは // http://law.e-gov.go.jp/anno
徳丸さんのブログに対するコメント
(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: 2019年2月18日)入力バリデーションはセキュリティ対策として最も重要なセキュリティ対策です。なぜセキュリティ対策であるのか？を理解していない方も見かけますが「ほぼ全てのインジェクション攻撃を無効化／防止する入力バリデーション」の効果と拡張方法を見れば解るのではないでしょうか？ ソフトウェア開発者が知っておくべきセキュリティの定義／標準／ガイドで紹介しているセキュリティガイドラインでは入力バリデーションが最も重要なセキュリティ対策であるとしています。 厳格な入力バリデーションを行うと、開発者が意識しなくても、非常に多くの脆弱性を利用した攻撃を防止できます。今回は比較的緩い入力バリデーション関数でも、ほとんどのインジェクション攻撃を防止できることを紹介します。 重要：セキュア／防御的プログラミングでは入力と出力のセキュリティ対策は”独立”した対策です。ど
ソフトウェア開発者が知っておくべきセキュリティの定義／標準／ガイド
(Last Updated On: 2018年8月4日)単純にこういった定義や標準があります、と紹介してもなかなか原文を参照することは敷居が高いです。このブログでも色々紹介できてきたので、ソフトウェア開発者が知っておくべきセキュリティの定義／標準／ガイドなどをまとめて紹介します。 セキュリティ対策の定義 そもそも定義を間違えていたら、ボタンの掛け違いは止まりません。まず、正しい定義を理解しなけばなりません。ソフトウェアのセキュリティといっても、他のセキュリティ対策の定義と基本は同じです。ISO 27000では広範囲なITセキュリティの対策を定義しています。勿論、用語の定義もあります。 ISO 27000のセキュリティ対策の定義 標準と基本概念から学ぶ正しいセキュリティの基礎知識 ざっくり言うと、基本的にはセキュリティ対策の本質は緩和策である、と理解していれば良いでしょう。 ISO 2700
今すぐできるWAFの導入
(Last Updated On: 2018年8月13日)PHPに簡易WAF機能を追加するのは簡単です。今すぐできます。同じ考え方で他の言語でも実装可能ですし、Apacheのmod_rewirteを使って実装、iptablesのstringモジュールなどを使っても実装できます。 ここで紹介するWAFは簡単な仕様ですが、本格的に拡張することも可能です。 簡易WAFの仕様 Webの一部を除き入力基本的には全てテキストです。攻撃によく利用される文字を除外することにより簡易WAFを実装します。 $_POST、$_GET、$_COOKIEは全てテキストだと仮定しバリデーションを行う（バイナリは無い） テキストの制御文字を検出する 検出する制御文字の例外は”\n”,”\r”,”\t”とする 文字エンコーディングチェックをする（UTF-8のみ） $_SERVER[‘HTTP_*’]も対象とする たったコ
SHA1でハッシュ化したパスワードは危険になった
(Last Updated On: 2018年4月3日)パスワードを平文で保存するのは論外で、MD5やSHA1でハッシュ化するのは当たり前です。しかし、SHA1を2000倍早くクラックする方法などが発見され「SHA1は脆弱だ」（ちなみにMD5はもっと危険）とされてからしばらく経ちます。アメリカ政府や大手企業はSHA1は使わない、としています。 Slashdot.orgにまた載っているので更に高速化できた、ということか? 参考： RainbowテーブルによるMD5ハッシュのクラック（英語） RainbowテーブルによるSHA1ハッシュのクラック（英語） 前のエントリ PostgreSQLでSHA1 でPostgreSQLでSHA1を使う方法の一つを紹介していますが可能であればSHA512など、より強いハッシュ関数を利用したり、Saltを利用する、等の方法を採用した方が良いと思います。 備考：
PHP7のタイプヒントベストプラクティス
(Last Updated On: 2018年9月26日)PHP 7から基本的なデータ型（整数型、浮動小数点型、配列型）タイプヒントが追加されます。直感的に書くコードと正しいコードには乖離があります。PHP7でタイプヒントを使う場合のベストプラクティスを紹介します。 タイプヒントとタイプヒントの問題点については前回のブログを参照してください。 PHP7タイプヒントの注意点 PHPはWebシステムで利用され、データベースやJSONなどの外部データとのやり取りが必要になります。PHP7のタイプヒントはデータ型変換を伴うので 入力データの形式／表現範囲 PHPデータ型の表現範囲 タイプヒント／キャストの動作 に注意する必要があります 入力データの形式 データベースの場合、入力データは基本的に”文字列”になります。データベースのデータ型をPHPなどの言語のデータ型と完全に一致するとは限りません。こ
徳丸浩氏との長年の議論に終止符 – 論理的／体系的セキュリティとそれ以外
(Last Updated On: 2018年8月4日)私が長年徳丸さんと議論していることをご存知の方も多いと思います。徳丸さんがなぜ論理的に矛盾する主張、明らかにセキュリティ標準規格／ベストプラクティスに反する主張を繰り返えしたのか、その理由が判明しました。それと同時に長年の議論に終止符が打たれ、徳丸さんの考えを完全に理解することができたと思われます。 徳丸さんがセキュリティ対策製品であるWAF（Web Application Firewall）を販売／推奨しつつ、アプリケーション側のファイアーウォールと言える「入力バリデーション」を「セキュリティ対策ではない」と主張されるのは、ジョブセキュリティやステスルマーケティングの類ではないのか？と思えるほどでした。アプリケーションがバリデーションしなければしないほどWAFの有効性は上がり、WAFが売れるでしょう。「WAFはセキュリティ対策」「ア
PHP7の現状
(Last Updated On: 2018年8月13日)PHP7が今年の秋リリースされる予定です。まだまだ多くの変更が行われる予定ですが、現状を簡単にまとめてみたいと思います。代表的な物のみ取り上げています。 ご存知ない方の為に書いておきます。現在リリースされているPHPはPHP5です。次のPHPはPHP7になり、PHP6はリリースされません。PHP6をUnicodeをネイティブ文字列としてサポートするバージョンとして開発されましたが、文字エンコーディングチェックを内部で自動的に行おうとするなど、無駄が多く遅いため破棄されました。（文字エンコーディングのバリデーションは本来アプリでするものです）このため、PHP6はスキップされ次のPHPはPHP7になります。 追記：PHP7.0は既にリリースされています。概要はPHP 7.0の概要・新機能・互換性、詳しくはマイグレーションドキュメントをご
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の圧縮の副作用を利用したサイドチャネル攻撃が有名です。 コンピュータの動作時間、温度、音、電子ノイズ、電力使用量など、アルゴリズム自体の脆弱性を攻撃するのではなく副産物を利用する攻撃方法でサイドチャネル攻撃の一種です。
IPAの「安全なSQLの呼び出し方」が安全になっていた
(Last Updated On: 2018年8月4日)IPAは「安全なSQLの呼び出し方」（PDF）を以下のURLから公開しています。 http://www.ipa.go.jp/security/vuln/websecurity.html 「安全なSQLの呼び出し方」は危険である、とするエントリを書こうかと思い、内容を確認するとそうでもありませんでした。 訂正：ツイッターで徳丸氏に確認したところ、徳丸氏もエスケープを含めたSQLインジェクション対策が必要であると考えられていた、ことを確認しました。徳丸氏にはセキュリティ専門家として大変不名誉な記述であった事を訂正し、深くお詫びいたします。内容についての修正は、識別子エスケープについてブログに書くとの事でしたのでブログの内容を確認してから修正します。 別冊の「安全なSQLの呼び出し方」は基本中の基本である「正確なテキストの組み立て」によるセ
PHPの比較とBOOL/NULL型の話
(Last Updated On: 2018年8月13日)先日、10年以上勘違いをしていたことがPHPの開発者MLで議論して発覚したので、その大恥を披露します。 PHPの比較とBOOL/NULL型の話です。 ことの発端はmin関数で var_dump(min(-100,-10, FALSE( or NULL), 10, 100); とするとFALSE（またはNULL）が返ってくる、というバグレポートからでした。 PHPのBOOL/NULL型は var_dump(TRUE == 1); var_dump(FALSE == 0); var_dump(NULL == 0); はそれぞれTRUEを返します。TUREは1、FALSE/NULLは0と評価されています。 算術演算の場合、BOOL/NULL型は数値として評価されます。 var_dump(TRUE + 1); // 2 var_dump(F
セッションアダプション脆弱性がないセッション管理が必要な理由
(Last Updated On: 2018年8月18日)徳丸さんから「ブログ読みました。サンプルも動かしました。問題は分かるのですが、セッションアダプションがないPHPだと、何が改善されるのかが分かりません。教えて下さい 」とあったのでツイッターで返信するには少し長いのでこちらに書きます。まだ直していない脆弱性を詳しく解説するのはあまりよくないのですが、今なら影響を受けるアプリはほぼないと思うので構わないでしょう。 まず前提として、Webサーバと同様にJavascriptからもクッキーが設定できます。Javascriptインジェクションに脆弱なコードがサイトに1つでもあると、サイト上のセッションアダプション脆弱性をもつアプリへの攻撃が可能になります。この攻撃を緩和する対策もありますが、それはそれ、これはこれなので省略します。 セッションアダプションに脆弱なセッション管理機構で困る代表的な
Tomcatの管理者は大忙し?
(Last Updated On: 2018年8月14日)http://www.milw0rm.com/exploits/6229 などはまだいいですが http://www.0x000000.com/?i=630 こういうのは、本当に使ってしまう輩がいそうで怖いです。 どうしても直ぐにバージョンアップできない場合、WAFは役に立ちます。今回の場合、 mod rewriteを使用した簡易WAF でも十分です。そう言えば、直ぐに使えるPoCを公開している http://www.0x000000.com/ は簡易WAFも紹介していたサイトです。簡易WAFを使いましょう、と言いたいのかも知れません。
画像ファイルに PHP コードを埋め込む攻撃は既知の問題
(Last Updated On: 2015年9月10日)国内外のメディアで「画像ファイルに攻撃用のPHPコードが含まれていた」と比較的大きく取り上げられています。しかし、この攻撃手法は古くから知られていた方法です。条件は多少厳しくなりますがPerl, Ruby, Pythonでも同様の攻撃は考えられます。PHPの場合は言語仕様的に他の言語に比べ攻撃が容易です。 典型的な攻撃のシナリオは次の通りです。 追記：Tokenizerを使った例に修正しました。 アバダなどの画像ファイルをアップロードできるサイトを探す ローカルファイルインクルードバグを探す 画像ファイルにサイトが利用している言語のコードを埋め込む 攻撃コードを含んだファイルを画像ファイルとしてアップロードする ローカルファイルインクルードバグを利用して攻撃コードを実行する PHPの場合、リモートインクルードバグを攻撃するための攻撃
PHPのSession Fixation問題
(Last Updated On: 2006年10月24日)PHPのセッション管理はセッションの固定化（Session Fixation）に脆弱であることは広く知れらていると思っていました。先日、php-users(ja)のMLに「Hardened PHPプロジェクトのStefanさんのパッチにSQLite Sessionモジュール用のセッションセーブハンドラパッチを追加したパッチを公開しました」と投稿しました。しかし、ダウンロード数等から推測するとセッションの固定化のリスクが正しく認識されていないのではないかと思えます。 セッション固定化のリスクを分かりやすく説明するには具体的な攻撃のシナリオを紹介した方がわかり易いのでいくつか説明します。以下の説明はデフォルト状態のPHPインストールでSession Fixation対策を行っていないのPHPアプリケーションに対して可能な攻撃の一例です
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
