セキュアコーディングで最も重要な部分を理解するのは簡単です。スライドを作ったので公開します。
https://www.slideshare.net/yohgaki/5-77628242
出力対策だけのセキュリティ対策は”誤り”です。
https://blog.ohgaki.net/reason-why-output-only-security-is-design-mistake
確証バイアスのせいか、”セキュリティ専門家”を含め、この基本原理が理解できないケースが多いです。
カテゴリー: Security
-
2017年版OWASP TOP 10
追記： 8月現在では、OWASP TOP 10 2017はWAFのプロモーションになっている、OWASP Proactive Controlsの”全ての入力をバリデーションする”と重複している、などの点が議論になりRCはリジェクトされ11月にリリースを目指して調整中になっています。
追記2：正式版が2017年12月にリリースされました。ここで紹介している脆弱性はA10（10番目の脆弱性）「不十分なログとモニタリング」として登録されました。WAFが必要であるかのような記載が削減されましたが、脆弱性の本質（入力検証しない＆対応しないアプリは脆弱なアプリ）は変わりありません。
このテーマついては既にブログは書いています。このエントリでは追加でQ＆Aを記載しています。
https://blog.ohgaki.net/2017-owasp-top-10-changes-web-security-rule
元々はこのスライドは非公開にするつもりでしたが、公開可能な内容で公開することにしました。
https://www.slideshare.net/yohgaki/2017owasp-top-10
開発会社としてはどうすれば良いのか？と質問を頂いたので追記します。
-
出鱈目なシグニチャのhash_hkdf関数を安全に使う方法
ユーザーが間違った使い方をしないよう、PHP 7.1に追加されたhash_hkdf関数のシグニチャが出鱈目である件について書いておきます。使い方を間違えると脆弱な実装になるので注意してください。
-
PHP：タイプヒントを使うと遅くなる
PHPにはタイプヒントと呼ばれる引数／戻り値データ型指定機能があります。これは便利な機能ですが性能に影響を与えます。
-
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年以上前から実施すべき、と勧めていますが） (さらに…)
-
入力値の種類は３種類しかない
入力の種類には3種類以上の種類、名前、電話番号、住所など沢山の種類があります。しかし、見方によってはたった3種類しかありません。この区別ができる／できない、で大きな違いができてしまいます。
-
SQLインジェクション対策 総”習”編 – 第五回関西DB勉強会
第五回 関西DB勉強会でお話しさせて頂いた SQLインジェクション対策 総”習”編 の公開用資料をSlideShareにアップロードしました。私のセッションを気に入って頂けた方が多かったようで何よりです。
関西DB勉強会、面白かったです。久々にお会いできた方もいました。超満員でもう少しで入りきれないほどでした。また参加できれば、と思っています。
PDFはこちらからダウンロードできます。
https://www.slideshare.net/yohgaki/sql-76168380
勉強会で使ったスライドは、面白おかしく柔らかい（？）スライドでした。あまり公開用には向いていません。実際に勉強会で使った資料が欲しい方はFacebookかメールで連絡してください。個別にお送りします。
-
アプリケーションのセキュリティと必要十分条件
セキュリティと必要十分条件については他のエントリでも書きました。以前書いたエントリではミクロの視点から単純な加算関数で考えました。今回はもう少し大きなマクロの視点、アプリケーションのセキュリティの必要十分条件を考えてみます。
論理的なセキュリティを考える為には必要なので書きました。ここに書いたことは読み物としては退屈かも知れませんが、重要な事だと考えています。
-
これから開発を始める場合のセキュリティ
取り敢えず言語とプログラミングの基礎を学習し終えて、これから本格的にソフトウェア開発をしよう、という場合に困るのが「セキュリティ」です。今回は簡単に、これから本格的に開発を行う、という方向けに知っておくべき事を紹介します。
初めてTeratailに回答した内容を多少まとめて加筆したモノになっています。
https://teratail.com/questions/74317
ブログにしたので、Tratailの回答は単純にこのエントリを参照するように修正するかも知れません。
-
戸締りと金庫とセキュリティ
ずっと感じてきたことですが、ブログにしていませんでした。具体的には
戸締りする前に、金庫を買うセキュリティ対策
です。
IT技術者以外の方向けに書いています。最近問題だ、と話題のStruts2というソフトウェアを引き合いに書いていますが、技術的なことはほとんど書いてありません。
-
暗号を積極的に使う理由
Googleは暗号を積極的に使っていることが知られています。暗号を積極的に使う理由を紹介します。
「信頼境界線の中で暗号を使っても、内部に侵入を許した時点で終わり」なので、「暗号を使っても意味がない」と考えているかも知れません。「リスクの廃除」だけが、セキュリティ対策ではありません。「リスクの緩和」もセキュリティ対策です。暗号は侵入を許してしまった場合のリスク緩和に効果的です。
-
文字列（ハッシュ）の安全な比較方法 – hash_equals
映画などでPINコードを一桁づつ解析してドアを開錠する、といったシーンがあると思います。こんなのは”映画の世界だけ”と思っている方も多いと思います。しかし、タイミング攻撃を利用すると”実際にこれと全く同じ方法”で鍵となる情報を解析できます。
タイミング攻撃とはサイドチャネル攻撃の一種で、鍵情報を比較的簡単に解析する方法です。PHP 5.6からはタイミング攻撃に脆弱でない比較方法を提供しています。
結論から書くと、秘密の文字列を比較する場合
if ($secret_str !== $user_input) { // ユーザー提供の秘密情報不一致 die('不正なアクセスです'); }といった通常の文字列は比較は危険です。
if (!hash_equals($secret_st, $user_input)) { die('不正なアクセスです'); }上記のようにhash_equals関数を利用しなければなりません。