WEBセキュリティについて

---

みなさんこんにちは。
システム開発部の瀬川です。プログラマーとして３年目に差し掛かりました。
フルスタックにしているため、まだまだ知識が浅いところも多くありますが、
最近は使用しているフレームワークや使用言語の深掘りに努めております。
今回、セキュリティー関連についてはかなり知識が乏しかったため、勉強ついでに記事を書くことにしました。

Webセキュリティ上の脅威の種類

• クロスサイトスクリプティング（XSS）⭐️
• クロスサイトリクエストフォージェリ（CSRF）⭐️
• SQLインジェクション（SQL Injection）⭐️
• 認証の不備
• 不正なリダイレクトとフォワード
• セッション固定攻撃
• 不適切なデータ保管

上記の内容は大分類としてありますが、小分類にすると下記のようになります。

• コンピューターウイルス
• フィッシング詐欺
• 不正アクセス
• スパムメール
• データ流出・損失
• 高額架空請求
• ネットショッピング、オークションでの被害

私生活でもよく聞いたり耳にする言葉ですね。
記載している以外にもかなり種類があり理解に時間がかかりましたが、主に⭐️がついたものについて解説と対策を説明していきたいと思います。
またSQLインジェクションについてはコードリックではFirebaseを使用しているので、比較もしていきたいと思います。


クロスサイトスクリプティング（XSS）
クロスサイトスクリプティングとは通称XSS（Cross Site Scripting）といいます。
一般的な脆弱性の1つで、ユーザーが入力したデータを正しく処理しないことによって引き起こされます。
攻撃者は悪意のあるスクリプトを注入し、ユーザーのブラウザでそれを実行させることができます。

【主な問題】
ユーザーのセッション情報や個人情報を盗み見られる可能性があります。
これにより、アカウントの不正利用や個人情報の漏洩が発生し、セキュリティの問題や信頼性の低下、法的なリスクが生じる可能性があります。

【対策①：サニタイジング（スクリプトの無害化）】
クロスサイトスクリプティング（XSS）攻撃は、悪意のあるスクリプトをWebアプリケーションのフォームに挿入し、ユーザーのブラウザ上でそのスクリプトが実行されることで悪意のある操作が行われる攻撃です。
これを防ぐために、サニタイジング（スクリプトの無害化）を行います。具体的には、特殊文字である「&」、「<」、「>」、「"」、「'」などをエスケープし、それらが文字列としてそのまま画面に表示されるようにします。
これにより、スクリプトが入力されても、そのまま表示されるだけであり、悪意のあるスクリプトが実行されることはありません。
サニタイジングはXSS攻撃への有効な対策であり、根本的な解決策でもあります。

【対策②：入力値を制限する】
ユーザーの入力を制限することも、クロスサイトスクリプティング（XSS)への対策方法の1つです。
例えば、郵便番号の入力フォームでは、数字以外の入力を許可しないようにすることで、悪意のあるスクリプトの挿入を防ぎます。
さらに、文字種の制限が難しい場合でも、入力値の長さに制限を設けることで、悪意のあるスクリプトの挿入をある程度抑制することができ、これにより攻撃のリスクを軽減できます。
 
【対策③：特化したAPIやソフトの導入】
外部APIを介して送信することにより、より強力な対策を講じることも可能です。

サニタイジングについては、チャットアプリの装飾禁止の関数で用いたりしていましたが、意外にもこういった対策としても役立っていたことに驚きました。

 
 クロスサイトリクエストフォージェリ（CSRF）
【主な問題】
ユーザーが意図しない操作を強制される可能性があります。
たとえば、ログアウトさせられたり、パスワードを変更されたり、不正な取引が行われたりする可能性があります。
これにより、セキュリティの問題や信頼性の低下、法的な問題が生じる可能性があります。

【対策①：CSRFトークンの使用】
CSRF攻撃は、ユーザーが認証された状態で悪意のあるサイトからリクエストを送信することで起こります。
この攻撃からの保護のために、WebアプリケーションにはCSRFトークンを導入します。
このトークンは、ユーザーのセッションと結びついており、フォームの送信やリクエストの際に一緒に送信されます。
サーバーはリクエストを受け取る際にトークンが有効であるか検証し、有効でない場合はリクエストを拒否します。

【対策②：SameSite属性の設定】
SameSite属性は、Cookieを送信する際に利用されます。SameSite属性をStrictまたはLaxに設定することで、クロスサイトリクエストフォージェリ攻撃からの保護を強化できます。
Strictでは同一オリジンからしかCookieが送信されず、Laxでは一部のクロスサイトリクエストに対してCookieが送信されないようになります。

【対策③：リファラーチェック】
リファラーチェックは、リクエストのリファラーヘッダーを検証して、正規のリクエストかどうかを確認します。
正規のリファラーからのリクエストであれば処理を続行し、そうでない場合はリクエストを拒否します。

【対策④：HTTPメソッドの制限】
特に重要な操作に対して、HTTPメソッドの制限を設けることで、攻撃の対象となるリクエストを制限します。
たとえば、CSRFトークンを要求するのはPOSTメソッドのみとするなどの方法があります。

①〜④の対策をすることで、第三者からの攻撃のリスクを軽減することができます。

この辺りは結構GCPで賄っているのかもしれません。
ここはもう少し詳しく確認する必要があるので、しっかり押さえていきたいですね。

 
SQLインジェクション（SQL Injection）

SQLインジェクション（SQL Injection）は、悪意のあるユーザーが不正なSQLクエリをデータベースに送り込むことによって、データベースシステムに対する攻撃を試みる手法です。
通常、WEBアプリケーションなどの入力フォームやURLパラメータなど、ユーザーからの入力を受け付ける箇所を標的とします。



このように噛み砕いて一つ一つ解決していくとわかりやすかったです。
Firebaseのルールがとても優秀なんだと改めて実感いたしました。
セキュリティと言ってもまだまだ幅広い世界ですが、まずはフロント周りのセキュリティを意識していきたいです。
設計段階で対策できそうな点もありそうなのと、関数を書くときやデータベースの連携を行う際にいつもより気にしていきたいと思いました。
エシカルハッキングとエシカルハッカーは最近トレンドに上がっていましたし、この内容をもっと深掘りすればより知識が深まりそうですので、しっかり予習も行なっていきたいです。