yohgaki's blog

カテゴリー: Development

  • 2017年版OWASP TOP 10

    追記： 8月現在では、OWASP TOP 10 2017はWAFのプロモーションになっている、OWASP Proactive Controlsの”全ての入力をバリデーションする”と重複している、などの点が議論になりRCはリジェクトされ11月にリリースを目指して調整中になっています。

    追記2：正式版が2017年12月にリリースされました。ここで紹介している脆弱性はA10（10番目の脆弱性）「不十分なログとモニタリング」として登録されました。WAFが必要であるかのような記載が削減されましたが、脆弱性の本質（入力検証しない＆対応しないアプリは脆弱なアプリ）は変わりありません。

     

    このテーマついては既にブログは書いています。このエントリでは追加でQ＆Aを記載しています。

    https://blog.ohgaki.net/2017-owasp-top-10-changes-web-security-rule

    元々はこのスライドは非公開にするつもりでしたが、公開可能な内容で公開することにしました。

    https://www.slideshare.net/yohgaki/2017owasp-top-10

    開発会社としてはどうすれば良いのか？と質問を頂いたので追記します。

    (さらに…)

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

    ユーザーが間違った使い方をしないよう、PHP 7.1に追加されたhash_hkdf関数のシグニチャが出鱈目である件について書いておきます。使い方を間違えると脆弱な実装になるので注意してください。

    (さらに…)

  • PHP：タイプヒントを使うと遅くなる

    PHPにはタイプヒントと呼ばれる引数／戻り値データ型指定機能があります。これは便利な機能ですが性能に影響を与えます。

    (さらに…)

  • 2017年度版 OWASP TOP 10 で変るWebセキュリティのルール

    追記： 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の修正点で、アプリケーション開発者にとって最も影響が大きい変更は

    • A7 Insufficient Attack Protection（不十分な攻撃防御）

    が追加された点です。これがWebセキュリティのルールを変える指針になります。（とは言っても、個人的にはこれと同じこと10年以上前から実施すべき、と勧めていますが） (さらに…)

  • 入力値の種類は３種類しかない

    入力の種類には3種類以上の種類、名前、電話番号、住所など沢山の種類があります。しかし、見方によってはたった3種類しかありません。この区別ができる／できない、で大きな違いができてしまいます。

    (さらに…)

  • SQLインジェクション対策 総”習”編 – 第五回関西DB勉強会

    第五回 関西DB勉強会でお話しさせて頂いた SQLインジェクション対策 総”習”編 の公開用資料をSlideShareにアップロードしました。私のセッションを気に入って頂けた方が多かったようで何よりです。

    関西DB勉強会、面白かったです。久々にお会いできた方もいました。超満員でもう少しで入りきれないほどでした。また参加できれば、と思っています。

    PDFはこちらからダウンロードできます。

    https://www.slideshare.net/yohgaki/sql-76168380

     

    勉強会で使ったスライドは、面白おかしく柔らかい（？）スライドでした。あまり公開用には向いていません。実際に勉強会で使った資料が欲しい方はFacebookかメールで連絡してください。個別にお送りします。

  • これから開発を始める場合のセキュリティ

    取り敢えず言語とプログラミングの基礎を学習し終えて、これから本格的にソフトウェア開発をしよう、という場合に困るのが「セキュリティ」です。今回は簡単に、これから本格的に開発を行う、という方向けに知っておくべき事を紹介します。

    初めてTeratailに回答した内容を多少まとめて加筆したモノになっています。

    https://teratail.com/questions/74317

    ブログにしたので、Tratailの回答は単純にこのエントリを参照するように修正するかも知れません。

    (さらに…)

  • 暗号を積極的に使う理由

    Googleは暗号を積極的に使っていることが知られています。暗号を積極的に使う理由を紹介します。

    「信頼境界線の中で暗号を使っても、内部に侵入を許した時点で終わり」なので、「暗号を使っても意味がない」と考えているかも知れません。「リスクの廃除」だけが、セキュリティ対策ではありません。「リスクの緩和」もセキュリティ対策です。暗号は侵入を許してしまった場合のリスク緩和に効果的です。

    (さらに…)

  • 簡単にインターネットから内部ネットワークを守る方法

    前のエントリでFirefox + NoScriptによる内部ネットワークを守る方法を簡単に紹介しました。本当はネットワークを分離（物理的またはVLAN）し、それぞれに安全に利用できるプロキシーサーバー（ローカルネットワークのリソースにアクセスさせない、など）を用意して利用する方が良い、のですがこれには”それなりのモノと手間”が必要です。

    Firefox + NoScriptだけでもかなり効果があるので改めて紹介します。前回紹介したのは10年も前ですね :D

    (さらに…)

  • 信頼境界線の引き方と防り方 – セキュリティの構造と設計

    信頼境界線（Trust Boundary）と境界防御はITセキュリティに限らず、セキュリティ対策の基礎中の基礎です。基礎中の基礎かつ最も重要な概念ですが習わないことが多いです。これが原因で「正しいセキュリティ対策」（≒効率的なセキュリティ対策）ができていないケースが多数あります。残念ながら”セキュリティに詳しい”とされている人でも全く理解していないケースが散見されます。

    このエントリでは主に、ソフトウェアセキュリティに於ける信頼境界線の概念と引き方（≒セキュリティ構造/設計）、ついて紹介します。かなり長いエントリになりましたがお付き合いください。

    (さらに…)

  • HMACハッシュの使い方のまとめ

    最近、HMACハッシュ（hash_hmac）の使い方を書いてきたのでまとめです。

    (さらに…)

  • プログラム・コードが正しく動作する為の必要条件と十分条件

    プログラム・コードが正しく動作する為の必要条件と十分条件を考えたことがあるでしょうか？

    プログラム・コードが正しく動作する為の必要条件と十分条件とは何でしょうか？

    (さらに…)

  • 文字列（ハッシュ）の安全な比較方法 – hash_equals

    映画などでPINコードを一桁づつ解析してドアを開錠する、といったシーンがあると思います。こんなのは”映画の世界だけ”と思っている方も多いと思います。しかし、タイミング攻撃を利用すると”実際にこれと全く同じ方法”で鍵となる情報を解析できます。

    タイミング攻撃とはサイドチャネル攻撃の一種で、鍵情報を比較的簡単に解析する方法です。PHP 5.6からはタイミング攻撃に脆弱でない比較方法を提供しています。

    結論から書くと、秘密の文字列を比較する場合

    if ($secret_str !== $user_input) {
  // ユーザー提供の秘密情報不一致
  die('不正なアクセスです');
}

    といった通常の文字列は比較は危険です。

    if (!hash_equals($secret_st, $user_input)) {
  die('不正なアクセスです');
}

    上記のようにhash_equals関数を利用しなければなりません。

    (さらに…)

  • PHPで整数オーバーフロー／アンダーフローをチェックする方法

    ユーザーから整数値を受け取った時にその値が整数型の範囲内に収まるか、チェックしたいことがあります。

    (さらに…)

  • SQL識別子のエスケープ

    SQLの識別子（テーブル名やフィールド名）はプリペアードクエリではエスケープできません。最近の開発者はSQLの”パラメーター”には注意を払うようになったので、SQLパラメーターによるSQLインジェクションはかなり少くなってきました。

    この結果、相対的にSQL識別子によるSQLインジェクション脆弱性の割合が増えています。実際、私がコード検査を行っているアプリケーションでも識別子が原因でSQLインジェクションに脆弱であるケースが半数くらいになっています。

    出力対策はセキュアコーディングの基本の１つです。プリペアードクエリだけでSQLによるインジェクションは防げません。DBMSに限らず、他のシステム（ライブラリも含む。特に文字列をパースする正規表現、XML処理など）にデータを送信する場合、完全に無害化する必要があります。

    参考： CERTトップ10セキュアコーディング習慣の7. 他のシステムに送信するデータを無害化する

    (さらに…)