yohgaki's blog

タグ: アンチプラクティス

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

    セキュアコーディングの第1原則は「入力をバリデーションする」です。セキュアコーディングの第1原則はソフトウェアセキュリティの一丁目一番地と言えるセキュリティ対策です。

    入力バリデーションを第一のセキュリティ対策としているガイドライン：

    セキュアプログラミング／セキュアコーディングを要求するセキュリティ認証：

    • ISMS – 国際情報セキュリティ標準 ISO 27000 の認証規格
    • PCI DSS – クレジットカード情報を取り扱う場合の認証規格

    90年代初めからコンピューターサイエンティストのセキュリティ専門家は「入力バリデーション」が重要であるとしてきました。「入力バリデーション」は論理的にセキュアな構造のソフトウェアを作る為に欠かせない必須の要素だからです。防御的プログラミングから数えると四半世紀を越える月日が経っています。

    しかし、残念ながらセキュアコーディングの第1原則の「入力バリデーション」は普及しているとは全く言えません。この状況には理由があります。

    この状況に責任があるIPAは、IPAのセキュアプログラミング講座 1に基礎的な誤りがあったことを明示し、開発者に与えた誤解が正されるよう、最大限の努力をすべきでしょう。

    IPAのあり得ないような基礎的誤りがどのような物だったか、ご覧ください。

    追記： IPAは問題のページを更新／削除したようです。

    (さらに…)

  • ベストプラクティスもどきのアンチプラクティス TOP 10

    ここ十数年で見聞きした、脆弱なアプリを作ってきたベストプラクティスもどきのアンチプラクティス、をリストアップしてみます。

    限定された条件ではベストプラクティスと言える物でも、一般化するとアンチプラクティスになる物は多いです。

    コード検査をしていると良く分るのですが、アンチプラクティスは強力な破壊力を持っています。ここに書いているアンチプラクティスを無くすだけでも、致命的な問題／脆弱なコードを多数無くすことができるでしょう。

    特徴として原理や原則、適切な構造に合致しない物がアンチプラクティスになっています。

    • 原理：コンピュータープログラムは妥当な入力でしか、正しく動作しない
    • 原則：Fail Fast原則、失敗するモノはできる限り早く失敗させる、が守られていない
    • 構造：セキュリティ対策では境界防御、それも最外周の防御、が欠かせないがアプリケーション境界の防御が不十分・不適切

    TOP 10と題しましたが、アンチプラクティスの順序と重要性（悪影響）にはあまり関連性はありません。

    (さらに…)

  • セキュリティの原理、原則、ベストプラクティス

    「セキュリティの」と付けていますが、どの分野でも共通することだと思います。

    何事でも論理的に何かのガイドライン／ルールを作る場合、まず変えることのできない

    • 原理 – 事物・事象が依拠する根本法則

    を見つけ、その原理から導き出される

    • 原則 – 多くの場合に共通に適用される基本的なきまり・法則

    を作り、さらに特定の条件下の具体的な事例として

    を作ります。原理、原則、ベストプラクティスを理解していないと様々な問題がおきます。これらの基本的関係は

    原理 ＞ 原則 ＞ ベストプラクティス

    です。しかし、適用範囲の広さは

    原理 ＜ 原則 ＜　ベストプラクティス

    です。例えば、ベストプラクティスは”例外的”に原則に反した方法が”最善の方法”となる場合も少なくないからです。よく混乱や誤解の元になりますが、条件を絞った場合（例外的なケース）のベストプラクティスも在ります。

    例外的なケース（一般的で無いモノ=例外的な物）をベストプラクティスにすることには異論もありますが、結構狭い条件でしかベストプラクティスにならないモノが”ベストプラクティス”と呼ばれていることは多いです。1

    (さらに…)

  • ソフトウェアはセキュリティの原理・原則から間違っている「入り口ノーガード設計」のままで良いのか？

    現在のWebアプリケーションのほとんどは「入り口対策」がない「入り口ノーガード設計」です。

    ※ アプリケーションの入力処理、つまりMVCアーキテクチャーならコントローラーレベルで「入り口対策」がない設計が「入り口ノーガード設計」です。

    このような設計になっているので、本来は自然数だけのハズのHTTPヘッダーのContent-Length（やContent-Type／Content-Disposition）にプログラムが書けてしまったStruts2 Webアプリにより国内ではクレジットカード情報が何十万件も盗まれる、米国では1億4千万件以上の信用情報が漏洩する、といった事件が発生しています。

    幸い、「入り口対策」がない「入り口ノーガード設計」でもこういった大規模インシデントになるような脆弱性の攻撃は多くありません。しかし、話題にならないだけで多数のインシデントが世界中で発生していると考えられます。

    先の事例はStruts2／フレームワークのセキュリティ問題、と捉えられていることが多いと思います。しかし、これは本質的にセキュリティ原則を無視した「入り口ノーガード設計」の問題です。

    コード検査していると「入り口対策」をしていて、本当に良かったですね！というケースに出会うことが少なくありません。

    2018年5月からEUでGDPRが施行されます。GDPR違反となると2000万ユーロまたは全世界売上の4％のどちらか高い方が罰金（組織によっては1000万ユーロまたは全世界売上の2％）となります。GDPRには様々な要件が要求されていますが、国際情報セキュリティ標準であるISO 27000で”普及している”とされた”セキュアプログラミング技術”の原則さえ採用しないシステムで個人情報漏洩が起きた場合の被害は、簡単に会社を潰すレベルの損害になる可能性があります。

    (さらに…)

  • 出力対策”のみ”のセキュリティはアンチプラクティス

    「しっかり出力対策”だけ”するのがセキュリティ対策のベストプラクティス」とする考え方1があります。しかし、これはベストプラクティスどころかアンチプラクティスです。

    アンチプラクティスをベストプラクティスと勘違いしている限り、満足のいくセキュリティ対策（＝リスク管理）は不可能です。セキュリティ対策は総合的なリスク対策です。「これ”だけ”やれば良い」とするセキュリティ対策は大抵アンチプラクティス2です。

    ※ 今まで出力対策”だけ”がセキュリティ対策だと勘違いしていた方には確証バイアスが働きやすいようです。論理的／構造的にどうすればリスクを効果的に削減できるのか？を考えると理解るはずです。

    (さらに…)

  • ホワイトリスト派とブラックリスト派 〜 セキュアコーディングが行われない理由

    セキュアコーディングの原則1は「信頼できない入力を全てバリデーションする」です。この原則は国際情報セキュリティ標準でも当たり前の要求事項となっています。しかし、残念ながら「信頼できない入力を全てバリデーションする」が正しく実装されているアプリケーションはほとんどありません。

    独自の定義や自分勝手なセキュアコーディング解釈をしているケースが散見されます。ここでいう「セキュアコーディング」とはCERTのセキュアコーディング、ISO 27000が要求しているセキュアプログラミングを指します。

    (さらに…)

  • 実は知られていない？リスク対策の原則？

    ISO 31000（リスクマネジメント標準規格）はa)からk)まで、11のリスク管理の原則を定めています。

    ITエンジニアであればISO 27000（情報セキュリティマネジメント標準規格）を一度は読んだことがあると思います。少なくとも名前くらいは知っていると思います。リスク管理の基礎／基本を理解していればISO 27000だけでも十分ですが、ちょっと自信がない、体系的には学んだ事がない方はISO 31000も参考にすると良いです。

    情報セキュリティマネジメントはリスクマネジメントの一分野です。一般論としてのリスク管理の基礎知識は役立ちます。

    リスク対策の原則が知られていない？ことも、間違ったセキュアコーディング理解の原因かもしれません。間違いだらけのセキュアコーディング解説も紹介します。

    (さらに…)

  • ソフトウェアセキュリティのアンチパターン

    アンチパターンを知ることにより失敗を防ぐ。これはデータベース設計やソフトウェア設計で多く利用されている手法です。今回はソフトウェアセキュリティのアンチパターンを紹介します。

    このエントリは不定期にメンテナンスするつもりです。

    (さらに…)

  • 本当にプリペアードクエリだけを使っていますか？

    'SELECT '.pg_escape_idetifier($_GET['col']).' WHERE '.pg_escape_identifier('tbl').' ORDER BY '.pg_escape_idetifier($_GET['col'])

    SQLクエリにはプリペアードクエリを使いましょう！と言われて久しいです。私もプリペアードクエリを積極的に使うべきだと考えています。

    • 多くの場合、速い
    • SQLパラメーターを分離して書くので「ついうっかり」が起こりにくい
      • 特に初心者は「ついうっかり」が多い

    しかし、「プリペアードクエリだけを使っていれば良いので、エスケープは要らない」という意見には賛成できません。なぜ賛成できないのか？コードを見れば分かります。

    何年か前に議論になった話題です。自分のエントリを検索して、たまたま見つけたのですが物がありました。

    例えば、入力バリデーションなしで以下のようなクエリは絶対に安全に実行できません。

    $result = pg_query_params('SELECT '.pg_escape_identifier($_GET['col]). ' FROM '.pg_escape_identifier($_GET['table']). ' WHERE id = $1', [$_GET['id']]);

    こんなクエリをそのまま書く人は居ませんが、プリペアードクエリ”だけ”ではインジェクション対策にならない事はSQLを知っていれば学生でも理解ります。

    特定カラムの抽出／ソート（これはエスケープでぼほOK）、テーブル指定をするクエリは当たり前に存在します。

    (さらに…)

  • DBMSの脆弱なAPI仕様は何時まで放置されるのか？

    広く使われているデータベースでもAPIが仕様として脆弱な物が長年放置されています。OracleやMS SQL Serverを利用している方ならよくご存知だと思います。

    (さらに…)

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

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

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

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

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

    (さらに…)

  • 「セキュアコーディング方法論再構築の試み」を再構築してみる

     

    セキュアコーディングに関して大きな誤解がある資料があったのでこのブログを書いています。

    一つ前のブログは二つ以上の議論を理解しながら読まなければならないので解りづらい、とご意見を頂いたので”「セキュアコーディング方法論再構築の試み」を再構築してみる”として書き直してみました。

    (さらに…)

  • セキュアコーディングを理解できていない例

    追記：解りづらい、とご指摘があったので「セキュアコーディング方法論再構築の試み」を再構築してみるとして書き直してみました。このエントリの方が詳しいですが、よろしければこちらもどうぞ。

    セキュリティの専門家と呼ばれる人であってもセキュアコーディング／セキュアプログラミングを正しく理解していない例は散見されます。今回はそのケースを紹介します。

    参考1：セキュアコーディングについて詳しくない場合、このブログを読む前にセキュアコーディング／セキュアプログラミングの歴史は理解しておた方が良いかも知れません。

    参考2：そもそも、原理的／論理的に入力対策を無視／軽視したセキュリティ対策は誤りです。

    参考3：前提知識として入力データには三種類しかなく、不正なデータはソフトウェアにとって百害あって一利無しのデータであることを知っている必要があります。

    (さらに…)

  • OWASPに対して失礼な誤解 – 入力バリデーションは重要なセキュリティ対策

    OWASPに対して大変失礼な誤解をしている意見を見かけたのでブログに書いておきます。

    https://www.slideshare.net/ockeghem/owasp-japan20120327

    OWASPは「入力バリデーション」とても重要な「セキュリティ対策」として考えていますが、OWASP的にはセキュリティ対策ではない、少なくとも重要なセキュリティ対策ではない、というとんでもない誤解はOWASPに対して大変失礼な誤解と言えます。

    (さらに…)

  • 「黒い」セキュリティだのみは捨て去る

    「黒い」セキュリティとはブラックリスト型セキュリティのことです。

    ブラックリスト型セキュリティとは「ブラックリスト型対策でセキュリティを維持しよう」とする概念です。セキュリティ対策では、ブラックリスト型対策はできる限り使わず、可能な限りホワイトリスト型対策を使う、が基本です。しかし、ブラックリスト型の「黒いセキュリティ」対策が理想的な対策である、と考えている人が少くないようです。

    「黒いセキュリティ」に頼ったITセキュリティは基本的に捨て去るべきです。

    (さらに…)