様々なセキュリティ上の攻撃方法とその対策

# 1. 秘匿情報の漏洩 - 物理的な漏洩
### 起きうる物理的漏洩
* カフェで仕事をしていて画面に表示されている個人情報や会社の機密情報を第三者が盗撮する。
* 自宅や会社のゴミ捨て場に捨てた会社の書類を第三者が持ち出す。
* 部屋の画像を友人に送り、その画像に会社の機密情報が含まれていた。
* 机の上に無造作に放置していた書類やPCを誰かが持ち出す。

### 対策
* 公共の場で個人情報や機密情報が書かれた画面を出さないというのもあるが、気をつけていてもうっかりそのような画面を出してしまうことが考えられるので、そもそも情報漏洩のリスクがある公共の場で仕事をしない。
* 機密書類などは必ずシュレッダーにかけて捨てる。自宅にそのような設備がなければ、会社などに持っていきシュレッダーにかける。またカードやディスクなどは確実に裁断し、PCなどは完全にデータを消去してから廃棄する。
* 部屋の様子など個人情報が写ってしまうリスクのある場所を友人などに送らない。SNSにのっけるなどはもってのほか。
* 機密情報が載っている書類やPCなどは肌身離さず持ち歩く。

# 2. 秘匿情報の漏洩 - 他サイト漏洩の影響
近年様々なWebサービスが開発・運営されており、複数のサービスに対してアカウントを作成している人が多い。そこで他のサイトやサービスの情報が漏洩したことによる秘匿情報漏洩について考える。
### 起きうる漏洩
* 銀行の複数の口座で暗証番号を同じに設定しており、勝手にお金が引き出される。
* サービスの４桁の暗証番号を誕生日に設定しており、自分の生年月日を知った人間がその情報を利用して勝手に買い物や契約をする。

### 対策
* 同じパスワードや暗証番号を使い回さない。
* アカウント管理サービスを利用する。（もっともこのサービスから情報が漏洩した場合のリスクは甚大）

# 3. 辞書アタックと強度の弱いパスワード
### 辞書アタック（辞書攻撃）とは？
* 辞書に載っている単語を延々と試すことでパスワードを解読する解析手法。
* サービスの利用者がパスワードを忘れないように身の回りの名詞や番号を利用することを狙った攻撃手法。

### 強度の弱いパスワードの例
* 誕生日に関連した番号：１月１日（0101）
* 自分の出身地や出身校に関連した名詞：東京（tokyo）、雄英高校(yuei)
* 自分の好きな食べ物やキャラクター：寿司(susi)、ドラえもん（doraemon）
* またはこれらの組み合わせ

