クライアントアプリケーションのセキュリティ：フロントエンド開発者向けの実用的なヒント

ご存じのように、BlackHatハッカーの攻撃のほとんどは、Webアプリケーションとサービスのサーバーデータを侵害することを目的としています。 同時に、少なくとも今日はクライアント側が攻撃されます。 ドライ定義によれば、攻撃とは、ネットワークとデータ転送、データとその置換、インフラストラクチャとWebアプリケーションの実装の技術的特徴を狙ったハッカー側の一連の対策です。 したがって、国際的な企業では、開発エンジニアがクライアントアプリケーションのセキュリティに対してより責任があり、徹底的なアプローチを取る必要があります。

私のプロジェクトを例に、今日のクライアントアプリケーションの攻撃方法と、これらの脅威を回避する方法について説明します。

ご覧のように、主な脅威の中でも、インジェクション、エラートリガー、認証バイパス、および安全でない機密データが最初にあります。 既知の脆弱性を持つコンポーネントを使用する脅威は依然として関連しています。 新しい脅威も登場しました。アクセス制御メカニズムのハッキング、データの安全でない逆シリアル化とシリアル化、不十分な詳細なログと監視です。

2001年、Mark CurfyとDennis GrovesはOWASP （Open Web Application Security Project）を設立しました。 これは、多数のアプリケーションセキュリティエンジニアが参加する、クライアントアプリケーションの脆弱性との闘いに関する経験を交換するための国際的なオープンソースプロジェクトです。 OWASPコミュニティは、脆弱性、トレーニング資料、テストおよび攻撃を撃退するためのツールに関する情報を含む多数の記事でポータルを埋めています。 実際の攻撃について説明し、その側面を明らかにし、脅威を防ぐために何をする必要があるかを説明します。

プロジェクトにとってどのような脅威が危険かを理解するには、徹底的にテストする必要があります。 これを行うために、ネットワークには特定の脆弱性を自動的に識別するアプリケーション、フレームワーク、およびオンラインサービスがあります。 ローカルテストの場合、アプリケーションとフレームワークの使用をお勧めします。また、運用中のプロジェクトのテストには、オンラインサービスを追加することも非常に便利です。

ただし、テストツールが重大な脆弱性に関するレポートで報告しなかったとしても（可能性は低い）、バージョン管理システムへの機密データの保存、アプリケーションの構築、認証メカニズム、パスワードハッシュアルゴリズム、機密データの暗号化機能、およびロギングシステムに引き続き注意を払ってくださいWebアプリケーション全体を監視します。 この場合、安全にプレイし、盲目的に自動化を信頼しない方が良いでしょう。

Git

まず、Gitの機密データについて説明しましょう。 理想的には、機密データを保存するために秘密の別個のリポジトリが割り当てられます。 そこから、試運転のための組み立て中に、機密データがプルアップされ、アプリケーションに縫い付けられます。 現在、Hashicorp Vault、Keywhiz、Docker secrets、Azure Key Vaultなどが人気です。

しかし、そのようなストレージがない場合はどうでしょうか？ ツールを使用して、バージョン管理システムの機能を拡張する秘密のファイルをエンコードおよび非表示にすることができます。

最初に思い浮かぶのは、ユニバーサルBlackBoxソリューションです。 Mercurial、Gitなど、任意のバージョン管理システムで使用できます。 さらに、Gitにはgit-cryptとgit-secretの2つの拡張機能があります。 公式ドキュメントの説明の観点から、最も使いやすく、より理解しやすいと思われたため、2番目の使用をお勧めします。 git-secretをインストールしたら、Gitリポジトリで初期化する必要があります。 .gitattributesファイルで使用される拡張子を指定することを忘れないでください。 次に、シークレットのアクセシビリティを構成します。機密データへのアクセスを提供するユーザーを特定します。 次に、機密データを含むファイルを追加し、 git-secret-hideます。 git-secret-reveal.隠しファイルを取得できますgit-secret-reveal.

Webpack

