Pharファイルを利用したコード実行 – POP攻撃
Pharファイルは複数のPHPスクリプトをアーカイブ＆パッケージ化して一つのファイルでアプリケーションとして実行する仕組みです。
PharファイルはPHPプログラムその物なのでこれを実行してしまうとPHPで実行できることは何でもできてしまいます。そもそもPharファイルはプログラムなので信頼できないPharファイルを実行したらやりたい放題なのに、なぜPharのデシリアライズがセキュリティ問題になるのか？解説します。
もっと読む特定の処理を行うデータを渡すURLの作り方
Webアプリケーションを作っているとデータの完全性と機密性を保ちつつ「特定の処理を行うデータを渡すURL」を作りたくなる場合があります。
例えば、特定のURLをクリックすると特定ユーザーの連絡先にユーザーを登録する、などです。
もっと読む入力バリデーションに「エスケープやフィルタリングが含まれる」とする驚くべき解説
標準的な入力バリデーションに「エスケープやフィルタリングが含まれる」とする驚くべき解説があります。そのような入力バリデーションを定義した標準的なセキュリティガイドライン／規格は見た事がありません。標準的な入力バリデーションでは何をすべし、とされているのか紹介します。
もっと読むデータ型とセキュアコーディング
このブログではどのように”データ型”の概念とセキュアコーディングが関連しているのか、Webサーバーアプリを主体に説明します。
セキュアコーディングの基本を理解している必要がありますが、難しくはないです。原則を知っているだけで十分です。セキュアコーディングの10原則は次の通りです。
- 第1 入力をバリデーションする
- 第2 コンパイラの警告に用心する
- 第3 セキュリティポリシーの為に構成／設計する
- 第4 簡易にする
- 第5 デフォルトで拒否する
- 第6 最小権限の原則を支持する
- 第7 他のシステムに送信するデータを無害化する
- 第8 縦深防御を実践する
- 第9 効果的な品質保証テクニックを利用する
- 第10 セキュアコーディング標準を採用する
１番目の原則「入力をバリデーションする」がデータ型と関連します。
もっと読むおかしなCWE-20の読み解き方（CWE-20入門）
徳丸さんが独自のCWE-20（≒入力バリデーション）解説を行っているので、CERT（1989年に米カーネギーメロン大学に設置された世界最古のコンピューターセキュリティ専門機関）が30年くらい前から提唱し、ISO 27000／NIST SP-800-171／PCI DSS等で要求されているCWE-20の解説を改めて書きます。
CWE-20（入力バリデーション）がなぜ重要なのか？それはCERT／MITRE／ISOが入力バリデーションをどのように解説しているかを見れば解ります。いずれも最も重要／一番最初の対策としています。（※ MITREはCWEを管理する組織で、CWEの本家と言える組織です）
徳丸さんのブログより前に、このブログでもCWE-20について以下のブログで既に書いています。CERT（≒米カーネギーメロン大学のコンピューターサイエンス学科）が提唱するセキュアコーディング／コンピューターサイエンスの基盤となる基礎概念の紹介では十分ではなかったかも知れません。
ソフトウェアに入力バリデーションは必要ない 〜 ただし条件付きで
「ソフトウェアには入力バリデーションは必要ない」そんな事がある訳けないだろう？！いつも言っている事と真逆でしょ？！と思うでしょう。
しかし、「入力バリデーションが必要ないソフトウェア（＝コード）」は沢山あります、条件付きですが。
もっと読む開発者必修の7PKとは？
7PKという用語を聞いた事がある開発者も多いと思います。7PKは業界標準のソフトウェアセキュリティ分類です。まだの方はこれを機会に是非覚えてください。CERT Top 10 Secure Coding Practicesと同じく開発者全員に必修の用語と概念と言えます。何故なら、CERT Top 10 Secure Coding Practicesも7PKも知らないのならISO 27000(ISMS)、NIST SP800-171に対応するアプリケーションは作れないからです。
※ 7PKやCERTセキュアコーディング原則を知らなくても、セキュアなソフトウェアを作ることも可能かも知れません。しかし、それはかなり遠回りになるでしょう。
もっと読むMITREがCWEを大幅更新 〜 セキュアコーディング対応を強化 〜
CWEはセキュアなソフトウェア開発を行う開発者にとっては欠かせない情報源です。2019年1月3日にCWE (Common Weakness Enumeration – 共通脆弱性タイプ） 3.2が公開されました。大幅更新と言える内容になっています。
この更新を一言で言うと「セキュアコーディング対応の強化」でしょう。
もっと読むIPAの「安全なウェブサイトの作り方」は安全な作り方のガイドではない
IPAは「安全なウェブサイトの作り方」とする資料を長年公開しています。しかし、これが、重大な誤りにより、全く安全ではないWebサイトの作り方なっています。
重大な誤りとは以下です。
コンピューターサイエンス／システムエンジニアリングの観点から考える情報セキュリティはISO 27000で標準としてまとめられています。GDPRなどの法制度やNIST SP800-171の義務化などISO 27000の重要性は高まるばかりです。ISO 27000は2000年から、入力バリデーションだけは具体的な対策を記述し、セキュアコーディング／セキュアプログラミングの導入を要求しています。
ISO 27000の基礎的要求事項を無視したセキュリティ対策で情報漏洩問題などが発生した場合、契約で定めた上限以上の損害賠償を課されるリスクが高くなります。法的な意味からも現在のIPAの「安全なWebサイトの作り方」は危険であると言えます。
※ 開発者が「入力バリデーションはしている」と思っている場合でも、穴だらけで脆弱／非効率で問題あり、である場合がほとんどです。MVCモデルのモデルでバリデーションしている！といった場合、ほぼ100％不十分なバリデーションしかしていません。そんなドイツ人開発者と議論した事もあります。
もっと読む正規表現をより安全に使う方法
正規表現は危険です。様々なリスクが正規表現にはあります。簡単に正規表現リスクとより安全に使う方法を紹介します。
もっと読むCWE-20は知られているか？ 〜 開発者必修のNo.1脆弱性のハズが知られていない 〜
CWE-20とは何か？と聞かれて即答できる開発者は多くないと思います。そもそもCWEとは何か？もあまり知られていないかも知れません。
実はCWE-20 不適切な入力バリデーション はソフトウェアセキュリティで最も重要な脆弱性とされています、CWEのみでなく情報セキュリティ標準的に情報セキュリティ関連法的にも。
※ CWE: Common Weakness Enumeration (共通脆弱性タイプ)
CWEは脆弱性識別子のCVEで有名なMITRE（米国でのIPAの様な組織）が管理するソフトウエア脆弱性パターンを列挙したドキュメント／データベースです。日本語名の通り、よくある共通のソフトウェア脆弱性を集めた物がCWEです。
もっと読むIPAは基礎的誤りを明示し、正しい原則を開発者に啓蒙すべき – その2
IPAは”旧セキュアプログラミング講座は更新しない”とWebサイトに記載していましたが、次のブログで「IPAは旧セキュアプログラミングガイドの基礎的誤りを明示し、正しい原則を開発者に啓蒙すべき」と指摘したところ修正されたので第二弾です。
※ 2018年3月に指摘し、少なくとも秋頃には修正されていました。因みに現在セキュアプログラミング講座はCERTのセキュアコーディング習慣（原則）に則った科学的／エンジニアリング的に妥当な解説になっています。
第一弾では「入力処理セキュリティ対策の解説が出力処理のセキュリティ対策の解説になっており、出鱈目である」と指摘しました。修正後のページは改善はされていますが、まだ入力処理と出力処理のセキュリティ対策とを一緒に説明している点はダメなままです。 入力対策と出力対策は実施する場所が異ります。分けて説明すべきでしょう。CERT Top 10 Secure Coding PracticesもCWE/SANS Top 25 Monster MitigationもOWASP Secure Coding Quick Reference Guideも分けています。全て1番目が入力対策でが、IPAの旧セキュアプログラミング講座では入力対策の重要性が理解らないでしょう。
”入力対策”の解説としていた項目が”出力対策”の解説になっていたモノを無理矢理”入力・注入対策”にした、といった事情もあると思います。
しかし、なぜCERTがセキュアコーディング原則の第一番目としている入力対策が独立した項目ではないのでしょうか？OWASP TOP 10:2017を策定する際に「ほぼ全てのWebアプリが十分な入力対策を行っていない」と指摘されています。この現状に異論はないと思います。入力対策の不備がWebアプリにとって大きなリスクとなっています。これは今に始まったことではなく、昔からですが。入力対策解説の不備は第三弾としてブログを書くかも知れません。
今回はSQLインジェクション対策の問題点を指摘します。
もっと読むコードで学ぶセキュアコーディング 〜 SQLインジェクション編
セキュアコーディング原則において、インジェクション対策の為に重要な原則は
- 原則1： 全ての入力をバリデーションする
- 原則７： 全ての出力を無害化する
の２つです。これらに、一般的なプログラミング原則であるフェイルファースト原則とフェイルセーフ原則、ゼロトラストを適用するとセキュアコーディングになります。
簡単なSQLインジェクション対策コードを使ってセキュアコーディングの概念を紹介します。
セキュアコーディング／セキュアプログラミングの原則と技術は国際情報セキュリティ標準（ISO 27000）でも要求される技術です。しかし、根本から誤ったセキュリティ対策の概念が長年啓蒙されています。GDPR対策にもISO 27000は重要です。日本に於てもISO 27000が要求する基礎的対策ができていない場合、法的リスクが非常に高いと言わざるを得ません。
もっと読む遅すぎるサニタイズではダメな例
PostgreSQL 11がリリースされました。このリリースでto_number()、to_char()、to_date()、to_timestamp()関数の仕様が変更されました。これらは名前の通り入力を変換する関数です。その際に
- サニタイズ – ダメな形式のデータを使える／安全なデータ形式に変換する
を行います。保存されるデータ形式は、保存可能な形に変換されます。しかし、これは十分ではないです。遅すぎるサニタイズがダメな例として紹介します。
※ エスケープやプリペアードクエリもサニタイズ（無害化）の一種です。
もっと読むリスク分析とリスク対応をしよう
情報セキュリティ対策 ≒ リスクの分析、対応と管理、としても構わないくらい情報セキュリティ対策にとってリスク分析は重要です。体系的にまとめられたセキュリティ対策ガイドラインなら、どれを見ても記載されています。
情報システムは「モノ」（物と人）、「ネットワーク」、「ソフトウェア」で出来ています。それぞれリスクを分析、対応、管理する必要があります。
当然、ソフトウェアのリスク分析も重要です。しかし、多くの場合は「脆弱性対策」という形でリスク分析をせずにいきなり対応する、といったショートカットが開発現場で日常的に行われています。目の前にある問題に直ぐ対応しなければならない！といった場合も多いので仕方ない側面もあります。
しかし、問題は開発工程の早い段階で対応すればするほど、少ないコストで対応できます。システム開発に関わる人なら誰でも認識している事です。できる限り早い段階で早く問題に対応する、は情報システム開発の要求仕様のみでなく、セキュリティ要求仕様にも当てはまります。
※ このブログの説明はWebシステムを前提にしています。STRIDE、DREAD、リスクマトリックスなどのリスク分析手法はISO 31000等を参照してください。このブログでは単純なアタックツリー形のリスク分析を紹介しています。
もっと読む