編集中はじめにこのドキュメントの目的は、セキュアコーディングの実践に向けた全体的なガイドラインを作成することです。ドキュメント全体のサイズはコンパクトに抑えながら、理解しやすいものにすることを目指しています。特定の分野についての追加情報を探している場合は、このドキュメントに記載された詳細へのリンクを参照してください。以下に挙げた情報は、広く受け入れられているセキュアコーディングの実践方法です。これらをベーステンプレートとして、それぞれのセクションを組織のポリシーとリスク許容度に応じた推奨事項で更新することをお勧めします。セキュアコーディングポリシーセキュアコーディングポリシーを常に維持します。(この標準はテクノロジに固有のものと、テクノロジに依存しないものがあります)、トレーニングに向けたコードレビュー結果のフィードバック、入力データ検証、出力データ検証などのアクティビティを一覧にします。セキュアコーディングポリシーは、なぜ必要になるのでしょうか。このポリシーは、組織全体で一貫性を維持するために役立ちます。開発プロジェクトにおけるセキュアコーディング標準の使用を垂直的および水平的に拡大する際にも役立ちます。以下のいずれかが必要になります。上記の要素を複数使用します。どちらも知識情報になるため、単一要素認証になります。ソフトトークンから生成される場合は、多要素認証になります。処理するトランザクションには、多要素認証を使用してください。クライアント側認証のみを使用している場合は、その認証が迂回、改ざんまたは悪用される可能性のないことを確認します。認証目的の場合、ユーザー名は一意であることが必要になります。重要なデータを処理するシナリオでは、ユーザーに一意の名前を選択します。銀行取引アプリケーション、ショッピングアプリケーション、個人を特定できるデータを処理するアプリケーションなどの場合です。日単位の周期でパスワードのローテーションを要求する必要があります。オンラインのパスワード推測とパスワード攻撃アプリケーションでは、以下のいずれかの方法で、オンラインのパスワード推測の試行を阻止する必要があります。回失敗したらアカウントをロックします。回失敗したら一時的にアカウントをロックします。可能であれば、パスワードのリセット時にアウトオブバンド検証を使用します。電話番号の入力を求めてはいけません。悪意のあるユーザーが、その情報を悪用する可能性があるためです。可能な場合は、ユーザー確認のためにセキュリティの質問について尋ねます。電子メールの検証機能アプリケーションで電子メールアドレスの所有権を検証する場合は、次の事項を調べます。(たとえば、ユーザーは通常と同じようにアプリケーションへのアクセスの認証を行う必要があります)。電子メールの検証コードは、最初の使用後に無効にする必要があります。時間後には無効にします。保存する必要があります。加えることが良策になりますが、十分とはいえません。コード内や構成ファイル内にパスワードを保存してはいけません。確認してはいけません。すべての内部接続と外部接続で、十分に適切な形式のユーザー認証とエンティティ認証が行われるようにします。この制御は迂回できないようにします。ロギングと監視すべての失敗をログに記録してレビューします。すべてのパスワードの失敗をログに記録してレビューします。すべてのアカウントのロックアウトをログに記録してレビューします。ビット以上にする必要があります。サーバーで処理する必要があります。それ以外の場合は、暗号学的に安全な乱数生成器によって生成する必要があります。分が推奨されています)。たびに設定する必要があります。送信を決して行わないように指示を与えます。値の露出を防止することです。アクセスを禁止するために設定する必要があります。(値を有効期限切れにして上書きします)。ロギングと監視すべてのセッションをログに記録しますが、カード所有者データや個人を特定できる情報はロギングしません。不審なアクティビティについて、すべてのログを監視します。アクセス制御https://www.owasp.org/index.php/Access_Control_Cheat_Sheetプレゼンテーション層ユーザーがアクセスできないリンクや機能は、表示しないことをお勧めします。その目的は、不要なアクセス制御メッセージを最小限に抑えることと、不必要にユーザーに表示される特権情報を最小限に抑えることです。ビジネス層システム内でアクションが実行される前に、確実にアクセス制御の検証を実行します。メッセージで、許可されていない機能を実行しようとすることがあります。データ層アクセス制御の検証を確実に実行して、ターゲットデータに対する操作がユーザーに許可されていることを確認します。実行できるものと想定してはいけません。ロギングと監視アクティビティに関連するアクセスのすべてをログに記録します。すべてのログを監視してレビューします。防止するために、エンコードしておく必要があります。エンコーディングの種類は、ユーザー制御のデータが挿入されるページのコンテキストによって決まります。エンティティエンコーディングが適しています。固有の出力エンコーディングが必要になります。対策の詳細については、次を参照してください。インジェクションの防止データの一部がユーザー制御であるかどうかを常に把握することは現実的ではありません。ステートメントの一部として使用するときには、いつでもパラメーター化クエリを使用する必要があります。インジェクション脆弱性の原因になります。インジェクションの防止を保証するアプローチです。送信をできる限り回避します。コマンドを実行するなど)。エスケープ処理ルーチンの作成時には、積極的なアプローチを使用するようにしてください。エンコードする積極的なアプローチを定義します。受け入れる場合は、より強力な検証が必要になります。これは、複雑になる可能性があります。詳細については、インフラストラクチャのセキュリティチームに問い合わせてください。セキュリティに有効だと見なされなくなりました)。分類されない情報の伝送などです。経由にする必要があります。経由でアクセスされるようにします。送信するのは言うまでもありません。経由で提示する必要があります。これには、CSS、スクリプト、イメージが含まれます。これを怠ると、中間者攻撃のベクトルを開いてしまうことになります。警告メッセージがブラウザーに表示されるようにもなります。ページを切り替える方法には注意が必要です。このような遷移は、攻撃の潜在的なターゲットになります。接続を許可しないように準拠ブラウザーに指示する必要があります。入力検証を使用して、アップロードされたファイル名が適切な拡張子タイプを使用していることを確認します。アップロードされたファイルが、定義済みの最大ファイルサイズを超えていないことを確認します。上に保存する際は新しいファイル名を使用します。このファイル名や一時ファイル名に、ユーザー制御のテキストを使用してはいけません。アーカイブに悪意のあるコンテンツが含まれていないか、分析する必要があります。提供されていることを確認します。ファイルに関する注意アップロード機能では、特定のファイルの種類と拡張子のみを許可するホワイトリストのアプローチを使用する必要があります。次に示すファイルの種類が許可されている場合には、セキュリティの脆弱性につながる可能性があるため、十分な注意が必要になります。クロスドメインのデータ読み込みを可能にします。攻撃を許す可能性があります。いう名前の付いたファイルを禁止することが最善策になります。ディレクトリ単位でのサーバー構成オプションを提供するものであり、許可してはいけません。画像書き換えライブラリを使用して、画像が正当であることを検証して、無関係なコンテンツを取り除きます。保存した画像の拡張子は、単にアップロードのヘッダーを信じるのではなく、画像処理によって検出された画像のコンテンツタイプに基づいて妥当な画像の拡張子に設定します。リストに含まれていることを確認します。ビジネスロジックの条件が満たされていない結果。ビジネスロジックが存在する環境に障害が発生した結果。アプリケーションが依存する上流システムまたは下流システムに障害が発生した結果。このようなエラーには、次のように対処します。関数のすべての呼び出しで、適切なエラー処理と戻り値のチェックを行うようにする。例外とエラー条件が適切に処理されるようにする。ユーザーにシステムエラーを返さないようにする。安全な方法でアプリケーションが失敗するようにする。エラーの発生時にはリソースを解放するようにする。スタックトレースがユーザーにスローされないようにする。メソッドがある場合は、それを使用する。メソッドは常に呼び出されるコードであり、例外をスローしたメソッドが参照するリソースの解放にも使用できます。これは、とても重要なことです。プールに返されなくなります。これは、プールの枯渇につながります。例外がスローされていない場合でも呼び出されます。認証と安全な通信のためのプロトコルとアルゴリズムについては、すべて暗号コミュニティによる入念な検査が必要です。(つまり、証明書が誰のものであるかを検証します)。ワイルドカード証明書は、それに関するビジネスニーズがない場合は使用を避けます。必要に応じて必要な期間だけ保存するようにして、機密情報が含まれないようにします。改ざんによる不正なアクティビティを実行できないようにします。フラグを設定して、通信回線を通した伝送が不用意に安全でない方法で行われないようにします。使用が強制適用されているかを判断します。全体を暗号化する必要があります。すべて、その名前、および必要な理由を定義します。安全な展開ホスト上の構成ファイル、ディレクトリ、およびリソースへのアクセスを認証と認可で保護し、直接的なアクセスを禁止します。ルールを使用して、ホスト上のリソースへのアクセスを禁止しておき、必要に応じてアクセス権を付与します。ようなディレクトリが保護されていることを確認します。ルールを使用して保護されていることを確認します。ファイルに直接アクセスできないようにします。クリーンな環境を維持します。アプリケーションで使用されることのないソースコードを含むファイルは削除します。開発ツールが含まれないようにします。実行可能ファイルのみが含まれるようにします。(これらには、バックドアが含まれている可能性があります)。コメント付きのコードとメタタグは、機密データを含んでいる可能性があるため削除します。可能であれば、リバースエンジニアリングを回避するために、ソースコードに難読化を施します。トークンの特徴ユーザーごと、およびユーザーセッションごとに一意。つのユーザーセッションに結び付けられる。暗号的に安全な乱数ジェネレーターによって生成されたもの。トークンの検証に失敗した場合はリクエストされたアクションを拒否します。ヘッダーを設定します。(ドメインに関係なく)、コンテンツのフレーム内表示をブロックします。すべてのサイトを対象に、コンテンツのフレーム内表示をブロックします。同一ドメイン内のサイトはブロックしません。セキュリティの構成ミス不要なサービス、ポート、プロトコルおよびデーモンは、すべて無効にします。既定のパスワードやベンダーが用意したパスワードは、すべて変更します。グループ化して、サーバーを保護します。内部の仕組みを公開しないように、エラーメッセージを変更します。スタックトレースがコンテナーに残されないようにします。ページは最小限にします。セキュリティで保護されていない直接的なオブジェクト参照https://www.owasp.org/index.php/Insecure_Direct_Object_Reference_Prevention_Cheat_Sheetディレクトリの一覧表示サーバーではディレクトリの一覧表示を有効にしてはいけません。並行実行と競合状態ロックメカニズムを使用して、共有リソースをロックします。共有リソースを読み取る前にロックを取得します。OWASPDisclaimers。