Awesome Application Security Checklist

Awesome-Application-Security-Checklist

セキュリティを念頭に置いてWeb/モバイルアプリケーションを設計、作成、テストしている場合、このカウンター測定のチェックリストは良い出発点になる可能性があります

認証システム（signup/signin/2因子/パスワードリセット）

• どこでもhttpsを使用します。
• Bcryptを使用してパスワードハッシュを保存します（塩は必要ありません - Bcryptあなたのためにそれを行います）。
• logout後にセッション識別子を破壊します。
• リセットパスワードですべてのアクティブセッションを破壊します（または提供する）。
• OAUTH2にstateパラメーターが必要です。
• ログインが成功した後、または他の中間リダイレクトでオープンリダイレクトはありません。
• サインアップ/ログイン入力を解析する場合、javascript：//、data：//、crlf文字をサニタイズします。
• 安全な、httponly cookieを設定します。
• モバイルOTPベースのモバイル検証では、 generate OTPか、 Resend OTPときにOTPを応答に戻さないでください。
• 特定のユーザーのLogin 、 Verify OTP 、 Resend OTP 、 generate OTP試みを制限します。指数関数的なバックオフセットまたは/およびキャプチャベースの課題のようなものを持っています。
• 電子メール付きリンクまたはSMSでパスワードトークンのリセットのランダム性を確認してください。
• 妥当な期間、リセットパスワードトークンで有効期限を設定します。
• リセットトークンが正常に使用された後に期限切れになります。

ユーザーデータと承認

• my cart 、 my historyのようなリソースアクセスは、セッションIDを使用して、リソースのユーザーの所有権を記録することを確認する必要があります。
• 連続的に反復可能なリソースIDを避ける必要があります。 /user/37153/ordersの代わりに/me/ordersを使用します。これは、承認トークンをチェックするのを忘れた場合の正気チェックとして機能します。
• Edit email/phone number機能には、アカウントの所有者への確認メールが付属する必要があります。
• アップロード機能は、ユーザーが提供するファイル名を消毒する必要があります。また、一般的にセキュリティ以外の理由により、コードを実行できる独自のサーバーではなく、S3（およびLambdaを使用した後処理）のようなものにアップロードします。
• Profile photo upload機能は、必要でない場合はすべてのEXIFタグを消毒する必要があります。
• ユーザーIDおよびその他のIDの場合、整数の代わりにRFC準拠のUUIDを使用します。 GitHubで言語の実装を見つけることができます。
• JWTは素晴らしいです。単一ページアプリ/APIに必要な場合は使用します。

データベース

• ユーザーを識別するデータに暗号化を使用し、アクセストークン、電子メールアドレス、請求の詳細などの機密データを使用します。
• データベースが安静時に低コストの暗号化をサポートしている場合（AWS Auroraなど）、ディスク上のデータを保護することを可能にします。すべてのバックアップが暗号化されていることを確認してください。
• データベースアクセスユーザーアカウントに最小限の特権を使用します。データベースルートアカウントを使用しないでください。
• 目的のために設計されたキーストアを使用して、秘密を保存して配布します。アプリケーションにハードコードをしないでください。
• SQL準備されたステートメントのみを使用して、SQL注入を完全に防ぎます。たとえば、NPMを使用している場合は、NPM-MysQLを使用しないでください。準備されたステートメントをサポートするNPM-MysQl2を使用します。

Android / iOSアプリ

• 支払いゲートウェイからのsalt 、ハードコードされてはなりません。
• サードパーティのSDKからのsecret / auth tokenハードコードされるべきではありません。
• server to serverを実行することを目的としたAPI呼び出しは、アプリから実行されるべきではありません。
• Androidでは、付与されたすべての権限を慎重に評価する必要があります。
• iOSでは、システムキーチェーンに機密情報（認証トークン、APIキーなど）を保存します。この種の情報をユーザーのデフォルトに保存しないでください。
• 証明書のピン留めを強くお勧めします。

セキュリティヘッダーと構成

• CSPヘッダーAdd 、XSSとデータインジェクション攻撃を緩和します。これは重要です。
• CSRFヘッダーAdd 、クロスサイトリクエストの偽造を防ぎます。また、CookieにSamesite属性を追加します。
• HSTSヘッダーAdd 、SSLストリッピング攻撃を防ぎます。
• ドメインをHSTSプリロードリストにAdd
• xフレームオプションAdd 、クリックジャックから保護します。
• X-XSS-PORTECTIONヘッダーAdd 、XSS攻撃を緩和します。
• DNSレコードを更新して、SPFレコードを追加してスパムおよびフィッシング攻撃を緩和します。
• サードパーティCDNからJavaScriptライブラリをロードするかどうかをSubResource Integrity Checkを追加します。追加のセキュリティのために、SRI SATを持っていないリソースをロードしないように、sri-for csp-directiveを追加します。
• ランダムなCSRFトークンを使用し、HTTPの投稿要求としてビジネスロジックAPIを公開します。初期リクエストアップグレードフェーズなど、HTTPを介してCSRFトークンを公開しないでください。
• Get Requestパラメーターで重要なデータまたはトークンを使用しないでください。サーバーログまたはマシン/スタックの処理の露出は、ユーザーデータを順番に公開します。

入力の消毒

