セキュリティソフトウェア ≠ ソフトウェアセキュリティ

CWE-700としても知られる7PK(7つの悪質な領域/王国)IEEE Explorerの論文解説では、「セキュリティ機能(Security features)」はソフトウェアセキュリティではない、としています。

Software security isn’t security software. All the magic crypto fairy dust in the world won’t make your code secure, but it’s also true that you can drop the ball when it comes to essential security features. 

ソフトウェアセキュリティはセキュリティソフトウェアではない。全ての魔法のような暗号などはあなたのソフトウェアを魔法の様に安全にはしない、不可欠なセキュリティ機能の場合では削除/省略することが不可能であることは事実だが。

例として暗号を例に「HTTPSがソフトウェアをセキュアにはしない」としています。これは暗号だけには留まりません。

※ 7PKとはソフトウェアセキュリティ全体を包括する7つの脆弱性分類を定義する論文です。実際には7つの領域+1つ(環境)を定義しています。

“セキュリティソフトウェア ≠ ソフトウェアセキュリティ” の続きを読む

開発者必修の7PKとは?

7PKという用語を聞いた事がある開発者も多いと思います。もし聞いた事が無い方はこれを機会に是非覚えてください。CERT Top 10 Secure Coding Practicesと同じく開発者全員に必修の用語と概念と言えるでしょう。何故なら、CERT Top 10 Secure Coding Practicesも7PKも知らないのならISO 27000(ISMS)、NIST SP800-171に対応するアプリケーションは作れないからです。

“開発者必修の7PKとは?” の続きを読む

MITREがCWEを大幅更新 〜 セキュアコーディング対応を強化 〜

CWEはセキュアなソフトウェア開発を行う開発者にとっては欠かせない情報源です。2019年1月3日にCWE (Common Weakness Enumeration – 共通脆弱性タイプ) 3.2が公開されました。大幅更新と言える内容になっています。

この更新を一言で言うと「セキュアコーディング対応の強化」でしょう。

“MITREがCWEを大幅更新 〜 セキュアコーディング対応を強化 〜” の続きを読む

IPAの「安全なウェブサイトの作り方」は安全な作り方のガイドではない

IPAは「安全なウェブサイトの作り方」とする資料を長年公開しています。しかし、これが、重大な誤りにより、全く安全ではないWebサイトの作り方なっています。

重大な誤りとは以下です。

コンピューターサイエンス/システムエンジニアリングの観点から考える情報セキュリティはISO 27000で標準としてまとめられています。GDPRなどの法制度やNIST SP800-171の義務化などISO 27000の重要性は高まるばかりです。ISO 27000は2000年から、入力バリデーションだけは具体的な対策を記述し、セキュアコーディング/セキュアプログラミングの導入を要求しています。

ISO 27000の基礎的要求事項を無視したセキュリティ対策で情報漏洩問題などが発生した場合、契約で定めた上限以上の損害賠償を課されるリスクが高くなります。法的な意味からも現在のIPAの「安全なWebサイトの作り方」は危険であると言えます。

※ 開発者が「入力バリデーションはしている」と思っている場合でも、穴だらけで脆弱/非効率で問題あり、である場合がほとんどです。MVCモデルのモデルでバリデーションしている!といった場合、ほぼ100%不十分なバリデーションしかしていません。そんなドイツ人開発者と議論した事もあります。

“IPAの「安全なウェブサイトの作り方」は安全な作り方のガイドではない” の続きを読む

CWE-20は知られているか? 〜 開発者必修のNo.1脆弱性のハズが知られていない 〜

CWE-20とは何か?と聞かれて即答できる開発者は多くないと思います。そもそもCWEとは何か?もあまり知られていないかも知れません。

実はCWE-20 不適切な入力バリデーション はソフトウェアセキュリティで最も重要な脆弱性とされています、CWEのみでなく情報セキュリティ標準的に情報セキュリティ関連法的にも。

※ CWE: Common Weakness Enumeration (共通脆弱性タイプ)

