セキュアコーディング／セキュアプログラミングが流行らない理由

8月 16, 2017 Computer, PHP Security, Programming, Secure Coding, Security
(Last Updated On: 2018年9月13日)

ISO 27000（ISMS）をはじめ、セキュアコーディング／セキュアプログラミングを行いなさい、と推奨するセキュリティガイドラインが多くあります。2014年改訂のISO 27000に至っては、セキュアプログラミングが広く普及したのでセキュアプログラミングを行うとする記述に簡素化しています。1

しかし、広く使われているフレームワークでさえセキュアコーディング／セキュアプログラミングをサポートする機能が無かったり／不十分でだったり、現状は到底普及している、とは言えないです。辛うじて普及しているかも？と言えるのはセキュアコーディング／セキュアプログラミングでは枝葉末節にあたるコーディング技術（ああすべき／こうすべき）くらいではないでしょうか？

なぜセキュアコーディング／セキュアプログラミングが普及していないのか？考えられる理由を挙げます。

セキュアコーディング／セキュアプログラミングとは？という方は以下を参考にしてください。

セキュアなアーキテクチャーが知られていない

アーキテクチャー（構造）はソフトウェア開発に於てとても重要です。構造の無いプログラムでは要求仕様通りの成果物を作ることは困難です。開発フレームワークにさえセキュアなアーキテクチャーのソフトウェア作成を支援する仕組みが全くない物も多くあるのが現状です。

CERTセキュアコーディング標準を採用してプログラムを書いても、セキュアなアーキテクチャーにはなりません。この為、CERTのCERT Top 10 Secure Coding Practicesでは「セキュアコーディング標準を採用」は最後の10番目とし、セキュアなアーキテクチャーになるようなプラクティスを推奨しています。

CERT Top 10 Secure Coding Practicesを実践すると、次のようなアーキテクチャーになります。

参考：

3種類の入力値しか存在しないことを知らない

この話をした時にある社長さんから「こんな事は知ってて当たり前でしょ！」と言われました。私もそう思います。しかし、セキュアなアーキテクチャーに必要な「”入力バリデーション”はできない」という人まで居たので説明しています。

かなり経験のあるRuby/Rails開発者の方やセキュリティに興味がある方などから「”入力バリデーション”はできない」と本気で議論を挑まれたことがあります。

3種類の入力値しかないことを、知らない方が少なからず居ると思われます。

参考：

Fail Fastの原則を知らない？

失敗するなら出来る限り早く失敗させる、はエラー処理の原則です。多くの開発者が入力ミスの処理で実践していると思います。知らないことは無いと思います。

入力ミスでさえFail Fast原則で対応しているのに、外部からの攻撃である可能性が高い不正な入力を出来る限り早く失敗させるコード（入力バリデーションを厳格に行っているコード）はあまり多くありません。

正しく処理できない仕様外の入力は、出来る限り早く、つまり入力処理で完全に廃除しなければなりません。しかし、セキュリティが必要なソフトウェアでもこうなっていない物がほとんどです。

これは次に紹介する理由が原因かも知れません。

参考：

セキュリティが重要でないプログラム／コードが存在する

ソフトウェアのセキュリティは重要ではありませんでした。重要なのは「とにかく動くこと」でした。おかしな入力で誤作動しても、おかしな入力をした方が悪い、という仕様が普通にありました。メールでお世話になっているSMTPは、送信者が簡単に偽装できました。現在でもセキュリティが重要でないソフトウェアでは「とにかく動く」を第一に作られている物が沢山あります。

開発者の周りには「セキュアコーディングでないコード／プログラムばかり」という状況で、要求仕様にセキュアなアーキテクチャの要求仕様もない、といった状態でセキュアな構造を持つコードは造られません。

これが負のサイクルを生み出していると考えられます。

この負のサイクルの作用として、経験が多いベテラン、比較的良いコードを書く開発者、であってもセキュアなアーキテクチャーのソフトウェアを見た事が無いため、経験則としてセキュアコーディングが”必要ない”、”効率的でない”（実際はセキュアなコードを効率的に書くためは必要）と、手近な情報による誤謬をしているケースが多数あるようです。

参考：

セキュリティ専門家の中にもセキュアなソフトウェアアーキテクチャーを知らなかった人達が居る

Fail Fastの原則は「コンピュータが正しく処理できる入力は限られる」という変えようがない事実から導き出された原則です。

