簡単な情報セキュリティのお話

理想のセキュリティとは

情報セキュリティの理想は不正アクセスや情報漏洩を防ぎつつ、便利に使用できる状態を保持することにあります。そのためには３つの要素の維持が必要になります。

３つの要素

1. 機密性－権限を持たない人が情報を見たり使用ができないようにする
2. 完全性－権限を持たない人が情報を書き換えたり、消したりできないようにする
3. 可用性－権限を持つ人がいつでも利用したい時に利用できるようにする
   
   

上記の要素が弱いことを脆弱性と言い、対策を行わないと以下のような問題が発生する可能性が高くなります。

発生が懸念される問題

• 個人情報が勝手に閲覧される（漏洩）
• webページの内容が改竄される
• webページ自体が閲覧不可能になる
  

問題が発生する理由としては以下のような理由が考えられる。

1. バグによるもの
2. 開発者側のセキュリティチェック不足
   
   
   
   
   
   
   

通信について

通信プロトコル

別々のデバイス（パソコンやスマホ）が信号やデータを通信によって情報の伝送を行っているが、その別デバイス同士がデータを伝送し合うために決られた（約束事）のことです。

このプロトコルをクライアント側（自分達）とサーバー側で統一することで通信をすることができるようになります。

「HTTP」はプロトコルの１種でwebページを構成するHTMLファイルやCSSなどのスタイルシートをデータにして通信することでwebページを表示させています。「HTTP」はステータスコードによってクライアント側にリクエストとサーバー側からのレスポンスを表示しどんな状態かを知ることができます。

HTTPステータスコード簡易一覧表

以下の一覧のようにステータス番号によってサーバー側からの大まかな返答の意味を知ることができます。この番号を確認することで不具合の原因を調べやすくすることができます。

ステートレス通信とは

サーバー側がクライアントのアプリケーション状態を管理していない状態の事でサーバーから返ってくる信号はリクエストされた情報の全てになります。

利点は、サーバー側はクライアント側のリクエストに対してそのままレスポンスするだけなので実装が簡略化できる。

欠点は、毎回全ての情報をレスポンスしている為、情報量が増えてくると負荷が大きくなってしまい、通信速度が遅くなるなどの状態になる。

ステートフル通信とは

サーバー側がクライアント情報をCookie（クッキー）を使ったセッション管理で維持しておくことでクライアントだけの情報をレスポンスできる仕組み。
例：ECサイトのカート機能

利点は、クライアント特有の情報の保持をすることができる

開発などをする場合は必要に応じて使い分けることが大事！

セッションとは

上記の説明で出てきたセッションについての説明です。

セッションは、ログインした時にユーザーの情報をログアウトするまで保持する操作のことです。識別子をセッションIDやセッショントークンと言ったりします。

Cookie（クッキー）

クライアント側のブラウザに保持することができる情報の事でこの情報がある事でSNSやwebサイトが快適に見れたり、ショッピングが安全にできるということになります。

代表的なサイバー攻撃の手法と対策（４種類）

XSS（クロスサイトスクリプティング）

HTML生成に問題があると、外部よりスクリプトを埋め込まれてCookieを盗まれたする攻撃手法。Javascriptによって攻撃されることが多い。

攻撃例としては、一般ユーザーがスクリプトを埋め込まれたサイトを閲覧した場合、ブラウザ上でスクリプトが実行されることで個人の情報が盗まれてしまうという被害になってしまいます。

XSSの対処方法

例えば、webサイトのinputタグに　<script>alert（”ヤッホー”）</script>　のようなスクリプトタグを打ち込んだとするとJavascriptによって画面にアラートが表示された場合、そのサイトには脆弱性が見られるので文字参照を使ってスクリプトタグを認識させないようにするなどの方法があります。
ちなみにRailsにはこの対策は埋め込まれています。

文字参照とは
エスケープすると言ったりします。
HTMLでは「＜」や「＞」などの記号をブラウザ上に表示させようと思うと特殊文字を使ってあげないと表示ができないので、その機能を使ってinput
タグのような文字入力をするタグから入力された値を特殊文字に変換することで対策を行う手法。以下に文字参照の例を記載。参考サイト

SQLインジェクション

SQL文の呼び出しにおいて、意図しないSQL文を実行させることで攻撃を行う手法です。
被害例としては、

• データベース内の全ての情報をが外部から盗まれる
• データベースの内容が書き換えられる
• IDとパスワードを使わずにログインされる
• その他サーバー上のファイルの読み出し、書き込みをされる

