出鱈目なシグニチャのhash_hkdf関数を安全に使う方法
ユーザーが間違った使い方をしないよう、PHP 7.1に追加されたhash_hkdf関数のシグニチャが出鱈目である件について書いておきます。使い方を間違えると脆弱な実装になるので注意してください。
ユーザーが間違った使い方をしないよう、PHP 7.1に追加されたhash_hkdf関数のシグニチャが出鱈目である件について書いておきます。使い方を間違えると脆弱な実装になるので注意してください。
PHPにはタイプヒントと呼ばれる引数/戻り値データ型指定機能があります。これは便利な機能ですが性能に影響を与えます。
追記: 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 Application Security Project)とはWebシステムのセキュリティ向上を目指す団体です。クレジットカード/デビットカード利用に必要なPCI DSS(Payment Card Industory Data Security Standard)標準に強い影響力を持っています。PCI DSS標準ではOWASPなどのセキュリティガイドを参照/実装するように求めています。
OWASP TOP 10はOWASPガイドプロジェクトの中で最も重要なプロジェクトです。今年はその新版が4年ぶりにこの夏公開予定です。この4月からRC版(PDF)が公開されています。
2017年度版OWASP TOP 10の修正点で、アプリケーション開発者にとって最も影響が大きい変更は
が追加された点です。これがWebセキュリティのルールを変える指針になります。(とは言っても、個人的にはこれと同じこと10年以上前から実施すべき、と勧めていますが) もっと読む
入力の種類には3種類以上の種類、名前、電話番号、住所など沢山の種類があります。しかし、見方によってはたった3種類しかありません。この区別ができる/できない、で大きな違いができてしまいます。
第五回 関西DB勉強会でお話しさせて頂いた SQLインジェクション対策 総”習”編 の公開用資料をSlideShareにアップロードしました。私のセッションを気に入って頂けた方が多かったようで何よりです。
関西DB勉強会、面白かったです。久々にお会いできた方もいました。超満員でもう少しで入りきれないほどでした。また参加できれば、と思っています。
PDFはこちらからダウンロードできます。
勉強会で使ったスライドは、面白おかしく柔らかい(?)スライドでした。あまり公開用には向いていません。実際に勉強会で使った資料が欲しい方はFacebookかメールで連絡してください。個別にお送りします。
取り敢えず言語とプログラミングの基礎を学習し終えて、これから本格的にソフトウェア開発をしよう、という場合に困るのが「セキュリティ」です。今回は簡単に、これから本格的に開発を行う、という方向けに知っておくべき事を紹介します。
初めてTeratailに回答した内容を多少まとめて加筆したモノになっています。
https://teratail.com/questions/74317
ブログにしたので、Tratailの回答は単純にこのエントリを参照するように修正するかも知れません。
Googleは暗号を積極的に使っていることが知られています。暗号を積極的に使う理由を紹介します。
「信頼境界線の中で暗号を使っても、内部に侵入を許した時点で終わり」なので、「暗号を使っても意味がない」と考えているかも知れません。「リスクの廃除」だけが、セキュリティ対策ではありません。「リスクの緩和」もセキュリティ対策です。暗号は侵入を許してしまった場合のリスク緩和に効果的です。
前のエントリでFirefox + NoScriptによる内部ネットワークを守る方法を簡単に紹介しました。本当はネットワークを分離(物理的またはVLAN)し、それぞれに安全に利用できるプロキシーサーバー(ローカルネットワークのリソースにアクセスさせない、など)を用意して利用する方が良い、のですがこれには”それなりのモノと手間”が必要です。
Firefox + NoScriptだけでもかなり効果があるので改めて紹介します。前回紹介したのは10年も前ですね :D
信頼境界線(Trust Boundary)と境界防御はITセキュリティに限らず、セキュリティ対策の基礎中の基礎です。基礎中の基礎かつ最も重要な概念ですが習わないことが多いです。これが原因で「正しいセキュリティ対策」(≒効率的なセキュリティ対策)ができていないケースが多数あります。残念ながら”セキュリティに詳しい”とされている人でも全く理解していないケースが散見されます。
このエントリでは主に、ソフトウェアセキュリティに於ける信頼境界線の概念と引き方(≒セキュリティ構造/設計)、ついて紹介します。かなり長いエントリになりましたがお付き合いください。
最近、HMACハッシュ(hash_hmac)の使い方を書いてきたのでまとめです。
プログラム・コードが正しく動作する為の必要条件と十分条件を考えたことがあるでしょうか?
プログラム・コードが正しく動作する為の必要条件と十分条件とは何でしょうか?
映画などでPINコードを一桁づつ解析してドアを開錠する、といったシーンがあると思います。こんなのは”映画の世界だけ”と思っている方も多いと思います。しかし、タイミング攻撃を利用すると”実際にこれと全く同じ方法”で鍵となる情報を解析できます。
タイミング攻撃とはサイドチャネル攻撃の一種で、鍵情報を比較的簡単に解析する方法です。PHP 5.6からはタイミング攻撃に脆弱でない比較方法を提供しています。
結論から書くと、秘密の文字列を比較する場合
if ($secret_str !== $user_input) { // ユーザー提供の秘密情報不一致 die('不正なアクセスです'); }
といった通常の文字列は比較は危険です。
if (!hash_equals($secret_st, $user_input)) { die('不正なアクセスです'); }
上記のようにhash_equals関数を利用しなければなりません。
ユーザーから整数値を受け取った時にその値が整数型の範囲内に収まるか、チェックしたいことがあります。
SQLの識別子(テーブル名やフィールド名)はプリペアードクエリではエスケープできません。最近の開発者はSQLの”パラメーター”には注意を払うようになったので、SQLパラメーターによるSQLインジェクションはかなり少くなってきました。
この結果、相対的にSQL識別子によるSQLインジェクション脆弱性の割合が増えています。実際、私がコード検査を行っているアプリケーションでも識別子が原因でSQLインジェクションに脆弱であるケースが半数くらいになっています。
出力対策はセキュアコーディングの基本の1つです。プリペアードクエリだけでSQLによるインジェクションは防げません。DBMSに限らず、他のシステム(ライブラリも含む。特に文字列をパースする正規表現、XML処理など)にデータを送信する場合、完全に無害化する必要があります。
Apache Struts2 の脆弱性対策について(CVE-2017-5638)(S2-045)は
という問題です。どうして「Content-Typeヘッダー」でコード実行ができたのか?気になったので調べたメモです。
コード実行ができた理由は「国際化(翻訳)用のメッセージ処理メソッドが、プログラミング言語のようにパースして実行する仕様」であったことでした。気にしていないとこのパターンでリモートコード実行ができてしまうコードも在ると思います。