ゼロトラストをより細かく分解する
セキュリティを維持する為にはゼロトラスト、何も信頼しない所から始めて信頼できることを検証する、作業が必要です。ゼロトラストは信頼できるモノと信頼できないモノに分ける作業ですが、より細かく考える必要があります。
※ より細かく考える、とはいっても「細かい事だけ」では合成の誤謬にハマります。全体と詳細、両方をバランスよく「ゼロトラスト」することが大切です。
セキュリティを維持する為にはゼロトラスト、何も信頼しない所から始めて信頼できることを検証する、作業が必要です。ゼロトラストは信頼できるモノと信頼できないモノに分ける作業ですが、より細かく考える必要があります。
※ より細かく考える、とはいっても「細かい事だけ」では合成の誤謬にハマります。全体と詳細、両方をバランスよく「ゼロトラスト」することが大切です。
なぜセキュアなシステムが作れないのか?この問いは
なぜバグフリーのシステムが作れないのか?1
と同類の問いです。一定規模を超えると完全にバグ/問題がないシステムを作るのは非常に困難です。どのような状況でも正常に動作する完全にバグ/問題がないシステムは簡単には作れません。しかし、バグ/問題がないシステムが容易に作れないからといって「体系的な対策を行わない」のは賢明なアプローチではありません。
このエントリではよりセキュリティ問題が少くなるアプローチを紹介します。これはセキュリティ標準やガイドラインに記載されている考え方をまとめたモノです。
ポイントは
です。
ブログで紹介するのを忘れていました。PHP用の入力バリデーションモジュール validateを作りました。
https://github.com/yohgaki/validate-php
PHP開発MLでの議論用に作ったので、作りかけと言える状態ですが、一応動作し使えます。
関数名はvalidate()の方が良いのでは?という意見があったので、名前は変更する予定です。valid()にしていた理由は”validate”だとあまりに一般的過ぎて、同じ名前の関数を定義しているユーザーがいるだろう、と予想したからです。自分のアプリやライブラリには名前空間を使うべきなので、モジュール関数はvalidate()にします。
いろいろ意見があったのですが、やはり入力処理における入力バリデーションとロジック処理の混同がありました。
入力処理における「形式的バリデーション」とロジック処理における「論理的/仕様的バリデーション」は別処理とした方が、構造的に優れています。この理由はまたの機会に書きます。
Python 2.7.14が2017/9/16にリリースされました。Pythonの開発はバージョン3系に移行しており、2系はセキュリティ修正のみのリリースになっています。とは言ってもモジュールの変更を見るとバグフィックスやドキュメント修正も含まれているようです。
Python 2.7.14のリリースはソフトウェアセキュリティの基本を学ぶには良い題材になります。
Railsユーザーがソースコード検査やWebサイト診断を受ける前に真っ先に使った方が良いセキュリティ検査ツールがあまり使われていないように感じています。
Brakemanはかなり良くできたツールです。私は何年も前から補助的に使っています。
Fedora 26でVMware Workstation Pro 12を使うことは可能です。可能ですが、少し手間が必要です。
追記: 2017/12現在、Fedora 27 + VMwareWorkstaion Pro 14を利用しています。この組み合わせの場合、普通にインストールするだけで利用できます。
先日、Fedora 25から26にアップグレードしました。特に問題なく使えているのですが、Intel Graphics for Linuxが更新されていない事に気がつきました。Intel Graphics for Linuxを更新する方法の備忘録です。インストール方法もほぼ同じです。
全てのセキュリティ対策は緩和策だと考えるべきです。これは個々の対策が完全であるか検証することが容易ではないからです。例えば、SQLインジェクション1つとっても本当に完全であるか?検証することは容易ではありません。プログラムが本当に思っているように動作するのか?検証する研究は、まだまだ研究段階です。
しかし、容易ではないからといって諦める訳にもいきません。不完全であっても形式的な論理検証は容易にできます。
ITシステム開発者必修のセキュリティ概念 Top 10です。ここで紹介する概念はセキュリティ設計やセキュアコーディングを行う上で欠かせないモノばかりです。順序はその基礎知識性、重要性、分かり易さで付けています。
では開発者必修のセキュリティ概念 Top 10です。
※ 長くなったので短い版を作りました。ロング版はこちら
ITシステム開発者必修のセキュリティ概念 Top 10です。さっと考えたので変更するかも知れません。これらの考え方や概念を理解していないと、ITセキュリティ標準やガイドラインなどで要求されているセキュアプログラミング/セキュアコーディングを効率的かつ効果的に利用することはできないでしょう。
ここで紹介する概念はセキュリティ設計やセキュアコーディングを行う上で欠かせないモノばかりです。
順序はその基礎知識性、重要性、分かり易さで付けています。では開発者必修のセキュリティ概念 Top 10です。
参考:思いの外、長くなったのでショート版を作りました。
'SELECT '.pg_escape_idetifier($_GET['col']).' WHERE '.pg_escape_identifier('tbl').' ORDER BY '.pg_escape_idetifier($_GET['col'])
SQLクエリにはプリペアードクエリを使いましょう!と言われて久しいです。私もプリペアードクエリを積極的に使うべきだと考えています。
しかし、「プリペアードクエリだけを使っていれば良いので、エスケープは要らない」という意見には賛成できません。なぜ賛成できないのか?コードを見れば分かります。
何年か前に議論になった話題です。自分のエントリを検索して、たまたま見つけたのですが物がありました。
例えば、入力バリデーションなしで以下のようなクエリは絶対に安全に実行できません。
$result = pg_query_params('SELECT '.pg_escape_identifier($_GET['col]). ' FROM '.pg_escape_identifier($_GET['table']). ' WHERE id = $1', [$_GET['id']]);
こんなクエリをそのまま書く人は居ませんが、プリペアードクエリ”だけ”ではインジェクション対策にならない事はSQLを知っていれば学生でも理解ります。
特定カラムの抽出/ソート(これはエスケープでぼほOK)、テーブル指定をするクエリは当たり前に存在します。
広く使われているデータベースでもAPIが仕様として脆弱な物が長年放置されています。OracleやMS SQL Serverを利用している方ならよくご存知だと思います。
Slideshareで「ネットワークから学ぶソフトウェアセキュリティの基礎」を公開しました。
ネットワークの世界で”当たり前”のセキュリティアーキテクチャーですが、残念ながらソフトウェアの世界では”当たり前”ではありません。
必要なセキュリティ対策やアーキテクチャーは状況やニーズによって変わります。セキュリティについて様々な考え方を持つことは構わないのですが、基礎中の基礎は”適用しないとしても”普遍です。
ISO 27000(ISMS)をはじめ、セキュアコーディング/セキュアプログラミングを行いなさい、と推奨するセキュリティガイドラインが多くあります。2014年改訂のISO 27000に至っては、セキュアプログラミングが広く普及したのでセキュアプログラミングを行うとする記述に簡素化しています。1
しかし、広く使われているフレームワークでさえセキュアコーディング/セキュアプログラミングをサポートする機能が無かったり/不十分でだったり、現状は到底普及している、とは言えないです。辛うじて普及しているかも?と言えるのはセキュアコーディング/セキュアプログラミングでは枝葉末節にあたるコーディング技術(ああすべき/こうすべき)くらいではないでしょうか?
なぜセキュアコーディング/セキュアプログラミングが普及していないのか?考えられる理由を挙げます。
セキュアコーディング/セキュアプログラミングとは?という方は以下を参考にしてください。
セキュアコーディングで最も重要な部分を理解するのは簡単です。スライドを作ったので公開します。
出力対策だけのセキュリティ対策は”誤り”です。
確証バイアスのせいか、”セキュリティ専門家”を含め、この基本原理が理解できないケースが多いです。