Secure Coding – ページ 2

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

1月 21, 2019 #7PK, #セキュアコーディング概念, #セキュリティ標準投稿者 yohgaki

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つ（環境）を定義しています。

Development, PHP Security, Programming, Secure Coding

コードの共通化を原則とするのはアンチプラクティス〜現代のプログラミング原則

1月 11, 2019 #セキュアコーディング, #セキュアコーディング論理投稿者 yohgaki

同じ処理を行うコードの共通化は、基本的には、ベストプラクティスです。しかし、アンチプラクティスとなる場合もあります。

Development, PHP Security, Programming, Secure Coding

開発者必修の7PKとは？

1月 7, 2019 #7PK, #セキュアコーディング論理, #セキュリティ標準, #入力バリデーション投稿者 yohgaki

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

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

Development, PHP Security, Programming, Secure Coding

MITREがCWEを大幅更新〜セキュアコーディング対応を強化〜

1月 6, 2019 #セキュアコーディング技術, #セキュアコーディング論理, #セキュリティ標準, #入力バリデーション, #未検証入力投稿者 yohgaki

CWEはセキュアなソフトウェア開発を行う開発者にとっては欠かせない情報源です。2019年1月3日にCWE (Common Weakness Enumeration – 共通脆弱性タイプ） 3.2が公開されました。大幅更新と言える内容になっています。

この更新を一言で言うと「セキュアコーディング対応の強化」でしょう。

Computer, Development, PHP Security, Programming, Secure Coding

IPAの「安全なウェブサイトの作り方」は安全な作り方のガイドではない

12月 25, 2018 #セキュアコーディング, #入力バリデーション, #未検証入力投稿者 yohgaki

IPAは「安全なウェブサイトの作り方」とする資料を長年公開しています。しかし、これが、重大な誤りにより、全く安全ではないWebサイトの作り方なっています。

重大な誤りとは以下です。

CWE-20 – 出鱈目なデータを排除する検証（入力バリデーション）について一切記載がない

コンピューターサイエンス／システムエンジニアリングの観点から考える情報セキュリティはISO 27000で標準としてまとめられています。GDPRなどの法制度やNIST SP800-171の義務化などISO 27000の重要性は高まるばかりです。ISO 27000は2000年から、入力バリデーションだけは具体的な対策を記述し、セキュアコーディング／セキュアプログラミングの導入を要求しています。

ISO 27000の基礎的要求事項を無視したセキュリティ対策で情報漏洩問題などが発生した場合、契約で定めた上限以上の損害賠償を課されるリスクが高くなります。法的な意味からも現在のIPAの「安全なWebサイトの作り方」は危険であると言えます。

※ 開発者が「入力バリデーションはしている」と思っている場合でも、穴だらけで脆弱／非効率で問題あり、である場合がほとんどです。MVCモデルのモデルでバリデーションしている！といった場合、ほぼ100％不十分なバリデーションしかしていません。そんなドイツ人開発者と議論した事もあります。

Development, PHP Security, Programming, Secure Coding

エラーと例外とセキュアコーディング／セキュアプログラミング

12月 23, 2018 #エラー処理, #セキュアコーディング, #未検証入力投稿者 yohgaki

エラーと例外の使い方は異なります。エラーより例外が推奨されていますが、これはセキュアコーディング／セキュアプログラミングの考え方とも関連しています。この辺りを整理してみます。

PHP Security, Programming, Secure Coding

正規表現をより安全に使う方法

12月 23, 2018 #ReDoS, #セキュアコーディング, #入力バリデーション, #正規表現投稿者 yohgaki

正規表現は危険です。様々なリスクが正規表現にはあります。簡単に正規表現リスクとより安全に使う方法を紹介します。

Development, PHP Security, Programming, Secure Coding

CWE-20は知られているか？〜開発者必修のNo.1脆弱性のハズが知られていない〜

12月 21, 2018 #セキュアコーディング, #セキュリティ標準, #入力バリデーション, #未検証入力投稿者 yohgaki

CWE-20とは何か？と聞かれて即答できる開発者は多くないと思います。そもそもCWEとは何か？もあまり知られていないかも知れません。

実はCWE-20 不適切な入力バリデーション はソフトウェアセキュリティで最も重要な脆弱性とされています、CWEのみでなく情報セキュリティ標準的に情報セキュリティ関連法的にも。

※ CWE: Common Weakness Enumeration (共通脆弱性タイプ)

CWEは脆弱性識別子のCVEで有名なMITRE（米国でのIPAの様な組織）が管理するソフトウエア脆弱性パターンを列挙したドキュメント／データベースです。日本語名の通り、よくある共通のソフトウェア脆弱性を集めた物がCWEです。

Computer, Development, PHP Security, Secure Coding

マイクロサービスアーキテクチャーのSSRF問題とセキュアコーディング

12月 13, 2018 #セキュアコーディング, #ゼロトラスト, #フェイルファースト, #未検証入力投稿者 yohgaki

Webシステムアーキテクチャーとしてマイクロサービスを利用しているケースは随分増えていると思います。従来から一般的に見られるWebアプリの作り方をすると、マイクロサービスではSSRF問題が簡単に発生します。

2017年版OWASP TOP 10ではA10 Insufficient Logging and Monitoringを新しく追加しました。一言でいうと、「未検証入力」を残してしまうアプリは脆弱なアプリである、とするのがA10脆弱性です。マイクロサービスで発生するSSRF問題の主な原因は「未検証入力」です。

「未検証入力」は既存の非マイクロサービスアーキテクチャーのWebアプリでも問題でしたが、マイクロサービスアーキテクチャーの登場によって、「未検証入力」がより重大な脅威になってきたことに対応する意味もあります。マイクロサービスアーキテクチャーで未検証入力を渡してしまうと簡単にSSRF問題が発生します。

※SSRF – Server Side Request Forgery（サーバーによるリクエスト詐称）

Computer, Database, Development, PHP Security, Secure Coding

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

12月 12, 2018 #SQLインジェクション, #セキュアコーディング, #セキュリティ標準, #入力バリデーション, #出力対策投稿者 yohgaki

IPAは”旧セキュアプログラミング講座は更新しない”とWebサイトに記載していましたが、次のブログで「IPAは旧セキュアプログラミングガイドの基礎的誤りを明示し、正しい原則を開発者に啓蒙すべき」と指摘したところ修正されたので第二弾です。

※ 2018年3月に指摘し、少なくとも秋頃には修正されていました。因みに現在セキュアプログラミング講座はCERTのセキュアコーディング習慣（原則）に則った科学的／エンジニアリング的に妥当な解説になっています。

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

第一弾では「入力処理セキュリティ対策の解説が出力処理のセキュリティ対策の解説になっており、出鱈目である」と指摘しました。修正後のページは改善はされていますが、まだ入力処理と出力処理のセキュリティ対策とを一緒に説明している点はダメなままです。入力対策と出力対策は実施する場所が異ります。分けて説明すべきでしょう。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インジェクション対策の問題点を指摘します。

Computer, PHP Security, Secure Coding

コードで学ぶセキュアコーディング – ファイルパスを安全に出力可能か？

12月 3, 2018 #インジェクション, #セキュアコーディング, #セキュアコーディング技術, #フェイルセーフ, #フェイルファースト, #出力対策, #未検証入力投稿者 yohgaki

セキュアなアーキテクチャーのソフトウェアの場合、

全ての入力データはバリデーション済み（またはバリデーション済みと信頼可能）であるため出力時にバリデーションを行うことに抵抗を感じる（≒ 省略したくなる）方も多いと思います。「同じ、ほぼ同じような処理を繰り返したくない」と感じるのは普通の開発者の感覚でしょう。

そこで「ファイルパスを安全に出力する方法」を考えてみます。

※ ここではUNIX系OSのファイルシステムを前提とします。安全なファイルパス出力からセキュアコーディングの考え方を紹介しています。

Computer, Database, Development, PHP Security, Programming, Secure Coding

コードで学ぶセキュアコーディング〜 SQLインジェクション編

11月 12, 2018 #SQLインジェクション, #セキュアコーディング, #セキュアコーディング技術, #フェイルセーフ, #フェイルファースト, #入力バリデーション, #出力対策, #未検証入力投稿者 yohgaki

セキュアコーディング原則において、インジェクション対策の為に重要な原則は

原則1：全ての入力をバリデーションする
原則７：全ての出力を無害化する

の２つです。これらに、一般的なプログラミング原則であるフェイルファースト原則とフェイルセーフ原則、ゼロトラストを適用するとセキュアコーディングになります。

簡単なSQLインジェクション対策コードを使ってセキュアコーディングの概念を紹介します。

セキュアコーディング／セキュアプログラミングの原則と技術は国際情報セキュリティ標準（ISO 27000）でも要求される技術です。しかし、根本から誤ったセキュリティ対策の概念が長年啓蒙されています。GDPR対策にもISO 27000は重要です。日本に於てもISO 27000が要求する基礎的対策ができていない場合、法的リスクが非常に高いと言わざるを得ません。

Computer, Database, Development, PHP Security, Programming, Secure Coding