カテゴリー: Development

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年以上前から実施すべき、と勧めていますが) もっと読む

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

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

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

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

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

 

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

これから開発を始める場合のセキュリティ

取り敢えず言語とプログラミングの基礎を学習し終えて、これから本格的にソフトウェア開発をしよう、という場合に困るのが「セキュリティ」です。今回は簡単に、これから本格的に開発を行う、という方向けに知っておくべき事を紹介します。

初めてTeratailに回答した内容を多少まとめて加筆したモノになっています。

https://teratail.com/questions/74317

ブログにしたので、Tratailの回答は単純にこのエントリを参照するように修正するかも知れません。

もっと読む

暗号を積極的に使う理由

Googleは暗号を積極的に使っていることが知られています。暗号を積極的に使う理由を紹介します。

信頼境界線の中で暗号を使っても、内部に侵入を許した時点で終わり」なので、「暗号を使っても意味がない」と考えているかも知れません。「リスクの廃除」だけが、セキュリティ対策ではありません。「リスクの緩和」もセキュリティ対策です。暗号は侵入を許してしまった場合のリスク緩和に効果的です。

もっと読む

簡単にインターネットから内部ネットワークを守る方法

前のエントリでFirefox + NoScriptによる内部ネットワークを守る方法を簡単に紹介しました。本当はネットワークを分離(物理的またはVLAN)し、それぞれに安全に利用できるプロキシーサーバー(ローカルネットワークのリソースにアクセスさせない、など)を用意して利用する方が良い、のですがこれには”それなりのモノと手間”が必要です。

Firefox + NoScriptだけでもかなり効果があるので改めて紹介します。前回紹介したのは10年も前ですね :D

もっと読む

信頼境界線の引き方と防り方 – セキュリティの構造と設計

信頼境界線Trust Boundary)と境界防御はITセキュリティに限らず、セキュリティ対策の基礎中の基礎です。基礎中の基礎かつ最も重要な概念ですが習わないことが多いです。これが原因で「正しいセキュリティ対策」(≒効率的なセキュリティ対策)ができていないケースが多数あります。残念ながら”セキュリティに詳しい”とされている人でも全く理解していないケースが散見されます。

このエントリでは主に、ソフトウェアセキュリティに於ける信頼境界線の概念と引き方(≒セキュリティ構造/設計)、ついて紹介します。かなり長いエントリになりましたがお付き合いください。

もっと読む

文字列(ハッシュ)の安全な比較方法 – hash_equals

映画などでPINコードを一桁づつ解析してドアを開錠する、といったシーンがあると思います。こんなのは”映画の世界だけ”と思っている方も多いと思います。しかし、タイミング攻撃を利用すると”実際にこれと全く同じ方法”で鍵となる情報を解析できます。

タイミング攻撃とはサイドチャネル攻撃の一種で、鍵情報を比較的簡単に解析する方法です。PHP 5.6からはタイミング攻撃に脆弱でない比較方法を提供しています。

結論から書くと、秘密の文字列を比較する場合

if ($secret_str !== $user_input) {
  // ユーザー提供の秘密情報不一致
  die('不正なアクセスです');
}

といった通常の文字列は比較は危険です。

if (!hash_equals($secret_st, $user_input)) {
  die('不正なアクセスです');
}

上記のようにhash_equals関数を利用しなければなりません。

もっと読む

SQL識別子のエスケープ

SQLの識別子(テーブル名やフィールド名)はプリペアードクエリではエスケープできません。最近の開発者はSQLの”パラメーター”には注意を払うようになったので、SQLパラメーターによるSQLインジェクションはかなり少くなってきました。

この結果、相対的にSQL識別子によるSQLインジェクション脆弱性の割合が増えています。実際、私がコード検査を行っているアプリケーションでも識別子が原因でSQLインジェクションに脆弱であるケースが半数くらいになっています。

出力対策はセキュアコーディングの基本の1つです。プリペアードクエリだけでSQLによるインジェクションは防げません。DBMSに限らず、他のシステム(ライブラリも含む。特に文字列をパースする正規表現、XML処理など)にデータを送信する場合、完全に無害化する必要があります。

参考: CERTトップ10セキュアコーディング習慣7. 他のシステムに送信するデータを無害化する

もっと読む

Struts 2の脆弱性でHTTPのContent-Typeヘッダーからリモートコード実行ができる理由

Apache Struts2 の脆弱性対策について(CVE-2017-5638)(S2-045)

  • HTTPプロトコルのContent-Typeヘッダーでリモートからコード実行ができる

という問題です。どうして「Content-Typeヘッダー」でコード実行ができたのか?気になったので調べたメモです。

コード実行ができた理由は「国際化(翻訳)用のメッセージ処理メソッドが、プログラミング言語のようにパースして実行する仕様」であったことでした。気にしていないとこのパターンでリモートコード実行ができてしまうコードも在ると思います。

 

もっと読む