脅威を排除する別の方法は、webpackを正しく構成することです。 XSS、XEE、および同様の攻撃から保護するには、CORS（クロスオリジンリソース共有）およびCSP（コンテンツセキュリティポリシー）ポリシーの順守を検討する必要があります。 どちらの場合も、プロジェクトで使用されている特定のスクリプトの信頼性を確認するために、ヘッダーに従うことが重要です。 ブラウザには、特定のソースの信頼性をチェックするメカニズムがあります。たとえば、CORSとCSPが正しく構成されていない場合、Safariはすべてのステップで警告を発行します。

CORSとCSPに準拠するには、2つの方法があります。 最初の方法は、バックエンドで応答ヘッダーを構成することです。 2つ目は、メタタグと属性を介して両方のポリシーを登録することです。 怠zyなバックエンド開発者がいて、常に忙しく、セキュリティポリシーに関心がない場合は、後者の方法をお勧めします。 メタタグは、アプリケーションの構築時にすぐに登録できます。 html-webpack-plugin、html-webpack-exclude-assets-plugin、script-ext-html-webpack-plugin、csp-html-webpack-plugin、cryptoなどのプラグインがこれに役立ちます。 さらに、プロジェクトにサードパーティのリソースがある場合（たとえば、CSSで使用される外部フォントへのリンク、CDNから読み込まれたリソースなど）、webpack-subresource-integrity-pluginも使用することをお勧めします。 したがって、スクリプトに読み込まれたリソースが信頼できること、ブラウザにインジェクションがなく、それらが完全で損なわれていないことをブラウザに通知します。 そして、誰かが悪意のあるデータをリソースに注入し、それをアップロードしたとしても、そのための準備をし、そのような脅威からプロジェクトを保護する必要があります。

プラグインのクラスインスタンスが作成される順序に特に注意を払いたいと思います。 順序は次のようになります。

 const SHA256 = (str) => CRYPTO.createHash('sha256').update( str, 'utf8').digest('base64'); const sha256Str = SHA256( '' + Date.now() ); […] new HtmlWebpackPlugin({   filename: 'index.html',   template: 'public/index.html' }), new ScriptExtHtmlWebpackPlugin({    custom: [{           test: /\.js$/,           attribute: 'nonce',           value: 'nonce-' + sha256Str    }] }), new HtmlWebpackExcludeAssetsPlugin(), new CspHtmlWebpackPlugin({    'base-uri': '\'self\'',    'object-src': '\'none\'',    'script-src': ['\'self\'', '\'unsafe-eval\'', '\'nonce-' + sha256Str + '\''],    'style-src': ['\'unsafe-inline\'', '\'self\''] }, {    devAllowUnsafe: false,    enabled: true,    hashingMethod: 'sha256' }), new SriPlugin({    hashFuncNames: ['sha256', 'sha384'],    enabled: true }), […] 

次に、アセンブリ中に、 <hed>にhttp-equiv=content-security-policyメタタグが表示されます。 ディレクティブは、信頼できるスクリプトとリソースを示すcontent属性に書き込まれます。

base-uriディレクティブは、スクリプト、CSS、画像などを読み込むために使用されるベースURLを示します。

通常、オブジェクトはロードされnoneため、 object-sr cディレクティブにnoneを設定しobject-sr 。

script-srcディレクティブはJSスクリプトに適用されます。

タイプnnce-<hshVlue>属性をnnce-<hshVlue>登録することを忘れないでください。 さらに、ハッシュはSHA256またはSHA512アルゴリズムを使用して計算する必要があります。

style-srcディレクティブに関しては、プロジェクトには特殊性があります。スタイル付きコンポーネントを使用して各コンポーネントのCSSを記述し、それらを相互に分離します。 そのため、私たちではstyle-src unsafe-inlineとselfがstyle-srcで使用されるように指定する必要があります。そうしないと、styled-componentsが落ちます。

