LoginSignup
0
0

More than 3 years have passed since last update.

VSCodeでSvelte+ASP.Net CoreでJWTを利用したSPAの認証(セキュリティ)

Posted at

初めに

 社内システムを主にやっていたので、WEBのセキュリティについては少し疎いので今後のために、今回のSvelte+ASP.Net coreの環境でのセキュリティを考えてみました。間違ってるとかこうすべきとか教えてほしいです。

IPAの資料を基にしました。

 セキュリティー対策についてはいろいろなものがネットに転がっていますが、今回はIPAで安全なウェブサイトの作り方をもとに、今回の開発環境を検証してみてみたいと思います。この記事を書くにあたって、いろいろと見て回ってはいますが。

SQLインジェクション

 EntityFrameworkの機能で処理している分には、問題なさそうです。直接SQL書くようなことは基本ないはずです。そのような事象にあたっても、文字列の結合で作らず、パラメタライズドクエリー(というか一般的にはプレースフォルダーを使うというんでしょうか)でやってれば大丈夫かと。というか、文字列結合でSQL書くな!っとことですよね。

OSコマンド・インジェクション

 これは、気を抜くと発生しそうですね。サーバー内でシェルやそれに近い機能を実行すること、特に送られてくるパラメータを利用するコマンドを実行する場合は、要注意ですね。基本使わないこのがいいかと思いますが、使いたいときがありそうに思います。

パス名パラメータの未チェック/ディレクトリ・トラバーサル

 基本的にファイルを操作する場合、ファイルやフォルダ名をユーザーが入力できる環境を提供しないことですね。何らかの理由で使うファイルは固定パスにするのはもちろん、ユーザーデータとして保存するようなファイルがあった場合も、書かれている対策にはユーザー入力をチェックするようなことが書かれていますが、ユーザーが見る名称と実際のファイル名は別で管理し、ファイル名のほうはシステムで設定するような作りにするのがいいかと思います。

セッション管理の不備

 基本的にセッションは使わない方向です。サーバーアクセスはステートレスなデータ操作に特化し、状態管理はフロントエンドでする方向で。サーバーアクセスをJWTで常に承認が必要な状態にしておけばだいじょうぶかと。

クロスサイト・スクリプティング

 今回の環境ではHTMLはフロントエンドでの実装ですので、Svelteのプレースフォルダを使う限りは自動的にエスケープしてサニタイズしてくれます。SvelteのAPI説明にありますが、「{@html}」を使わなければ問題ないかと。「{@html}」を使う場合は要注意です。DOM Based XSSでも、結局はページ内に別のスクリプトを侵入させるのは同じでその元ネタが違うのですから、最終HTMLに表示するところでサニタイズされれば大丈夫でしょう。

CSRF(クロスサイト・リクエスト・フォージェリ)

 JWTを使っての認証と承認ですので、大丈夫かと。(ちなみにASP.Net core MVCの場合は自分でAntiForgeryの設定が必要そうです。Razorの場合は基本的にAntiForgeryがテンプレートで設定されたと思います。)

HTTPヘッダ・インジェクション

 今のところレスポンスヘッダを自身で設定したことがないのですが、「HttpResponse.AppendHeader」を使っていれば大丈夫でしょう。ASP.Net coreではレスポンスヘッダを直接編集するほうが難しそうです。ちゃんと改行ははじいてると思いますが、試してみます。

メールヘッダ・インジェクション

 これはちょっと厄介そうです。スパムの発生元となるみたいですね。メール送信を行う場合、使っているライブラリ(フレームワーク内にあるならばフレームワーク)が対策しているかどうかチェックしておくか、ユニットテストで確認しておく必要がありそうです。自分でメール送信をフルスクラッチすることはほぼないと思うので。

クリックジャッキング

 これは対策すべきか。基本的にiframeで別のページから参照させたいような条件がない限り、使えなくしておくに越したことはないので、「X-Frame-Options」は「DENY」設定しておこうかと思います。これに関連して見たレスポンスヘッダの記事がよさそうだったので、あとで参照を書いておきます。

バッファオーバーフロー

 C#とかでやってる限り問題ないが、その下でC++のライブラリなどを使うことがあるなら要注意。でもどれがそうかわからないので使っているライブラリやパッケージは常に最新を心がけ、できればユニットテストで危なそうなものは確認しておくとかでしょうか。

アクセス制御や認可制御の欠落

 まあ、基本的にバックエンドではログインや一般参照ページ以外は承認が必要にしておくこと(コントローラに[Authorize]を必ずつける)。また、処理によってはロールなどで使えるユーザーを限定する。また、画面遷移時に未認証が発覚すればログインページに戻す処理を入れておくとかでしょうか。

ついでレスポンスを少しセキュアにする

 ついでに、「ASP.NET Core でセキュアな レスポンスヘッダー を設定する」を参考に、いくつかのヘッダを追加しておくとより良いかと思います。必要なければRefereも出さないようにしておくのがよさそうですし。

 今どきのフレームワークは優れていて、いろいろと対策してくれてますね。それでも作る際に気を付けておくべきことはけっこうあるなー。
 また、新しい手口もすぐに出てくるので、情報には敏感になっている必要がありますね。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0