TODOライブラリの脆弱性自動検知ツール参考文献Coding-securityNext.js・Reactで行うべきセキュリティの対策フロントエンド開発を行うに当たり最低限行うべき対策。リクエストに含まれる文字列をそのままHTMLへ挿入すると、意図せぬJavaScriptが実行される恐れがある。罠サイト経由でアクセスした際、URLのパラメータ等に悪意あるコードを埋め込まれ、SSRでレンダリングされたHTMLから実行される。攻撃者が投稿したフォームを他のユーザーが閲覧時に実行される。DOMツリーを書き換える系の操作で悪意あるスクリプトを挿入。クライアントサイドで起こるため、検知が難しい。対策として、DOM操作用の関数を利用する。許可されていないJavaScriptの実行やリソースの読み込みをブロック。レスポンスヘッダーに付与することで適用される。baseURLを変更されないようにする。Flash等のプラグインに対する制限を付与。文字列を安全な型として扱う。DOMPurifyで検査可能。CSPを適用させると、HTML内にインラインJavaScriptは禁止される。回避方法として、unsafe-inlineを使うのではなく、nonce-sourceやhash-sourceを利用すると安全にインライン記述ができる。script要素に指定したランダムなトークンがCSPヘッダーに指定されたものと同一でないとエラーを吐くもの。script要素のhash値を計算し、それをCSPヘッダーに指定して、同一でないとエラーを吐くもの。上記を指定しても許可されないscript要素の作成が必要な場合に利用。innerHTMLやdocument.writeは機能しない。対策方法dangerouslySetInnerHTMLの利用を禁止する。しても利用する必要がある場合は、DOMPurify等を用いてサニタイジングして、html-react-parser等でパースすることでdangerouslySetInnerHTMLの利用を回避する。hrefにURLを挿入する場合は、http(s)以外受け付けないようサニタイジングを行う。scriptタグを利用する場合はnonceの設定を忘れずに行う必要がある(通常パッケージマネージャーによってライブラリの導入を行うため、使う場面は限られる)。TypesはReactの実装内で類似のことがなされるため不要。根拠dangerouslySetInnerHTMLを利用しない場合、ReactがHTMLとして解釈されないようにエスケープしてくれるため。React公式ドキュメントhrefにjavascript:脆弱性を生むコードが指定されることは対策されないため手動でサニタイジングをする必要がある(2024年9月現在)。CSPを用いることで許可されていないソースからのスクリプトの読み込みを制限でき、安全性が高まる。仕組み化BiomeやESLintでdangerouslySetInnerHTMLを利用するとCIが失敗するようにする(デフォルトの設定で有効化済)。CodeRabbit等のGPTを利用して検知。ヘッダーに記述する内容をテンプレート化して提供。攻撃者の罠によってWebアプリケーションの持っている機能がユーザーの意思と関係なく実行されてしまうこと。formから送信されるリクエストは同一オリジンポリシーで制限されないため生じる。HttpOnly属性のついていないCSRF対策専用のCookieをformを送るときに、headerに入れる。同一のtokenがformにも入れてあればOK。HttpOnly属性がついていなくても、異なるドメインからはCookieにアクセスできないため対策になる。v14.0以上を利用することで特筆すべき対策は不要。Handlers(route.tsx)を利用する場合は下記対策が必要になる。基本的に不要な対策バックエンドサーバーでoriginヘッダーを検証。Cookieを設定し、クロスサイトサイトへCookieを付与しない。formのPOST等でCSRF_TOKENを使い、フォームの正当性の検証。cookieを利用し、フォームの正当性を検証。SameSite=Lax;X-Requested-With等の(CORS安全とされるリクエストヘッダー以外の)任意のヘッダーを付与して、そのヘッダーがリクエストに含まれているか検証。プリフライトリクエスト内でチェックするため、リクエスト回数が増える。他の方法がない場合に利用。根拠Next.jsのv14.0以上ではOriginヘッダーの検証が自動で行われる。Cookieは最新版のChrome等のブラウザでデフォルト搭載されている。HTTPで初回通信しても、次からはHTTPS通信を強制する。HTTPS通信を行う有効期限。サブドメインに対してもHTTPSを強制するか。preloadに登録されているドメインか確認して、初回からHTTPS通信を強制する。読み込むリソースの内容のハッシュ値のbase64エンコードされたものをintegrity属性に指定することで改ざんを検知する仕組み。443番ポートのみ開放。Contentのブロック。サブリソース完全性の利用。根拠HSTSを利用することで、通信のHTTPS化を強制でき、中間者による改ざんによって生じる悪意あるスクリプトの埋め込みを防止できる。Contentのブロックはブラウザでデフォルト搭載。ビルド時にnpmからパッケージをインポートし、scriptタグによる読み込みをしなければ問題なし。ライブラリの脆弱性検知ツールによる対応で十分。仕組み化ヘッダーに記述する内容をテンプレート化して提供。hstspreload.orgをチェックすることで設定を確認。iframeで透明なボタンを配置して、ユーザーの操作を促す。対策方法X-Frame-Optionsの設定。必要に応じてDENY以外にSAMEORIGIN等に変更する。'none'根拠X-Frame-Optionsを設定することで、iframe等で埋め込まれることを防止できるため。仕組み化ヘッダーに記述する内容をテンプレート化して提供。SQLインジェクション対策方法Prisma等のORMの機能を利用してデータベースにアクセスし、生のSQLや$queryRaw、$executeRawを利用しない。しても利用する場合は、個別に調査して無害化する。TypedSQLの利用。根拠ORMのデフォルト機能として、SQLインジェクションの恐れのあるテキストはエスケープされるため(Prisma以外のORMの場合念の為確認が必要)。CodeRabbit等のGPTを利用して検知。ブラウザ上で異なるオリジン間の安全なリソース共有を可能にする仕組み。Access-Control-Allow-Originなどを使用して動作させる。Originヘッダの値をそのままAccess-Control-Allow-Originヘッダに設定するとすべてのオリジンを許可していることと同一なため使用不可。CPU・メモリ等、ハードウェアの特性を悪用した攻撃。高精度なタイマーを使い、徐々にメモリ内の内容を推測するもの。ヘッダが指定されたリソースの読み込みを同一オリジンまたは同一サイトに制限可能。CORSヘッダを設定することを強制。SharedArrayBufferやperformance.measureMemory()を利用しない。Isolation(SharedArrayBufferやperformance.measureMemory()を利用する場合のみ)(不用意に設定するとWebサイトが動かなくなることがあるため注意が必要))。決済やソーシャルログイン等を利用している場合はブロックされるのでsame-origin-allow-popupsを指定する。Isolationでオリジンごとにプロセスの分離できるため。isolation・CORSの仕組みはデフォルトでブラウザに搭載されている。仕組み化ヘッダーに記述する内容をテンプレート化して提供。対策方法Referrer-Policyの設定。strict-origin-when-cross-origin根拠Referrer-Policyを適切に設定することで、遷移先が外部サイトの場合にreferrerを送信しなくなる。仕組み化ヘッダーに記述する内容をテンプレート化して提供。token等の利用)。'server-only';の利用によるサーバーサイドのロジックの明示的な分離。本番環境では本番モードで起動する。ブラウザから見えてもいい環境変数以外の名称にNEXT_PUBLIC_接頭詞をつけない。根拠httpOnly属性を付与することで、JavaScriptからCookieにアクセスできないようにできる。ページ遷移時やフォーム送信時等のリクエストにおいて、ブラウザはCookieを自動的にサーバへ送信するため、対策が必要。Componentは開発者ツールから内部のコードが見れてしまう。'server-only';を付与することで、サーバーサイドからしかコードが実行されなくなる。本番モードでは、Reactはエラーや拒否されたプロミスをクライアントに送信しないため、エラーハンドルの実装により機密情報が漏洩することは対策済み。NEXT_PUBLIC接頭詞をつけない環境変数をクライアントサイドから読み込むとエラーになるため、機密情報がクライアントサイドに流出することは対策可能。CodeRabbit等のGPTを利用して検知。オープンリダイレクト対策方法リダイレクト設定を記述する場合は、特定のURLのみリダイレクトが可能なようにバリデーションを行う。根拠リダイレクト先の設定でバリデーションを行うと、悪意あるリダイレクト先は排除できる。CodeRabbit等のGPTを利用して検知。同様のことをDompurifyやReactのデフォルトの機能でできるため不要とする。チェックリストデータアクセス層:独立したデータアクセス層の確立された慣行があるかどうか要確認。データベースパッケージや環境変数がデータアクセス層の外でインポートされていないことを要確認。server”ファイル:アクションの引数がアクション内、またはデータアクセス層内で検証されているか?アクション内でユーザーが再認証されているか?/[param]/:角括弧が付いているフォルダはユーザー入力を表す。パラメータが検証されているか?middleware.tsxおよびroute.tsx:従来の技術を使って要追加の監査。定期的にペネトレーションテストや脆弱性スキャンを実施するか、チームのソフトウェア開発ライフサイクルに従って実施。ActionsのPropsにユーザーに操作されたくない引数を入れてないか(userIdはsessionから取得する等の方法を取る必要がある)。layoutで認証チェックをしていないか。actionsで行うべきである。TODO下記はフロントエンドWebアプリケーション開発に直接関わらない箇所なため、TODOとして残している。一部はフロントエンドの高度化により対策が必要なものもあるため、現在執筆中である。