カテゴリー
Development PHP Security Programming Secure Coding

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

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

カテゴリー
PHP Security Programming Secure Coding

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

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

カテゴリー
Development PHP Security Programming Secure Coding

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

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

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

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

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

カテゴリー
Computer Development PHP Security Secure Coding

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

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

 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インジェクション対策の問題点を指摘します。

カテゴリー
Computer PHP Security Secure Coding

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

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

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

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

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

カテゴリー
Computer Database Development PHP Security Programming Secure Coding

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

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

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

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

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

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