SQLインジェクション対策保証付きソースコード検査はじめました

Webシステムに限らず、SQLインジェクション脆弱性は絶対に作りたくない脆弱性の1つです。裁判でSQLインジェクション対策漏れよる損害賠償が契約金額を上回った事例もあります。

ソースコード検査ならSQLインジェクションが行えないことを保証することが可能です。私の会社ではソースコード検査サービスを提供していますが、これまでに検査証を発行したアプリケーションでSQLインジェクションが問題になった事はありません。 “SQLインジェクション対策保証付きソースコード検査はじめました” の続きを読む

何故こうなった?プログラムの動作原理を無視したセキュリティ対策

正しく動作するプログラムには

  • 正しい/妥当なデータ
  • 正しいコード

の両方が必要です。

仕様から間違っている場合を除けば、セキュリティ問題はプログラムの誤作動によって起こります。データかコード、どちらかの問題によって発生します。

当たり前の常識ですが、これを無視したセキュリティ対策がまかり通っている、それが現在の状況です。何故こうなってしまったのでしょう?

“何故こうなった?プログラムの動作原理を無視したセキュリティ対策” の続きを読む

PHPのserialize()/unserialize()を安全に利用する方法

serialize()でシリアライズしたデータを外部に送信/保存1し、それをunserialize()すると危険です。

アンシリアライズは複雑なメモリ操作が必要で、PHPに限らず、何度もメモリ破壊攻撃の脆弱性が見つかっています。このため、外部入力データのアンシリアライズは行うべきではありません。現在のPHPプロジェクトでは、RubyやPythonと同じく、アンシリアライズのメモリ問題を”脆弱性として取り扱わないことになっています。

しかし、外部データでもunserialize()を安全に利用する方法はあります。

“PHPのserialize()/unserialize()を安全に利用する方法” の続きを読む

APIを過信するとおかしな事になる例 – SAML認証成り済まし

今年の2月にSAMLライブラリの脆弱性が報告されていたことを覚えている人も居ると思います。

この脆弱性はXMLコメント(<!– –>)の取り扱いの違いによって、本来のユーザーではない攻撃者を認証してしまう事が問題であったとしています。

攻撃用の文字列サンプルは以下のような物です。

<NameID>user@example.com<!—->.evil.com</NameID>

攻撃が可能になる理由はXMLコメントの取り扱いの違いにあります。

  • あるライブラリは<!– –>までの文字列(user@example.com)までをNameIDとして取り扱う
  • 別のライブラリは<!– –>を取り除いた文字列(user@example.com.evil.com)をNameIDとして取り扱う

これにより攻撃者が別のユーザーに成り済ませてしまう問題が発生しました。1

“APIを過信するとおかしな事になる例 – SAML認証成り済まし” の続きを読む

ドイツ人と入力バリデーションについて議論した話

メールアドレスから恐らくドイツ人だと思われる開発者とWebアプリ(サーバー側)の入力バリデーションについて議論した内容を簡単に紹介します。

どこかでした議論と同じでデジャブー感ですが、これから書くような感じの内容でした。議論相手のドイツ人の言葉がくだけた感じに書いていますが、「自分の考え方は完璧、私の考え方はとんでもない非常識」と思っていたらしく、お世辞にも丁寧な書き方のメールではありませんでした。この為、くだけた感じで書いています。

とんでもない勘違いをしているのに自信満々の人は手に負えない、と感じる人が多いと思います。私の場合、こういう人でもどういう論理とポイントで議論すれば良いのか?参考になるので楽しんで議論しています。

“ドイツ人と入力バリデーションについて議論した話” の続きを読む

入力バリデーションが甘いソースコードの検査は本当に大変

入力バリデーションが甘いアプリケーションのソースコードの検査は大変です。何が大変なのか、簡単に紹介します。

ついでに入力バリデーションが甘いアプリケーションの脆弱性診断はかなり簡単でであることも簡単に紹介します。

“入力バリデーションが甘いソースコードの検査は本当に大変” の続きを読む

出力対策の3つの役割 – フェイルセーフ頼みはNG

出力対策だけ行なえばOK!と考えてしまう原因は出力対策に3つの役割があることに気付かないからでは?と思ってこのエントリを書いています。

出力対策は”必須である場合”と”フェイルセーフ対策”である場合があります。

出力対策の基本はこちらです。

出力対策の3原則 + 1原則

“出力対策の3つの役割 – フェイルセーフ頼みはNG” の続きを読む

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

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

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

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

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

“忘れられた入力処理と出力処理の責任” の続きを読む