カテゴリー: Secure Coding

常識?非常識?プログラムは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年からプログラミング原則としている)入力データバリデーション・入力妥当性チェックの用語定義が間違っているのは致命的な間違いです。

もっと読む

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

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

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

もっと読む

CSSのエスケープ方法

プログラムからCSSファイルにデータを書き込む場合、エスケープしないと不正なCSSになってしまう場合があります。現在のブラウザはCSSでプログラムを実行する仕様が削除されているのでコード実行脆弱性の問題になりませんが、不正なCSSはセキュリティ問題(クリックジャック等)になる場合もあります。

HTML内のCSSの場合、エスケープしないとJavaScriptの実行を許してしまいます。HTMLエスケープでJavaScript実行は防げますが、不正なCSSのインジェクションを防ぐにはCSSエスケープが必要です。適切に処理しないとCSSキーロガーを仕込まれて情報を盗まれたりします。

もっと読む

JSONPathインジェクション

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

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

https://jsonpath.com/

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

もっと読む

データ型とセキュアコーディング

このブログではどのように”データ型”の概念とセキュアコーディングが関連しているのか、Webサーバーアプリを主体に説明します。

セキュアコーディングの基本を理解している必要がありますが、難しくはないです。原則を知っているだけで十分です。セキュアコーディングの10原則は次の通りです。

1番目の原則「入力をバリデーションする」がデータ型と関連します。

もっと読む

おかしな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ではない」です。

もっと読む

7PK – APIの乱用とは?

7PKとは「Seven pernicious kingdoms: a taxonomy of software security errors」の略でソフトウェアセキュリティ領域の分類の一つです。CWEのビューのCWE-700としても利用されています。CWE-700となっているので、ISO 27000などのセキュリティ標準で要求される「セキュアコーディング」の基礎知識として知っておくべき分類方法/概念です。

入力バリデーションの次に重要な領域である「APIの乱用/誤用」を紹介します。

※ 入力バリデーションが第一番目である理由は、入力データの妥当性が保証されていなとプログラムは絶対に正しく動作しないからです。不正な入力で動作しているように見えても、誤った出鱈目な結果を返しているだけです。プログラムが脆弱性なく正しく動作する為には入力バリデーションが欠かせません。

もっと読む

7PK – セキュリティソフトウェア ≠ ソフトウェアセキュリティ

CWE-700としても知られる7PK(7つの悪質な領域/王国)IEEE Explorerの論文解説では、「セキュリティ機能(Security features)」はソフトウェアセキュリティではない、としています。

Software security isn’t security software. All the magic crypto fairy dust in the world won’t make your code secure, but it’s also true that you can drop the ball when it comes to essential security features. 

ソフトウェアセキュリティはセキュリティソフトウェアではない。全ての魔法のような暗号などはあなたのソフトウェアを魔法の様に安全にはしない、不可欠なセキュリティ機能の場合では削除/省略することが不可能であることは事実だが。

暗号を例に「HTTPSがソフトウェアをセキュアにはしない」としています。これは暗号だけには留まりません。

※ 7PKとはソフトウェアセキュリティ全体を包括する7つの脆弱性分類を定義する論文です。実際には7つの領域+1つ(環境)を定義しています。

もっと読む

開発者必修の7PKとは?

7PKという用語を聞いた事がある開発者も多いと思います。7PKは業界標準のソフトウェアセキュリティ分類です。まだの方はこれを機会に是非覚えてください。CERT Top 10 Secure Coding Practicesと同じく開発者全員に必修の用語と概念と言えます。何故なら、CERT Top 10 Secure Coding Practicesも7PKも知らないのならISO 27000(ISMS)、NIST SP800-171に対応するアプリケーションは作れないからです。

※ 7PKやCERTセキュアコーディング原則を知らなくても、セキュアなソフトウェアを作ることも可能かも知れません。しかし、それはかなり遠回りになるでしょう。

もっと読む