# 2021/02/21 メンター相談

# 自作でCSRFトークンを生成するAPIサーバーを作ろうとした場合、トークンの乱数生成はどのような観点で仕様を考えたらいいでしょうか？
## 乱数衝突
- 他の文脈でもIDの衝突の考慮する場合がある
- UUIDv4モジュールを使っている
- https://www.npmjs.com/package/uuidv4
- この値がどれだけcollisionが発生するか
- 結構天文学的な数字なので、UUIDとかに使ってもほぼほぼ衝突しないはず
- 今回のCSRFの場合、セッションごとに一時的に作るものなので、あまり衝突を気にする必要がない
## 長さ、文字列
- あまり気にしたことはなかった
- ライブラリのデフォルトの長さを使っていた
## CSRFトークンを作る時の注意
- CSRFトークンをアプリ全体で1つに統一して使い回すのはNG
- AさんBさんがいて、Aさんが悪意あるユーザの場合、同じCSRFトークんなので、Bさんへの攻撃に利用される可能性がある
- 昔徳丸さんが、この共通で1つのみ用意することを記載していた本の批判をしてたことがあった
- https://blog.tokumaru.org/2015/06/webcsrf.html
- 文字列比較の仕様を突いた脆弱性には注意する必要がある
- トークンを比較する時に、compareStringにある値を指定するとnullになってしまうなど
- トークン検証を自前で作って思わぬミスを産んでしまう場合あり
- https://blog.tokumaru.org/2018/11/csrf_97.html
## セッションの種類
- リクエスト単位
- ブラウザバックした場合に注意
- ブラウザバックすると、元画面の時のトークンから変わってしまうので、操作が失敗する場合がある（銀行とか）。なのでリクエスト単位でトークン生成している場合は、ブラウザバック時の挙動もチェック必要
- セッション単位
- CSRFトークンは、ユーザに見えてしまうということを念頭に！

# リクルートにいた時、アプリケーションのQAはどのように行われていたのか教えていただきたいです。
## ゼクシィ縁結び
- 各チームにリーダーがいた
- リーダとテスト作るチームが集まって、テストを作成
- 最初はQAチームがユーザ目線で基本を作るが、技術的側面に関してのコメントをリーダ含めて行う
- 先に開発者の目線で作成すると、ユーザー目線のケースが抜ける場合があるので、QAチームに先に作ってもらってた
- メンバー人数
- 各モジュール3~5人×モジュール4つほど = 計20人ほど

# HTMLをそのまま出力しなくてはいけない時にそのメソッド(ReactだとdangerouseInnerHTML)を使うとき、使っても大丈夫かどうかの判断ってどのように行なっているでしょうか？
- 中のメソッドを見ることはしてない
- その前にサニタイズをしていることが多い
- DOMPurifyなどを使って、きれいにしてから、dangerouseInnerHTMLのメソッドを使う
- https://github.com/cure53/DOMPurify
- dangerouseInnerHTMLを使うタイミングは？
- プレビュー機能を作りたい場合
- ユーザーが入れたコードを直接、プレビュー機能として表示させたい場合
- マークダウン でユーザーが入力してくることが想定されるアプリなど
- HTMLからマークダウン への変換は、サニタイズとは違う！
- react-markdown
- dangerouseInnerHTMLを使わないライブラリ
- そういった安全なライブラリを探すのもあり

# 前回のメンターセッションでクローラーやイタズラは排除しているとのことでしたが、それはどんな風に排除しているのでしょうか？
## クローラ
- 行儀の良いクローラ
- ロボットテキストをつける
- 許可されているページのみクローリング
- これで問題なし
- 行儀の悪いクローラ（スクレイピングなど）
- googleのrecaptchaを入れてしまうなど
- これが使えない場合は、ログ監視をする
- kibanaというアクセスログの監視ツール
- アクセスログは頻度は高くないので、その場合はアプリケーションログを見ることになるので、アプリケーションの設計に依存する
- ただbanすると、すぐに別アカウントを使い始めていたちごっこになるので、banするよりもbanしないで、そういう傾向を察知する方が良いかも
## Fraud DetectionのSaaS市場
- 海外で注目されている
- 決済でよく使われてる
- 犯罪で使われた住所などのデータをためておき、それを検知したら排除するなど
- リクルートにいた時に注目されていたのが、Sift
- https://www.g2.com/categories/fraud-detection
- frau deetection saas
- https://sift.com/products/payment-protection

# 個人情報が流出した時に何件個人情報が漏れたとか発表していますが、それはログなどからある程度とれるようにあらかじめをログを設計しておくものなのでしょうか？
- 漏れ方にもよる
## 障害発生時の対応手順
- [「障害対応とポストモーテム」の障害発生フロー](https://quipper.hatenablog.com/entry/2019/11/27/080000/incident-response-and-postmortem)に沿っていることが多い
- プラハの会社全体で障害対応が決まっているわけではないが、リクルート出身者が多いので、Quipperのこの手順にそうことが多い
- 調査する時はアプリケーションログを見るので、とっておくにこしたことはない
- 影響範囲の調査
- ログをみて、XSSならばscriptタグで検索したり
- PHPのライブラリかフレームワークかの脆弱性でセッションが入れ替わった時があり、何人が入れ替わったのか調査が発生したことがあった（大変だった、、）
- 機械学習に異常検知もある
- https://www.sbcloud.co.jp/entry/2020/10/28/elasticsearchML
- Googleだとポストモーテム（直訳で死後）という形式で障害の振り返りを行う
- https://sre.google/sre-book/example-postmortem/

###### tags: `メンター相談`,`2月`