カテゴリー: Security

shellスクリプト文字列のエスケープ

大抵のシェルスクリプトはセキュリティ対策を考慮する必要がないので与えられたパラメーターはそのまま利用されています。シェルスクリプトを利用して権限の無いユーザーが勝手なコマンドを実行できないようにするにはエスケープが必要になります。

  • setuid/setgidをしたシェルスクリプト
  • 信頼できない入力を処理するシェルスクリプト

この様な場合はエスケープ(やバリデーション)が必要になります。

もっと読む

常識?非常識?プログラムは1文字でも間違えると正しく動作しない

プログラムのコードを書く場合1文字でも間違えると致命的な問題になる事がよくあります。=< であるべき所を < で条件分岐すると困った事になります。何を当たり前の事を言っているのだ?と思うでしょう。プログラマには常識です。プログラマーは1文字も間違いがないコードを書くために懸命にコードを書いています。

しかし、プログラムでデータを処理する場合1文字でも正しく取り扱うことができないモノが含まれると正しく動作できない、これは常識でしょうか?それとも非常識でしょうか?プログラマは自分が書いたコードに正しく処理可能なデータであることを保証するコードに(データを検証するコードを記述)しているでしょうか?入力データの検証はアプリケーションでは必須ですが検証できているでしょうか?

もっと読む

出力時のフェイルセーフ対策が最も重要なセキュリティ対策であるはずがない

コンピューターサイエンス・システムエンジニアリングに基づくソフトウェアセキュリティ対策は論理的に構築されており問題ないです。しかし、一般に広まっているソフトウェアセキュリティ対策には出鱈目が普通にまかり通っています。

その最たる例はCWE-20の出鱈目な紹介や解釈です。

Terminology

The “input validation” term is extremely common, but it is used in many different ways. In some cases its usage can obscure the real underlying weakness or otherwise hide chaining and composite relationships.

Some people use “input validation” as a general term that covers many different neutralization techniques for ensuring that input is appropriate, such as filtering, canonicalization, and escaping. Others use the term in a more narrow context to simply mean “checking if an input conforms to expectations without changing it.” CWE uses this more narrow interpretation.

太字部分の訳

他の人々はより狭いコンテクストで”変更しなくても入力が期待に沿うモノかチェックすること”の意味で使用する。CWEはこの狭い意味の解釈を採用している。

このように現在の本家CWE-20の用語補足では「”変更しなくても入力が期待に沿うモノかチェックすること”の意味で使用」と明記されていますが、CWE-20にエスケープやフィルタリングが含まれる、とする驚くべき解説をする”セキュリティ専門家”が居たりします。(普通は「CWEはこの狭い意味の解釈を採用している」と注釈なくてもそれ以前に解説の文意で判る)

もっと読む

ユーザーや開発者はIPA・専門家の責任にしてWebアプリなどに”本物”のセキュアコーディングを適用する方がよい

非エンジニアのユーザーに現在のほぼ全てのWebサーバーは送信されてくるデータが妥当かどうか確認していない、と説明すると驚きます、「そんな仕組みでマトモに動くソフトウェアが作れるのか?」と。当然の疑問でしょう。

実際、コンピュータサイエンス・システムエンジニアリングの世界では一貫して入力データの妥当性検証を重要なセキュリティ対策として実装するように求めています。

現在のISO 27000ではセキュアプログラミング技術の採用を要求しています。セキュアプログラミングで最も重要な事は入力データバリデーションです。2013年にISO 27000が改定されるまで、入力データバリデーションだけは具体的な仕様が解説されていました。2013年の改定で普及したので「セキュアプログラミングを採用する」と簡易にされました。(ハンドブックではないJIS Q 27000:2014の冒頭の改定の経緯解説に書かれています)

もっと読む

JVNのCWE-20の解説が間違っている件について