CWEは脆弱性識別子のCVEで有名なMITRE(米国でのIPAの様な組織)が管理するソフトウエア脆弱性パターンを列挙したドキュメント/データベースです。日本語名の通り、よくある共通のソフトウェア脆弱性を集めた物がCWEです。

“CWE-20は知られているか? 〜 開発者必修のNo.1脆弱性のハズが知られていない 〜” の続きを読む

PHP 7.3

PHP 7.3が今月(2018/12)リリース予定です。新機能や機能変更は小振りですが、結構多くの追加/変更があります。ソースコード中のUPGRADINGに変更点は記載されています。ここでは独断と偏見で選んだ重要度が高い追加/変更を紹介します。 ※ PHP 7.3.0 RC6時点のUPGRADINGから紹介します。

記載していない変更の方が多いです。詳しくはリリース版のUPGRADINGを参照してください。

“PHP 7.3” の続きを読む

コードで学ぶセキュアコーディング 〜 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等を参照してください。このブログでは単純なアタックツリー形のリスク分析を紹介しています。

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

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

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

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

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

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

  • ◯◯対策として△△を実施する

といったセキュリティ仕様をセキュリティ要求だと勘違いしているケースも数えきれません。

システム要求定義がないプロジェクトが簡単に炎上するように、セキュリティ要求定義がないシステムも簡単に無視することが不可能な脆弱性だらけのシステムになります。

特にソフトウェアの分野では「リスク分析」が不十分過ぎる、さらには全く無い、システムで溢れています。これでは十分な安全性を効率良く達成することは不可能です。

続きを読む

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

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

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

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

PHP用のCookieセッションセーブハンドラー

JWTが凄い使われ方をしているようなので、可能な限りマシなCookieベースのセッションセーブハンドラーを書きました。メリットは

  • サーバー側のリソース(DBやファイルなど)を使わないので簡単にスケールする

ことにあります。

しかし、Cookieの保存は大きく分けて3つの問題があります。

  1. ネットワークが不安定だとデータが失われる場合がある(ネットワーク接続の問題)
  2. ロックがないのでデータが失われる場合がある(サーバー側の問題)
  3. 更新のタイミングによりデータが失われる場合がある(クライアント側の問題)

※ この問題はこのCookieを利用したセーブハンドラの問題ではなく、クッキー等のクライアント側にセッションデータを持たせるセッション管理の仕組み全般に存在します。

このハンドラーはデータ改ざんを検出するようになっており、Cookieの問題により改ざん攻撃と誤検出する可能性があります。

1、2は一般に広く認知されている問題でしょう。この場合はほぼ攻撃と誤検出されないと思われます。攻撃ではないのに攻撃と誤検出するのはほぼ3のケースだと考えられます。壊れ方によっては3ケースでも攻撃とは検出せず、仕様として単純にクッキーをリセットする場合もあります。タイミングによるデータ損失が100%攻撃と誤検出されるのではありません。

調べたのはしばらく前になりますが、タイミングによって失われるケースも完全に無視してよい程度ではありませんでした。これはブラウザのクッキー保存の実装コードの問題と考えられます。初期のバージョンはこの問題に対する緩和対策をしたコードにしていました。今は対タンパー性を上げる為にほぼ完全にバリデーションするコードになっています。(詳しくはコメント欄を参照)

どちらも一長一短で何とも言えないです。更新タイミングによるデータ損失が、どのブラウザで起きるのか、どのような使い方をすると起きるのか、どの程度あるのか、分らないので攻撃と誤検出するケースがある場合には教えていただけると助かります。※

※ 現コードはHMACで使用するクッキーをバリデーションしているので、更新タイミングによるデータ損失があると攻撃と誤検出します。きっちり正しく動作するコード ≠ きっちり厳格にバリデーションするコード、となる数少ないタイプのコードになります。ブラウザがRDBMSのトランザクションのように保存すれば済む話ですが。

“PHP用のCookieセッションセーブハンドラー” の続きを読む

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セキュリティはここまでダメなのか?” の続きを読む