IPAは基礎的誤りを明示し、正しい原則を開発者に啓蒙すべき – その2

 IPAは”旧セキュアプログラミング講座は更新しない”とWebサイトに記載していましたが、次のブログで「IPAは旧セキュアプログラミングガイドの基礎的誤りを明示し、正しい原則を開発者に啓蒙すべき」と指摘したところ修正されたので第二弾です。

※ 2018年3月に指摘し、少なくとも秋頃には修正されていました。因みに現在セキュアプログラミング講座はCERTのセキュアコーディング習慣(原則)に則った科学的/エンジニアリング的に妥当な解説になっています。

 第一弾では「入力処理セキュリティ対策の解説が出力処理のセキュリティ対策の解説になっており、出鱈目である」と指摘しました。修正後のページは改善はされていますが、まだ入力処理と出力処理のセキュリティ対策とを一緒に説明している点はダメなままです。  入力対策と出力対策は実施する場所が異ります。分けて説明すべきでしょう。CERT Top 10 Secure Coding PracticesもCWE/SANS Top 25 Monster MitigationもOWASP Secure Coding Quick Reference Guideも分けています。全て1番目が入力対策でが、IPAの旧セキュアプログラミング講座では入力対策の重要性が理解らないでしょう。

入力対策”の解説としていた項目が”出力対策”の解説になっていたモノを無理矢理”入力・注入対策”にした、といった事情もあると思います。

しかし、なぜCERTがセキュアコーディング原則の第一番目としている入力対策が独立した項目ではないのでしょうか?OWASP TOP 10:2017を策定する際に「ほぼ全てのWebアプリが十分な入力対策を行っていない」と指摘されています。この現状に異論はないと思います。入力対策の不備がWebアプリにとって大きなリスクとなっています。これは今に始まったことではなく、昔からですが。入力対策解説の不備は第三弾としてブログを書くかも知れません。

今回はSQLインジェクション対策の問題点を指摘します。

“IPAは基礎的誤りを明示し、正しい原則を開発者に啓蒙すべき – その2” の続きを読む

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

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

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

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

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

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

“コードで学ぶセキュアコーディング 〜 SQLインジェクション編” の続きを読む

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

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

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

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

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

“遅すぎるサニタイズではダメな例” の続きを読む

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

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

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

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

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

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

“リスク分析とリスク対応をしよう” の続きを読む

Railsのリモートコード実行脆弱性、今昔

去年、今年とStruts2、Drupalのリモートコード実行脆弱性が問題になりました。記憶に新しい方も多いと思います。Railsにもリモートコード実行脆弱性が複数レポートされており、Railsユーザーであればよくご存知だと思います。

ざっと思い付く昔の脆弱性から最近の脆弱性まで簡単にまとめてみます。

“Railsのリモートコード実行脆弱性、今昔” の続きを読む

ITセキュリティ対策の構造化

ITセキュリティ対策の概念で最も足りていないモノは「構造化」ではないでしょうか?

システム開発者は常に「システムの構造化」を考えています。構造化プログラミング、オブジェクト指向設計、DoA、DDDなど「システムの構造化」には様々な構造が考えられています。

何故か「セキュリティの構造化」を十分考えていないのが現状です。その結果、「”基本構造が無い”場当たり的セキュリティ対策」に終始しています。

“ITセキュリティ対策の構造化” の続きを読む

入力データのバリデーションを簡単に 〜 Validate for PHP 0.7.0

基本的にWebアプリへの入力データは全てバリデーションする必要があります。具体的には以下のような構造でバリデーションが必要です。

Webアプリへの入力データの種類は大抵の場合、数百程度です。Validate for PHPはこれらの入力仕様を定義すれば、アプリケーション内で繰り返し同じ入力仕様をバリデーションできるように作られています。

Validate for PHPのスクリプト版をPre Alphaとしてリリースします。このブログのGitHubリポジトリのリンクは0.7.0ブランチに向いています。開発版はmasterブランチを参照してください。

“入力データのバリデーションを簡単に 〜 Validate for PHP 0.7.0” の続きを読む

それは”ただのバグ”なのか?それとも?

ソフトウェアにバグがあった場合、そのバグは”ただのバグ”で”単純に意図しない余計な動作をする箇所を直す”、で万事OK!でしょうか?

ここでは”ただのバグ”とは”問題が起きた時に問題が起きた箇所を直せばOK”なバグとして話を進めます。

