コーディングと脆弱性
脆弱性のうちコーディングだけで対策できるものと、設計時に対策しないといけないものがあるんではないかというのを前々から考えていたりする。当然、設計時に対策するものについては、実装であるコーディングでも対策は必要といやぁ必要だろう。
まあ、コーディングだけで対策できるものも場合によっては、設計時に検討するフレームワークやツールで何とかなるものもあるだろう。
とはいえ、コーディングがもっとも重要な防衛ラインといえるだろうなぁ。
というわけで、コーディングだけで対策できそうなWebアプリの脆弱性といったら以下のものがあげられるかなぁと。
- XSS
- 各種インジェクション系
- ディレクトリトラバーサル
- バッファオーバフロー（ほぼ無いけど）
他にもあるかも。
いずれも、自由に開発できるアプリor関数、メソッドと他のアプリ（DBとかブラウザとかOSとか）or他の関数、メソッドとの境界で発生するものだ。コーディング時に外部とのやり取りを行うデータがどういったものがあるのか、それは常に開発者自身が意図したものなのかといったことを検討しないといけない。こういった部分は、設計などの上流工程で対策しようとするのは不可能ではないが難しいと思う。
なので、どうしてもプログラマの力量にかかってくると思う。しかし、現状では境界部分の重要性が十分に検討され、脆弱性対策できているわけではない。
これは、正しいコードと間違ったコードが世の中に広まってないからかなぁと思う。
やっぱり、間違っているサンプルコードではなく、間違っている生きたコードと、正しい生きたコードのデータベースみたいなのが欲しいなぁ。
Hiddenは危険？
ってことはないんだけど、実際のところ、Hiddenにエスケープ漏れや妥当性検証漏れって言うのが発生しやすいというのが現状だと思う。これは、HiddenがTextとは違って、一見するとブラウザから変更できないように見えるからじゃないかと思う。実際、脆弱性が見つかることが多いのは、Hiddenだったり、Option、Checkboxだったりするしなぁ。
Hidden全てにおいて必ずエスケープ、や妥当性検証ができるのであれば問題ないけど、それができなくて、エスケープ漏れ、検証漏れが発生する危険性を減らせるのであれば、Hiddenを必要最低限しか使わないという規約もありじゃないかと思う。全然いい規約じゃないけどね。
って書くとHiddenは危険脳っていわれるかなぁ。