Fail  Fastの原則はセキュアコーディング／セキュアプログラミングの最重要事項です。このためCERT Top 10 Secure Codingでは「入力バリデーション」を第一位のセキュリティ対策として薦めています。

しかし、セキュリティ専門家と言われ、実際にセキュリティサービスを提供している人達の中には

  • 入力バリデーションはできない
  • 入力バリデーションはセキュリティ対策ではない
  • 入力バリデーションはセキュリティ対策として重要ではない

と、誤った主張をしていた人達が少なからず居ました。

セキュリティ専門家と呼ばれている人達には、セキュアなソフトウェアアーキテクチャーを知らなかった人達が居ました。あきれた主張には

  • 入力バリデーションは中の脆弱性を隠す対策で、セキュリティ対策として採用すべきではない

といった物までありました。外部からブラックボックス検査（侵入検査など）を行っていたりWAF2を売っている場合、セキュアな構造のソフトウェアになると困るのは解りますが、このような”業者の論理”は通用しないです。3

入力バリデーションに対する誤解も酷かった上に、入力対策と出力対策が独立した対策で”両方とも実施する対策”である、という点の誤解も酷かったです。

ソフトウェアセキュリティの基礎の基礎が無いセキュリティでも役には立ちますが、効果的ではありません。

参考：

セキュリティ専門家がセキュアなアーキテクチャーを教えていない

IPAの「セキュアプログラミング講座」は2016年の終り頃に改訂されて、入力対策と出力対策を取り違えている、致命的間違いは無くなりました。しかし、CERTなどが推奨するセキュアなアーキテクチャーを持つソフトウェアが作れるような内容にはまだなっていません。

セキュアなソフトウェアのアーキテクチャーを知らないのか、知っていても教えないのか判りませんが、IPAを含めセキュリティ専門家によってセキュアコーディング／セキュアプログラミングの基礎が十分に啓蒙されている、とはとても言えない状態だと思います。

やっと2017年6月の改訂版で普通になりました。遅いですね。まだ、ほとんどの開発者は知らないのではないでしょうか？セキュアになるソフトウェアの構造の解説がないことが残念です。ソフトウェアセキュリティの専門家には当たり前でも、開発者、中にはセキュリティ専門家と言われる人にも普及しているとは言えません。

因みにIPAはISO 27000等の標準も推進する組織です。ISO27000では、制定当初の2000年4からセキュアプログラミングの基礎の基礎である入力バリデーションを要求しています。そのIPAがセキュアプログラミングの基礎、しかもソフトウェアセキュリティに対して即効性がある基礎を長年啓蒙しなかった状況には首をひねります。5 6

正しく動作するソフトウェアには作り方があります。問題を先送りする作り方では何時まで経っても安全なソフトウェアは作れません。

正しく動作するソフトウェアの作り方

世界観の違いが問題

セキュアコーディングの世界観（考え方や物の見方）と構造化プログラミングの世界観は大きな違いあります。

プログラミングの「世界観」

構造化プログラミングの場合、”部品”（機能）で設計します。”部品”の中に機能を閉じ込め（抽象化）します。セキュリティ対策も”部品”の中で行い抽象化するのが良い！という考え方になります。

セキュアコーディングにも同様の考え方がありますが、ソフトウェア全体からセキュリティ対策がどうすべきなのか？も考えます。これが構造化設計と異なる（追加される）部分があり、構造化設計＝最高！、と考えているとセキュアコーディングの考え方は要らない、となるのかも知れません。

構造化設計とセキュアコーディング設計の世界観は二者択一なのか？

他の理由

コンピューターサイエンスの基礎知識の有無も原因の１つだと思われます。

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

”形式的検証”と”組み合わせ爆発”から学ぶ入力バリデーション

参考：

    1. 古いISO 27000は具体的な入力バリデーション方法まで書いていた。 ↩
    1. Web Application Firewall ↩
    1. 外部から脆弱性を検査するブラックボックス検査がやり易い＝攻撃者が外部から攻撃できる箇所を探し易い、であることは自明です。攻撃しやすいソフトウェアアーキテクチャーの方が良い！というならネットワークファイアーウォールなどを使うべきではありません。ネットワーク内の脆弱性を隠す物なので。 ↩
    1. 元になったBS7799からいうと恐らく1995年からと思われます。 ↩
    1. 例えば、今年前半に流行ったStruts2の脆弱性攻撃もセキュアなアーキテクチャーであれば攻撃を防止できていた。 ↩
  1. 2017年6月改訂版だと普通になっていたので修正しました。 ↩

投稿者: yohgaki