ウェブサイト及びサーバー監視の プレミアム製品

Server Densityについて

Webアプリケーションを保護する方法

Webアプリケーションを保護する方法

100%セキュリティーを確保することは不可能ですが、皆さん自身、Webアプリ、また顧客への様々なタイプの攻撃を軽減するために、Webアプリを保護するためのステップはあります。Server Density バージョン2ではこれらを製品をできるだけ強化した上で実践しようとしています。

これらのヒントは、SQLインジェクションからの保護、フィルタリング、セッション処理、およびXSRF保護になどのセキュリティのベストプラクティスに追加されるものです。以下の提案を実践する前に基本をご理解頂くために、OWASPのチートシートとOWASP チートシートをご確認下さい。:

SSL のみ

私が2009年にServer Densityを設立した当初は、できるだけ簡単にセットアップをするために、アクセスと監視エージェントのポストバックは、HTTPやHTTPS経由で許可されていました。ほとんどのサーバーがアウトバウンドポート80を常に許可していました。また、デフォルトを少し前にHTTPSに変更したので、これは考えていたほど問題にはなりませんでした。SSLは一般的にはパフォーマンス上でもボトルネックと考えられがちですが、それは決して正しい解釈ではなく、すべての接続先にSSLを強制しない理由は実際にはありません。

Server Density バージョン2では、新しいエージェントの導入とWeb UIへのアクセスの両方にSSLを強制できるように、新しいURLを使用しています。当社はまだ非SSLの下での古いドメインのエンドポイントをサポートしていますが、最終的には、それをリタイアさせます。

実装の状況を確認するための優れたレポートと今後のセキュリティのための推薦項目を取得するために、 Qualys SSLサーバーのテストを皆さんのURLで実行して下さい。

Server Density SSL

当社はまだRC4の脆弱性を解決するための最善の方法を検討中ですが、TLS1.2.のみサポートすることが適切だと思われます。しかしながら、 ブラウザーの開発バージョンでのみ現在はサポートしています。当社はブラウザーのオプションとして提供しており、ブラウザーのサポートが改善すれば、おそらく旧バージョンは無効にします。

完全な前方秘匿性のあるSSLのサポート

通常では、SSLへのすべての接続はURLは単一のプライベートキーにて暗号化されています。もし誰かがすべてのトラフィックをキャプチャした場合に、彼らは皆さんのキーにアクセスすれば、復号化される可能性があります。完全な前方秘匿性 はすべてのセッションにおいて新しいキーを交渉することでこれに対応します。つまり、一つのキーの妥協は、そのセッションのデータのみに影響を与えます。

もし、これを実行したい場合には、Webサーバーの設定の特定の暗号スイートを許可する必要があります。ECDHE-RSA-AES128-SHA:AES128-SHA:RC4-SHA はほとんどのブラウザーと互換性があります。理論と実装の詳細は、このブログの記事に記載されています

当社はnginx load balancersでSSLを終了し、これらの設定でSSLを実装します。

  
ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers   on;
# prefer RC4-SHA to avoid BEAST
ssl_ciphers ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH;

Google Chromeで接続状況の詳細を確認して、ECDHE_RSAを見つけることで、暗号タイプで完全な前方秘匿性を使用して接続しているかどうか分かります。:

server-density-perfect-forward-secrecy1

厳格なトランスポートセキュリティの使用

SSLの強制はHTTPの厳格なトランスポートセキュリティ と一緒に組み合わされるべきです。さもなければ、ユーザーがプロトコルなしで、例えばhttps://example.comではなくexample.comとタイプして、リダイレクトされる形で自身のドメインに入り込んでくるリスクがあります。HTTP経由のコミュニケーションでは短時間しかないので、リダレクトはセキュリティーホールを開けることになります。

このような事象は、返信と共にSTSヘッダを送信することで解決されます。それはブラウザーに記憶していて、リクエストを実際に発行せずに、強制的にhttpからhttpsに変換されるためです。これは再度チェックされる前に、ブラウザーが設定を記憶する時間のヘッダを送信することよりアーカイブされます。:


strict-transport-security:max-age=315360000; includeSubdomains

ヘッダは10年間に設定され、それぞれのアカウントが例えば、example.serverdensity.io.というような独自のURLを取得するためにサブドメインも含まれます。

ブラウザーのベンダーに厳格なトランスポートセキュリティの設定を送信

まだ、STSヘッダにも潜在的な欠点があります。それは初めのリクエストがあってから送信されるためです。これと組み合わせるためにはURLをブラウザーのベンダーに送信してsubmit your URL to browser vendors ブラウザーがSSL経由でURLにアクセスするように強制します。

これがクロームでどのように機能するかはFirefox seedsクロームのリストからURLを送信することで分かります。

