最低限知っておくべきwebサイトのセキュリティ

Webサイトを構築する上で新人向けの説明用に必要な前提知識をまとめる。
以前同じタイトルで書いた事があるけど、今回はもっと初歩から解説します。

普通のセキュリティといえば、ドアの戸締りとかガスの元栓を締めたりする事ですが
Webサイトのセキュリティといえば、Webサイトのサービスを災害から守ったり、
悪意のある利用者からの不正な利用や、誤操作によるデータの破壊や流出等から
守る事です。
Webサービスでは以下の様な箇所のセキュリティを意識する必要があります。

1. Webサイトのアプリケーション
2. アプリケーションを設置しているサーバ
3. サーバを設置している場所
4. サーバをネットワークに接続するインフラ環境
5. サーバやアプリケーションを保守する管理者の端末
6. 利用者のブラウザ

今回は、Webサービスについて主に解説しますので、それ以外の項目について先に簡単に説明します。

アプリケーションを設置しているサーバ

LinuxだったりWindowsだったりすると思いますが、サーバの提供するサービスに、セキュリティホールが見つかるとすぐに対策をする必要があります。
先日もDebian系のディストリビューションのSSH等に誰でもログインできる様なセキュリティホールが見つかりました。

サーバを設置している場所

誰でも触れる様な場所にサーバがあると、サーバを盗んだり、破損させたり、データを抜き出したりができる様になります。
入退室の管理をしっかりと行い、一部の人間のみが入れる様な環境を構築した方がベターです。

サーバをネットワークに接続するインフラ環境

回線が頻繁に切断される様な状況であったり、外部からのアクセスをFWによって監視していない状況であると、予期しないアクセスを行われる事があります。

サーバやアプリケーションを保守する管理者の端末

サーバが以下にセキュアでも管理者の端末にパスワードがかかっておらず、誰でも操作できる様だと、そこから情報の流出やサービスの破壊が行われるリスクがあります。

利用者のブラウザ

利用者のブラウザの設定によっては、内部のクッキーを外部のサイトに垂れ流したり、ウイルスに感染して入力している情報が流出している可能性もあります。

Webサービスのセキュリティ

一般的に以下の様な攻撃方法があり、対策の必要があります。

1. XSS(クロスサイトスクリプティング)
2. CSRF(クロスサイトリクエストフォージェリ)
3. パラメータ改竄
4. セッションハイジャック
5. セッション固定攻撃
6. SQLインジェクション

XSS(クロスサイトスクリプティング)

ユーザの入力した内容を表示する場所(掲示板のコメントとか)に、javascriptのソースコード等を張る事で、攻撃者が他のユーザに任意のコードを実行させる攻撃を言います。

対策方法

文章内容をサニタイズ(& を & に、< を < に、> を > に、" を " など)したり、許可する構文のみに限定し、構文に当てはまらない入力値をはじく様にします。

Railsでの対策

<%= params[:nyuryokuchi] %>ではなく、全部<%= h params[:nyuryokuchi] %>と、hを使います。
社内では表示時にhタグをつけないとエラーにするsafe_erbを使うプロジェクトもいくつかあります。

CSRF(クロスサイトリクエストフォージェリ)

リンクにパラメータをつけ、そのリンクをクリックしたユーザーに意図しない操作を強制させる攻撃です。

対策方法

主にGETでurlの末尾に?等でつける攻撃が多いので、postのみに限定するだけでも
掲示板からの攻撃は減る。(ちゃんとした対策じゃないけど)
セッション情報を種に乱数を使ったトークンを生成して、入力画面からそのトークン情報も送る様にし、作成画面で、トークン情報がセッション情報と一致するかを確認する。

Railsでの対策

フォームを記述する時にform_tag メソッドを使って記述する。

パラメータ改竄

hiddenパラメータやコンボボックス等のパラメータを、ソースコードの記述内容を変えて、送るパラメータを想定外のパラメータにする攻撃。

対策方法

送られてきたパラメータのチェックや権限の確認を確実に実施する。
また、そもそもそういったパラメータはサーバ側で管理する。

Railsでの対策

対策方法に準じる。
データ生成に限ってはvaildateを使って確実に確認するのは有り。
自分のユーザー情報を見る画面の設計を/user/show/1等にして、
idを変えたら他のユーザーの個人情報が見れる等もっての外。

セッションハイジャック

他人が利用しているセッションのidを使ってアクセスすることで他人になりすます攻撃。
ログイン済みのユーザーのセッションをハイジャックするとそのユーザーでログインしたように扱われる。

対策方法

セッションIDを、長くユニークな類推できない物にする。(1,2,3....の様なのは最低)
セッションの判別にIPアドレス等も含める。
盗聴されない様、sslを利用する。

Railsでの対策

セッションIDは既に長くユニークな類推し辛い物なので、セッションの判別にIPアドレスを追加するくらい。

セッション固定攻撃

CSRFとセッションハイジャックの合わせ技の様な行為。
リンク元にセッションIDを付加して、利用するセッションIDを特定させる。

対策方法

セッションの判別にIPアドレス等も含める。
セッション利用時にセッションを初期化する。

Railsでの対策。

rails1.2.6で対策された。
あげるとするとセッションの判別にIPアドレス等も含める。
ログイン時にセッションを初期化する等

SQLインジェクション

SQL文に利用されそうなパラメータに、作成者の想定外の文法を書く事で不正な動作を起こさせる攻撃。
ログイン画面で、user_id,passwdというパラメータが有った場合、
"select * from users where user_id = '" + params[:user_id] + "' and passwd = '" + params[:passwd] + "'"と書かれていると類推して、
passwd に [' or '' = ']等と入力する等

対策方法

入力値をチェックしてからsqlを実行する。

Railsでの対策方法

ActiveRecordのconditionsを書く際、?を確実に使う。
正：User.find(:first,:conditions => ["user_id = ? and passwd = ?", params[:user_id], params[passwd] ])
誤：User.find(:first,:conditions => "user_id = '#{ params[:user_id] }' and passwd = '#{ params[:passwd] }'")

というわけでセキュリティについてまとめてみた。
「これもいるんじゃね？」って奴あれば是非教えて下さい。