@IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- @IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
WEBアプリケーションの脆弱性検査を行っていますか?
1
投票結果総投票数:30 | |||
---|---|---|---|
なにもしていない。 | 10票 | 33.33% | |
SQLインジェクション検査ぐらいは行っている。 | 9票 | 30.00% | |
XSS検査までなら行っている。 | 8票 | 26.67% | |
完璧! | 3票 | 10.00% | |
|
投稿者 | 投稿内容 | ||||||||
---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2005-07-10 23:29
SQLインジェクション,XSSに代表されるWEBアプリケーションへの攻撃
が後を絶ちません。 本来ならば、これらの攻撃に対する脆弱性検査がテスト工程において 行われ、システムリリース前にセキュリティホールが潰されているべ きであると思いますが、私が今まで携わってきたWEBシステムでは、 社内向けシステム、一般ユーザ向けシステムのどちらにおいても脆弱 性に関するテスト項目は存在しませんでした。 一般的に脆弱性テストはどの程度まで行われているものなのでしょう か? | ||||||||
|
投稿日時: 2005-07-11 12:09
どもです。がると申します。
初手にシビアな突込みを。 「完璧に投票した方はもう一度見直しましょう」 理由は言わずもがな。0.1歩くらいまちがえると、どこぞの社長のごとき 「完璧なセキュリティ」が発生します :-P さて。
まぁ正直そんなモンでしょう。お金にならないですし:-P セキュリティが甘いことで「損益がしゃれにならない」ことがもう少し 身に染みれば状況も変わってくるんでしょうけれどねぇ。
一般の定義が難しいところですが。 昨今のニュースを見ている限りですと「やってない」んでしょうね :-P 私の場合ですと、脆弱性リスト(自作)をベースにテスト項目を作ります。 もっともその前に、そのリストを使って「設計を」するのですが :-P # 設計段階でミスると後が大変なので。 | ||||||||
|
投稿日時: 2005-07-11 13:01
全くやってないところがほとんどのような「気がする」です
ファイアウォールとかIDSとかの箱モノを買ってくれば セキュリティが得られる、と思ってる人が上のほうには 多いような。 素人質問で恐縮ですが、Webアプリケーションの脆弱性って、 テストで簡単にみつけられるものなんでしょうか? | ||||||||
|
投稿日時: 2005-07-11 13:30
二重投稿に、時間が大分経過してから気づきました(苦笑
削除できないので修正だけ行います。 [ メッセージ編集済み 編集者: がるがる 編集日時 2005-07-11 16:41 ] | ||||||||
|
投稿日時: 2005-07-11 16:34
こんにちは。
SSL使ってるから大丈夫だろ!とかおっしゃられるお偉いさんもいたりしました。
うーん、やっぱりセキュリティ意識レベルの高いSEさんになってくると、しっかり やっているのですね。 私はまだまだどの部分に脆弱性が存在する可能性があるかを完全に把握出来ていな いので、どこまでテストをすればほぼ安全なシステムであるといえるのかが分から ず、恐怖に怯えながら設計をしています。。 | ||||||||
|
投稿日時: 2005-07-11 17:10
脆弱性になりうる部分って、それほど多くは無いから整理して覚えれば難しくは無いはずです。WEBアプリケーションを作る上で考慮する必要があるのはたぶん、以下の3つぐらいですよね。 ・セッションハイジャック ・バッファオーバーラン ・XSS脆弱性、SQLインジェクション、OSコマンドインジェクション等、ブラウザから送られる値の未チェックに起因するもの せいぜいこの程度ですよ。 後は脆弱性と言うよりは、攻撃手法として2つ。 ・ブルートフォース ・DNSハイジャック(ファーミングも含むのかな?) | ||||||||
|
投稿日時: 2005-07-11 18:08
情報提供ありがとうございます。 WEBサーバ設定周りは考慮外とすると、 1.セッションIDには推測不可能なものを使用。 2.クッキーに余計な情報を書き込まない。 3.hiddenフィールドに書き換えられてはまずい情報を使わない。 4.HTMLエンコード。 5.DBに格納する入力文字列のサニタイジング。 あたりをマークすれば、とりあえず安全だろうと言えるのでしょうか? Javaで考えるならば 1.はコンテナが発行するHTTPSessionを使用 2.はSessionID以外に使用しない 4.はView周りのフレームワーク任せ 5.はPreparedstatementを使う ことで対応して、 3.のhidden関連の設計だけ頭を使って考える。の対応でなんとかなりそ うだと認識していますが、やっぱりちょっと不安だったりします。。
うわ、こんなのもあるんですね・・・ |
1