出力対策”のみ”のセキュリティはアンチプラクティス

「しっかり出力対策”だけ”するのがセキュリティ対策のベストプラクティス」とする考え方1があります。しかし、これはベストプラクティスどころかアンチプラクティスです。

アンチプラクティスをベストプラクティスと勘違いしている限り、満足のいくセキュリティ対策(=リスク管理)は不可能です。セキュリティ対策は総合的なリスク対策です。「これ”だけ”やれば良い」とするセキュリティ対策は大抵アンチプラクティス2です。

※ 今まで出力対策”だけ”がセキュリティ対策だと勘違いしていた方には確証バイアスが働きやすいようです。論理的/構造的にどうすればリスクを効果的に削減できるのか?を考えると理解るはずです。

“出力対策”のみ”のセキュリティはアンチプラクティス” の続きを読む

まだ誰も知らない脆弱性/攻撃に備える方法

セキュリティを考えると全ての入力データはアプリケーションがバリデーションすべきで、長さ/形式は厳格にバリデーションすべきです。1

厳格なバリデーションは開発者が意識/把握していない各種インジェクション脆弱性にも対応できること、インジェクション攻撃が持たらす被害が致命的であることが、その理由です。

適切なバリデーションは最強のセキュリティ対策の1つ2です。強いデータ型は弱いバリデーションの一種ですが、それでもセキュリティ対策として高い評価を得ています。にも関わらず強いバリデーションである厳格なデータバリデーションはコンピューターサイエンティストのセキュリティ専門家3以外にはあまり評価されていないように感じます。

今回は低レベルのライブラリにもコードインジェクション脆弱性のリスクがあること、その対策としてバリデーションが如何に効果的であるか紹介します。

“まだ誰も知らない脆弱性/攻撃に備える方法” の続きを読む

2017年版OWASP TOP 10

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

 

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

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

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

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

“2017年版OWASP TOP 10” の続きを読む

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

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

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

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

 

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

なぜ強い型を持つ言語はセキュリティ的に強いのか? – データ型のバリデーションと構造化されたセキュリティ対策

強いデータ型を持つ言語は弱いデータ型の言語(PHPやJavaScriptなど)に比べよりセキュアなのか?「なぜよりセキュアなのか?」簡単に解説します。

結論から書くと「強いデータ型」はそれだけでは「強いセキュリティ構造」を作るモノではなく、少しだけ安全なコードを書く手助けくらいの効果しか期待できません。安全かつ正しく動作するプログラムを最小のコストで作りたい場合、契約プログラミングを行うのが効果的です。

“なぜ強い型を持つ言語はセキュリティ的に強いのか? – データ型のバリデーションと構造化されたセキュリティ対策” の続きを読む

正規表現でのメールアドレスチェックは見直すべき – ReDoS

前のエントリでStackExchangeがReDoSで攻撃されサイトがダウンした問題を紹介しました。少しだけ掘り下げて見たところ、正規表現だけでメールアドレスをチェックしている場合、壊滅的なReDoS(十分短い文字列で指数関数的に実行時間が増加する)が可能なことが判りました。

結論を書くと、正規表現でのメールアドレスチェックは見直すべき、です。(特にRubyユーザー)

追記:影響範囲はメールアドレスチェックに限らないので、正規表現チェックは全体的に見直さないと、どこが脆弱なのか判りません。見直してチェックしたとしても、それが完全であったと保証することは困難です。ネット検索して直ぐに見つかった検索パターンは非常に脆弱であったこと、メールアドレスのマッチパターンは脆弱になりやすい繰り返しの繰り返しが含まれること、これらがあったのでタイトルが「正規表現でのメールアドレスチェックは見直すべき 」になっています。

“正規表現でのメールアドレスチェックは見直すべき – ReDoS” の続きを読む

StackExchangeが攻撃されたReDoSの効果

StackExchangeがReDoS攻撃に遭いサイトがダウンした原因をStackExchangeのブログで紹介していました。

PHPへの影響があるか試してみました。結論を書くと、脆弱な正規表現を使っていて攻撃者が入力をコントロールできる場合、簡単に攻撃できるようです。PCRE、Onigurumaの両方で試してみましたがどちらも脆弱でした。

参考:正規表現でのメールアドレスチェックは見直すべき – ReDoS Onigurumaでは破滅的なReDoSが可能です。以前からメールアドレスのチェックに利用する正規表現には注意喚起していましが、どの程度浸透していたのだろうか?

“StackExchangeが攻撃されたReDoSの効果” の続きを読む

セキュアなアプリケーションアーキテクチャ

セキュアなアプリケーションには共通したアーキテクチャがあります。基本的には防御的プログラミング(セキュアプログラミング)を行い、防御的プログラミングのテクニックの1つである契約プログラミングを実践したアーキテクチャがセキュアなアーキテクチャです。

アプリケーションのセキュリティ問題のほとんどはインジェクション問題です。インジェクション問題以外にもセキュリティ問題はありますが、ここではインジェクション問題のみを考慮します。

“セキュアなアプリケーションアーキテクチャ” の続きを読む