• XSSを防ぐために、すべてのユーザー入力またはユーザーにさらされた入力パラメーターSanitize 。
• SQL注入を防ぐために、常にパラメーター化されたクエリを使用してください。
• CSVインポートなどの機能に直接使用する場合、ユーザー入力を消毒します。
• coolcorp.io/usernameのようなURLパターンを使用している場合、プロファイル名としてrobots.txtなどの特別なケースのユーザー入力Sanitize 。
• オブジェクトがどれほど小さくても、文字列の連結でJSONを手渡しまたは構築しないでください。言語定義されたライブラリまたはフレームワークを使用します。
• SSRFを防ぐために何らかのURLを使用する入力を消毒します。
• ユーザーに表示する前に出力を消毒します。

サービス保護の拒否

• APIでのDOS攻撃がサイトを不自由にしないことを確認してください。少なくとも、ログインやトークンの生成ルーチンなどの遅いAPIパスにレートリミッターがあります。 DOSに対するバックエンドサービスを保護するために、フロントエンドAPIのCaptchaを検討してください。
• ユーザーが送信したデータとリクエストのサイズと構造に正気の制限を強制します。
• CloudFlareなどのグローバルキャッシュプロキシサービスを介して、分散型サービス拒否（DDOS）緩和を使用します。これは、DDOS攻撃に苦しみ、DNSルックアップとして機能する場合にオンにできます。

操作

• 小さくて経験の浅い場合は、AWS ElasticBeanStalkまたはPAASを使用してコードを実行します。
• まともなプロビジョニングスクリプトを使用して、クラウドにVMを作成します。
• 不要なopen portsを備えた機械を確認してください。
• databasesのNO/デフォルトパスワード、特にMongoDB＆Redisを確認してください。
• SSHを使用してマシンにアクセスします。パスワードをセットアップしないでください。代わりにSSHキーベースの認証を使用してください。
• アップデートをタイムリーにインストールして、Heartbleed、Shellshockなどのゼロデイの脆弱性に基づいて行動します。
• サーバー構成を変更して、HTTPSにTLS 1.2を使用し、他のすべてのスキームを無効にします。 （トレードオフは良いです。）
• デバッグモードをオンにしないでください。一部のフレームワークでは、デバッグモードは、本格的なリプルまたはシェルにアクセスするか、エラーメッセージスタックトレースで重要なデータを公開することができます。
• 悪い俳優とDDOに備えてください - DDOS緩和のあるホスティングサービスを使用してください。
• システムの監視をセットアップし、ログスタッフ（新しい遺物などを使用してください）。
• エンタープライズの顧客向けに開発する場合は、コンプライアンス要件を順守してください。 AWS S3の場合、この機能を使用してデータを暗号化することを検討してください。 AWS EC2を使用している場合は、この機能を使用して暗号化されたボリュームを使用することを検討してください（ブートボリュームでさえ暗号化できます）。

クラウド構成

• すべてのサービスが最小ポートを開いていることを確認してください。あいまいさによるセキュリティは保護ではありませんが、標準以外のポートを使用すると、攻撃者にとって少し難しくなります。
• パブリックネットワークでは見えないプライベートVPCのバックエンドデータベースとサービスをホストします。 AWSセキュリティグループと、サービスを誤って一般に見えるようにすることができるVPCをピアリングする場合は、非常に注意してください。
• 個別のVPCとピアVPCで論理サービスを分離して、サービス間通信を提供します。
• すべてのサービスが最小限のIPアドレスセットからのみデータを受け入れるようにします。
• 発信IPおよびポートトラフィックを制限して、APTと「司法化」を最小限に抑えます。
• ルート資格情報ではなく、常にAWS IAMの役割を使用してください。
• すべてのOPSおよび開発者スタッフに最小限のアクセス特権を使用します。
• スケジュールに応じて、パスワードとアクセスキーを定期的に回転させます。

CI＆CDユニット/統合テストのカバレッジを使用して、設計と実装を監査します。コードレビュープロセスを使用し、自己承認を無視します。ベンダーライブラリやその他の依存関係を含む、生産にプッシュする前に、サービスのすべてのコンポーネントがAVソフトウェアによって静的にスキャンされていることを確認してください。展開用のロールバックソリューションを設計します。

人々

• 電子メール（[email protected]など）とセキュリティ研究者が脆弱性を報告できるページを設定します。
• 何を作成しているかに応じて、ユーザーデータベースへのアクセスを制限します。
• バグ記者に礼儀正しくしてください。
• 安全なコーディングの観点から、仲間の開発者によるコードレビューを行ってください。 （その他の目）
• ハックまたはデータ侵害の場合は、以前のログをデータアクセスについて確認して、パスワードを変更するように依頼します。組み込まれている場所に応じて、外部機関による監査が必要になる場合があります。

インフラストラクチャー

• ダウンタイムなしでアップグレードできることを確認してください。完全に自動化された方法でソフトウェアをすばやく更新できることを確認してください。
• クラウドコンソールを介してではなく、Terraformなどのツールを使用してすべてのインフラストラクチャを作成します。インフラストラクチャは「コード」として定義され、ボタンを押すだけで再現できる必要があります。クラウド内で作成されたリソースに対して手でゼロトレランスを持つことができます。TerraFormは構成を監査できます。
• すべてのサービスに集中ロギングを使用します。ログにアクセスまたは取得するためにSSHを必要としないでください。
• 1回限りの診断を除き、サービスにsshしないでください。 SSHを定期的に使用すると、通常、重要なタスクを自動化していないことを意味します。
• AWSサービスグル​​ープで恒久的にポート22を開いておくことはありません。代わりに、ボックス上のSSHに認定されたIPのみを許可することを検討します。
• パッチとアップグレードする長寿命サーバーの代わりに、不変のホストを作成します。 （不変のインフラストラクチャを参照してください。
• sensedeepやサービスなどの侵入検知システムを使用して、aptsを最小限に抑えます。