### 対策
* 全く無関係なランダムな文字や数字の組み合わせを用いる。
* [最もよく使われているパスワードトップ200](https://nordpass.com/most-common-passwords-list/ "Top200 most common passwords")を参考にここで使われている文字を使用しない。

# 4. 不十分なアクセス権限（パーミッション）
### パーミッションとは
ファイルやディレクトリに対するアクセス権

### パーミッションを表す記号
##### 基本的意味
|英字|数字|意味|
|---|---|---|
|r|4|読み出し可能|
|w|2|書き込み可能|
|x|1|実行可能（ディレクトリだと探索可能）|
|-|0|許可なし|

##### 組み合わせ
上表の読み出し、書き込み、実行それぞれに対してパーミッションを与えるかどうかを考える。
例えば読み書きができるファイルのパーミッションの数字は6となり、英字ではrw-と表される。
この組み合わせを本人、グループ、他人それぞれに与える。例えば後で出てくるCGIのファイルは755という番号が与えられ、英字では-rwxr-xr-xとなる。（先頭の文字はファイルの場合「-」、ディレクトリの場合は「d」と書く。）

参照：[パーミッションの基本の数字と組み合わせ](https://hayakawa.ddo.jp/beginner/ux/permit.html)

また実際にどのように権限を与えるかについて以下の記事にわかりやすくまとめてある。
[Linuxの権限確認と変更(chmod) (超初心者向け)](https://qiita.com/shisama/items/5f4c4fa768642aad9e06)



### パーミッションが必要な場面
* CGIを設置する場合
  * CGIとはクライアント側の要求に応じてWebサーバが外部プログラムを呼び出して実行する仕組み。
  * パーミッションを755とし、本人以外の書き込みを禁止する。
* htaccessが必要な場合
  * htaccessはWebサーバとしてApacheを使用していてサーバ管理者が許可したときに使用可能になるサーバの挙動をディレクトリごとに設定する分散設定ファイル。
  * ファイルやディレクトリへのアクセス制限、Basic認証などが設定可能
  * こちらの記事を参考にさせていただいた。[.htaccessの使い方・設定方法](https://www.webdesignleaves.com/pr/html/htaccess.html)
* 勝手にダウンロードされたら困るファイルがある場合

### 対策
ファイルやディレクトリの権限を確認し、不用意に権限を与えない。

# 5. 不十分な認証方法の実装
Webサイトへのログインやインターネットショッピングでの本人確認で用いられるようなIDやパスワードなどの情報を第三者に見られないようにする工夫を考える。
### 不十分な認証方法の実装例
1.  認証処理をJavaScriptで実装し、HTTPに埋め込む。
2.  Basic認証を用いてHTTP通信を行う。

### 不十分である理由と対策
1. この場合、デベロッパーツールを用いてスクリプトを読めばどのような認証をしているか一目で分かってしまう。対策としては認証処理に関わる実装をフロントでせず、サーバサイドでする。
2. Basic認証ではBase64でエンコーディングした情報をネットワーク上に流すことになるのだが、この情報は簡単にデコードされてしまうため通信が暗号化されていないHTTP通信ではIDやパスワードが流出してしまう恐れがある。対策としては、通信が暗号化されているHTTPS通信を用いたり、盗聴ができないDigest認証を用いたりすることが挙げられる。

# 6. ディレクトリ・トラバーサル
### ディレクトリ・トラバーサルとは？
フォルダ（ディレクトリ）を遡り、任意のファイルにアクセスする脆弱性。
* 例えば`../../etc/passwd`のような入力を与えることでそれぞれのディレクトリの名称が分からなくてもパスワードファイルにアクセスできる恐れがある。
* こういった入力を複数パターン繰り返すことでパスワードの在り処を導ける可能性がある。

### 対策
* ファイルやフォルダのパーミッションを適切に設定する。（パーミッションについては４章参照）
* 公開すべきでないファイルはサーバ上に設置しない。
* 外部から入力されたパラメータでのファイル参照を許可しない。
* 相対パスでのファイル参照を許可しない。

参照：[ディレクトリトラバーサル](https://eset-info.canon-its.jp/malware_info/term/detail/00156.html)

# 7.SQLインジェクション
### SQLインジェクションとは？
外部から意図しないSQLを注入し、不正にデータベースを操作する攻撃。

### SQLの基礎知識
SQLとは、データベースを操作するための問い合わせ言語。
* SQLの基本形
[B]（テーブル）から[C]の条件で[A]（列の値）を取り出す
```sql:SQLの基本形
SELECT [A] FROM [B] WHERE [C]
```

* リテラル
```sql:リテラルの例
-- 文字列型
SELECT id FROM employee WHERE employee_name = 'john'
-- 数値型
SELECT name FROM employee WHERE age >= 25
-- 日付型
SELECT name FROM employee WHERE hire_date >= '2014/12/01'
```

* クォート
  * データの区切り文字として使われる特殊な意味を持つ記号
  * シングルクォート(')を使い、文字列リテラルの範囲を示す。２つで一組。

* コメント
「--」以降はSQL文として無効となる。
```sql:コメントの例
SELECT id FROM employee -- WHERE employee_name = 'john'
```
### 攻撃方法
シングルクォート(')と--(コメント)を使って攻撃。
```sql:通常の認証判定SQL
SELECT * FROM user WHERE id= 'hanako' AND pass= '123'
```
この意味は「userテーブルでidがhanakoでpassが123な行が1つでもあれば認証可、0なら認証不可」

```sql:攻撃目的の認証判定SQL
SELECT * FROM user WHERE id= 'hanako' -- ' AND pass= '123'
```
この意味は「userテーブルでidがhanako~~でpassが123~~な行が1つでもあれば認証可、0なら認証不可」
「' -- 」を挿入することによってpassを設定しなくても認証が許可され、ログインできてしまう。

参照：[SQLインジェクションに関する資料](https://www.ipa.go.jp/files/000062611.pdf "AppGoatを利用した集合教育補助資料-SQLインジェクション編-")

### 対策
* エスケープ処理の実施
  * SQLにおいて特別な意味を持つシングルクォート(')とコメント(--)を普通の文字として解釈されるように処理する。
  * 例：「'」→「''」、「--」→「--'」
  * 参照（p12）：https://www.ipa.go.jp/files/000024396.pdf


* SQL文の組み立ては全てプレースホルダで実装
```sql:プレースホルダ
-- 準備されたSQL文
SELECT * FROM employee WHERE id = '?' AND password = '?';
```
この「?」の部分は確定として、構文の書き換えを防止。入力された値は文字列とした扱われない。

参照：[実際のプレースホルダーの実装例](https://blog.senseshare.jp/placeholder.html "プレースホルダとは何か？SQLインジェクション攻撃を回避せよ！")

* 入力されている情報、データベースに格納する情報が正しいか確認する（バリデーションを行う）
```ruby:バリデーションの実装例
# Productの名前(name)に英数字しか使えないように設定
class Product < ApplicationRecord
  validates :name, format: { with: /\A[a-zA-Z]+\z/,
    message: "英文字のみが使えます" }
end
```

参照：[Railsを用いたバリデーション](https://railsguides.jp/active_record_validations.html)

* WAF (Web Application Firewall)の設置

# 8. OSコマンドインジェクション
### OSコマンドインジェクションとは？
* 外部から意図しないOSコマンドを注入し、システムを不正に操作する攻撃。
* 外部プログラムを呼び出し可能な関数等を使用しているウェブアプリケーションには注意が必要。

### OSコマンドの基礎知識
* シェル
  * OSのユーザのためにインターフェースを提供するソフトウェア
  * 入力されたコマンドをOSに認識されることが可能。
* よく使うコマンド
  * cat ファイル名：ファイルの中身参照
  * ls：ファイルの一覧表示
  * echo "文字"：文字が出力
* 記号文字
  * &&(AND)：複数のコマンドを連結、||(OR)

### 攻撃手法
* ID(tanaka)やメールアドレスに連結してOSコマンドを打ち込む。
```shell:&&を用いた攻撃
tanaka && cat password.txt
```
&&に続く文字が「rm -rf」の場合PC上の全ファイルが削除されてしまう。

### 対策
* OSコマンドを呼び出す関数の使用を避ける。
  * PHP : exec(), passthru(), system()
  * Perl : open(), system(), eval()
  * Python : os.system(), os.popen()
* もし、そのような関数を使用する場合、エスケープ処理を施す
  * PHP : escapeshellarg(), escapeshellcmd()
  * Perl : quotemeta()
  * Python : bleach
* WAF (Web Application Firewall)の設置

参照：[OSコマンドインジェクションの対策](https://www.nttpc.co.jp/column/security/os-command_injection.html)

# 9. XSS（クロス・サイト・スクリプティング）
### XSS（クロス・サイト・スクリプティング）とは？
スクリプトをサイトに送り込み、スクリプトを含むHTMLを出力することでブラウザ上で実行させる攻撃。

### XSS攻撃のタイプ
* 格納型
  * 攻撃は脆弱性サイトのみを悪用。
  * スクリプトを埋め込んだ後は、当該サイトへのアクセスのたびにスクリプトが実行される。
  * 攻撃例：投稿フォームにJavascriptを埋め込んでcookie情報などを投稿するようにしてしまう。
* 反射型
  * 罠サイトと脆弱性サイトの２サイトを悪用。
  * 罠サイト経由で脆弱性サイトにアクセスしたときにスクリプトが実行
  * 攻撃例：偽のショッピングサイトに掲載している商品のリンクから偽のWebサイトにリンクさせユーザーのブラウザで不正なスクリプトを実行させる。

# 10. CSRF(クロスサイト・リクエスト・フォージェリ)
* サイトを横断してリクエストを偽造
* セッションIDを悪用し、ウェブサイトにログインしている利用者に意図しない操作をさせる攻撃のこと。
* ログイン者しか実行できない操作を攻撃者が不正に操作する攻撃。

対策
* 処理を実行するページをPOSTメソッドでアクセスするようにして、hiddenパラメータに秘密情報が挿入されるよう前のページを自動生成する。この秘密情報にsession IDを用いたり推定困難なランダム値を利用する。
* 処理の実行前にもう一度パスワードの入力をもとめる。

参考資料：[安全なウェブサイトの作り方 - 1.6 CSRF](https://www.ipa.go.jp/security/vuln/websecurity-HTML-1_6.html)

# まとめ
* 物理的な漏洩や辞書攻撃などエンジニアでなくてもできるセキュリティ対処は当たり前過ぎて強く意識していなかったので、アウトプットによって改めて強く意識することができた。
* パーミッションや認証については、誰がどのファイルやディレクトリその他データベースの情報などにアクセスして良いのかということをまず設計の段階で十分に洗い出す必要があると感じた。また、他の第三者が見られるようなスクリプトを書いていないかも十分に調べて書く必要があると感じた。
* スクリプティングについては、エスケープ処理を用いて不正な型を送らせないようにすることがまず絶対的に必要だし、そもそもスクリプティングがされてしまうような設計については本当にこの設計でないといけないのかと改めて考える必要があると感じた。