XSS(Cross Site Scripting)
- 不正なプログラムをWebページに仕込み、攻撃対象とは別のWebページに情報を流出させたりすること
- サイトに設置されたフォームにユーザーが情報を入力・送信する際に、埋められた悪質なHTMLスクリプトが実行され、入力された情報に加えCookie情報なども攻撃者に送られます。
*引用
https://www.shadan-kun.com/waf_websecurity/xss/
対策
- スクリプトの構成に必要な&，<，>，”，’の５文字の特殊文字に着目し、これらが文字列としてそのまま画面に表示されるように置換（エスケープ）し、スクリプトの無害化（＝サニタイジング）を行います
- htmlspecialchars関数
- 入力値を制限する
- 例えば郵便番号の入力では、数字以外の入力を許可しないこと
- 入力値の長さに制限を設けることで、攻撃が可能となるスクリプトの挿入をある程度抑制することが可能
CSRF(Cross Site Request Forgeries)
-
Webアプリケーションに対して不正なリクエストを送信する攻撃手法
- 1.ログイン状態で、不正なリンクを踏ませる（「面白い画像を見つけた」とか「プレゼントに当選しました！」とか「至急、口座の確認が必要です！」といった内容)
- 2.このリンクには、Webアプリケーションに対して、勝手に投稿を行ったり、決済したりするような処理が仕込まれており、ログイン状態にあるユーザーがこれをクリックすることで、自分がWebアプリケーションに対してその操作を命令した状態になっ
- 3.処理リクエストを受け取ったWebアプリケーションは、ユーザーからの正規のリクエストだと判断してしまい、実際にその処理が実行されてしまう
＊引用
https://blog.senseshare.jp/csrf.html
対策
- ユーザー側の対策としては、怪しいリンクは絶対にクリックしないこと
- サービス開発側の対策としては、処理リクエストが「正規なアクセスなのかどうか」をチェックしてから処理を行う仕組みを導入
- トークンの確認（一時的なランダムトークンをサーバで発行し、セッションとして保持）
- ブラウザにはセッション Cookie と、トークンを とフォームパーツとして含んだ HTML を返す
- POST された際に、フォームの送信データのトークンと、セッションで保持しているトークンが一致するかで正規なリクエストかどうかを判断する
*引用
https://tech.basicinc.jp/articles/231
- トークンの確認（一時的なランダムトークンをサーバで発行し、セッションとして保持）
SQL Injection
- 第三者がSQLコマンドを悪用してデータベースの情報へ不正にアクセスし、情報を搾取や改ざん、削除する攻撃手法
- サイトに設置されたお問い合わせフォームなどの入力フォームに対し、攻撃者が不正に情報を引き出させるSQL文を入力されるケース
対策
- SQL文の組み立ては全てプレースホルダで実装する
- 変数のように値が変動する箇所」と「データベースへ登録する処理」の間に挟むことで変動する箇所を「値」として処理するしくみ
- エスケープ処理を行う
＊プレースホルダ
- QL文中に変数を埋め込むための仕組みを提供します。SQL文中に「?」または「:name」のような特殊な文字列
＊プリペアドステートメント - データベースへのクエリを実行するための準備が整ったSQL文
プリペアドステートメント例）
$stmt = $dbh->prepare("INSERT INTO REGISTRY (name, value) VALUES (:name, :value)");
セッション固定攻撃
- セッションIDを取得して送り付け、なりすましログインをする
- 攻撃者は、正規サイトにセッションIDを作成する
- 何らかの方法で、利用者に送り付け、セッションIDを強制させる
- 利用者が攻撃者に強制されたセッションIDを使って正規サイトにログインに成功すると、正規サイトではセッションIDと利用者の紐づけを行い記憶
- 正規サイトでは、利用者との紐づけが行われたセッションIDでアクセスすれば、利用者になりすますことができま
対策
- セッションIDの更新
- session_regenerate_id(true);が利用できます。引数にtrueをセットした場合、サーバのセッションファイルを破棄した上でセッションIDを更新します。
- セッションIDの管理をクッキーでのみ扱う
- 認証にはセッションID以外の多重チェックを行う