Web開発者向けのセキュリティノート

安全で信頼できるクラウドベースのWebアプリケーションを開発するのは簡単なことではありません。 でも-非常に難しい。 これがそうではないと思うなら、あなたは科学に未知のより高い生命体の代表者であるか、あなたはかさばるローストされたオンドリを待っています。



最小限の実行可能な製品を作成するというアイデアに触発され、1か月で何か有用で安全なものを開発できると確信している場合は、そのような「製品」ではなく、単なるプロトタイプをリリースする前によく考えてください。







Webプロジェクトのセキュリティを確保するために解決する必要があるタスクの次のチェックリストを確認すると、開発に含まれるものの多くが考慮されていないことがわかります。 どうする 少なくとも、潜在的なユーザーに正直になり、プロジェクトがまだ開発中であること、彼らがまだ完全なセキュリティシステムを持っていないプロトタイプに慣れることを提案することを伝えます。

データベース

• 可能であれば、暗号化を使用して、ユーザーを識別する情報を保存し、アクセストークン、電子メールアドレス、支払いの詳細などの機密データを保存します（特に、このアプローチでは、完全に一致するデータベースクエリを検索レベルに制限します）。
  
  
  
  
• DBMSが保存されたデータの費用対効果の高い暗号化をサポートしている場合、それを有効にしてディスク上の情報を保護します。 さらに、すべてのデータベースバックアップも暗号化されていることを確認します。
  
  
  
  
• データベースにアクセスするには、最小限の特権を持つユーザーアカウントを使用します。 スーパーユーザーアカウントを使用せずに、未使用のアカウントとパスワードが弱すぎるアカウントのシステムを確認してください。
  
  
  
  
• このような作業シナリオ用に設計されたキーストアを使用して、アカウントデータ、システムアクセストークン、およびその他の秘密情報を保存および転送します。 そのようなデータをアプリケーションコードにハードコードして保存しないでください。
  
  
  
  
• 準備済みのSQLクエリのみを使用して、SQLインジェクションによる攻撃からシステムを保護します。 たとえば、プロジェクトがNode.js用に設計されている場合、mysql nmpライブラリを使用しないでください。準備済みクエリをサポートするmysql2ライブラリを参照してください。
  
  

開発

• 各リリースの前に、システムコンポーネントの脆弱性を確認してください。 私たちはすべてのライブラリ、パッケージ、および作業環境について話している。 理想的には、チェックはCI-CDプロセスの一部として自動化されるべきです。
  
  
  
  
• 本番サーバーのセキュリティに関してあなたがとるのと同じ注意でこの問題を扱うことにより、開発コンピュータのセキュリティを確保してください。 開発は、潜在的に危険な外部環境マシンから隔離され、保護された状態で実行する必要があります。
  
  

認証

• bcryptなどの適切な暗号化アルゴリズムを使用して、すべてのパスワードがハッシュされていることを確認してください。 自己記述のハッシュ関数を使用せず、高品質のランダムデータを使用して、使用する暗号システムを正しく初期化します。
  
  
  
  
• 実績のある実証済みのコンポーネントを使用して、ログインを整理し、忘れたパスワードを復元し、パスワードをリセットします。 車輪を再発明しないでください。 実際、独立した開発では、考えられるすべてのシナリオでこのようなメカニズムの正しい動作を保証することは非常に困難です。
  
  
  
  
• ユーザーがランダムな文字セットで構成される長いパスワードを作成することを奨励する、シンプルだが脅威にならないパスワード要件を実装します。
  
  
  
  
• すべてのサービスプロバイダーに多要素認証を使用します。
  
  

DOS攻撃からの保護

• API に対するDOS攻撃がサイトのパフォーマンスに影響しないことを確認してください。 少なくとも、最も遅いAPIパスと、認証に関連付けられているプロジェクトの部分で要求頻度の制限を実施します。 たとえば、アクセストークンを作成するためのログインモジュールとサブシステムについて話すことができます。 サーバーサブシステムをDOS攻撃から保護するために、外部からアクセスできるプロジェクトの部分でCAPTCHAを使用することを検討してください。
  
  
  
  
• ユーザーがシステムに送信できるデータのサイズと構造、および実行するクエリに強力な制限を設定します。
  
  
  
  
• CloudFlareなどのグローバルキャッシュプロキシサービスを使用するなど、分散DOS攻撃の影響を軽減するためにシステムを使用することを検討してください。 攻撃中、これはプロジェクトの存続に役立ち、通常はサーバーの負荷を軽減し、サイトの読み込みを高速化します。
  
  

Webトラフィック

• 承認システムを保護するだけでなく、サイト全体にTLSを使用します。 認証フォームを保護するためだけにTLSを使用しないでください。 移行中に、strict-transport-security HTTPヘッダーを使用して、HTTPSプロトコルの使用を強制します。
  
  
  
  
• CookieにはhttpOnly属性が必要であり、保護されている必要があり、属性の中にはパスとドメインパラメーターが存在している必要があります。
  
  
  
  
• 安全でないインラインおよび安全でない評価の許可を与えることなく、コンテンツセキュリティポリシー（ CSP ）を使用します。 このポリシーの設定は簡単ではありませんが、労力と時間を費やす価値があります。 CDNコンテンツにはサブリソース整合性エンジンを使用します。
  
  
  
  
• クライアント応答でX-Frame-OptionおよびX-XSS-Protection HTTPヘッダーを使用します。
  
  
  
  
• HSTSメカニズムを使用して、TLSのみを使用してシステムへのアクセスを提供します。 クライアントシステムを信頼しないでください。サーバー側でHTTPSを使用してください。
  
  
  
  
• すべてのフォームでCSRFトークンを使用し、新しいSameSite Cookie属性を使用してCSRF攻撃から保護します。 最新バージョンのブラウザでサポートされています。
  
  

