Webのセキュリティについて

情報セキュリティの３要素##

機密性：アクセスを認められたものだけが、その情報にアクセスできる状態を確保すること

完全性：情報が破壊・改ざん・消去されていない状態を確保すること

可用性：必要なときはいつでもその情報にアクセスできる状態を確保すること

情報セキュリティが維持できず、何らかの損失が発生する可能性を**「リスク」**
リスクを現実化させる要因を**「脅威」**
脅威に対する弱みを**「脆弱性」**と言う。

システムへの攻撃手法##

パスワードクラッキング

IDとパスワードによる認証を行う会員制Webサイトからユーザーのパスワードを抜き出そうとする攻撃

辞書攻撃
→パスワードによく使われる単語をまとめたファイル（辞書）を用意しておいて、それを使ってログインを次々に試してパスワードを当てていく攻撃

ブルートフォース攻撃
→パスワードに使われる文字の全組み合わせをしらみつぶしに試していく方法

パスワードクラッキングを防ぐ方法###

①アカウントロック
https://qiita.com/inodev/items/eeb26ea9408d4627bf0a

まず、deviseのマイグレーションファイルを調整する

db/migrate/20150416180122_devise_create_users.rb

      ## Lockable
      t.integer  :failed_attempts, default: 0, null: false # Only if lock strategy is :failed_attempts
      # t.string   :unlock_token # Only if unlock strategy is :email or :both
      t.datetime :locked_at

    # add_index :users, :unlock_token,         unique: true

User（該当モデル）にdeviseの:lockableを追加。

app/models/user.rb

class User < ActiveRecord::Base
  # Include default devise modules. Others available are:
  # :confirmable, :lockable, :timeoutable and :omniauthable
  devise :database_authenticatable, :registerable,
         :recoverable, :rememberable, :trackable, :validatable,
         :lockable
end

deviseの設定ファイルにロック内容を設定する。

config/initializers/devise.rb

config.lock_strategy = :failed_attempts # 一定回数ログインミスでロック
config.unlock_strategy = :time          # ロック解除条件は時間経過のみ
config.maximum_attempts = 10            # 10回連続ミスでロック
config.unlock_in = 1.hour               # 1時間ロック継続
config.last_attempt_warning = false    # あと1回ミスしてロックされる時に警告を出さない

②パスワードの強度を上げる

/model/user.rb

validate :password_complexity
def password_complexity
  return if password.blank? || password =~ /^(?=.*?[A-Z])(?=.*?[a-z])(?=.*?[0-9])(?=.*?[#?!@$%^&*-]).{8,70}$/
  errors.add :password, "パスワードの強度が不足しています。パスワードの長さは8〜70文字とし、大文字と小文字と数字と特殊文字をそれぞれ1文字以上含める必要があります。"
end

Dos攻撃

短時間にサーバーが処理しきれないような大量のアクセスを行うことで、サービス停止に陥らせる攻撃

SYN Flood攻撃
→TCPのやりとりにおけるSYNパケットだけを大量に送りつけて、サーバーを接続待ち状態にさせることで、別のユーザーからの新たな接続を確立できなくする攻撃

F5
→繰り返しアクセスし続けることで、リクエストへの反応ができないレベルまで、Webサーバーへの負荷を高める攻撃

セッションハイジャック

ログインしてから利用するようなWebシステムの場合、CookieやセッションIDを使って、アクセスしてきたユーザーがログイン済みかどうかを判断している。何らかの手段で第三者がCookieの中身やセッションIDをを取得されると容易に個人情報が取得されてしまう。これがセッションハイジャック。

Cookieの仕組み（https://www.slideshare.net/BurpSuiteJapanUserGr/burpsuitejapanhttp）
↓↓

セッションハイジャックを防ぐ方法###

より安全な方法で、この問題を解決する方法は、セッションの有効期限をサーバー側に保存すること。
https://techracho.bpsinc.jp/hachi8833/2018_10_23/62858

ユーザー認証にdeviseを利用している場合
deviseに組み込まれている「Timeoutableモジュール」を有効にする。このモジュールは、ユーザーセッションが期限切れかどうかの検証を行う。これを利用するには、アプリでユーザーを表すモデルの中でこのモジュールを次のように有効にする必要があります

Ruby.User.rb

class User < ActiveRecord::Base
  devise :timeoutable
end

次にdeviseイニシャライザのtimeout_inオプションに必要な値（デフォルトは30分）を設定

Ruby/config/initializers/devise.rb

# ==> Configuration for :timeoutable
# The time you want to timeout the user session without activity. 
# After this time the user will be asked for credentials again. 
# Default is 30 minutes.
config.timeout_in = 30.minutes

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

エンドユーザー側がWebページを制作することのできる動的サイト（Twitter・掲示板）などに対して、自身制作した不正なスクリプト（java/HTML等）を挿入するサイバー攻撃。エンドユーザーが被害者となることが一つの特徴。

1.攻撃者CがXSSに対して脆弱性のあるA社を発見し、A社に興味を持ちそうなユーザーのいる掲示板サイトBに罠を仕掛ける（例：スクリプト付リンクを貼る）。
2.ユーザーが掲示板サイトBを閲覧する。
3.掲示板サイトB内でスクリプト実行
4.ユーザーはスクリプト情報を持ったままA社のページに移動（クロスサイト）する。
5.スクリプトの効果により「A社のサイトとして」表示された偽サイトにジャンプする。
6.騙されたユーザーが情報を入力した結果、スクリプトが悪さをする
7.攻撃者Cの手により、ユーザーに対して様々な被害が発生（マルウェア感染・攻撃者Cへの情報漏洩など）。

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

ログインが必要なサイトに対して操作を行うリンクにユーザーがアクセスすることで被害を受ける攻撃