scriptタグは、自動的にnnce-<hshVlue> 、 integrityおよびcross-originます。 リソースが信頼できるソースからプルされていることをブラウザに伝えます。 それ以外の場合、ブラウザがリソースがCSPまたはCORSに一致しないと判断した場合、このスクリプトまたはCSSファイルは読み込まれず、コンソールに次のように書き込みます。 「このスクリプトに注意してください、初期化するこの行に彼。 見て、あなたに何か問題があります！」

MDN 、OWASP、およびW3Cのドキュメントには、CSPおよびCORSポリシーを実施するためのガイドラインが記載されています。 さらに、侵入テストツールキットは、プロジェクトのCORSおよびCSPルールへの準拠を報告します。 プロジェクトの自動テストを実施するフレームワークまたはツールは、欠陥を指摘します。

ユーザー認証

OpenID ConnectとKerberosプロトコルを使用します。 外部ユーザーの認証には、かなり一般的なOpenID標準が使用されます。

Kerberosは内部ネットワークにより適しています。銀行では、従業員の自動認証に使用されます。 組織の従業員が働くローカルマシンがあるとします。 彼はこのマシンで一度認証すると、どこにいてもログインとパスワードを再度入力する必要がなくなります。従業員はアプリケーションにログインし、システムはすぐに認証します。 Kerberosにはローカルマシン用の微妙な設定があり、これは各コンピューターと各ブラウザーに対して構成する必要があるため困難です。 Internet Explorerが通常デフォルト設定をプルアップし、ChromeがIE設定をプルアップする場合、Firefoxは個別に設定する必要があります。 MacOS XのSafariは設定自体を見つけますが、WindowsのSafariの場合は手動で設定する必要があります。

すべてのブラウザーで、アプリケーションが正常に機能するかどうかを確認する必要があります。 たとえば、Windowsで作業している場合、Safariをローカルにインストールしてプロジェクトをテストし、Macで作業している場合、仮想マシンでWindowsを起動して、対応するブラウザーバージョンでアプリケーションを実行します。

認証は、Passport.jsおよびエクスプレスセッションパッケージ、Auth0 SDKを使用して、最新のアプリケーションに実装できます。

OpenID Connectまたはその他のプロトコルを介して認証サービスを開発できない場合は、Auth0などのプロキシレイヤーを使用して、インターネットリソースへの安全なアクセスをユーザーに提供することを専門とするサードパーティ企業を通じて認証が行われるようにします。

アプリケーションをNode.jsにアップグレードするときは、サーバーでPassport.js、エクスプレスセッションなどのパッケージを使用することをお勧めします。 クライアントのセキュリティを確保するために、認証用のコンポーネントを独自に上げます。 フォームフィールドの自動補完を除外するために、認証フォームでautocomplete off属性を指定することを忘れないでください。

パスワードハッシュ