“それは”ただのバグ”なのか?それとも?” の続きを読む

なぜWebセキュリティはここまでダメなのか?

インターネット上に16億件の企業ユーザーのメールアドレスとパスワードが公開されている、とニュースになっています。ほとんどの漏洩元はこれらの企業ではなく、他の一般公開されているWebサービスなどのアカウント情報漏洩※だと考えられています。

この事例から、非常に多くのWebサービスが情報漏洩を伴うセキュリティ問題を抱えているにも関わらず、気がつくことさえも出来ていないという現状があると考えるべきでしょう。(もしくは気付いていても公開していない)

侵入されたことを検知/対応する技術の導入も重要ですが、ここではなぜWebセキュリティはここまでダメになっているのか?を考えます。

※ 情報漏洩にはベネッセのケースのように内部の人による持ち出しも含まれていますが、外部の攻撃者が盗んだ情報も少なくないと考えるべきでしょう。

“なぜWebセキュリティはここまでダメなのか?” の続きを読む

データフロー分析とセキュリティ

データフロー分析とはコールフローグラフ(CFG)を使ってプログラムを分析する手法です。ソフトウェアのセキュリティ対策にもデータフロー分析は広く利用されています。例えば、静的ソースコード検査ツールは静的(=プログラムを動作させず)にプログラム実行時のデータフローを分析し、問題を発見する手法です。

コールフローグラフ

データフロー分析の基礎知識はハーバード大学コンピューターサイエンス学科の講義資料(PDF)が参考になります。こちらを参考にしてください。英語の資料ですが容易な内容です。

“データフロー分析とセキュリティ” の続きを読む

ゼロトラストとフェイルファースト

今のプログラムに足りないモノでセキュリティ向上に最も役立つ考え方のトップ2つ挙げなさない、と言われたらどの概念/原則を挙げるでしょうか?

私なら

  • ゼロトラスト
  • フェイルファースト

を挙げます。

極論すると、この2つ知って実践するだけでセキュアなソフトウェアを作れるようになるからです。この2つだけでは十分ではないですが、これを知って、実践しているだけでも開発者は今のコードより段違いにセキュアなコードが自分で書けるようになります。

もう一つ追加するなら

  • 多層防御(縦深防御)

を加えます。これはゼロトラストとフェイルファーストから導き出せる概念です。ゼロトラストとフェイルファーストで検証を行うと自然と多層防御になります。多層防御はセキュリティ対策の基本ですが、特にソフトウェアでは実践されている、とは言えない状況です。

これら3つはとても有用な概念で単純明解な概念ですが、知られていなかったり、誤解されていたりすることが多い概念/原則と言えるかも知れません。

“ゼロトラストとフェイルファースト” の続きを読む

NHKのスマホセキュリティ対策と今のWebアプリセキュリティ対策は基本構造が同じ

NHKが紹介したスマホのセキュリティ対策には問題があると指摘がある、と少し話題になっていました。

ブログで指摘されているNHKが紹介した対策ページの問題点の概要は以下の通りです。

  • Androidの設定から「提供元不明のアプリ」のチェックボックスをオンにしてはならない、必ずオフにする、の説明が無かった。
  • セキュリティベンダー広報担当者の説明を長々と回りく引用し説明に終始し、インストールしないことが大事であるのに、インストールしてしまった場合の症状や攻撃手法を羅列した。
  • 「見覚えのないアプリは速やかに削除すること。そして、自分がどんなアカウントを利用していたかを確認し、パスワードを変更したり、企業に相談したりするなどしてほしい」などど、そもそもインストールしない、怪しいアプリをインストールできないようにする、の説明がなかった。

要するに著者は、最も根源的かつ基本的なセキュリティ対策である「検証もされていないダメなアプリを入れてはダメ」が抜けた上で、

▽セキュリティー対策ソフトを入れる。

などといった”遅すぎる事後対策”かつ”ベンダーの商売に利する対策”を啓蒙したことが問題である、との認識だと思います。

NHKが紹介した対策ページではスクリーンショット等も交えながら

▽アプリは公式アプリストアからのみダウンロードする。

としているのに、「提供元不明のアプリ」(Android 8ではアプリごとの「不明なアプリ」)のチェックボックスをオフにする、を説明しないのは何事だ!という事です。