コンテンツのセキュリティポリシーの強制

最も一般的なセキュリティ上の脆弱性の中でトップ10の中で, クロスサイトスクリプティングは3番目となっています。これはリモートコードが通常正しくないかもしくは良くないフィルタリングにより、サイトに注入されし、実行されるものです。

これに対処するための正しい方法は、許可されたリモートリソースのホワイトリストを提供することです。もしスクリプトURLがこのリストとマッチしない場合は、ブラウザーはブロックします。 これはすべてをブロックでき、その後で追加機能で特定のURを開くことができるので、新製品で実行する方が簡単です。しかしながら、ブラウザー開発ツールを使用する場合は、どのリモートホストが呼び出されているか簡単に確認することができます。

当社が使用しているCSP:


content-security-policy:script-src 'self' 'unsafe-eval' https://maps.google.com https://*.gstatic.com https://*.googleapis.com https://*.mixpanel.com https://*.mxpnl.com; connect-src 'self' https://maps.google.com https://*.gstatic.com https://*.googleapis.com https://*.mixpanel.com https://*.mxpnl.com; frame-src 'self' https://maps.google.com https://*.gstatic.com https://*.googleapis.com https://*.mixpanel.com https://*.mxpnl.com; object-src 'none

当社はこれを必要とするサードパーティの複数のライブラリをリライトするように、ここでは特別に安全ではない評価をしました。

すべてのコンテンツをホストすることができるドメインのワイルドカードの使用に注意して下さい。例えば、*.cloudfront.netにワイルドカードを使用する場合には、誰でもファイルをアップロードできるAmazonのCDNなので、誰もが任意のスクリプトをホストできるようになります!

またContent-Security-Policyは 標準のヘッダですが、 Firefox や IE は X-Content-Security-Policyのみサポートします。ヘッダの名前や指令についての詳細の情報はOWASPのドキュメントご覧下さい。 またこの入門編としてこのチュートリアルをチェックしてみて下さい。.

その他のHTTP セキリュティーヘッダ

またブラウザーによっては、その他のリスポンスヘッダの設定により、さらに追加のセキリュティ機能が可能になります。 それらは全般的にサポートされておらず、別の階層の(わずかの)保護だけですが、検討の価値はあります。:

パスワード、リメンバー・ミー、ログインリセットを正しく使用

これはアプリへのメインのゲートウェイであるので、ロギングする際のすべての段階を正しく実行しているか確認する必要あります。リサーチまた安全なプロセスをデザインするのに必要な時間はわずかです。

それから OWASPのチートシートと照らし合わせて認証プロセスを見直して下さい。.

マルチファクター認証を提供

server-density-mfa

もし、アプリが些細な消費者向の製品以上であると考えるのであれば、ユーザーがログインする前に、彼らが持っているものを使用して認証するマルチファクタ認証を提供する必要があります。 Google Authenticator のスタンダードを使用して下さい。なぜならば、それは 、すべてのプラットフォームで利用可能な認証のアプリがあり、ほとんどすべてのプラットフォーム用のライブラリを持っていからです。 カスタムでインストールするのは非常に厄介であり、独自アプリは皆さん自身のシステムを実装してくれません!

MFAトークンを追加/削除のようなものを再認証するようにして下さい。ユーザーがパスワードの変更などほとんどのアクションでその都度認証しなければならないことで不満を感じないように、当社は、すべてのユーザー·プロファイルの変更のためにこれを実行し、タイムアウトを持つことにしました。しかしながら、新たにトークンを追加したり、既存のトークンを削除する場合には、その都度認証が必要になります。

MFA は重要なアプリにとって、アカウントのハイジャックからの保護のために非常に重要です。

セキュリティ監査の実施

誰も完璧ではありません、皆さんが、正しく物事をやっていることを確認する唯一の方法は、それを壊すことによって、サードパーティにセキュリティを確認してもらうことです。

当社は、コードレビューと実装プロセス(コードを細かに確認)の一環として内部で自身のセキュリティレビューを行うだけでなく、外部のセキュリティコンサルタントからの定期的なレビューを受けています。当社のレビューは the guys at &yet (through lift security)によって行われますが、 Matasano も知知名度が高いです。私は、一つの会社が監査を行って、修正を施した後で別の会社に変更点を監査してもらうことをお勧めします。

継続的な改善

セキュリティとは攻撃のリスクを軽減するためにレイヤを追加していくということす。しかし、キーワードはリスクの軽減です。. 新たな脅威は、常に浮上しており、継続的にセキュリティをを施す必要があります。つまり、すべての既存の施策の定期的な見直し、新たな防御機構をチェックし、セキュリティのアナウンスに注意を払うことを意味します。