序文
フロントエンドとバックエンドの分離の開発モデルでは、開発の役割と機能の観点から最も明白な変化は次のとおりです。過去に、サーバーエンドレベルを探索し、サーバーエンドコードを書き込むために必要なブラウザー環境の開発のみを担当するフロントエンドの学生です。そして、私たちの前の基本的な質問は、Webセキュリティを確保する方法です。
この記事では、フロントエンドのWeb開発におけるフロントエンドとバックエンドの分離モード、および対策と予防策によって発生するセキュリティ問題の解決策を提案します。
クロスサイトスクリプト攻撃の防御（XSS）
問題と解決策
クロスサイトスクリプト（XSS、クロスサイトスクリプト）は、Webサイトを攻撃する最も一般的で基本的な方法です。攻撃者は、Webページに攻撃コードを含むデータを公開できます。ブラウザがこのWebページを表示すると、特定のスクリプトがブラウザユーザーのIDと権限として実行されます。 XSSは、ユーザーデータ盗み、ユーザー情報をより簡単に変更でき、CSRF攻撃などの他のタイプの攻撃を引き起こす可能性があります。
XSS攻撃を防ぐための基本的な方法は、HTML（HTMLエスケープ）でHTMLページへのデータ出力が逃げられるようにすることです。たとえば、次のテンプレートコード：
コードコピーは次のとおりです。
<textarea name = "description"> $ description </textarea>
このコードの$説明はテンプレートの変数です（異なるテンプレートで定義された変数の構文は異なります。ここには図です）。ユーザーが送信したデータは、「JavaScript」を含むコードを入力して、上記のテンプレートステートメントの結果を次の結果にすることができます。
コードコピーは次のとおりです。
<textarea name = "description">
</textarea> <script> alert（ 'hello'） '</script>
</textarea>
ブラウザでレンダリングされた上記のコードは、JavaScriptコードを実行し、画面上でHelloをアラートします。もちろん、このコードは無害ですが、攻撃者はJavaScriptを作成してユーザー情報を変更したり、Cookieデータを盗んだりできます。
ソリューションは非常にシンプルです。これは、htmlが$説明の値を逃れるためです。脱出後の出力コードは次のとおりです
コードコピーは次のとおりです。
<textarea name = "description">
</textarea> <script> alert（hello！）</script>
</textarea>
上記の脱出されたHTMLコードは有害ではありません。
ミッドウェイのソリューション
ページ内のすべてのユーザー出力データをエスケープします
データを逃れるためのいくつかの状況と方法があります。
1.テンプレート内で提供されるメカニズムを使用して脱出します
Midwayは、Template言語としてKissy Xtemplateを使用しています。
XTEMPLATEの実装では、テンプレートデータは2つのブラケット（{{val}}）を使用して構文が解析されます。デフォルトでは、データはHTMLエスケープであるため、開発者は次のようなテンプレートを書くことができます。
コードコピーは次のとおりです。
<textarea name = "description"> {{description}} </textarea>
XTEMPLATEでは、出力データを脱出したくない場合は、3つのブラケット（{{{{val}}}）を使用する必要があります。
2。ミッドウェイのエスケープ関数を明確に呼び出します
開発者は、node.jsプログラムまたはテンプレートでMidwayが提供するHTMLエスケープメソッドを直接呼び出して、次のように表示されます。
方法1：node.jsプログラムのHTMLエスケープデータ
コードコピーは次のとおりです。
var security = require（ 'Midway-Security'）;
//サーバーからのデータ、例えば{html： '</textarea>'、その他： ""}
data.html = security.escapehtml（data.html）;
xtpl = xtpl.render（data）;
方法2：HTMLテンプレート内のHTMLデータをエスケープします
コードコピーは次のとおりです。
<textarea name = "description"> security.escapehtml（{{{description}}}）</textarea>
注：security.escapehtmlは、テンプレート内でデータが逃げられない場合にのみ、エスケープに使用されます。それ以外の場合、テンプレートの内部とプログラムはオーバーレイを2回逃れ、期待を満たさない出力が得られます。
推奨：dxtemplateを使用する場合は、直接逃げるためにテンプレートの組み込み{{{}}を使用することをお勧めします。他のテンプレートを使用する場合は、security.escapehtmlを使用することをお勧めします。
ページ上のユーザーからの豊富なテキスト出力をフィルタリングします
「実際、私はいくつかの掲示板やフォーラムなど、いくつかのフォントサイズ、色、背景、その他の機能を提供するために、いくつかの掲示板やフォーラムなど、豊富なテキストを出力したいだけです。
1.ミッドウェイでセキュリティによって提供されるリッチテキスト関数を使用します
Midwayは、豊富なテキストをフィルタリングし、XSS、フィッシング、Cookieの盗難などの脆弱性を防ぐために特別に使用されるRichTextメソッドを提供します。
メッセージボードがあり、テンプレートコードは次のとおりです。
コードコピーは次のとおりです。
<div>
{{{メッセージ}}}
</div>
メッセージはユーザーの入力データであるため、メッセージボードのコンテンツには豊富なテキスト情報が含まれています。ここでは、3つのブレースがdxtemplateで使用され、HTMLエスケープはデフォルトでは実行されません。次に、ユーザーが入力したデータは次のとおりです。
コードコピーは次のとおりです。
<Script src = "http://eval.com/eval.js"> </script> <span style = "color：red; font-size：20px; position：fixed;">メッセージを残します</span>
上記の豊富なテキストデータがページに直接出力されると、eval.comサイトから現在のページへのJSの注入に必然的につながり、XSS攻撃が発生します。この脆弱性を防ぐために、テンプレートまたはプログラムのSecurity.RichTextメソッドを呼び出して、ユーザーによるリッチなテキスト入力を処理します。
呼び出し方法はEscesshtmlに似ており、2つの方法があります
方法1：node.jsプログラムで直接呼び出します
コードコピーは次のとおりです。
message = security.richtext（message）;
var html = xtpl.render（メッセージ）
方法2：テンプレートを呼び出します
コードコピーは次のとおりです。
<div>
security.richText（{{{message}}}）
</div>
リッチテキストセキュリティ方法を呼び出した後、最終出力は次のとおりです。
コードコピーは次のとおりです。
<div>
<span style = "color：red; font-size：20px;">メッセージを残しています</span>
</div>
最初に：XSS攻撃を引き起こすスクリプトタグが直接フィルタリングされることがわかります。同時に、CSS属性位置：固定。スタイルのスタイルもフィルタリングされています。最後に、無害なHTMLリッチテキストは出力です
XSS攻撃につながる可能性のある他の方法について学ぶ
ページテンプレートでのXSS攻撃の可能性に加えて、Webアプリケーションにはリスクもある可能性のある他の方法がいくつかあります。
1。エラーページの脆弱性
ページが見つからない場合、システムは、http：// localhost/page/not/fundなど、404の発見されていないエラーを報告する場合があります。
404 NotFound
Page/Page/NOT/FUINDは存在しません
明らかに：攻撃者はこのページを使用してこのような接続を構築できますhttp：// localhost/％3cscript％3ealert％28％27hello％27％29％3c％2fscript％3e、および犠牲者をクリックして誘います。エラーページが出力変数をエスプターしない場合、接続内の<script> alert（ 'hello'）</script>が実行されます。
Expressでは、404ページを送信する方法は次のとおりです
res.send（404、「ごめんなさい、私たちはそれを見つけられない！」）
ここで、開発者はエラーページ（404またはその他のエラーステータス）の処理に注意を払う必要があります。エラーメッセージの返されたコンテンツにパス情報が含まれている場合（実際、より正確にするには、ユーザー入力情報）、EscaseHTMLを実行する必要があります。
その後、エラー処理のセキュリティメカニズムは、ミッドウェイフレームワークレベルで完了します。
ミッドウェイソリューションの追加メモ
他のテンプレートエンジン
Midwayはデフォルトでdxtemplateテンプレートをサポートしていますが、Jade、口ひげ、EJSなどの他のテンプレートもサポートする可能性があります。現在、主流のテンプレートでは、デフォルトの脱出および非エスケープの出力変数ライティング方法が提供され、開発者はセキュリティに特別な注意を払う必要があります。
脱出に対するその他のサポート
ページ上の通常とリッチのテキストデータ出力に加えて、一部のシナリオには、脱出が必要な他の状況も含まれています。 Midwayは、開発者が使用するための一般的に使用される脱出方法を提供します。
EscapeHTMLは、指定されたHTMLで文字をフィルタリングしてXSSの脆弱性を防ぎます
jsencode javascript入力文字列の脱出。中国語のユニコードエスケープ、単一の引用、二重引用符は逃げます
EscapeJsonはJSON構造の脱出機能を破壊せず、JSON構造の名前とVauleでEscaseHTML処理のみを実行します
Escapejsonforjsvarは、当然のことながらJsencode+EscapeJsonです
例は次のとおりです
コードコピーは次のとおりです。
var jsontext = "{/" <script>/"：/" <script>/"}";
console.log（securityutil.escapejson（jsontext））; // {"<script>"： "<script>"}
var jsontext = "{/" hello/"：/" <script>/"}";
console.log（securityutil.escapejsonforjsvar（jsontext））; // {/"/u4f60/u597d/"：/"<script>/"}}
var str = "alert（/" hello/"）";
console.log（securityutil.jsencode（str））; // alert（/"/u4f60/u597d/"）
クロスサイトリクエスト偽造攻撃の防止（CSRF）
問題と解決策
用語の定義：フォーム：クライアントにデータを送信するためにブラウザが使用するフォームを一般的に指します。タグ、ajax送信データ、フォーム送信データなど、htmlに等しい形式のタグを含みます。
クロスサイトリクエストフォーファリー（CSRF、クロスサイトリクエスト偽造）は、もう1つの一般的な攻撃です。攻撃者はさまざまな方法でリクエストを偽造し、フォームを送信するというユーザーの動作を模倣し、それによりユーザーのデータを変更したり、特定のタスクを実行したりする目的を達成しました。
ユーザーのふりをするために、CSRF攻撃はXSS攻撃と組み合わされることがよくありますが、他の手段を使用できます。たとえば、ユーザーに攻撃を含むリンクをクリックするように誘導します。
CSRF攻撃を解決するというアイデアは、2つのステップに分かれています。
1。攻撃の難しさを増やします。取得リクエストは簡単に作成できます。ユーザーは、リンクをクリックしてGet-Typeリクエストを開始できます。投稿リクエストは比較的困難です。多くの場合、攻撃者はJavaScriptを使用してそれらを実装する必要があります。したがって、フォームまたはサーバーインターフェイスがタイプの提出後のリクエストのみを受け入れることを保証すると、システムのセキュリティが増加する可能性があります。
2。リクエストを認証して、リクエストが実際にフォームに記入されたり、リクエストを開始したり、ユーザーがサードパーティによって偽造したりするのではなく、ユーザーによって提出されたことを確認します。
通常のユーザーがウェブサイト情報を変更するプロセスは次のとおりです
ユーザーリクエスト情報（1） - >ウェブサイトは、ユーザーの変更された情報フォーム（2） - >ユーザーの変更情報を表示し、[3）を変更します - >ウェブサイトはユーザーの変更されたデータを受け入れ、保存します（4）
CSRF攻撃はこのルートを取ることはありませんが、ステップ2でユーザーの提出情報を直接鍛造します。
ステップ2（1） - >変更する情報を偽造して送信する（2） - >ウェブサイトは攻撃者を受け入れてパラメーターデータを変更して保存します（3）
これら2つの状況を区別できる限り、CSRF攻撃を防ぐことができます。では、それを区別する方法は？ステップ2で提出された情報を確認して、データがステップ1のフォームから得られることを確認することです。特定の検証プロセスは次のとおりです。
情報の変更を要求するユーザー（1） - > Webサイトには、情報の変更に使用される空白のフォームが表示されます。フォームには特別なトークンが含まれており、セッション（2） - >ユーザーが情報を変更して送信し、トークン情報をサーバー（3）に送信します（3） - > Webサイトは、セッションのユーザーとトークンが送信したトークンを比較します。一貫しているはずです。次に、ユーザーによって変更されたデータが受け入れられ、保存されます。
このようにして、攻撃者が情報を変更して提出するように偽造した場合、彼はセッションに直接アクセスできないため、実際のトークン値を取得できません。リクエストがサーバーに送信された場合、サーバーがトークン検証を実行したとき、それは一貫性がなく、リクエストが直接拒否されたことがわかります。
ミッドウェイソリューション
Get Submissionフォームを無効にします
サーバーがGETによって提出されたフォームデータを受け入れない場合、攻撃者に大きな困難を引き起こします。 A-Label HREF属性またはIMG-Label SRC属性をページに作成してリクエストを作成するのは非常に簡単だからですが、送信する場合は、スクリプトを使用して実装する必要があります。
CSRFトークンでリクエストを確認します
MidwayにはTaobaoの分散セッションとトークン検証の論理が含まれていないため、ミッドウェイフレームワークでは、サーバーとクライアントの間にトークンのみが転送され、実際の検証作業は行われません。プロセスは次のとおりです。
その後、途中で、node.jsとtaobaoの分散セッションが接続された後、中間層でトークン検証を自動的に実行することを検討できます。結局のところ、セキュリティ検証が実行されるほど、コストが低くなります。
提案：Midwayでは、リクエストにトークン値があるかどうかを判断できます。修正操作にトークンがない場合は、中間層で直接検討してください。安全でないと廃棄することができます。
その他のセキュリティの問題
いくつかの一般的なWebセキュリティの問題があります。ここにいくつかの紹介のみがあり、将来的にはミッドウェイフレームワークに引き続き継承されます。
HTTPヘッダーセキュリティ
CRLFインジェクション攻撃者は、2つのCRLF特殊文字を応答ヘッダーに注入する方法を見つけ、例外的な応答データ形式を作成し、それによりスクリプトを注入します。
Cookieがデフォルトで持ち込まれ、サーバーは一般にCookieのサイズを制限するため、すべてのリクエストを拒否されます。これにより、ユーザークッキーが特定のしきい値を超えるように設定されている場合、ユーザーはWebサイトにアクセスできなくなります。
Cookieの予防とコントロール、一般的なCookie盗難はJavaScript（XSS脆弱性）を通じて取得されるため、CookieをHTTPのみに設定し、Cookieの有効期限を追加してください
Cookieのセキュリティ問題に関して、WebXは以前にすでに良い解決策を持っていました。今回は、MidwayはCookieの設定と検証について責任を負いません。また、チェックのためにWebXレベルへの転送のみを担当しています。
node.jsについて
XSSなどの無視の脆弱性は、すべての脆弱性の中で無視されるのが最も簡単であり、インターネット攻撃全体の70％以上を占めています。 node.jsコードを作成する場合、開発者は常に自分自身を思い出させ、ユーザーの入力を信頼しないでください。
たとえば、次の例。
var mod = fs.readfilesync（ 'path'）;パスがユーザー入力から来る場合、ユーザーが /etc /パスワードを入力すると仮定すると、読み取らないコンテンツが読み取られ、パスワードリークのリスクが発生します
var result = eval（jsonval）; jsonvalがユーザー入力ではなくJSONであることを確認してください
...ユーザーの入力を含む他の場所では、ユーザーの入力が期待される値であることを確認してください。
要約します
フロントエンドとバックエンドの分離モードでは、従来のフロントエンド開発者はバックエンドコードの書き込みを開始できます。アーキテクチャはテンプレートレイヤーのみを担当しますが、大量のバックエンドコードにもさらされます。したがって、セキュリティはフロントエンドにとって大きな課題です。