サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
デスク環境を整える
blog.ohgaki.net
(Last Updated On: 2018年8月13日)全てのセキュリティ対策は緩和策だと考えるべきです。これは個々の対策が完全であるか検証することが容易ではないからです。例えば、SQLインジェクション1つとっても本当に完全であるか?検証することは容易ではありません。プログラムが本当に思っているように動作するのか?検証する研究は、まだまだ研究段階です。 しかし、容易ではないからといって諦める訳にもいきません。不完全であっても形式的な論理検証は容易にできます。 論理的な正しさを検証する方法 必要十分条件を使って考えると、使わない場合に較べ誤りを少なくできます。プリペアードクエリがSQLインジェクション対策として必要十分であるか考えてみます。SQLインジェクションはSQL文に変数が含まれる”動的クエリ”の場合に発生することを頭に入れておきます。 p – プリペアードクエリを使い全てのパラメー
(Last Updated On: 2018年8月16日)ITシステム開発者必修のセキュリティ概念 Top 10です。さっと考えたので変更するかも知れません。これらの考え方や概念を理解していないと、ITセキュリティ標準やガイドラインなどで要求されているセキュアプログラミング/セキュアコーディングを効率的かつ効果的に利用することはできないでしょう。 ここで紹介する概念はセキュリティ設計やセキュアコーディングを行う上で欠かせないモノばかりです。 順序はその基礎知識性、重要性、分かり易さで付けています。では開発者必修のセキュリティ概念 Top 10です。 参考:思いの外、長くなったのでショート版を作りました。 1. ゼロトラスト ゼロトラスト(Zero Trust)とは何も信頼しないことです。 しかし、実際には何らかの信頼がなければ効率的にシステム/ソフトウェアを作ることはできません。信頼はそこ
(Last Updated On: 2019年2月18日)'SELECT '.pg_escape_idetifier($_GET['col']).' WHERE '.pg_escape_identifier('tbl').' ORDER BY '.pg_escape_idetifier($_GET['col']) SQLクエリにはプリペアードクエリを使いましょう!と言われて久しいです。私もプリペアードクエリを積極的に使うべきだと考えています。 多くの場合、速い SQLパラメーターを分離して書くので「ついうっかり」が起こりにくい 特に初心者は「ついうっかり」が多い しかし、「プリペアードクエリだけを使っていれば良いので、エスケープは要らない」という意見には賛成できません。なぜ賛成できないのか?コードを見れば分かります。 何年か前に議論になった話題です。自分のエントリを検索して、たまたま見つけ
(Last Updated On: 2018年9月13日)ISO 27000(ISMS)をはじめ、セキュアコーディング/セキュアプログラミングを行いなさい、と推奨するセキュリティガイドラインが多くあります。2014年改訂のISO 27000に至っては、セキュアプログラミングが広く普及したのでセキュアプログラミングを行うとする記述に簡素化しています。1 しかし、広く使われているフレームワークでさえセキュアコーディング/セキュアプログラミングをサポートする機能が無かったり/不十分でだったり、現状は到底普及している、とは言えないです。辛うじて普及しているかも?と言えるのはセキュアコーディング/セキュアプログラミングでは枝葉末節にあたるコーディング技術(ああすべき/こうすべき)くらいではないでしょうか? なぜセキュアコーディング/セキュアプログラミングが普及していないのか?考えられる理由を挙げます
(Last Updated On: 2018年8月13日)追記: 8月現在では、OWASP TOP 10 2017はWAFのプロモーションになっている、OWASP Proactive Controlsの”全ての入力をバリデーションする”と重複している、などの点が議論になりRCはリジェクトされ11月にリリースを目指して調整中になっています。 追記2:正式版が2017年12月にリリースされました。ここで紹介している脆弱性はA10(10番目の脆弱性)「不十分なログとモニタリング」として登録されました。WAFが必要であるかのような記載が削減されましたが、脆弱性の本質(入力検証しない&対応しないアプリは脆弱なアプリ)は変わりありません。 このテーマついては既にブログは書いています。このエントリでは追加でQ&Aを記載しています。 2017年度版 OWASP TOP 10 で変るWebセキュリティのルー
(Last Updated On: 2018年8月13日)PHPにはタイプヒントと呼ばれる引数/戻り値データ型指定機能があります。これは便利な機能ですが性能に影響を与えます。 データ型チェックのオーバーヘッド 性能への影響は簡単なベンチマークで確認できます。単純な加算を行う関数fを定義して確認しました。PHPのバージョンは7.0.19です。 タイプヒントを指定しない場合 $ php -r 'function f($a, $b) { return $a + $b; } $s=microtime(true); for($i=0;$i<100000000;$i++) { f(2,3); } echo microtime(true) - $s, "\n";' 2.4526360034943 intタイプヒントを指定した場合 $ php -r 'function f(int $a, int $b)
(Last Updated On: 2018年8月8日)追記: 8月現在では、OWASP TOP 10 2017はWAFのプロモーションになっている、OWASP Proactive Controlsの”全ての入力をバリデーションする”と重複している、などの点が議論になりRCはリジェクトされ11月にリリースを目指して調整中になっています。 追記2:12月現在ではPDF版がリリースされています。現時点ではWebページの内容はドラフト版になっています。リリース版では「A7-Insufficient Attack Protection」は「A10-Insufficient Logging & Monitoring」になり、緩い要求事項に変更されていますが、基本的な要求事項は変わりません。マトモな入力バリデーションがないと要求されるログと監視機能を提供できません。 OWASP(Open Web Ap
(Last Updated On: 2018年10月12日)入力の種類には3種類以上の種類、名前、電話番号、住所など沢山の種類があります。しかし、見方によってはたった3種類しかありません。この区別ができる/できない、で大きな違いができてしまいます。 入力の種類 セキュリティ対策上、最も重要な区別は以下の区別です。 正しい入力値 入力ミスの入力値 不正な入力値 これらの入力値は”独立”しています。この三種類以外の入力値はありません。従って 全ての入力 = 正しい入力値 + 入力ミスの入力値 + 不正な入力値 になります。 不正な入力値はプログラムにとって、全く意味がなく120%有害なデータです。 意味がなく害しかない不正な入力値は拒否します。不正な入力の拒否はセキュリティ上、重要な意味を持ちます。ソフトウェアは非常に複雑であり、正しい入力だけであっても、正しく処理することは困難です。不正な
(Last Updated On: 2018年8月13日)第五回 関西DB勉強会でお話しさせて頂いた SQLインジェクション対策 総”習”編 の公開用資料をSlideShareにアップロードしました。私のセッションを気に入って頂けた方が多かったようで何よりです。 関西DB勉強会、面白かったです。久々にお会いできた方もいました。超満員でもう少しで入りきれないほどでした。また参加できれば、と思っています。 PDFはこちらからダウンロードできます。
(Last Updated On: 2018年3月17日)取り敢えず言語とプログラミングの基礎を学習し終えて、これから本格的にソフトウェア開発をしよう、という場合に困るのが「セキュリティ」です。今回は簡単に、これから本格的に開発を行う、という方向けに知っておくべき事を紹介します。 初めてTeratailに回答した内容を多少まとめて加筆したモノになっています。 https://teratail.com/questions/74317 ブログにしたので、Tratailの回答は単純にこのエントリを参照するように修正するかも知れません。 ISO 27000 体系的に情報セキュリティを学ぶなら、まず一度ISO 27000(国際情報セキュリティ標準)を読むと良いです。ISO 27000はISMS(情報セキュリティマネジメントシステム)認証の基盤となる標準規格です。日本でも5000ほどの組織が認証を取得
(Last Updated On: 2018年10月12日)信頼境界線(Trust Boundary)と境界防御はITセキュリティに限らず、セキュリティ対策の基礎中の基礎です。基礎中の基礎かつ最も重要な概念ですが習わないことが多いです。これが原因で「正しいセキュリティ対策」(≒効率的なセキュリティ対策)ができていないケースが多数あります。残念ながら”セキュリティに詳しい”とされている人でも全く理解していないケースが散見されます。 このエントリでは主に、ソフトウェアセキュリティに於ける信頼境界線の概念と引き方(≒セキュリティ構造/設計)、ついて紹介します。かなり長いエントリになりましたがお付き合いください。 セキュアコーディングの概念は解説していません。このエントリはセキュアコーディングの概念を理解してから読まないと理解が困難かも知れません。CERTのトップ10セキュアコーディング習慣を先に
(Last Updated On: 2018年8月13日)最近、HMACハッシュ(hash_hmac)の使い方を書いてきたのでまとめです。 HMACハッシュの使い方 基本的なHMACハッシュの使い方です。HMACを使うと、文字列連結で作るハッシュ値より安全なハッシュ値を取得可能です。文字列連結は使わず、HAMCハッシュを使うべきです。 hash_hmac()の使い方 文字列(ハッシュ)の安全な比較方法 ハッシュ値が鍵となっているケースは多いです。この場合、ハッシュ値の比較はhash_equals関数を使わなければ、タイミング攻撃に脆弱になります。 文字列(ハッシュ)の安全な比較方法 – hash_equals URL/URI別+有効期限付きのCSRF対策 HMACハッシュを利用すると、全てのURIに同じCSRFトークンを使う必要はありません。URI固有かつ有効期限付きのCSRFトークンをデ
(Last Updated On: 2018年8月13日)コンピュータで数値を正確に扱うのは「実は結構難しい」です。つまり「コンピューターは数値を正確に扱えない」という事です。「コンピューターが数値を正確に扱えない?!何を言ってるんだ?!」と思った方は是非読んでみてください。 コンピューターは数値を正確に取り扱えない コンピューターは数値を正しく取り扱えるから便利なのでは?と思うかも知れません。「コンピューターは数値を正確に取り扱えない」これは動かし難い事実/制限です。 コンピューターが数値を正しく取り扱える条件が決まっています。条件の範囲外であれば正確に取り扱えません。 この問題によりロケットが爆発するといった事例もあります。 整数 最も解りやすいのは整数です。通常、整数は固定の記憶領域を持つ整数型で表現されます。32ビット整数、64ビット整数、という言葉はITシステムの開発者でなくても
(Last Updated On: 2019年2月5日)HMACを使った鍵の生成(導出)方法を書いているので、念の為にパスワードのハッシュ化方法について書いておきます。一般にユーザー入力のパスワードをアプリケーションデータベース等に保存する場合、HMACやHKDFを使わずに、password_hash()を使うべきです。 参考: 覚えないパスワードは生成する物 覚える場合のパスワードの作り方 password_hashとは パスワードをアプリケーションに保存する場合、パスワードが管理者や開発者、攻撃者によって解析/窃取されるリスクを考慮する必要があります。平文のテキストでパスワードを保存した場合、簡単に盗まれてしまいます。 password_hash関数はcrypt関数のラッパー関数です。password_hash関数でできることはcrypt関数できます。password_hash関数が存
(Last Updated On: 2018年8月8日)Apache Struts2 の脆弱性対策について(CVE-2017-5638)(S2-045)は HTTPプロトコルのContent-Typeヘッダーでリモートからコード実行ができる という問題です。どうして「Content-Typeヘッダー」でコード実行ができたのか?気になったので調べたメモです。 コード実行ができた理由は「国際化(翻訳)用のメッセージ処理メソッドが、プログラミング言語のようにパースして実行する仕様」であったことでした。気にしていないとこのパターンでリモートコード実行ができてしまうコードも在ると思います。 Struts2修正版(2.5.10.1)で変更された箇所 バージョン番号やテストプログラム除く変更箇所は以下の部分です。 --- a/core/src/main/java/org/apache/struts2/i
(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
(Last Updated On: 2018年8月13日)HMACの応用的な使い方をここ数本のブログで書いてきましたが、HMACの基本的な使い方を紹介していませんでした。リクエストパラメーターを安全に検証/バリデーションする方法を例に紹介します。unserialize()を安全に利用する利用例にもなります。 参考: HMACハッシュの使い方のまとめ HMACが考案された背景 HMACをAPIキーのバリデーションに使う方法を紹介する前に、何故HAMCが考案されたのか紹介します。 HMACはRFC 2104で標準化されています。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関数を利用し
(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
(Last Updated On: 2018年8月13日)より高度なCSRF対策 – URL/URI個別にバリデーションする方法でハッシュ(HMAC)を使えばデータベースを使わずに有効期限付きのURLを作れる、と紹介しました。今回は有効期限付きURL(URI)の作り方を紹介します。 ハッシュ値(鍵)の安全性 より高度なCSRF対策 – URI個別にバリデーションする方法のハッシュ関数の安全な使い方の紹介が不十分なところもあるので、このエントリでもう少し詳しく説明します。RFC 5869のHKDFのようなハッシュ関数は以下のように書けます。 <?php // RFC 5869のHKDFのようなハッシュ値を求める $prk =hash_hmac('sha256', 'some key', 'salt'); $hkdf_like_key = hash_hmac('sha256', $prk, '
(Last Updated On: 2018年8月13日)ハッシュ関数は色々な場面で利用できます。このエントリではハッシュ関数の使い方、特にリクエストにサインする方法として、データベースを使わずURI個別のCSRFトークンを生成しバリデーションする方法を紹介します。 論理的な背景 まず前提条件となる知識を整理し、なぜこのエントリのようなハッシュ関数の使い方をしているのか紹介します。 大別するとハッシュ関数には二種類あります。ハッシュ関数の種別を正しく区別することが重要です。 暗号学的なハッシュ関数 – SHA2など 暗号学的でないハッシュ関数 – CRCなど 暗号学的なハッシュ関数には次の特徴があります。 同一のハッシュ値であるのに、そっくりだが実は異なるというようなメッセージの作成が不可能であること ハッシュ値から、そのようなハッシュ値となるメッセージを得ることが(事実上)不可能であるこ
(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を自動的にシ
(Last Updated On: 2019年2月19日)ホワイトリストの考え方/作り方は難しくありません。しかし、間違えていることが少なくないようです。 GoogleがCSP(Content Security Policy – ホワイトリスト型のJavaScriptインジェクション対策)の利用状況を調べたところ以下のような結果が得られました。 we take a closer look at the practical benefits of adopting CSP and identify significant flaws in real-world deployments that result in bypasses in 94.72% of all distinct policies. なんと、約95%のCSP利用サイトがCSPの保護が無効になるような設定になっていた、として
(Last Updated On: 2018年8月13日)PHP 5.6.25/7.010以降で修正されたセッションデータインジェクション Fixed bug #72681 (PHP Session Data Injection Vulnerability). (CVE-2016-7125) の解説です。 この脆弱性を利用するとオブジェクトインジェクションが簡単に行えます。結構深刻な問題ですが、あまり話題にはなっていないように思います。 最初にこのエントリを書いた時にはレガシーコードの残骸を読み間違えて、幅広い影響があると勘違いしていました。現在のPHPでは値が設定されていないセッション変数は定義できないので、影響するケースは”セッション変数を制御できる状態”に限られます。このレガシーコードの残骸は必要ないので以下の修正をPHPのmasterブランチにコミットする予定です。 https:/
この関数は、URL リライト機構に新しい名前/値の組を追加します。 名前および値は、URL (GET パラメータとして) およびフォーム (hidden フィールドとして) で追加されます。これは、session.use_trans_sid で透過的 URL リライティングが有効になっている場合に セッション ID が渡される方法と同じです。 この関数の挙動は、php.ini パラメータ url_rewriter.tags および url_rewriter.hosts によって制御されます。 注意: もし出力バッファリングが有効になっていない場合、この関数を コールすると出力バッファリングが暗黙的に開始されます。 このマニュアルページはPHP 7.1の説明になっています。私がURL Rewriterのバグを修正し、仕様を拡張(url_rewriter.hosts設定、専用の出力バッファを追
(Last Updated On: 2018年12月14日)不完全なSQLインジェクション対策だけで、SQLインジェクション対策は万全、と誤解しているケースが少なくないです。 プリペアードクエリ/プレイスホルダを使ったSQLインジェクション対策でOK は誤りです。「とにかくプレイスホルダを使おう」では脆弱性は無くなりません。 簡単な証明:プリペアードクエリ”だけ”では、識別子(カラム/テーブル等)を使うソートクエリ、特定カラム抽出クエリを”原理的”に無害化できない。識別子のエスケープ/バリデーションが必須。(問題はコレだけはありません) 似たような間違いに「出力対策をするのがセキュリティ対策」だとする考え方があります。こういう考え方になる原因はセキュリティ設計や原則を理解していないことにあると思われます。 出力対策”のみ”のセキュリティはアンチプラクティス アンチプラクティスであっても正し
(Last Updated On: 2018年8月13日)PHPスクリプトを分析するツールをまとめたページの紹介です。 PHPのコードを分析して脆弱性を見つける為のツールから、PHPソースコードを整形するツール、PHPスクリプトの内容の分析をするツールなど色々あり、よくまとまっています。 https://github.com/exakat/php-static-analysis-tools ここに載っていない物でいつも利用している物に3v4l.orgがあります。PHPソースコード/スクリプトの解析ツールといっても良い物で、ちょっとしたコードをチェックするにはオススメです。簡単に機能を紹介します。 現在のリリース版からサポートが終了したPHP4まで含めた複数のPHP実行環境でPHPスクリプトを実行し結果を比較 複数のPHP実行環境でのスクリプト実行時間の比較 OPコードの表示(PHPバイトコ
(Last Updated On: 2018年8月18日)PHPのheader関数とheader_remove関数の注意点です。あまり使わないと思いますが、Set-Cookieヘッダーや他のヘッダーで注意しないと問題になります。普段はsetcookie関数でクッキーを設定していてたまたまheader関数でクッキーを設定した、という場合にheader関数とsetcookie関数の仕様の違いにより、思ってもいない結果になります。 header関数の仕様 header関数の仕様は以下の通りです。 void header ( string $string [, bool $replace = true [, int $http_response_code ]] ) header() は、生の HTTP ヘッダを送信するために使用されます。 HTTP ヘッダについての詳細な情報は » HTTP/1.
(Last Updated On: 2018年9月21日)このブログで利用しているセキュリティ関係のプラグインを紹介します。こういう情報はあまり公開しない方が良いのですが、本気の攻撃者の場合はプラグインファイルの存在を総当たりで検出すれば判ってしまいます。 プラグイン選定の基準 あまりブログのメンテナンスに時間を使いたくないので、出来るだけ手間を掛けずにメンテナンスできる物を選んでいます。条件として 利用者が多い(少なくとも数千程度は居る) 比較的評価が高い 更新が比較的頻繁に行われている(行われていた) を基準に選んでいます。このブログではWordPress本体だけでなく、プラグインも含めて自動更新しています。利用者が多い方が互換性に注意した更新を行っている、と考えられるので比較的利用者が多いプラグインの方が更新安全性が高いことを期待できるからです。 同じ機能を持つプラグインを多数比較/
次のページ
このページを最初にブックマークしてみませんか?
『yohgaki's blog』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く