以前から気になっては居たのですがJVNのCWE-20の解説ページが出鱈目です。用語の定義が間違っています。もう何年も前から修正されていません。Draftとは言え「セキュアコーディングの第一原則」(IPAは2017年からプログラミング原則としている)入力データバリデーション・入力妥当性チェックの用語定義が間違っているのは致命的な間違いです。

追記:指摘通りに修正されました

このブログ最後に記載の通り、メールにて誤りを指摘していました。最初のJVNへのメールから3週間かかりましたが指摘した通りに修正されました。

標準的な入力バリデーション(入力の妥当性チェックにはエスケープやフィルタリング、脆弱性を隠すという意味はありません。入力データが形式的に妥当であることを検証するのが入力データバリデーションです。これは70年代のFormal Verificationの頃からの定義です。

近年になって乱用/誤解/拡大解釈により間違った意味で使われている場合があるので注意が必要です。

もっと読む

Pharファイルを利用したコード実行 – POP攻撃

Pharファイルは複数のPHPスクリプトをアーカイブ&パッケージ化して一つのファイルでアプリケーションとして実行する仕組みです。

PharファイルはPHPプログラムその物なのでこれを実行してしまうとPHPで実行できることは何でもできてしまいます。そもそもPharファイルはプログラムなので信頼できないPharファイルを実行したらやりたい放題なのに、なぜPharのデシリアライズがセキュリティ問題になるのか?解説します。

もっと読む

JSONPathインジェクション

JSONPathはCSSのセレクタやXPathのクエリのような形でJSON形式のデータを選択/クエリする仕様です。最近のRDBMSはJSONPathクエリをサポートしているので、SQLインジェクション対策の一種として必要となる場合もあります。

JSONPathの説明はしないので仕様などはオンラインの評価環境で確認してください。

https://jsonpath.com/

JSONPathクエリは上記のような”意味を持つ文字”を使ってクエリを実行します。インジェクション攻撃は一文字でも意味がある文字があると攻撃される、と思って構わないです。JSONPathクエリもインジェクション攻撃が可能です。

もっと読む

おかしな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(7つの悪質な領域 – CWE-700として定義されている業界標準のソフトウェアセキュリティ分類)では「セキュリティ機能はソフトウェアセキュリティではない」としています。明白なのは「他のソフトウェアやデバイスのセキュリティ機能によるセキュリティ」です。7PKでは例としてHTTPSを挙げています。

HTTPSは必要なセキュリティ機能ですが、HTTPSの利用=ソフトウェアセキュリティ、ではありません。HTTPSを使って保護できる分野はありますが、HTTPSを使っても開発者が作っているソフトウェアのセキュリティを作る物ではないからです。

結局の所、他の”モノ”に頼らず開発者が作っているソフトウェアの中でセキュリティを作らないとソフトウェアは安全になりません。7PKの「セキュリティ機能はソフトウェアセキュリティではない」とは、「ソフトウェアセキュリティはそのソフトウェアを開発している開発者が実現する」ということです。

7PKソフトウェアセキュリティの基礎概念の一つと考えられています。 (CWE-700) セキュリティ機能を使うこと自体はセキュリティ対策になります。しかし、セキュリティ機能を使う=ソフトウェアセキュリティ対策、にはなりません。「セキュリティ機能を使う」は「必要なセキュリティ対策」のサブセット(一部、それも極一部)でしかないからです。「セキュリティ機能を使う」=「必要なセキュリティ対策」、こういった誤解が度々あるので7PKでは「セキュリティ機能」の解説として態々明示していると思われます。一言でいうなら「ソフトウェアセキュリティは”その”ソフトウェアを作っている開発者の責任に於て作るモノ」です。「◯◯、△△、を使えばOKではない」です。

もっと読む

欧州の個人データ移転規制が日本は対象外となる件について

2019/1/22の日経の記事で「欧州の個人データ移転規制、日本は対象外 枠組み23日発効」と報道されました。

一部に誤解を招きかねない解説が見られます。「欧州の個人データ移転規制」が「日本は対象外」となるのですが、これは利便性が上るだけで日本企業に高額なGDPR制裁金が課されなくなる訳ではありません。移転規制がなくなり便利になりますが、制裁金が課されるリスクは高くなります。

もっと読む

危険なコードを書くメカニズム

世の中のソフトウェアには危険なコードが埋もれています。これがセキュリティ問題の原因になっています。なぜ危険なアプリケーションが書かれるのか?その仕組みを理解すると、対策が可能です。

もっと読む

リスク分析とリスク対応をしよう

情報セキュリティ対策 ≒ リスクの分析、対応と管理、としても構わないくらい情報セキュリティ対策にとってリスク分析は重要です。体系的にまとめられたセキュリティ対策ガイドラインなら、どれを見ても記載されています。

情報システムは「モノ」(物と人)、「ネットワーク」、「ソフトウェア」で出来ています。それぞれリスクを分析、対応、管理する必要があります。

当然、ソフトウェアのリスク分析も重要です。しかし、多くの場合は「脆弱性対策」という形でリスク分析をせずにいきなり対応する、といったショートカットが開発現場で日常的に行われています。目の前にある問題に直ぐ対応しなければならない!といった場合も多いので仕方ない側面もあります。

しかし、問題は開発工程の早い段階で対応すればするほど、少ないコストで対応できます。システム開発に関わる人なら誰でも認識している事です。できる限り早い段階で早く問題に対応する、は情報システム開発の要求仕様のみでなく、セキュリティ要求仕様にも当てはまります。

※ このブログの説明はWebシステムを前提にしています。STRIDE、DREAD、リスクマトリックスなどのリスク分析手法はISO 31000等を参照してください。このブログでは単純なアタックツリー形のリスク分析を紹介しています。

もっと読む

究極のセキュリティ要求事項とは?

前のブログでリスク分析について書きました。リスク分析方法を書く前にセキュリティ要求について書きます。ISO 27000では6つのセキュリティ要素が情報セキュリティに必要であるとしています。

  • Confidentiality – 機密性
  • Integrity – 完全性
  • Availability – 可用性
  • Reliability – 信頼性
  • Authenticity – 真正性
  • Non-repudiation – 否認防止 (Accountability – 責任追跡性)

これらが基礎的な情報セキュリティの要求事項になります。以上です。

※ 2014年の改訂でセキュリティのCIAに信頼性、真正性、否認防止を加えたモノが情報セキュリティに必要な要素と定義されています。ISO 13335(古い情報セキュリティ標準)で定義していた要素に戻った形になりました。

これで終わってしまうと何の事なのか?究極の要求事項とは何なのか?となると思います。もう少し説明します。究極の要求事項を知って適用するだけ、でも大きな違いが生まれると思います。

もっと読む

無視されているリスク分析

炎上プロジェクトの主な原因の1つに、システム要求定義が不明確であること、があります。何を作ったらよいのか、よく分らない状態で作って上手く行くのを願うのは、サイコロを振るのと変りありません。

これと同じことが情報セキュリティ対策でも起きています。

致命的な脆弱性が残っているシステムの主たる原因の1つに、セキュリティ要求定義が不明確、ならまだよいのですがセキュリティ要求定義なし、であることが少なくない数あります。IoTやスマートカーのセキュリティを見れば明らかです。セキュリティ要求定義が不明確か無い状態で作った、としか思えない事例が数えきれません。

漏れのないセキュリティ要求定義には漏れのないリスク分析が必要です。

  • ◯◯対策として△△を実施する

といったセキュリティ仕様をセキュリティ要求だと勘違いしているケースも数えきれません。

システム要求定義がないプロジェクトが簡単に炎上するように、セキュリティ要求定義がないシステムも簡単に無視することが不可能な脆弱性だらけのシステムになります。

特にソフトウェアの分野では「リスク分析」が不十分過ぎる、さらには全く無い、システムで溢れています。これでは十分な安全性を効率良く達成することは不可能です。

続きを読む