タグ

ブックマーク / blog.ohgaki.net (120)

  • 出鱈目なシグニチャのhash_hkdf関数を安全に使う方法

    (Last Updated On: 2018年8月13日)ユーザーが間違った使い方をしないよう、PHP 7.1に追加されたhash_hkdf関数のシグニチャが出鱈目である件について書いておきます。使い方を間違えると脆弱な実装になるので注意してください。 hash_hkdf関数はRFC5869のHKDFハッシュの実装で、既存の鍵から新しい鍵を導出する鍵導出関数(Key Derivation Function – KDF)です。鍵導出とは 既に存在する鍵から別の鍵を作ること です。マスター鍵から暗号化に利用する別の鍵を作る、といった場合に利用します。 hash_hkdf関数は以下のシグニチャを持っています。 string hash_hkdf ( string $algo , string $ikm [, int $length = 0 [, string $info = ” [, string

    出鱈目なシグニチャのhash_hkdf関数を安全に使う方法
  • Pharファイルを利用したコード実行 – POP攻撃

  • 開発者は必修、CWE/SANS TOP 25の怪物的なセキュリティ対策

    (Last Updated On: 2018年11月3日)SANS TOP 25 の解説はもっと後で行うつもりでした。しかし、現在のアプリケーション開発者向け教育に対する疑念のエントリへの反響が大きいようなので書くことにしました。 やるべきセキュリティ対策には優先順位があります。効果が大きい対策から行うべきです。セキュリティ対策は全体的に行うべきものですが、最も効果的な対策を除いて対策を行うようでは全体的な対策など行えません。 CWE/SANS TOP 25とは? SANS TOP 25の正式名称はCWE/SANS TOP 25 Most Dangerous Software Errorsです。名前の通り最も危険なソフトウェア脆弱性のトップ25を挙げ、その対策を解説したセキュリティ対策のガイドラインです。SANS TOP 25は米国のセキュリティ教育・認証・研究機関であるSANSが不定期に

    開発者は必修、CWE/SANS TOP 25の怪物的なセキュリティ対策
  • IPAの「安全なウェブサイトの作り方」は安全な作り方のガイドではない

    (Last Updated On: 2019年2月1日) IPAは「安全なウェブサイトの作り方」とする資料を長年公開しています。しかし、これが、重大な誤りにより、全く安全ではないWebサイトの作り方なっています。 重大な誤りとは以下です。 CWE-20 – 出鱈目なデータを排除する検証(入力バリデーション)について一切記載がない コンピューターサイエンス/システムエンジニアリングの観点から考える情報セキュリティはISO 27000で標準としてまとめられています。GDPRなどの法制度やNIST SP800-171の義務化などISO 27000の重要性は高まるばかりです。ISO 27000は2000年から、入力バリデーションだけは具体的な対策を記述し、セキュアコーディング/セキュアプログラミングの導入を要求しています。 ISO 27000の基礎的要求事項を無視したセキュリティ対策で情報漏洩問題

    IPAの「安全なウェブサイトの作り方」は安全な作り方のガイドではない
  • 攻撃可能面(アタックサーフェス)の管理 – セキュリティの基本

    (Last Updated On: 2022年10月1日) Attack Surface (攻撃可能面=攻撃可能な箇所)の管理はセキュリティ対策の基中の基です。あまりに基すぎてあまり語られていないように思います。 攻撃可能面を管理するには先ず攻撃可能な箇所がどこにあるのか分析(=リスク分析)します。その上でできる限り攻撃可能な箇所を削減(=リスク削減)します。攻撃可能面の分析と管理とはリスク分析と管理です。セキュリティ対策そのものと言える、基的な管理です。 Attack Surface (攻撃可能面) The attack surface of a software environment is the sum of the different points (the “attack vectors“) where an unauthorized user (the “attack

    攻撃可能面(アタックサーフェス)の管理 – セキュリティの基本
  • JavaScriptでインジェクションリスクがある関数/機能など

    (Last Updated On: 2018年8月9日)Webブラウザに対するJavaScriptコードのインジェクションは サーバー側のコードが原因(サーバー側のPHPRubyPythonJavaScriptが原因) クライアント側のコードが原因(クライアント側のJavaScriptが原因) サーバーとクライアント(上記の両方) で起きる可能性があります。ここでは主にクライアント側が関係するケースで注意しなければならない箇所を紹介します。 どこが危険なのか? ブラウザ上のJavaScriptの場合、ECMAScriptの基として実装されている機能、DOM機能として実装されている機能があります。更にこの他にもHTMLCSS機能もあり複雑です。SVGなどこの他の標準にもJavaScriptが記述できるモノがあります。 JavaScriptを実行可能となる部分へユーザー入力データを出

    JavaScriptでインジェクションリスクがある関数/機能など
  • PHPでCSRF対策を自動的に行う方法

    (Last Updated On: 2018年8月13日)PHPでWebページにCSRF対策を追加するのは簡単です。全てのページにCSRF対策を追加する場合、ファイルを1つインクルードする以外、ほとんど何も行う必要がありません。 CSRF Protection for PHPの機能 自動的にHTMLフォームやリンクにCSRFトークンを追加 CSRFトークンの有効期限を設定可能 まだまだ多くのアプリケーションが固定かつ有効期限を設定しないのCSRFトークンを使っています。この状態では一旦CSRFトークンを盗まれると、攻撃者にいつまででも攻撃される可能性があります。 このスクリプトの場合、有効期限付きのCSRFトークンをWebページに自動追加して防御します。 後で記載するようにPHP 7.1でoutput_rewrite_var()のバグを完全に直しました。なのでPHP 7.1以降の利用がお勧

    PHPでCSRF対策を自動的に行う方法
  • セキュアコーディング/セキュアプログラミングが流行らない理由

    (Last Updated On: 2018年9月13日)ISO 27000(ISMS)をはじめ、セキュアコーディング/セキュアプログラミングを行いなさい、と推奨するセキュリティガイドラインが多くあります。2014年改訂のISO 27000に至っては、セキュアプログラミングが広く普及したのでセキュアプログラミングを行うとする記述に簡素化しています。1 しかし、広く使われているフレームワークでさえセキュアコーディング/セキュアプログラミングをサポートする機能が無かったり/不十分でだったり、現状は到底普及している、とは言えないです。辛うじて普及しているかも?と言えるのはセキュアコーディング/セキュアプログラミングでは枝葉末節にあたるコーディング技術(ああすべき/こうすべき)くらいではないでしょうか? なぜセキュアコーディング/セキュアプログラミングが普及していないのか?考えられる理由を挙げます

    セキュアコーディング/セキュアプログラミングが流行らない理由
  • PHPで整数オーバーフロー/アンダーフローをチェックする方法

    (Last Updated On: 2018年8月24日)ユーザーから整数値を受け取った時にその値が整数型の範囲内に収まるか、チェックしたいことがあります。 PHPの整数型 PHPの整数型(int)の範囲はOSとPHPバージョンに依存します。詳しくはPHPの制限を参照してください。 符号付き32bit整数しか扱えない場合でも、PHPは浮動小数点型(float)に自動変換するので開発者から見るとどのような環境でもIEEE 754 倍精度浮動小数点型が扱える整数範囲(符号付き53bit整数)まで正確に演算できるように見えます。 整数型が自動的に浮動小数点型になる動作はstrict_typesが有効な場合に問題となるので注意が必要です。 整数型オーバーフロー/アンダーフローのチェック PHPには任意精度整数演算を行うBCMathモジュールがデフォルトで組み込まれています。BCMathを使うと簡単

    PHPで整数オーバーフロー/アンダーフローをチェックする方法
    Kenji_s
    Kenji_s 2017/04/02
  • コンピュータは数値さえ正確に扱えない

    (Last Updated On: 2018年8月13日)コンピュータで数値を正確に扱うのは「実は結構難しい」です。つまり「コンピューターは数値を正確に扱えない」という事です。「コンピューターが数値を正確に扱えない?!何を言ってるんだ?!」と思った方は是非読んでみてください。 コンピューターは数値を正確に取り扱えない コンピューターは数値を正しく取り扱えるから便利なのでは?と思うかも知れません。「コンピューターは数値を正確に取り扱えない」これは動かし難い事実/制限です。 コンピューターが数値を正しく取り扱える条件が決まっています。条件の範囲外であれば正確に取り扱えません。 この問題によりロケットが爆発するといった事例もあります。 整数 最も解りやすいのは整数です。通常、整数は固定の記憶領域を持つ整数型で表現されます。32ビット整数、64ビット整数、という言葉はITシステムの開発者でなくても

    コンピュータは数値さえ正確に扱えない
  • HMACを利用した安全なAPIキーの送受信

    (Last Updated On: 2018年10月9日)Webアプリケーションの機能をサービスとして提供する場合、ランダムな値の秘密のAPIキーを鍵とすることが多いです。 // 何らかのAPIを呼び出す http://example.com/api/v2/get_something?api_key=qwertyuiop シンプルな方法で使いやすいですが、鍵となるAPIキーをそのまま使っているので鍵が漏洩する可能性があります。HMACやHKDFを使うと鍵となるAPIキーを直接使わないでAPIへのアクセスを認証できます。 HMACを使ったAPIキーによる認証 前提条件: $api_keyは暗号学的に安全な鍵。例:$api_key = base64_encode(random_bytes(32)); 鍵となるAPIキーを直接GETやPOSTで渡さなければ、鍵が漏れる心配がなくなります。HMAC

    HMACを利用した安全なAPIキーの送受信
  • ハッシュ(HMAC)を使って弱い鍵を強い鍵に変える方法

    (Last Updated On: 2019年2月5日)既存の鍵から別の鍵を導出する方式としてはHKDF(RFC 5869)があります。AES用に弱い鍵から強い鍵を作るにはHKDFでなくてもHMACで十分です。実際、HKDFはHMACを組み合わせて鍵を導出しているだけなので、ここで紹介するHMACのみの鍵導出と同等です。 ※ PHP 7.2からHKDFを実装したhash_hkdf()を使えます。hash_hkdf()が利用できる場合はシンプルにhash_hkdf()を使うと良いです。 前提条件 Web環境の場合、暗号化が必要となるのはサーバーサイドだけの場合も多いです。この場合、ユーザーが入力したパスワードを使ってデータを暗号化する際に暗号学的に強い鍵を使うことが容易な場合が多いです。弱い鍵から強い鍵をHMACで導出するだけです。 AESを使った暗号化にはPHPのOpenSSL関数を利用し

    ハッシュ(HMAC)を使って弱い鍵を強い鍵に変える方法
  • より高度なCSRF対策 – URL/URI個別にバリデーションする方法

    (Last Updated On: 2018年8月13日)ハッシュ関数は色々な場面で利用できます。このエントリではハッシュ関数の使い方、特にリクエストにサインする方法として、データベースを使わずURI個別のCSRFトークンを生成しバリデーションする方法を紹介します。 論理的な背景 まず前提条件となる知識を整理し、なぜこのエントリのようなハッシュ関数の使い方をしているのか紹介します。 大別するとハッシュ関数には二種類あります。ハッシュ関数の種別を正しく区別することが重要です。 暗号学的なハッシュ関数 – SHA2など 暗号学的でないハッシュ関数 – CRCなど 暗号学的なハッシュ関数には次の特徴があります。 同一のハッシュ値であるのに、そっくりだが実は異なるというようなメッセージの作成が不可能であること ハッシュ値から、そのようなハッシュ値となるメッセージを得ることが(事実上)不可能であるこ

    より高度なCSRF対策 – URL/URI個別にバリデーションする方法
    Kenji_s
    Kenji_s 2017/02/28
  • ハッシュ(HMAC)を使ってパスワード付きURL/URIを作る方法

    (Last Updated On: 2018年8月18日)より高度なCSRF対策 – URL/URI個別にバリデーションする方法でハッシュ(HMAC)を使えばデータベースを使わずに有効期限付きのURLを作れる、と紹介しました。今回はパスワード付きURL(URI)の作り方を紹介します。 まず、安全性についてはハッシュ(HMAC)を使って有効期限付きURLを作る方法を参照してください。 ハッシュ(HMAC)を使って有効期限付きURL/URIを作る方法とほとんど同じです。以下の方法でデータベースを使わずにパスワード付き(この例の場合は有効期限付き)のURIを作れます。 <?php // 有効期限付きURIの作成 // 有効期限付きURIにするURI $uri = 'http://example.com/some_path'; // 秘密鍵 - 'secure random data'はrando

    ハッシュ(HMAC)を使ってパスワード付きURL/URIを作る方法
  • PHPのmt_rand()/rand()問題

    (Last Updated On: 2019年1月29日)PHPのmt_rand()とrand()には状態の初期化/再初期化に問題があります。話しを簡単にするためにrand()をmt_rand()のエイリアスにする提案 https://wiki.php.net/rfc/rng_fixes が適用された状態を前提にMT rand問題として解説します。しかし、基的には古いPHPでrand()を使う場合も同じ(かそれ以上)の問題があります。 そもそもMT randは暗号理論的に安全な乱数生成器ではありません。安全な乱数の取得に使ってはなりませんが、MT rand以前の乱数に比べ予測が困難、ということで不適切な箇所で利用しているケースが散見されます。 結論から言うと、MT randで生成された乱数値は安全ではなく非常に危険1、です。 MT randのシード問題 PHPはMT randを自動的にシ

    PHPのmt_rand()/rand()問題
    Kenji_s
    Kenji_s 2017/02/01
  • ISO 27000の入力データ妥当性確認

    (Last Updated On: 2019年3月14日)セキュリティ標準では入力データの妥当性確認(入力バリデーション)が要求されています。具体的な方法はBS 7799(英国のJIS規格のような物、2000年に国際標準化)が作られた時(90年代後半)から記載されており、前の版までのISO 270001にも記載されています。2013年版のISO 27000ではセキュアプログラミングが普及したので具体的な方法などは省略しています。(日では普及していないような。。) セキュアプログラミングの基中の基セキュリティ対策ではない、というような意味が全く解らない議論もあるのが現状です。 かなり昔に似たようなことを書いたようにも思いますが、記憶が定かではありません。今でも有効なので改めて(?)ブログにします。 ISO27000の入力データ妥当性確認 以下の解説はJIS X 5080:2002 (

    ISO 27000の入力データ妥当性確認
  • 正規表現でのメールアドレスチェックは見直すべき – ReDoS

    (Last Updated On: 2018年8月13日)前のエントリでStackExchangeがReDoSで攻撃されサイトがダウンした問題を紹介しました。少しだけ掘り下げて見たところ、正規表現だけでメールアドレスをチェックしている場合、壊滅的なReDoS(十分短い文字列で指数関数的に実行時間が増加する)が可能なことが判りました。 結論を書くと、正規表現でのメールアドレスチェックは見直すべき、です。(特にRubyユーザー) 追記:影響範囲はメールアドレスチェックに限らないので、正規表現チェックは全体的に見直さないと、どこが脆弱なのか判りません。見直してチェックしたとしても、それが完全であったと保証することは困難です。ネット検索して直ぐに見つかった検索パターンは非常に脆弱であったこと、メールアドレスのマッチパターンは脆弱になりやすい繰り返しの繰り返しが含まれること、これらがあったのでタイト

    正規表現でのメールアドレスチェックは見直すべき – ReDoS
  • アプリケーション仕様?セキュリティ仕様?

    (Last Updated On: 2018年8月4日)アプリケーション仕様なのでセキュリティ仕様ではない、という議論があるようですがこれは正しくありません。 セキュリティ仕様とは「リスクを変化させるモノ全て」です。リスクの変化を低下させるモノなのか、増加させるモノなのかも関係ありません。変化するモノは全てセキュリティ対策です。これはITセキュリティ対策とは上位互換の関係にあるリスク対策の基概念です。 全てのアプリケーション仕様とセキュリティ仕様の関係 全てのアプリケーション仕様とセキュリティ仕様をベン図で表すと以下のようになります。 “全ての”セキュリティ仕様とアプリケーション仕様を考える場合、セキュリティ仕様はアプリケーション仕様の完全なサブセットになります。 これはセキュリティ仕様は「アプリケーション仕様の中でリスクを変化させるモノ全て」だからです。 特定のアプリケーション仕様とセ

    アプリケーション仕様?セキュリティ仕様?
  • mbstring正規表現デフォルト文字エンコーディングは”EUC-JP”だった

    (Last Updated On: 2018年8月13日)デフォルト文字エンコーディング設定の仕様変更はPHP 5.6リリースの際に私が行った変更ですが、ブログで紹介していなかったような気がするので紹介します。PHP 5.5以下のmbstring正規表現デフォルト文字エンコーディングは”EUC-JP”でした。 一応、RFCには all functions that take encoding option use php.internal_encoding as default (e.g. htmlentities/mb_strlen/mb_regex/etc) と書いているのですが、これだけではmb_eregなどのデフォルト文字エンコーディングが変わっている事に気が付かない方も多い(気が付かない方が多い?)と思います。 PHP 5.6のデフォルト文字エンコーディング設定 PHP 5.5以

    mbstring正規表現デフォルト文字エンコーディングは”EUC-JP”だった
  • PHPの制限一覧

    (Last Updated On: 2018年9月21日)PHPには他の言語と同様に様々な制限があります。まとまった資料が見つからなかったのでまとめておきます。PHPの制限と言っても実行時間の制限のようにマニュアルに記載されているINI設定などは記載していません。 PHPのデータ型制限 整数型 PHPの整数型のレンジはOSにより異なります。 32ビットOS – 符号付き32ビット整数。最大2^31-1、最小-2^31 64ビットOS – 符号付き64ビット整数。最大2^63-1、最小-2^63。ただし、PHP 7.0未満のWindows OSでは64ビットOSでも最大2^31-1、最小-2^31。 ネイティブの整数型を超える範囲の整数には任意精度整数(実質無制限)をサポートするGMPまたはBCmathが利用可能です。モジュールはデフォルトで組み込まれないですがGMPの利用を推奨。PHP 5

    PHPの制限一覧
    Kenji_s
    Kenji_s 2016/04/05