API

• 総当たり攻撃によって検出できるリソースがパブリックAPIにないことを確認します。
  
  
  
  
• ユーザーは、APIを使用する前に完全に認証され、適切に承認される必要があります。
  
  

検証とデータ変換

• クライアント側で、ユーザーが入力したデータを確認します。 これにより、ユーザーは自分のアクションにすばやく対応できます。 ただし、このチェックを信頼しないでください。 サイトのページに表示する前に、ユーザーが入力した内容を常に確認し、必要な形式に変換してください。
  
  
  
  
• サーバー上のホワイトリストを使用して、ユーザーからのすべてを確認します。 ユーザーが入力したエンコードされていないデータをHTTPリクエストとレスポンスに挿入しないでください。 どのような状況でも、ユーザーがSQLクエリやその他のサーバーロジックで入力した潜在的に危険なデータを使用しないでください。
  
  

クラウド設定

• すべてのクラウドサービスで開いているポートの最小数があることを確認します。 情報隠蔽による保護は保護ではありませんが、非標準のポートを使用すると、システムを攻撃しようとする人々の生活が複雑になります。
  
  
  
  
• データベースとサービスを、外部からアクセスできない仮想プライベートクラウド（VPS、仮想プライベートクラウド）に保持します。 エラーが原因で内部サービスが外部から見える可能性があるため、AWSセキュリティグループを設定し、VPC間のピアリングを設定するときは非常に注意してください。
  
  
  
  
• 異なるVPCで論理サービスを分離し、サービス間の通信のためにそれらの間のピアリングを構成します。
  
  
  
  
• すべてのサービスが、最低限必要なIPアドレスのセットからのデータのみを受け入れるようにしてください。
  
  
  
  
• IPアドレスとポートで発信トラフィックを制限し、 標的を絞ったサイバー攻撃とボット攻撃の可能性を最小限に抑えます。
  
  
  
  
• スーパーユーザーアカウントではなく、常にAWS IAMロールを使用します。
  
  
  
  
• システムのメンテナンスに関係する人および開発者には、最小限のアクセス権限を使用してください。
  
  
  
  
• 定期的に、スケジュールに従って、パスワードとパスワードを入れ替えます。
  
  

インフラ

• ダウンタイムなしでプロジェクトの更新を実行できることを確認してください。 ソフトウェアを迅速に更新できる完全自動システムを実装します。
  
  
  
  
• クラウド管理コンソールではなく、Terraformなどのツールを使用してインフラストラクチャ全体を構築します。 インフラストラクチャをコードアプローチとして実装するよう努めます。 これにより、必要に応じて、1回のキーストロークですべてを再作成できます。 クラウドリソースを手動で作成することは避けてください。 構成を監査します。
  
  
  
  
• すべてのサービスに集中ログツールを使用します。 ログを表示またはダウンロードするためだけにSSH経由でシステムに接続する必要がないように、ログシステムを構築する必要があります。
  
  
  
  
• 診断の孤立したケースを除き、SSHを介してサービスに接続しないでください。 通常、SSHを定期的に使用するということは、重要なタスクが自動化されないことを意味します。
  
  
  
  
• どのAWSサービスグル​​ープでもポート22を常に開いたままにしないでください。 絶対にSSHアクセスが必要な場合は、ログインとパスワードではなく、公開キー認証のみを使用してください。
  
  
  
  
• パッチを適用して更新する長期間有効なサーバーではなく、 不変のホストを優先します 。 このトピックに関する有用な資料を次に示します。
  
  
  
  
• 侵入検知システムを使用して、標的のサイバー攻撃による被害を最小限に抑えます。
  
  

インフラ運用

• 未使用のサービスとサーバーを無効にします。 最も安全なサーバーは、電源コードが引き出されたサーバーです。
  
  

システムテスト

• 監査アーキテクチャとシステムの実装。
  
  
  
  
• システムの侵入をテストします-自分自身をハックします。 ただし、このようなテストに外部の専門家を参加させることは有用です。
  
  

スタッフ研修

• サイバーリスクとシステムをハッキングするために使用されるソーシャルエンジニアリングの方法について話すことで、スタッフ（特に初心者）を訓練します。
  
  

緊急時対応計画

• 防御対象を記述する脅威モデルを作成します。 優先順位を付けて、考えられる脅威と攻撃の参加者をリストする必要があります。
  
  
  
  
• 明確な危機管理計画を準備します。 いつかそれが必要になります。
  
  

まとめ

この記事のチェックリストは完全なものではありません。 問題は、各Webプロジェクトが一意であり、その作成者だけがそのプロジェクトを脅かすものと、これらの脅威に対処する方法を正確に知っていることです。 ただし、さまざまなプロジェクトには多くの共通機能があります。 したがって、私たちは誰もがここに表示されるリストを自分のプロジェクトに合わせて調整できると信じています。



読んだ内容は、安全なWebアプリケーションの開発に関する資料の著者としての14年以上の経験に基づいています。 この経験は彼にとって簡単なものではありませんでした。彼の調査結果は、Webソリューションのセキュリティを懸念している人々にとって楽になると確信しています。

親愛なる読者！ このリストに何を追加しますか？