Webシステムアーキテクチャーとしてマイクロサービスを利用しているケースは随分増えていると思います。従来から一般的に見られるWebアプリの作り方をすると、マイクロサービスではSSRF問題が簡単に発生します。
2017年版OWASP TOP 10ではA10 Insufficient Logging and Monitoringを新しく追加しました。一言でいうと、「未検証入力」を残してしまうアプリは脆弱なアプリである、とするのがA10脆弱性です。マイクロサービスで発生するSSRF問題の主な原因は「未検証入力」です。
「未検証入力」は既存の非マイクロサービスアーキテクチャーのWebアプリでも問題でしたが、マイクロサービスアーキテクチャーの登場によって、「未検証入力」がより重大な脅威になってきたことに対応する意味もあります。マイクロサービスアーキテクチャーで未検証入力を渡してしまうと簡単にSSRF問題が発生します。
※SSRF – Server Side Request Forgery（サーバーによるリクエスト詐称）
(さらに…)全ての入力データはバリデーション済み（またはバリデーション済みと信頼可能）であるため出力時にバリデーションを行うことに抵抗を感じる（≒ 省略したくなる）方も多いと思います。「同じ、ほぼ同じような処理を繰り返したくない」と感じるのは普通の開発者の感覚でしょう。
そこで「ファイルパスを安全に出力する方法」を考えてみます。
※ ここではUNIX系OSのファイルシステムを前提とします。安全なファイルパス出力からセキュアコーディングの考え方を紹介しています。
(さらに…)セキュアコーディング原則において、インジェクション対策の為に重要な原則は
の２つです。これらに、一般的なプログラミング原則であるフェイルファースト原則とフェイルセーフ原則、ゼロトラストを適用するとセキュアコーディングになります。
簡単なSQLインジェクション対策コードを使ってセキュアコーディングの概念を紹介します。
セキュアコーディング／セキュアプログラミングの原則と技術は国際情報セキュリティ標準（ISO 27000）でも要求される技術です。しかし、根本から誤ったセキュリティ対策の概念が長年啓蒙されています。GDPR対策にもISO 27000は重要です。日本に於てもISO 27000が要求する基礎的対策ができていない場合、法的リスクが非常に高いと言わざるを得ません。
(さらに…)PostgreSQL 11がリリースされました。このリリースでto_number()、to_char()、to_date()、to_timestamp()関数の仕様が変更されました。これらは名前の通り入力を変換する関数です。その際に
を行います。保存されるデータ形式は、保存可能な形に変換されます。しかし、これは十分ではないです。遅すぎるサニタイズがダメな例として紹介します。
※ エスケープやプリペアードクエリもサニタイズ（無害化）の一種です。
(さらに…)情報セキュリティ対策 ≒ リスクの分析、対応と管理、としても構わないくらい情報セキュリティ対策にとってリスク分析は重要です。体系的にまとめられたセキュリティ対策ガイドラインなら、どれを見ても記載されています。
情報システムは「モノ」（物と人）、「ネットワーク」、「ソフトウェア」で出来ています。それぞれリスクを分析、対応、管理する必要があります。
当然、ソフトウェアのリスク分析も重要です。しかし、多くの場合は「脆弱性対策」という形でリスク分析をせずにいきなり対応する、といったショートカットが開発現場で日常的に行われています。目の前にある問題に直ぐ対応しなければならない！といった場合も多いので仕方ない側面もあります。
しかし、問題は開発工程の早い段階で対応すればするほど、少ないコストで対応できます。システム開発に関わる人なら誰でも認識している事です。できる限り早い段階で早く問題に対応する、は情報システム開発の要求仕様のみでなく、セキュリティ要求仕様にも当てはまります。
※ このブログの説明はWebシステムを前提にしています。STRIDE、DREAD、リスクマトリックスなどのリスク分析手法はISO 31000等を参照してください。このブログでは単純なアタックツリー形のリスク分析を紹介しています。
(さらに…)前のブログでリスク分析について書きました。リスク分析方法を書く前にセキュリティ要求について書きます。ISO 27000では6つのセキュリティ要素が情報セキュリティに必要であるとしています。
これらが基礎的な情報セキュリティの要求事項になります。以上です。
※ 2014年の改訂でセキュリティのCIAに信頼性、真正性、否認防止を加えたモノが情報セキュリティに必要な要素と定義されています。ISO 13335（古い情報セキュリティ標準）で定義していた要素に戻った形になりました。
これで終わってしまうと何の事なのか？究極の要求事項とは何なのか？となると思います。もう少し説明します。究極の要求事項を知って適用するだけ、でも大きな違いが生まれると思います。
(さらに…)炎上プロジェクトの主な原因の１つに、システム要求定義が不明確であること、があります。何を作ったらよいのか、よく分らない状態で作って上手く行くのを願うのは、サイコロを振るのと変りありません。
これと同じことが情報セキュリティ対策でも起きています。
致命的な脆弱性が残っているシステムの主たる原因の１つに、セキュリティ要求定義が不明確、ならまだよいのですがセキュリティ要求定義なし、であることが少なくない数あります。IoTやスマートカーのセキュリティを見れば明らかです。セキュリティ要求定義が不明確か無い状態で作った、としか思えない事例が数えきれません。
漏れのないセキュリティ要求定義には漏れのないリスク分析が必要です。
といったセキュリティ仕様をセキュリティ要求だと勘違いしているケースも数えきれません。
システム要求定義がないプロジェクトが簡単に炎上するように、セキュリティ要求定義がないシステムも簡単に無視することが不可能な脆弱性だらけのシステムになります。
特にソフトウェアの分野では「リスク分析」が不十分過ぎる、さらには全く無い、システムで溢れています。これでは十分な安全性を効率良く達成することは不可能です。
続きを読むソフトウェアにバグがあった場合、そのバグは”ただのバグ”で”単純に意図しない余計な動作をする箇所を直す”、で万事OK！でしょうか？
ここでは”ただのバグ”とは”問題が起きた時に問題が起きた箇所を直せばOK”なバグとして話を進めます。
(さらに…)インターネット上に16億件の企業ユーザーのメールアドレスとパスワードが公開されている、とニュースになっています。ほとんどの漏洩元はこれらの企業ではなく、他の一般公開されているWebサービスなどのアカウント情報漏洩※だと考えられています。
この事例から、非常に多くのWebサービスが情報漏洩を伴うセキュリティ問題を抱えているにも関わらず、気がつくことさえも出来ていないという現状があると考えるべきでしょう。（もしくは気付いていても公開していない）
侵入されたことを検知／対応する技術の導入も重要ですが、ここではなぜWebセキュリティはここまでダメになっているのか？を考えます。
※ 情報漏洩にはベネッセのケースのように内部の人による持ち出しも含まれていますが、外部の攻撃者が盗んだ情報も少なくないと考えるべきでしょう。
(さらに…)今のプログラムに足りないモノでセキュリティ向上に最も役立つ考え方のトップ2つ挙げなさない、と言われたらどの概念／原則を挙げるでしょうか？
私なら
を挙げます。
極論すると、この2つ知って実践するだけでセキュアなソフトウェアを作れるようになるからです。この2つだけでは十分ではないですが、これを知って、実践しているだけでも開発者は今のコードより段違いにセキュアなコードが自分で書けるようになります。
もう一つ追加するなら
を加えます。これはゼロトラストとフェイルファーストから導き出せる概念です。ゼロトラストとフェイルファーストで検証を行うと自然と多層防御になります。多層防御はセキュリティ対策の基本ですが、特にソフトウェアでは実践されている、とは言えない状況です。
これら3つはとても有用な概念で単純明解な概念ですが、知られていなかったり、誤解されていたりすることが多い概念／原則と言えるかも知れません。
(さらに…)セキュアコーディング／セキュアプログラミングはコンピューター動作の基礎的原理から構築されています。初めてプログラムが書かれた時から現在に至るまで、全てのプログラムは同じ基本構造を持っています。
基本原理／基本構造に合わないセキュリティ対策/構造では満足できるセキュリティ状態の達成は不可能です。残念ながら大半のWebアプリが原理に反する脆弱な構造を持っています。
IPAが出鱈目なセキュアプログラミングを啓蒙していた責任は大きいと言わざるを得ないでしょう。昨年、修正しましたが誤りを訂正すべく十分な啓蒙を行っているとは言えないように見えます。
(さらに…)
