2
0

More than 3 years have passed since last update.

セッションを用いたセキュリティ攻撃の知識

Last updated at Posted at 2021-03-24

本記事について

プログラミング初心者がセキュリティ攻撃に関する知識とその対策について学んだので、その備忘録として載せております。

どうかお手柔らかにお願いいたしますm (- -)(_ _)ペコリ

セッション

webサービスにおいて情報を一時的に保存しておく仕組み(概念)
利用者の状態を保持するために使用
保存先はクッキー

クッキー

ブラウザにある一時的に保存できる保存場所

セッションハイジャック

XSSなどを用いて、正規利用者ではない者が正規利用者のセッションを取得する手法
セッションが保存されているクッキーを狙った攻撃
セッションIDを盗み出す、または乗っ取る攻撃

クッキーにあるセッションIDという識別番号を盗み出すとセッションハイジャックが成立
クッキーにはセッションIDという識別番号を用いて保存している。

セッションID

通信中の正規利用者(クラインアント)へ付与される、固有の識別情報
正規利用者を識別するために付与される固有の番号
→ログイン情報などが含まれている

セッションハイジャックをされると正規利用者できる大概のことができてしまう。
→送金や物品購入などができてしまう。

セッションIDの推測

セッションIDの生成規則に問題があると第三者に予測される。
外部から参照可能な値を用いてセッションIDを推測する。

対策として独自でセッションIDの生成を行わなわず、フレームワークなどの開発ツールを利用する。脆弱性が発見された場合も素早く指摘改善が見込まれるため。

セッションIDの盗み出し

JavaScriptではというスクリプトでクッキーの情報が表示でき、このスクリプトに変更を加える。攻撃者側にユーザーの情報を送るようにする。

対策①
特殊文字等によるXSSの対策を講じる

対策②
SSLを用いる

SSL(Secure Socket Layer)

インターネット環境の安全性向上のため、インターネット上の通信を暗号化してくれる技術
→第3者の情報の盗聴や改ざんを防げる

デプロイするHerokeではhttps://<アプリの名前>.heroku.com/となっており、SSLに対応している。

SSLに対応したwebアプリケーションなどのURLはhttps://から始まる

対策はXSSを防ぐことや安全なネットワーク環境を用いることが有効

セッションIDの強制

セッションIDの固定化
セッションIDを攻撃者が外部から強制的に固定する

①攻撃者は普通の利用者としてセッションIDを取得
②ユーザー(正規利用者)に対しての①で取得したIDを強制
③ユーザーは標的アプリケーションにログイン
④攻撃者はユーザーに強制したセッションIDを使って標的アプリケーションにログイン

対策としてはログイン後にセッションIDを変更する。固定化されないように常に変更し続けることが重要。認証を都度変更することが大事。

deviseでも固定化への対策等が行われている。

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

webアプリケーションなどへ不正なリクエストを行う攻撃手法
攻撃者が正規利用者になりすましてリクエストを送る攻撃
→ログイン情報などを盗み出されアカウントが不正利用される。
 利用者の所持している金銭が利用される

別のサイトを経由して不正なリクエストを行うことからクロスサイト(サイトをまたいだ)リクエストフォージェリ(リクエストの偽装)と言われる。
→サイトをまたいだリクエストの偽装

XSS クライアント側の脆弱性
CSRF サーバサイド側の脆弱性
→総合的な対処が必要

CSRFはすべてのリクエストに行う必要はなく、どのリクエスト対して脆弱性対策が必要かを考えることが重要
他ユーザーから勝手に実行されては困るようなリクエスト(物品購入処理やパスワード変更等)

HTTPメソッドのデータベースの情報が書き換えられるためのリクエスト

リクエストが不正か否かを判別する手法
対策①パスワードの再入力
CSRF対策以外にも物品の購入などにおいてノイ利用者の意思の念押し、共用のPCにおいて正規利用者以外の利用者が重要な処理を実行するのを防ぐ、パスワード変変更等において効果あり

対策②リクエストへのトークン(秘密情報)の埋め込み
攻撃者が知り得ないトークン(秘密情報を)を要求するようにする。

トークン

1度だけ使用可能なパスワード
ユーザーの認証に用いられれる秘密情報
ユーザーのブラウザ上のみに保管されるもの

Ruby on Railsのフォームのヘルパーメソッドはトークンをおいている。トークンはログイン情報と照らし合わせることができるため、不正なリクエストかどうか判別できる。送信者のブラウザで保存されたトークンなので、固有のものとなるため。

トークンが存在するのはPOST、DELETE、PATCH、PUTなどのHTTPメソッドの時のみ、重要な処理についてはこれらのHTTPリクエストのメソッドになるようにする、

CRSFを防ぐにはトークンを埋め込んだりパスワードを再入力させたりするなどして、リクエストの際正規利用者しか知り得ない情報を用いることが有効。

以上です

2
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
0