原因としては、ユーザーからの入力がアプリケーション内部でSQL文として処理されてしまうことが原因になっている。参考サイト

SQLインジェクションの対処方法

• SQL文中で意味を持つ特殊文字をエスケープする（XSS参照）
• バインド機構を使う

バインド機構とは

ユーザーからの値を割り振る前にそのままデータベースを処理する所に送られ、SQL文の構造を確定する仕組み。
具体的には、where句の条件にプレースホルダーと言う機能を使うことでSQL文の構文を確定することで入力された値は、ただの文字列として判断させるようにすることで対策を行う方法。

＃「？」の部分がプレースホルダーに当たる
SELECT * FROM user WHERE user_id=? AND password=?

CSRF（クロスサイトリクエストフォージェリ）

攻撃者は罠用webサイトにスクリプトや自動転送（HTTPリダイレクト）をしこむことによって、一般の利用者が使用しているwebサイト（ショッピングサイトなど）の情報（パスワードなど）を意図せず書き換えてしまう攻撃方法。

攻撃順序

1. 利用者はショッピングサイトにログインしている
2. 攻撃者は罠サイトを用意
3. 利用者は罠サイトを閲覧
4. 罠サイトからログインしているサイトにパスワード変更などの指示が送信される
5. ショッピングサイトのパスワードが書き換わってしまう

CSRFの対処方法

「重要な処理」に対するリクエストが利用者の意図によるものかどうかを確認する必要がある。

• CSRF対策の必要があるページを区別する
• 正規利用者の意図したリクエストを区別できるように実装する
  
  
  
  
  

CSRF対策の必要があるページの例

• 購入確定画面
• ユーザー情報の更新など
  
  
  

正規利用者が意図したリクエストを区別する方法

秘密情報の埋め込み－トークンの事

パスワードの再入力

Refererのチェック

Railsでの対策方法は簡単

アプリケーションのコントローラーに以下の記述を施す。

class ApplicationController < ActionController::Base
  # Prevent CSRF attacks by raising an exception.
  # For APIs, you may want to use :null_session instead.
  protect_from_forgery with: :exception
end

セッションハイジャック

正規利用者ではない人がセッションIDを乗っ取る攻撃方法です。正規利用者の個人情報閲覧、送金、物品購入、なりすましメール送信、SNSでの犯罪予告など、加害者側が正規利用者のIDを使ってやれることは多岐に渡ります。参考サイト

攻撃手法

セッションIDの推測

セッションIDの生成に規則的な問題があった場合にIDを予測され悪用されること。
生成規則に問題があるセッションIDは以下のようなものを元にして生成しているものが多い。

• ユーザーIDやメールアドレス
• リモートIPアドレス
• 日時
• 乱数

そのうちユーザーIDや日時は外部から参照可能な為、セッションIDを推測しやすくなってしまう。
webアプリケーション開発ツールが持つセッション管理機構を利用するのが安全と言われています。

セッションIDの盗み出し

セキュリティに不備があるネットワークを使うとcookieが盗聴される。
盗聴を防ぐ方法にはSSL（Secure Socket Layer）、インターネット上の通信を暗号化してくれる技術を使うことが多い。

セッションIDの強制（または固定化）

攻撃手順

1. 悪意のある加害者は普通の利用者としてセッションIDを取得
2. 加害者に対して取得したセッションIDを強制
3. 被害者は標的アプリケーションにログイン
4. 悪意のある加害者は、被害者に強制したセッションIDを使って標的アプリケーションにアクセスする

対策として行われていることは、利用者の認証が完了した時点でセッションIDを変更するという方法です。そうすることで、認証前にセッションIDが固定されても認証後にセッションIDが変わる為、固定されたセッションIDでアクセスができなくなる。

セッションハイジャックの対処方法

Railsでは対策が簡単にできます。
セッションの盗聴への対策は、アプリケーションのconfig/environments/production.rbファイルの以下の記述のコメントアウトを外してあげればokです。
それによりアプリケーションを公開する際に先ほど紹介したSSLを使い通信経路を暗号化してくれます。

config.force_ssl = true

セッションの固定化への対策は、ログイン成功後に古いセッションを向こうにし新しいセッションIDを発行する方法です。
セッションを再発行したいアクションないに以下の１行を指定することでセッションの固定化を防ぐことができます。

reset_session

長くなってしまいましたが以上でセキュリティの基礎を終わります。