何故かあたり前にならないエスケープ処理
私が3年前(2006年)に「SQL Injectionの仕組みと対策」を執筆していた時には、既にJavaScriptインジェクションやSQLインジェクション攻撃は比較的広く知られていました。この問題はそれ以前からスラッシュドットジャパンでも取り上げられていました。/.で取り上げられたので、そこら中のWebサイトとユーザが被害に合うのでは?とヒヤヒヤしたので良く覚えています。
JavaScriptインジェクションやSQLインジェクション攻撃は、文字をデータとして厳格に取り扱い、特殊文字をエスケープすれば無くなります。これを怠ると、システムのどこで問題が発生するか予想できなくなります。つまり、いい加減にエスケープ処理を取り扱うと安全なシステムは作れないのです。
(中略)
2006年当時、近い将来この問題は解決されると信じていました。しかし、残念ながらこの予想は全く外れました。
(以下略)
もちろん、ネタですよ、ネタw
しっかし、なくならないなぁorz
だるい
なんかネタが浮かんだので書いてみる。
セッションIDって?
http://b.hatena.ne.jp/into_the_blue/20091001#bookmark-16421068
語弊がある言い方だけど、セッションIDってそもそもユーザ認証ではなく、ユーザ識別だと思う。
セッションが生きている場合に限り、どのユーザがリクエストを送信しているのかを識別するものであって、そのユーザが本人かどうかを確認する認証ではない。
なので、セッションIDを含んだURLをリンクとして貼り付けると、セッションが生きている間、その人と認識されるのは当たり前。
今回の大本の問題のケースでは、セッションの維持時間をある程度短くするとか、するべきだったんだろうなぁ。
まあ、それもこれもDocomoが<追記>一部の端末で<追記>未だにCookie対応していないのが原因なんだが。
GateWayでCookie付加するようには出来ないのかなぁ?システム上大変だろうけど・・・
何故かあたり前にならない文字エンコーディングバリデーション
http://blog.ohgaki.net/char_encoding_must_be_validated
まあ、当たり前にはならないでしょう。どう考えても不正な文字エンコーディングを受け付ける言語やらフレームワーク、DB、ブラウザが悪いと思う。不正な文字エンコーディングをチェックするというのはバッドノウハウだと思うし。そんなことに対応するのは大変すぎるからねぇ。
アプリ開発者を啓蒙するより、PHPとか直したほうが早いと思うんだけど。
XSSやSQLインジェクションが発生しないようにエスケープ処理やバインド機能を使うというのは、プログラムの基本に立ち返って、どんなデータが渡されても正確に処理を実行するために必要なことなので、当たり前といえると思う。
でも、不正な文字エンコーディングのチェックはプログラミング手法ではなく、それを受け取って変に解釈してしまうDBやらブラウザなどが直せないからしょうがなくやることなので、まずはそっちを直せと声を大にしていうべきなんじゃないかなぁ。
それをやっているのでしょうけど、まずは直すように回りから声を出してというべきなんじゃ?
(追記)
そういえば、ご自身の記事で「セキュリティやエラー処理など細かい部分の解説は理解の妨げになるため,敢えて省略しています。」なんて言ってるよなぁ。一応、次の記事で追加しているけど、検索でサンプルコードを探しているような人はそこまで読まないと思う。2つ目の記事のコードを書いておいて「ここはこういう風に書くことをおまじないとして覚えておいてください。後で説明します」で言いと思うんだけど。「やってみせ、言ってきかせて、させてみて、誉めてやらねば人は動かじ」だと思うんだけどなぁ。
セキュリティ教育と安全なWebサイト開発方法論 〜効果的なセキュリティ教育実施と安全なWebサイト開発の方法を探る〜
http://www.mbsd.jp/event/detail125-desc.html
に行ってきたので、簡単なメモ
楽天のインターネットセキュリティの取り組み
- 楽天におけるインターネットセキュリティの考え方
- 取り組み
- 組織
- 開発プロセス
- セキュリティ教育を実施した後、要件定義→セキュリティレビュー→開発→QA→監査
- PDCAサイクルを回している
- セキュリティ教育を徹底している
- 開発エンジニア全員に教育している
- 案件によって、設計段階でレビューする
- 前工程(要件定義、設計)で仕様上の問題をつぶしている
- 外部委託する際にはセキュリティ要件を必ず入れている
- さすがにどんなものかは教えてくれない
- QAを現場でツールを使って行っている
- 最後にツールで漏れるものについては専門家がチェックしている
- 運用
- 楽天の特徴
- 専門家が対策(開発標準?)を効率化している
- 特別なことをやっているわけではない
- 当たり前のことを当たり前に高いレベルでやっている
- プロアクティブ・セキュリティSDL
- 監査した結果、問題があればプロセス(手順、作業(実装?)、要件)改善を行っている
- 前工程で対策のメリット
- SDLの考え
- 自社開発のため、セキュリティ教育の効果は高い
- 前工程で対策しても、安全確認は手を抜けない
- QA,監査は重要と考えている
- 本質的にアプローチしていくことが重要
- WAFは使わない
- コードを直す方が安い
- 障害ポイントが増える
- WAFは使わない
- プロセス改善を繰り返すことで、セキュアなプロダクト開発を成長させる
- セキュリティ教育がSDLの基本
→再監査費用が2割減(多分余分な修正コストも)
Webサイトセキュリティの最新事情 2009
よく覚えてないwというか会社に置いてきた資料にメモってたw
- 繰り返し検査することで、発見される脆弱性も減ってくる
- 教育を行っている組織では脆弱性も少ない
- 検査して一番発見される脆弱性はXSS、SQLインジェクションはそれほど多くない
ディスカッション
感想
SDLを導入するのに抵抗がなかったことというのが大きいと思う(あ、メモってないw)。経営者だけでなく開発者一人一人にセキュリティ対策が必要という意識が最初からあったのは普通の企業じゃ無理だろうな。開発者にめんどくさい、難しいと思われたら、どんなすばらしい開発規約を作っても、守られないだろうし。
他の会社じゃこうはうまくいかないだろう。多くの開発者にはやはり、セキュリティ対策は難しい、めんどくさいという感じだろうし・・・
後は、「根本的な対策」という言葉が何度も出てきたなぁ。いろいろ脆弱性はあるけど、根本的なことは同じだからねぇ。
しかし、セキュリティに苦手意識がある人をどうすりゃいいかが、今後の問題だろうなぁ。
Webアプリケーション セキュリティ対策は 難しい?
http://webappsec.sakura.ne.jp/modules/wfdownloads/singlefile.php?cid=3&lid=9
セキュメロの資料を公開した。まあ、ツッコミはいろいろあると思いますが、受けます
Pixy
http://pixybox.seclab.tuwien.ac.at/pixy/index.php
PHP用ソースコードチェックツールらしい。後で試す