フェイルファースト

Computer, Development, PHP Security, Secure Coding

マイクロサービスアーキテクチャーのSSRF問題とセキュアコーディング

12月 13, 2018 #セキュアコーディング, #ゼロトラスト, #フェイルファースト, #未検証入力投稿者 yohgaki

Webシステムアーキテクチャーとしてマイクロサービスを利用しているケースは随分増えていると思います。従来から一般的に見られるWebアプリの作り方をすると、マイクロサービスではSSRF問題が簡単に発生します。

2017年版OWASP TOP 10ではA10 Insufficient Logging and Monitoringを新しく追加しました。一言でいうと、「未検証入力」を残してしまうアプリは脆弱なアプリである、とするのがA10脆弱性です。マイクロサービスで発生するSSRF問題の主な原因は「未検証入力」です。

「未検証入力」は既存の非マイクロサービスアーキテクチャーのWebアプリでも問題でしたが、マイクロサービスアーキテクチャーの登場によって、「未検証入力」がより重大な脅威になってきたことに対応する意味もあります。マイクロサービスアーキテクチャーで未検証入力を渡してしまうと簡単にSSRF問題が発生します。

※SSRF – Server Side Request Forgery（サーバーによるリクエスト詐称）

Computer, PHP Security, Secure Coding

コードで学ぶセキュアコーディング – ファイルパスを安全に出力可能か？

12月 3, 2018 #インジェクション, #セキュアコーディング, #セキュアコーディング技術, #フェイルセーフ, #フェイルファースト, #出力対策, #未検証入力投稿者 yohgaki

セキュアなアーキテクチャーのソフトウェアの場合、

全ての入力データはバリデーション済み（またはバリデーション済みと信頼可能）であるため出力時にバリデーションを行うことに抵抗を感じる（≒ 省略したくなる）方も多いと思います。「同じ、ほぼ同じような処理を繰り返したくない」と感じるのは普通の開発者の感覚でしょう。

そこで「ファイルパスを安全に出力する方法」を考えてみます。

※ ここではUNIX系OSのファイルシステムを前提とします。安全なファイルパス出力からセキュアコーディングの考え方を紹介しています。

Computer, Database, Development, PHP Security, Programming, Secure Coding

コードで学ぶセキュアコーディング〜 SQLインジェクション編

11月 12, 2018 #SQLインジェクション, #セキュアコーディング, #セキュアコーディング技術, #フェイルセーフ, #フェイルファースト, #入力バリデーション, #出力対策, #未検証入力投稿者 yohgaki

セキュアコーディング原則において、インジェクション対策の為に重要な原則は

原則1：全ての入力をバリデーションする
原則７：全ての出力を無害化する

の２つです。これらに、一般的なプログラミング原則であるフェイルファースト原則とフェイルセーフ原則、ゼロトラストを適用するとセキュアコーディングになります。

簡単なSQLインジェクション対策コードを使ってセキュアコーディングの概念を紹介します。

セキュアコーディング／セキュアプログラミングの原則と技術は国際情報セキュリティ標準（ISO 27000）でも要求される技術です。しかし、根本から誤ったセキュリティ対策の概念が長年啓蒙されています。GDPR対策にもISO 27000は重要です。日本に於てもISO 27000が要求する基礎的対策ができていない場合、法的リスクが非常に高いと言わざるを得ません。

Computer, Database, Development, PHP Security, Programming, Secure Coding

遅すぎるサニタイズではダメな例

10月 26, 2018 #PostgreSQL, #セキュアコーディング論理, #セキュリティ構造, #フェイルファースト, #入力バリデーション, #出力対策, #未検証入力投稿者 yohgaki

PostgreSQL 11がリリースされました。このリリースでto_number()、to_char()、to_date()、to_timestamp()関数の仕様が変更されました。これらは名前の通り入力を変換する関数です。その際に

サニタイズ – ダメな形式のデータを使える／安全なデータ形式に変換する