OWASP Webサイトでは、データベースに組み込まれているパスワードハッシュメカニズムを使用しないことをお勧めします。 このためには、Argon2、PBKDF2、ccrypt、bcryptなどのパッケージを使用することをお勧めします。 私の練習では、Argon2を使用します。これはGCC、PGP / GPGアルゴリズムなどのラッパーですが、GCCパッケージを最初にインストールする必要があります。 Argon2の使用スキーム：

 1.  GCC >= 4.8 install $ brew install gcc 

 2.     - $ npm install -g node-gyp 

 3.   Argon2 $ npm install argon2 

 4.   import * as ARGON from 'argon2'; ARGON.generateSalt().then( (salt: string) => {  ARGON.hash('some-user-password', salt)    .then((hash : string) => {       console.log('Successfully created Argon2 hash:', hash);       // TODO: store the hash in the user database  }); }); argon2.verify( 'previously-created-argon-hash-here', 'some-user-password').then(() => {  console.log('Successful password supplied!');  // TODO: log the user in }).catch(() => {  console.log('Invalid password supplied!'); }); 

難読化

難読化により、コードを変更してコンポーネントに分解できないようにすることができます。 結局のところ、攻撃者だけでなく、攻撃者はリバースエンジニアリングを非常に頻繁に使用します。プログラマは何らかの種類のJSファイルを取得し、ソースの分析を開始します。 したがって、悪意のあるコードを実装するために、特定のスクリプトの使用方法を学習したり、作業のメカニズムを理解したりできます。 または、これらのメカニズムを使用してWebアプリケーションをハッキングし、ステルス攻撃を実行します。

ハッカーは問題になりません。 まず、リソースの調査を行い、脆弱性と攻撃ベクトルを決定します。 たとえば、データを操作したり、トランスポートプロトコルに含まれる脆弱性を悪用したりします。 攻撃ベクトルは、特定のオペレーティングシステムの脆弱性を標的にすることができます; UNIXシステムには多くの脆弱性があります。 ただし、管理者がセキュリティポリシーを適切に構成していない場合（たとえば、外部へのURLが正しく構成されていない場合）のみ、脆弱性を利用できます。

そのため、偵察にはリバースエンジニアリングが使用されます。 完全に除外することは不可能ですが、非常に難しい場合があります。 これには、さまざまな難読化ツールが使用されます。私の場合はjavascript-obfuscatorです。 それに基づいて、webpackのプラグイン-webpack-obfuscatorが作成されました。 また、webpack用にobfuscator-loaderが作成されました。 このパッケージには、低、中、高のさまざまなレベルの偏執病に対する推奨設定があります。これらは公式Webサイトで見つけることができます。 この難読化ツールを使用する場合は、webpackに組み込まれた縮小メカニズムではうまく機能しないことに注意してください。 ミニファイと難読化を一緒に使用しないでください。併用すると、難読化ツールがスクリプトコードを完全に破壊する可能性があります。

さらに、難読化ツールは、スクリプトのボリュームとその読み込みを増やします。 ここで、自分で決定する必要があります。セキュリティ、安定性、信頼性を向上させますが、利便性と速度を失います。 または速度を気にしますが、ガイドラインに従うことについては安全性を忘れます。

脅威のログと監視

既知の脆弱性を持つパッケージの使用などの脅威があります。 このような状況では、npm audit、Snyk、LGTMなどの脅威分析ツールが役立ちます。 Npm auditはnpmに組み込まれている標準ユーティリティですが、このコマンドを常に呼び出すか、松葉杖を作成する必要があります。 したがって、Snykを使用することをお勧めします。 このプロジェクトには、脆弱性を持つ独自のデータベースがあります。 テストを開始すると、Snykはこのデータベースにアクセスし、部外者がアクセスできないSnykプロジェクトにレポートを内密にアップロードします。 確かに、プロジェクトを無料で確認できるのは300回だけで、各事前コミットを確認すると、これらの300回の無料試行は非常に迅速に終了します。 したがって、事前プッシュまたは事前マージフックのチェックを実行することをお勧めします。

人間はどのシステムでも最も重要な脆弱性です。 したがって、アプリケーションのビルドを開始する前にプロジェクトを必ず確認してください。ソースコードにも悪意のあるものが含まれている可能性があります。 プロジェクトにアクセスできるのは1人だけですが、通常はチームとして作業します。 会社を「美しく」辞め、マークを残すことを決めたある種の「賢明な人」が現れたらどうでしょうか？ これも念頭に置いておく必要があります。

プロジェクトの最初からSnykパッケージを使用し、コンソールからスキャンを開始することをお勧めします。 ここではすべてが簡単です。インストール後、アカウントのログインとパスワードを設定すると、テスト自体は次のように実行できます。

• npm i snyk —D依存関係をインストールし、package.jsonで「snyk」：trueを指定した後、次を実行します。

 ./node_modules/.bin/snyk wizard --dev 

• package.jsonで、スクリプトと設定を追加します。

 { ... "scripts": {  ...  "test": "npm run test:snyk && npm run test:jest",  ...  "test:snyk": "snyk test --dev",  ...  "prepare": "npm run prepare:snyk",  "prepare:snyk": "snyk protect" }, "husky": {  "hooks": {   "commit-msg": "commitlint -E HUSKY_GIT_PARAMS",   "pre-commit": "npm run test:snyk && npm run lint && npm run test:jest",   "pre-push": [    "npm run test:snyk",    "npm run lint",    "npm run test:jest",    "npm run build:production"   ],   ...  } }, "snyk": true } 

上記では、セキュリティの脅威に関するローカルチェックを確認しました。 パッケージの既知の脅威を確認するには、LGTMの使用もお勧めします。 このプロジェクトをGitHubまたはBitbucketと組み合わせて使用​​して（試してみるまでは必要ありませんでした）、プッシュするたびにコードがすぐにチェックされます。

アプリケーション監視

フロントエンドの領域では、ツールはすでに十分に確立されており、クライアントパーツのログ記録と監視にあらゆる好みのツールが利用できます。 最も有名なのは、Sentry、TrackJS、およびInsightOpsです。 Sentryサーバーは、その物理サーバーに展開できます。 たとえば、2つのプロジェクトでは、アプリケーションの動作をログに記録するために完全に構​​成された別のサーバーを使用しました。 URLにアクセスして、すべてのログをそこにドロップしました。 アプリケーションでエラーが発生した場合、try catchブロックにラップされ、ravenパッケージメソッドを介してSentryサーバーに送信されます。 すべてがシンプルで便利です。 登録していないSentryで不明瞭なURLが表示される場合、埋め込みまたは不明瞭なメッセージが表示される場合、それらはあなたをハッキングしようとしています。 私の練習では、これは定期的に起こりました。 たとえば、プロジェクトの1つ-広告ブロッカーとアンチウイルスをバイパスするサービス-は、絶えずそれに対抗し、ハッキングしようとしました。

監視には、Grafanaの使用もお勧めします。 システムによって監視される基準と指標のシステムを検討することが重要です。 トラフィック、広告のリターン、レンダリング広告の程度、Yandexからのバナーの数などに注目しました。 （ランブラーグループのプロジェクト）。 Yandexはリクエストを処理する方法を理解する必要がありました。これはサードパーティのサービスであるため、監視が必要であり、失敗するとプロジェクト全体が完全に崩壊する可能性があるためです。

サードパーティのサービスとのすべての通信を監視すると、エラーがすぐに見つかります。 私の実践からの話：Yandexから、広告の返信が突然停止することがわかりました。 技術的な不具合があり、広告ネットワーク全体が緊密に停止したことが判明しました。 そして、Yandexが最初に私たちに知らせたのではありませんでしたが、私たちは彼らに電話をして、彼らのサービスで何が起こっているのかを彼らに尋ねました。

監視する最良の方法は何ですか？ 小さなURLを取得し、GETパラメーターを記述して、このURLにGETリクエストを送信します。 サーバー側で、このURLを処理し、ログをデータベースに書き込み、監視をGrafanaに上げます。 すべてがシンプルです。

それだけです 将来的には、Webアプリケーションを脅威から保護するというトピックについて引き続き執筆していきます。 最後まで読んだすべての人に-あなたのプロジェクトの安全を願っています）））

トピックを読むためのソースのリスト：

www.owasp.org/index.php/Main_Page

tproger.ru/translations/webapp-security

S.ホークス。 さらに高速な単一ページアプリケーション：セキュリティ

シーコード、ロバートC. CERT Cセキュアコーディング標準/ロバートC.シーコード。 -2008

チェタン・カランド。 ノードアプリケーションの保護-2017

スティーブン・パーマー。 Webアプリケーションの脆弱性の検出、悪用、防止-2011

ロバート・シモンスキー、ショーン・フィリップ・オリヤノ。 クライアント側の攻撃と防御-2012

マーカスピント、ダフィッドシュトゥッタード。 Web Application Hacker's Handbook：セキュリティの欠陥の発見と活用、第2版-2011

カールデュナ。 Node.js Webアプリケーションを保護する-2015