SQLインジェクション対策保証付きソースコード検査はじめました
Webシステムに限らず、SQLインジェクション脆弱性は絶対に作りたくない脆弱性の１つです。裁判でSQLインジェクション対策漏れよる損害賠償が契約金額を上回った事例もあります。
ソースコード検査ならSQLインジェクションが行えないことを保証することが可能です。私の会社ではソースコード検査サービスを提供していますが、これまでに検査証を発行したアプリケーションでSQLインジェクションが問題になった事はありません。 もっと読む
何故こうなった？プログラムの動作原理を無視したセキュリティ対策
正しく動作するプログラムには
- 正しい／妥当なデータ
- 正しいコード
の両方が必要です。
仕様から間違っている場合を除けば、セキュリティ問題はプログラムの誤作動によって起こります。データかコード、どちらかの問題によって発生します。
当たり前の常識ですが、これを無視したセキュリティ対策がまかり通っている、それが現在の状況です。何故こうなってしまったのでしょう？
参考： プログラム動作の構造、原理と原則
PostgreSQLの文字列型の最大長は？
PostgreSQLには
- varchar(n) 型
- char(n) 型
- text型
の文字列型があります。他にバイナリも保存できる
- bytea型
もあります。
text／byteaの最大サイズは1GiBだ、と私も思っていたのですが違いました。
PHPのserialize()/unserialize()を安全に利用する方法
serialize()でシリアライズしたデータを外部に送信／保存1し、それをunserialize()すると危険です。
アンシリアライズは複雑なメモリ操作が必要で、PHPに限らず、何度もメモリ破壊攻撃の脆弱性が見つかっています。このため、外部入力データのアンシリアライズは行うべきではありません。現在のPHPプロジェクトでは、RubyやPythonと同じく、アンシリアライズのメモリ問題を”脆弱性として取り扱わない”ことになっています。
しかし、外部データでもunserialize()を安全に利用する方法はあります。
PHPセッションとSameSiteサポート – CSRF, XSS対策
PHPのセッションID用クッキーと他のクッキー関数にSameSiteサポートが追加されます。
https://wiki.php.net/rfc/same-site-cookie
これによりクロスサイト・リクエスト・フォージェリ攻撃（CSRFやXSS）などを緩和できます。
APIを過信するとおかしな事になる例 – SAML認証成り済まし
今年の2月にSAMLライブラリの脆弱性が報告されていたことを覚えている人も居ると思います。
この脆弱性はXMLコメント（<!– –>）の取り扱いの違いによって、本来のユーザーではない攻撃者を認証してしまう事が問題であったとしています。
攻撃用の文字列サンプルは以下のような物です。
<NameID>user@example.com<!—->.evil.com</NameID>
攻撃が可能になる理由はXMLコメントの取り扱いの違いにあります。
- あるライブラリは<!– –>までの文字列（user@example.com)までをNameIDとして取り扱う
- 別のライブラリは<!– –>を取り除いた文字列（user@example.com.evil.com）をNameIDとして取り扱う
これにより攻撃者が別のユーザーに成り済ませてしまう問題が発生しました。1
ドイツ人と入力バリデーションについて議論した話
メールアドレスから恐らくドイツ人だと思われる開発者とWebアプリ（サーバー側）の入力バリデーションについて議論した内容を簡単に紹介します。
どこかでした議論と同じでデジャブー感ですが、これから書くような感じの内容でした。議論相手のドイツ人の言葉がくだけた感じに書いていますが、「自分の考え方は完璧、私の考え方はとんでもない非常識」と思っていたらしく、お世辞にも丁寧な書き方のメールではありませんでした。この為、くだけた感じで書いています。
とんでもない勘違いをしているのに自信満々の人は手に負えない、と感じる人が多いと思います。私の場合、こういう人でもどういう論理とポイントで議論すれば良いのか？参考になるので楽しんで議論しています。
入力バリデーションが甘いソースコードの検査は本当に大変
入力バリデーションが甘いアプリケーションのソースコードの検査は大変です。何が大変なのか、簡単に紹介します。
ついでに入力バリデーションが甘いアプリケーションの脆弱性診断はかなり簡単でであることも簡単に紹介します。
出力対策の3つの役割 – フェイルセーフ頼みはNG
出力対策だけ行なえばOK！と考えてしまう原因は出力対策に3つの役割があることに気付かないからでは？と思ってこのエントリを書いています。
出力対策は”必須である場合”と”フェイルセーフ対策”である場合があります。
出力対策の基本はこちらです。
とあるネットワーク技術者の防御法
今回は「とあるネットワーク技術者がいかにしてネットワークシステムのセキュリティを守っているのか？」という話です。
「え？！」と思うハズですが、最後までお読みください。
忘れられた入力処理と出力処理の責任
入力処理と出力処理はプログラムの基本処理です。当たり前の処理ですが、Webアプリケーションでは基本的な事が知られているようで知られてないと思います。
入力処理と出力処理の両方ともがデータに対する責任を持っています。データに対する責任といっても、その責任は異なります。このエントリはプログラムの基本機能、入力処理/ロジック処理/出力処理が持っている責任を紹介します。
脆弱性がないプログラムを作るには、コードからの視点、データからの視点、両方が必要です。ソフトウェアセキュリティの専門家は両方の視点からのセキュリティ対策を啓蒙しているのですが、上手く伝わっていないです。
このエントリはデータからの視点で見たデータセキュリティの話です。