確かにその通りだと思います。「提供元不明のアプリ」のチェックボックスは必ずオフにする、は一般スマホユーザーが何がなくてもいの一番にすべきセキュリティ対策でしょう。実際に「提供元不明のアプリ」インストールが原因で攻撃が多数成功しているのですから。

このスマホセキュリティ対策と同じようなことがソフトウェアセキュリティ対策で当たり前に行われている、と感じていました。手元の「危険なアプリの構造、安全なアプリの構造」(公開していません)の導入部分に追加したスライドを紹介します。

“NHKのスマホセキュリティ対策と今のWebアプリセキュリティ対策は基本構造が同じ” の続きを読む

ドイツ人と入力バリデーションについて議論した話

メールアドレスから恐らくドイツ人だと思われる開発者とWebアプリ(サーバー側)の入力バリデーションについて議論した内容を簡単に紹介します。

どこかでした議論と同じでデジャブー感ですが、これから書くような感じの内容でした。議論相手のドイツ人の言葉がくだけた感じに書いていますが、「自分の考え方は完璧、私の考え方はとんでもない非常識」と思っていたらしく、お世辞にも丁寧な書き方のメールではありませんでした。この為、くだけた感じで書いています。

とんでもない勘違いをしているのに自信満々の人は手に負えない、と感じる人が多いと思います。私の場合、こういう人でもどういう論理とポイントで議論すれば良いのか?参考になるので楽しんで議論しています。

“ドイツ人と入力バリデーションについて議論した話” の続きを読む

入力バリデーションが甘いソースコードの検査は本当に大変

入力バリデーションが甘いアプリケーションのソースコードの検査は大変です。何が大変なのか、簡単に紹介します。

ついでに入力バリデーションが甘いアプリケーションの脆弱性診断はかなり簡単でであることも簡単に紹介します。

“入力バリデーションが甘いソースコードの検査は本当に大変” の続きを読む

忘れられた入力処理と出力処理の責任

入力処理と出力処理はプログラムの基本処理です。当たり前の処理ですが、Webアプリケーションでは基本的な事が知られているようで知られてないと思います。

入力処理と出力処理の両方ともがデータに対する責任を持っています。データに対する責任といっても、その責任は異なります。このエントリはプログラムの基本機能、入力処理/ロジック処理/出力処理が持っている責任を紹介します。

脆弱性がないプログラムを作るには、コードからの視点、データからの視点、両方が必要です。ソフトウェアセキュリティの専門家は両方の視点からのセキュリティ対策を啓蒙しているのですが、上手く伝わっていないです。

このエントリはデータからの視点で見たデータセキュリティの話です。

“忘れられた入力処理と出力処理の責任” の続きを読む

入力バリデーションで許可した文字で発生するリスク

入力バリデーションでほぼ全てのインジェクションリスクを回避/防止できるケースは以前書いたブログで紹介しています。

今回は趣向を変えて、入力バリデーションで許可してしまった文字で発生するリスクをざっと紹介します。

“入力バリデーションで許可した文字で発生するリスク” の続きを読む

データのセキュリティ対策が無いセキュリティ対策?!

ソフトウェアのセキュリティ問題の多くは「ソフトウェアの誤作動」です。つまり、正しく動作するソフトウェアならセキュリティ問題の大半は発生しません。1

コンピュータープログラムが正しく動作するには「正しいコード」と「正しいデータ」の両方揃う事が必須条件です。これはプログラムの動作原理に基づく条件なので、誰にも変えることは出来ません。

“データのセキュリティ対策が無いセキュリティ対策?!” の続きを読む

RDBMSから学ぶデータセキュリティ

RDBMSはデータセキュリティを学ぶには良い題材です。RDBMSはできる限り正しいデータを保存する仕組みがあるからです。RDBMSからどのようにデータのセキュリティを保証するのか紹介します。

プログラムが正しく動作する為には

  • 正しいコードであること
  • 正しい(妥当な)データであること

絶対条件です。どちらが欠けてもプログラムは正しく動作しません。

SQLiteは手軽で良いのですが、組み込み型であるためデータセキュリティを学ぶには機能的に問題があります。SQLiteにはデータ型を保証する機能もデータの内容を検証する機能もありません。1

利用するRDBMSはPostgreSQLを用い、データセキュリティに関連性の強い機能のみを対象とします。

“RDBMSから学ぶデータセキュリティ” の続きを読む