タグ: 出力対策

  • 忘れられた入力処理と出力処理の責任

    入力処理と出力処理はプログラムの基本処理です。当たり前の処理ですが、Webアプリケーションでは基本的な事が知られているようで知られてないと思います。

    入力処理と出力処理の両方ともがデータに対する責任を持っています。データに対する責任といっても、その責任は異なります。このエントリはプログラムの基本機能、入力処理/ロジック処理/出力処理が持っている責任を紹介します。

    脆弱性がないプログラムを作るには、コードからの視点、データからの視点、両方が必要です。ソフトウェアセキュリティの専門家は両方の視点からのセキュリティ対策を啓蒙しているのですが、上手く伝わっていないです。

    このエントリはデータからの視点で見たデータセキュリティの話です。

    (さらに…)

  • データのセキュリティ対策が無いセキュリティ対策?!

    ソフトウェアのセキュリティ問題の多くは「ソフトウェアの誤作動」です。つまり、正しく動作するソフトウェアならセキュリティ問題の大半は発生しません。1

    コンピュータープログラムが正しく動作するには「正しいコード」と「正しいデータ」の両方揃う事が必須条件です。これはプログラムの動作原理に基づく条件なので、誰にも変えることは出来ません。

    (さらに…)

  • 今さら聞けない「コード」と「データ」の話

    ビルドを繰り返して時間があったので、ついついとても長いデータの話を書いてしまいました。今さら聞けない「コード(機能)」と「データ」の話として、もっと単純化してみます。

    当然の話なのですが、現実には当たり前ではなかったりします。

    「データ」のセキュリティを考慮しないセキュリティ対策はあり得ないのですが、多くのプログラムは「コード(機能)」のセキュリティに偏重した構造と対策になっています。

    安全なプログラムの作成には「コード(機能)」と「データ」のセキュリティを分けて考える必要があります。

    (さらに…)

  • コマンド実行時、コマンドと引数を分離すれば完璧?

    プログラムを作っているとOSコマンドを実行したくなる時があります。OSコマンドの実行に問題があり、不正なコマンドをインジェクションされると大変な事になります。

    どのようなセキュリティガイドラインでも「OSコマンドの実行に注意する」と大抵書かれています。

    多くの場合、「コマンド実行時、コマンドと引数を分離すれば安全に実行できるAPIを利用すれば安全に実行できる」としています。

    この記述は間違ってはいないです。しかし、正しくは

    • コマンド実行時、コマンドと引数を分離すれば”比較的”安全に実行できる”場合が多い

    です。

    コマンドと引数を分離するAPI利用だけでは完璧とは言えないセキュリティ対策です。

    (さらに…)

  • 「出力対策だけのセキュリティ設計」が誤りである理由

    まず結論から。タイトルの通り「出力対策だけのセキュリティ設計は設計ミス」です。

    なぜ「出力対策だけのセキュリティ設計は設計ミス」なのか?

    (さらに…)

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

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

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

    (さらに…)

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

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

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

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

    (さらに…)

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

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

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

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

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

    (さらに…)

  • SQLインジェクション対策 総”習”編 – 第五回関西DB勉強会

    第五回 関西DB勉強会でお話しさせて頂いた SQLインジェクション対策 総”習”編 の公開用資料をSlideShareにアップロードしました。私のセッションを気に入って頂けた方が多かったようで何よりです。

    関西DB勉強会、面白かったです。久々にお会いできた方もいました。超満員でもう少しで入りきれないほどでした。また参加できれば、と思っています。

    PDFはこちらからダウンロードできます。

    https://www.slideshare.net/yohgaki/sql-76168380

     

    勉強会で使ったスライドは、面白おかしく柔らかい(?)スライドでした。あまり公開用には向いていません。実際に勉強会で使った資料が欲しい方はFacebookかメールで連絡してください。個別にお送りします。

  • プログラム・コードが正しく動作する為の必要条件と十分条件

    プログラム・コードが正しく動作する為の必要条件と十分条件を考えたことがあるでしょうか?

    プログラム・コードが正しく動作する為の必要条件と十分条件とは何でしょうか?

    (さらに…)

  • コンピュータは数値さえ正確に扱えない

    コンピュータで数値を正確に扱うのは「実は結構難しい」です。つまり「コンピューターは数値を正確に扱えない」という事です。「コンピューターが数値を正確に扱えない?!何を言ってるんだ?!」と思った方は是非読んでみてください。

    (さらに…)

  • APIとエスケープ/バリデーションとセキュリティ

    今回はセキュリティ対策におけるAPIとエスケープ/バリデーションをどう考えるかの話です。

    Cプログラマになろうとしているプログラマにメモリ管理を教えないことは考えられません。メモリ管理を考えなくても文字列の処理をしたりするライブラリなどもありますが、メモリ管理をあまり考えなくても良いAPIさえ使っていればOK、メモリリークもValgrindでチェックしてレポートされなければOK、と考えているプログラマが作ったプログラムが安全である可能性は低いでしょう。

    言語やプラットフォームの基本中の基本を避けて通っては安全なプログラムの構築が難しくなるだけです。

    安全なプログラムを作るために「プログラマに何を教えるべきか?」が今日のテーマです。

    (さらに…)

  • 出力先のシステムが同じでも、出力先が異なる、を意識する

    出力先のシステムが同じでも、出力先が異なる場合はよくあります。これを意識していないとセキュリティ問題の原因になります。
    (さらに…)

  • エンジニア必須の概念 – 契約による設計と信頼境界線

    少し設計よりの話を書くとそれに関連する話を書きたくなったので出力の話は後日書きます。

    契約による設計(契約プログラミング)(Design by Contract – DbC)は優れた設計・プログラミング手法です。契約による設計と信頼境界線について解説します。
    (さらに…)