を行います。保存されるデータ形式は、保存可能な形に変換されます。しかし、これは十分ではないです。遅すぎるサニタイズがダメな例として紹介します。

※ エスケープやプリペアードクエリもサニタイズ（無害化）の一種です。

Computer, Database, Development, PHP Security, Programming, Secure Coding, Security

リスク分析とリスク対応をしよう

10月 16, 2018 #セキュアコーディング, #セキュリティ標準, #ゼロトラスト, #フェイルセーフ, #フェイルファースト, #ベストプラクティス, #リスク分析, #リスク管理, #入力バリデーション, #出力対策, #未検証入力投稿者 yohgaki

情報セキュリティ対策 ≒ リスクの分析、対応と管理、としても構わないくらい情報セキュリティ対策にとってリスク分析は重要です。体系的にまとめられたセキュリティ対策ガイドラインなら、どれを見ても記載されています。

情報システムは「モノ」（物と人）、「ネットワーク」、「ソフトウェア」で出来ています。それぞれリスクを分析、対応、管理する必要があります。

当然、ソフトウェアのリスク分析も重要です。しかし、多くの場合は「脆弱性対策」という形でリスク分析をせずにいきなり対応する、といったショートカットが開発現場で日常的に行われています。目の前にある問題に直ぐ対応しなければならない！といった場合も多いので仕方ない側面もあります。

しかし、問題は開発工程の早い段階で対応すればするほど、少ないコストで対応できます。システム開発に関わる人なら誰でも認識している事です。できる限り早い段階で早く問題に対応する、は情報システム開発の要求仕様のみでなく、セキュリティ要求仕様にも当てはまります。

※ このブログの説明はWebシステムを前提にしています。STRIDE、DREAD、リスクマトリックスなどのリスク分析手法はISO 31000等を参照してください。このブログでは単純なアタックツリー形のリスク分析を紹介しています。

Computer, Development, PHP Security, Secure Coding, Security

究極のセキュリティ要求事項とは？

10月 14, 2018 #セキュリティ標準, #ゼロトラスト, #フェイルセーフ, #フェイルファースト, #ベストプラクティス, #リスク分析, #リスク管理, #未検証入力投稿者 yohgaki

前のブログでリスク分析について書きました。リスク分析方法を書く前にセキュリティ要求について書きます。ISO 27000では6つのセキュリティ要素が情報セキュリティに必要であるとしています。

Confidentiality – 機密性
Integrity – 完全性
Availability – 可用性
Reliability – 信頼性
Authenticity – 真正性
Non-repudiation – 否認防止 (Accountability – 責任追跡性）

これらが基礎的な情報セキュリティの要求事項になります。以上です。

※ 2014年の改訂でセキュリティのCIAに信頼性、真正性、否認防止を加えたモノが情報セキュリティに必要な要素と定義されています。ISO 13335（古い情報セキュリティ標準）で定義していた要素に戻った形になりました。

これで終わってしまうと何の事なのか？究極の要求事項とは何なのか？となると思います。もう少し説明します。究極の要求事項を知って適用するだけ、でも大きな違いが生まれると思います。

Computer, Development, PHP Security, Programming, Secure Coding, Security

無視されているリスク分析

10月 11, 2018 #ゼロトラスト, #フェイルセーフ, #フェイルファースト, #ベストプラクティス, #リスク分析, #未検証入力投稿者 yohgaki

炎上プロジェクトの主な原因の１つに、システム要求定義が不明確であること、があります。何を作ったらよいのか、よく分らない状態で作って上手く行くのを願うのは、サイコロを振るのと変りありません。

これと同じことが情報セキュリティ対策でも起きています。

致命的な脆弱性が残っているシステムの主たる原因の１つに、セキュリティ要求定義が不明確、ならまだよいのですがセキュリティ要求定義なし、であることが少なくない数あります。IoTやスマートカーのセキュリティを見れば明らかです。セキュリティ要求定義が不明確か無い状態で作った、としか思えない事例が数えきれません。

漏れのないセキュリティ要求定義には漏れのないリスク分析が必要です。