カテゴリー: Programming

  • ソフトウェアセキュリティのアンチパターン

    アンチパターンを知ることにより失敗を防ぐ。これはデータベース設計やソフトウェア設計で多く利用されている手法です。今回はソフトウェアセキュリティのアンチパターンを紹介します。

    このエントリは不定期にメンテナンスするつもりです。

    (さらに…)

  • PHP用入力バリデーションモジュール – validate

    ブログで紹介するのを忘れていました。PHP用の入力バリデーションモジュール validateを作りました。

    https://github.com/yohgaki/validate-php

    PHP開発MLでの議論用に作ったので、作りかけと言える状態ですが、一応動作し使えます。

    関数名はvalidate()の方が良いのでは?という意見があったので、名前は変更する予定です。valid()にしていた理由は”validate”だとあまりに一般的過ぎて、同じ名前の関数を定義しているユーザーがいるだろう、と予想したからです。自分のアプリやライブラリには名前空間を使うべきなので、モジュール関数はvalidate()にします。

    いろいろ意見があったのですが、やはり入力処理における入力バリデーションとロジック処理の混同がありました。

    入力処理における「形式的バリデーション」とロジック処理における「論理的/仕様的バリデーション」は別処理とした方が、構造的に優れています。この理由はまたの機会に書きます。

     

  • Python 2.7.14から学ぶセキュリティの基本

    Python 2.7.14が2017/9/16にリリースされました。Pythonの開発はバージョン3系に移行しており、2系はセキュリティ修正のみのリリースになっています。とは言ってもモジュールの変更を見るとバグフィックスやドキュメント修正も含まれているようです。

    Python 2.7.14のリリースはソフトウェアセキュリティの基本を学ぶには良い題材になります。

    (さらに…)

  • Railsユーザーが真っ先にするべきセキュリティチェック – Brakeman

    Railsユーザーがソースコード検査やWebサイト診断を受ける前に真っ先に使った方が良いセキュリティ検査ツールがあまり使われていないように感じています。

    Brakemanはかなり良くできたツールです。私は何年も前から補助的に使っています。

    (さらに…)

  • セキュリティ対策が論理的に正しいか検証する方法

    全てのセキュリティ対策は緩和策だと考えるべきです。これは個々の対策が完全であるか検証することが容易ではないからです。例えば、SQLインジェクション1つとっても本当に完全であるか?検証することは容易ではありません。プログラムが本当に思っているように動作するのか?検証する研究は、まだまだ研究段階です。

    しかし、容易ではないからといって諦める訳にもいきません。不完全であっても形式的な論理検証は容易にできます。

    (さらに…)

  • 知っておくべきITセキュリティ概念Top 10 〜ショート版〜

    ITシステム開発者必修のセキュリティ概念 Top 10です。ここで紹介する概念はセキュリティ設計やセキュアコーディングを行う上で欠かせないモノばかりです。順序はその基礎知識性、重要性、分かり易さで付けています。

    では開発者必修のセキュリティ概念 Top 10です。

    ※ 長くなったので短い版を作りました。ロング版はこちら

    (さらに…)

  • 当たり前?非常識?開発者必修のセキュリティ概念 Top 10

    ITシステム開発者必修のセキュリティ概念 Top 10です。さっと考えたので変更するかも知れません。これらの考え方や概念を理解していないと、ITセキュリティ標準やガイドラインなどで要求されているセキュアプログラミング/セキュアコーディングを効率的かつ効果的に利用することはできないでしょう。

    ここで紹介する概念はセキュリティ設計やセキュアコーディングを行う上で欠かせないモノばかりです。

    順序はその基礎知識性、重要性、分かり易さで付けています。では開発者必修のセキュリティ概念 Top 10です。

    参考:思いの外、長くなったのでショート版を作りました。

    (さらに…)

  • 本当にプリペアードクエリだけを使っていますか?

    'SELECT '.pg_escape_idetifier($_GET['col']).' WHERE '.pg_escape_identifier('tbl').' ORDER BY '.pg_escape_idetifier($_GET['col'])
    

    SQLクエリにはプリペアードクエリを使いましょう!と言われて久しいです。私もプリペアードクエリを積極的に使うべきだと考えています。

    • 多くの場合、速い
    • SQLパラメーターを分離して書くので「ついうっかり」が起こりにくい
      • 特に初心者は「ついうっかり」が多い

    しかし、「プリペアードクエリだけを使っていれば良いので、エスケープは要らない」という意見には賛成できません。なぜ賛成できないのか?コードを見れば分かります。

    何年か前に議論になった話題です。自分のエントリを検索して、たまたま見つけたのですが物がありました。

    例えば、入力バリデーションなしで以下のようなクエリは絶対に安全に実行できません。

    $result = pg_query_params('SELECT '.pg_escape_identifier($_GET['col]). ' FROM '.pg_escape_identifier($_GET['table']). ' WHERE id = $1', [$_GET['id']]);

    こんなクエリをそのまま書く人は居ませんが、プリペアードクエリ”だけ”ではインジェクション対策にならない事はSQLを知っていれば学生でも理解ります。

    特定カラムの抽出/ソート(これはエスケープでぼほOK)、テーブル指定をするクエリは当たり前に存在します。

    (さらに…)

  • セキュアコーディング/セキュアプログラミングが流行らない理由

    ISO 27000(ISMS)をはじめ、セキュアコーディング/セキュアプログラミングを行いなさい、と推奨するセキュリティガイドラインが多くあります。2014年改訂のISO 27000に至っては、セキュアプログラミングが広く普及したのでセキュアプログラミングを行うとする記述に簡素化しています。1

    しかし、広く使われているフレームワークでさえセキュアコーディング/セキュアプログラミングをサポートする機能が無かったり/不十分でだったり、現状は到底普及している、とは言えないです。辛うじて普及しているかも?と言えるのはセキュアコーディング/セキュアプログラミングでは枝葉末節にあたるコーディング技術(ああすべき/こうすべき)くらいではないでしょうか?

    なぜセキュアコーディング/セキュアプログラミングが普及していないのか?考えられる理由を挙げます。

    セキュアコーディング/セキュアプログラミングとは?という方は以下を参考にしてください。

    (さらに…)

  • 5分で解るセキュアコーディング

    セキュアコーディングで最も重要な部分を理解するのは簡単です。スライドを作ったので公開します。

    https://www.slideshare.net/yohgaki/5-77628242

    出力対策だけのセキュリティ対策は”誤り”です。

    https://blog.ohgaki.net/reason-why-output-only-security-is-design-mistake

    確証バイアスのせいか、”セキュリティ専門家”を含め、この基本原理が理解できないケースが多いです。

     

  • 2017年版OWASP TOP 10

    追記: 8月現在では、OWASP TOP 10 2017はWAFのプロモーションになっている、OWASP Proactive Controlsの”全ての入力をバリデーションする”と重複している、などの点が議論になりRCはリジェクトされ11月にリリースを目指して調整中になっています。

    追記2:正式版が2017年12月にリリースされました。ここで紹介している脆弱性はA10(10番目の脆弱性)「不十分なログとモニタリング」として登録されました。WAFが必要であるかのような記載が削減されましたが、脆弱性の本質(入力検証しない&対応しないアプリは脆弱なアプリ)は変わりありません。

     

    このテーマついては既にブログは書いています。このエントリでは追加でQ&Aを記載しています。

    https://blog.ohgaki.net/2017-owasp-top-10-changes-web-security-rule

    元々はこのスライドは非公開にするつもりでしたが、公開可能な内容で公開することにしました。

    https://www.slideshare.net/yohgaki/2017owasp-top-10

    開発会社としてはどうすれば良いのか?と質問を頂いたので追記します。

    (さらに…)

  • 出鱈目なシグニチャのhash_hkdf関数を安全に使う方法

    ユーザーが間違った使い方をしないよう、PHP 7.1に追加されたhash_hkdf関数のシグニチャが出鱈目である件について書いておきます。使い方を間違えると脆弱な実装になるので注意してください。

    (さらに…)

  • PHP:タイプヒントを使うと遅くなる

    PHPにはタイプヒントと呼ばれる引数/戻り値データ型指定機能があります。これは便利な機能ですが性能に影響を与えます。

    (さらに…)

  • 2017年度版 OWASP TOP 10 で変るWebセキュリティのルール

    追記: 8月現在では、OWASP TOP 10 2017はWAFのプロモーションになっている、OWASP Proactive Controlsの”全ての入力をバリデーションする”と重複している、などの点が議論になりRCはリジェクトされ11月にリリースを目指して調整中になっています。

    追記2:12月現在ではPDF版がリリースされています。現時点ではWebページの内容はドラフト版になっています。リリース版では「A7-Insufficient Attack Protection」は「A10-Insufficient Logging & Monitoring」になり、緩い要求事項に変更されていますが、基本的な要求事項は変わりません。マトモな入力バリデーションがないと要求されるログと監視機能を提供できません。

    OWASP(Open Web Application Security Project)とはWebシステムのセキュリティ向上を目指す団体です。クレジットカード/デビットカード利用に必要なPCI DSS(Payment Card Industory Data Security Standard)標準に強い影響力を持っています。PCI DSS標準ではOWASPなどのセキュリティガイドを参照/実装するように求めています。

    OWASP TOP 10はOWASPガイドプロジェクトの中で最も重要なプロジェクトです。今年はその新版が4年ぶりにこの夏公開予定です。この4月からRC版(PDF)が公開されています。

    2017年度版OWASP TOP 10の修正点で、アプリケーション開発者にとって最も影響が大きい変更は

    • A7 Insufficient Attack Protection(不十分な攻撃防御)

    が追加された点です。これがWebセキュリティのルールを変える指針になります。(とは言っても、個人的にはこれと同じこと10年以上前から実施すべき、と勧めていますが) (さらに…)

  • 入力値の種類は3種類しかない

    入力の種類には3種類以上の種類、名前、電話番号、住所など沢山の種類があります。しかし、見方によってはたった3種類しかありません。この区別ができる/できない、で大きな違いができてしまいます。

    (さらに…)