LINE Login ではじめる 「とりまセキュリティ」 あかこう（@_akakou） 

専門：匿名認証技術、Trusted Device 資格試験 情報処理安全確保支援士（未登録） ウェブ・セキュリティ実務試験 あかこう（赤間 滉星） 慶應義塾大学 政策・メディア研究科 M1 自己紹介 1/2 Xアカウント：@_akakou ２ 

自己紹介 2/2 Yahoo主催のハッカソンによく参加 Hack Day 入賞 × 3 Hack U 優勝 × 3 元「真のLYインターン生」を自称 Yahoo（2022夏）インターン参加 LINE（2023夏）インターン参加 ３ 

アジェンダ 最近考えてる「仮説」の話 作ってみたモノの話 仮説検証のために実験した話 1. 2. 3. ５ 

最近考えてる「仮説」の話 1. 

背景 専門家ではないため、対策をしたとしても不完全である セキュリティにかけるコスト（時間、金）がない すぐ使える攻撃遮断システム（WAF）は遮断漏れがある 個人開発のWebアプリに対するセキュリティ対策はとても難しい →個人開発のセキュリティが深刻な問題に 7 

とりま （＝とりあえず＋まぁ） 

LINEでなんでも ログインすれば 攻撃防げね？ 

仮説 LINE Loginで常にログインを要求すれば、攻撃を防げるのでは？ （≒身元確認によって、攻撃を防げるのではないか） 理由1. 多くの攻撃は無差別なスキャンなため 理由2. BAN（失効）することで攻撃コストをあげられるため 理由3. 攻撃者を追跡して責任を追求できる（かもしれない）ため とりま 10 

/admin.php /admin.php /admin.php 「その前に 認証して！」 理由1. 多くの攻撃は無差別なスキャン 多くの攻撃はBotによる無差別なスキャン →Botはアカウントを持たないため、認証を要求するだけで防げる Botはアカウントを持たない ため、ブロックできる Bot サイトA サイトB 常にLINE Login するサイト https://www.cscloud.co.jp/news/press/202302215611/ 無差別な攻撃の割合は とても多い 個人開発サイト ではもっと増え る可能性 !? 44％ 11 

理由2. BANすることで攻撃コストをあげられる BANによって攻撃のコストを あげる（抑止効果） 日本の※電話番号が必要であ り、アカウント作成にコストが かかる 特にBANされた後に、もう一度 アカウント作成するのは大変 　（別の電話番号が必要） ③攻撃 ①電話番号 ②LINE アカウント サービス 攻撃者 LINE（Login） ④BAN 攻撃までの コストが高い 12 ※地域の設定が必要 

LINE Login （＋携帯通信会社） 理由3. 攻撃者を追跡して責任を追求できる 追跡できる状態にすることで、攻撃のリスクを上げる（抑止効果） →LINEアカウントに登録された電話番号を元に追跡が可能（かも） ①攻撃 サービス 攻撃者 ②開示請求 ③開示請求 ④追跡 裁判所 追跡される リスクが発生 13 

eKYC SMS認証 Google / Twitter SSO LINE Login 本人性 ◯ ◯ ✕ ◯ 普及度 ✕ ◯ ◯ ◯ コスト（金、時間） ✕ ✕ ◯ ◯ ユーザビリティ ✕ ✕ ◯ ◯ プライバシ※ ✕ ✕ ◯ ◯ Why LINE Login 上記の話は身元確認全 般の話（LINE Loginに 限らない） 個人開発では、「普及 度」「コスト」やその 他要素も大事 　→LINE Loginのみが 　　全て満たす ※サービスが電話番号やユーザの個人情報にアクセスできるか 14 

２．作ってみたモノの話 

作ってみた：torima プロキシ https://github.com/ochanoco/torima 「なんでもLINE Login」によっ て、セキュリティを担保する BANの判断のため、リクエスト のログを保存 サービスにある脆弱性の影響を 　 受けずらいプロキシ方式を採用 セキュア プロキシとDocker を用いて低導入コ ストを実現 低コスト 攻撃 ユーザビリティの高い LINE Loginを利用 セキュリティ上、必要な ※ときだけ、認証を要求 ユーザフレンドリ torima サービス ハッカー 「LINEでなんでもログインすれば、とりま攻撃防げね？」を セキュア・ユーザフレンドリ・低コストに実現する攻撃対策システム ※セキュリティ上 必要なときの例 GET以外のアクセス ホワイトリストにない パスへのアクセス クエリパラメータを 　 含むアクセス etc... 16 

3. 仮説検証のために実験した話 

実験 「攻撃になりうる」リクエストに対しLINE Loginを要求 →どれだけ攻撃を防げるか実験 サイト：簡単な掲示板 デプロイ先：Azure （Central US ） 期間：10/18 ~ 11/5 UTC 実験環境 　（作りたての個人開発のサイトを再現） 19 

結果（攻撃） リクエスト件数：648件 （攻撃回数：349件） 送信元IP: 175個 ほぼ全て無差別なスキャンだった →認証するだけで、ブロックできた（理由1） 攻撃 53.9% 通常 46.1% 謎HEADアクセス 5.62％ 通常のリクエストと 攻撃の割合 攻撃の分類とその割合 合計 648件 合計 395件 Proxy 認証試行 0.244％ 20 機密情報のありそうな パスへランダムアクセス 94.1％ 

結果（精度） 正常 87% 誤検知 13% 正常 99.6% 誤検知 0.4% すべて設定ミス・実装の 甘さが原因だった →修正することで、 　十分な精度で利用可能 設定ミスに よる誤検知 （/robots.txt /favicon.ico） 余計なヘッダの 落とし忘れ x 1 （Proxy- Authorization） 間違ったブロックした （False Positive）の割合 間違ってブロックできなかった （False Negative）割合 合計 239件 合計 409件 21 

True Positive 👍 57.6% True Negative 👍 33.7% FP: False Positive 👎 8.6% False Negative 👎 0.244％ 22 合計 648件 

今後の展望 実際に個人開発されたWebアプリ上で実験 どれくらい攻撃を防げるか（セキュリティ） ユーザの離脱率はどれくらいか（ユーザビリティ） デプロイは開発者にとって簡単か？（低コスト） その他バグ改善 一部のブラウザで調子悪い 23 

まとめ 仮説 LINE Loginで常にログインを要求すれば、「とりま」攻撃を防げるのでは？ 実装物 上記仮説に基づいて、セキュア・ユーザフレンドリ・低コストに 実現する攻撃対策プラットフォーム 実験 実装物をもとに仮説検証し、攻撃を防げることがわかった 24 

付録: 関連調査（ヤフコメ） 25 ヤフコメに電話番号を必須化したと ころ、新規悪質ユーザが５６％減少 →セキュリティの文脈ではないが、 　同様の効果が表れる可能性 https://x.com/itmedia_news/status/1630079045386870784 

付録: 関連調査（捜査機関への対応 - LINE） 26 https://www.lycorp.co.jp/ja/privacy-security/privacy/transparency/ https://linecorp.com/ja/security/transparency/2022h2 法に基づいて、LINEヤフーは 機関に対応する場合がある →攻撃者を追跡する請求できる 可能性がありそう？