なぜセキュリティ対策はリスクの増減として考えるのか?

ITセキュリティ標準ではセキュリティ対策(リスク対応)はリスクの増減に着目して対策を行います。(最初のリスクアセスメントが正しく実行されていれば、リスクの増減を見るだけで管理/対策できる)概念的な部分は理解しづらいようなので、なぜセキュリティ対策をリスクの増減として考えるのか解説します。

ここで紹介していることはリスク管理の基本的な概念です。リスク対策はITセキュリティ対策に対して上位互換、つまりより広い範囲のリスク/セキュリティ対策です。

“なぜセキュリティ対策はリスクの増減として考えるのか?” の続きを読む

セキュアプログラミング第一位の対策、入力バリデーションはセキュリティ対策ではない?!

セキュアコーディング/セキュアプログラミングにおける最も重要なセキュリティ対策は「入力バリデーション」です。国際標準ではセキュリティ対策か否かは「リスクの変化」によって決り、※多くのセキュリティ専門家が「入力バリデーションをNo1のセキュリティ対策である」と結論づけています。(※ 対策の目的が何か?などの主観に基く評価はセキュリティ対策か否か、を決める指標ではありません)

どういう論理なのかは全く理解できないのですが、これに異論を唱える方も居るようです。実際のセキュアコーディング/セキュアプログラミングのガイドラインなどがどうなっているのか?紹介します。

このブログを継続して読んでいる方にはただの繰り返しなので読み飛ばしてください。そもそもセキュアコーディング/セキュアプログラミングとは何か?は過去のブログをご覧ください。

“セキュアプログラミング第一位の対策、入力バリデーションはセキュリティ対策ではない?!” の続きを読む

セキュアプログラミングの7つ習慣

セキュアなプログラミングには基本的な考え方があります。それ守ることによりセキュアなプログラムを作ることができます。基本的な考え方を無視または意識しないでセキュアなプログラミングを目指しても遠回りだったり、漏れが生まれたりします。基本的な考え方を無視・意識しないでセキュアなプログラミングを行おうとしても無理があります。

ここで紹介するのは私の考えであり、どこかで標準化されている物ではありません。しかし、基礎からまとめると概ね同じような物になると思います。

“セキュアプログラミングの7つ習慣” の続きを読む

CERT Top 10 Secure Coding Practices

CERTは米カーネギーメロン大学に設置されたコンピュータセキュリティ対策を行う老舗の組織です。CERTが設立される前もセキュリティが無視されていたのではありませんが、CERT設立後と前ではコンピュータセキュリティ、特にソフトウェアセキュリティに対する考え方が大きく変わりました。詳しくはセキュアプログラミング(防御的プログラミング)の歴史をざっと振り返るを参照してください。

CERTはSecure Coding Standardsとして

を公開しています。その中でもセキュアコーディング(セキュアプログラミング/防御的プログラミング)で最も重要なトップ10をTop 10 Secure Coding Practicesとしてまとめています。

日本語訳が無いようなので資料として利用できるよう私訳しておきます。
(追記:IPAのセキュアコーディングガイドは入力対策が出鱈目でした。 2017年からやっとIPAがCERT Secure Coding Practicesをセキュアコーディングの”原則”として紹介するようになりました。CERT版では出力対策を7番目に記載しています。IPAは順序を変えて2番目にしています。トップ10の原則とする際に順序を入れ替えるのは混乱の元です。オリジナルの順序のままにすべきだと思います。順序を変えると外国人とコミュニケーションが取れなくなります。)

よく勘違いされているので書いておきます。入力対策と出力対策は”独立したセキュリティ対策”です。間違えないようにしましょう。

入力バリデーションが第1位の対策であるのは科学的論理的原理的な理由が根拠となっています。最も重要な対策ですが、よく誤解されています

参考:

“CERT Top 10 Secure Coding Practices” の続きを読む

セキュアプログラミング(防御的プログラミング)の歴史をざっと振り返る

キュアプログラミング(防御的プログラミング)の歴史をざっと振り返ってみたいと思います。セキュアプログラミングは防御的プログラミングとも言われるプログラミングの原則の1つ※です。古くからある概念ですが、誤解または理解されていない概念の1つではないでしょうか?

Defensive Programmingとして記載されています。

何故、一般に広く常識として理解されていないのか?その理由は防御的プログラミングの歴史にあるのかも知れません。

参考:

“セキュアプログラミング(防御的プログラミング)の歴史をざっと振り返る” の続きを読む

開発者は必修、CWE/SANS TOP 25の怪物的なセキュリティ対策

SANS TOP 25 の解説はもっと後で行うつもりでした。しかし、現在のアプリケーション開発者向け教育に対する疑念のエントリへの反響が大きいようなので書くことにしました。

やるべきセキュリティ対策には優先順位があります。効果が大きい対策から行うべきです。セキュリティ対策は全体的に行うべきものですが、最も効果的な対策を除いて対策を行うようでは全体的な対策など行えません。
“開発者は必修、CWE/SANS TOP 25の怪物的なセキュリティ対策” の続きを読む

そもそもエスケープとは何なのか?

まずエスケープ処理について全て書こう、ということでPHP Securityカテゴリで様々なエスケープ処理について書いてきました。しかし、「エスケープ処理とは何か?」を解説していなかったので解説します。

エスケープ処理は文字列処理の基本中の基本です。

「エスケープは要らない、知る必要もない」という意見を稀に聞きますが、プログラムに於ける文字列処理とその重要性を理解していないからでしょう。全ての開発者はエスケープ処理の必要性を理解し、確実かつ適切にエスケープできなければなりません。
“そもそもエスケープとは何なのか?” の続きを読む

エンジニア必須の概念 – 契約による設計と信頼境界線

少し設計よりの話を書くとそれに関連する話を書きたくなったので出力の話は後日書きます。

契約による設計(契約プログラミング)(Design by Contract – DbC)は優れた設計・プログラミング手法です。契約による設計と信頼境界線について解説します。
“エンジニア必須の概念 – 契約による設計と信頼境界線” の続きを読む

セッションのクッキーを設定する場合のベストプラクティス

HTTPセッションは通常クッキーを利用して行います。クッキーを利用したセッションの場合、お薦めする設定は以下の通りです。

  1. ドメイン名は指定しない
  2. パスはルート(/)を指定する
  3. セッション管理用のクッキーはセッションクッキー(有効期間0)にする
  4. httponly属性を付ける
  5. 可能な場合は必ずsecure属性をつける
  6. 複数アプリケーションを利用する場合はsession.nameまたはsession_name()でセッションクッキー名で指定する (アプリケーションの固有名デフォルトで設定し、設定項目として変更できるようにする)

“セッションのクッキーを設定する場合のベストプラクティス” の続きを読む