セキュアコーディングは、XSSやメモリリークなどの脆弱性に早期に対処し、ソフトウェアのレジリエンスを高め、リスクを軽減します。
プロアクティブなプラクティスにより、コストのかかるリリース後の修正を防ぎ、ユーザーの信頼を育むことで、時間とコストを節約できます。
ベストプラクティスには、入力の検証、サードパーティコードの保護、SASTなどのツールの継続的なチェックの活用が含まれます。
OWASP、CERT、NIST の標準は、開発者が安全で信頼性の高いアプリケーションを構築するのに役立ちます。
Wiz Codeは、リアルタイムスキャン、実用的なフィードバック、SDLCを保護するためのガイダンスによる安全なコーディングをサポートします。
セキュアコーディングとは?
セキュアコーディングとは、開発の早い段階でセキュリティのベストプラクティス、手法、ツールを適用することで、セキュリティの脆弱性に耐性のあるソフトウェアを開発する手法です。 セキュアコーディングは、ユーザーエクスペリエンスだけを考えるのではなく、ソフトウェア開発ライフサイクルの最初から、すべての機能をセキュリティ対策に合わせます。
たとえば、サニタイズせずにクライアントからすべてのデータを受け入れるアプリケーションは、実装、使用、および保守が容易な場合があります。 ただし、攻撃者が悪意のあるコードを挿入するためのエントリポイントを開きます。
The Secure Coding Best Practices [Cheat Sheet]
With curated insights and easy-to-follow code snippets, this 11-page cheat sheet simplifies complex security concepts, empowering every developer to build secure, reliable applications.
Download Cheat Sheet
Why is secure coding important?
セキュアコーディングは、セキュリティをソフトウェアのDNAに組み込み、SQLインジェクション、バッファオーバーフロー、クロスサイトスクリプティングなどの脆弱性を防ぎます。 これは、侵害を防ぐだけでなく、ユーザーの信頼を保護し、セキュリティをシフトレフトし、データ保護法の厳しい基準を満たす方法です。
その見返りは? リリース後の不測の事態が減り、アプリが強化され、ユーザーと組織の両方に対する保護が強化されます。
安全なソフトウェアを構築するための7つの安全なコーディング手法
安全なソフトウェア開発プロセスは、脆弱性を防ぎ、アプリケーションを安全に保つのに役立つ適切なコーディング手法に従うことから始まります。 もし、'より詳細なリソースを探している場合は、OWASPの安全なコーディング要件を確認してください。 開発者ガイド.
それまでの間、より安全なソフトウェアシステムを構築するためにすぐに使用を開始できるいくつかの重要な手法を次に示します。
1. 最新の言語とツールを使用する
メモリ関連のセキュリティ脆弱性の多くは、手動のメモリ管理と組み込みのメモリ チェックがないプログラミング言語に影響を与えます。 新しいプロジェクトを開始するときは、本当に C/C++ が必要かどうかを確認し、必要であれば スマート ポインター そして 静的コードアナライザー 言語の欠陥の影響を最小限に抑えるため。
システムプログラミング機能が必要な場合は、 錆 その型システムはコンパイル時にメモリの使用をチェックするため、良い選択です。 ジグザグ また、隠れた制御フローやメモリ割り当てがないため、良い代替手段になるかもしれません。
システム プログラミング機能が必要ない場合は、Java や C# などのガベージ コレクション言語を使用すると、多くのメモリの問題から保護できます。
2. 入力データと出力データの検証とサニタイズ
未検証のユーザーデータは、インジェクションの欠陥の主な理由です。 そのため、システムに入力されるすべてのデータを検証することが非常に重要です。 衛生管理は、使いやすさを犠牲にすることなくセキュリティを維持できるもう1つのステップです。 サニテーションは、ユーザー入力が無効な場合に拒否する代わりに、問題のある入力部分(つまり、HTML内のJavaScript)を切り取り、残りのデータを使用します。 クライアント/サーバー環境で実行する場合は、この検証とサニテーションがサーバー上で行われるようにします。 これは、 バリデーターとサニタイザー ユーザーデータを受け入れるすべての API エンドポイントに。 また、検証が容易なデータ形式を選択することも意味します (たとえば、本格的な HTML ではなく単純な Markdown を受け入れるなど)。
入力データをクリーンに保つことは、常に可能であるとは限りません。バリデーションライブラリにもバグがあります。 ユーザーに漏れないようにするには、ユーザー入力に基づく出力のみを安全な方法で表示します (つまり、HTML をレンダリングしないでください)。
3. サードパーティのコードの整合性を確認する
サードパーティのライブラリとフレームワークは、開発をスピードアップするための命の恩人ですが、それらはあなたの家で構築されたものではないため、ひもが付いています。 それらをビルドプロセスへの入力と同様に扱い、慎重に吟味され、管理されています。
厄介な驚きを避けたいですか? 依存関係をピン留めする 特定のバージョンまたはハッシュ テストされていない更新が本番環境に忍び込むのを防ぐため。 これらのライブラリを定期的に監査および更新することは魅力的ではありませんが、古いコードがアキレス腱になるのを防ぐ唯一の方法です。
4. 厳格なアクセス制御を強制する
アクセス制御により、コードやリソースを表示または変更できるユーザーを制限し、機密性の高い機能やデータを権限のないユーザーから保護します。 にこだわる 最小特権の原則: ユーザーが仕事をするために必要なものだけを提供し、それ以上でもそれ以下でもありません。
セキュリティを強化するには、ロールベースのアクセス制御 (RBAC) と多要素認証 (MFA) の実装を検討してください。 これらの対策により、攻撃対象領域がさらに縮小され、権限のない個人が重要なシステムやデータにアクセスできないようにすることができます。
5. 適切なエラー処理とログ記録を実装する
攻撃者にロードマップを渡したい人はいませんが、過度に詳細なエラーメッセージはまさにそれを可能にします。 スタックトレースやデータベースエラーなど、内部の詳細をユーザーの手に渡らないようにします。 代わりに、チームの目だけに安全かつ思慮深く記録します。
優れたログは、何が、いつ、なぜ起こったのかというストーリーを伝えます。 怪しいものがないか監視しますが、機密データをログに記録してやりすぎないようにしましょう。 ここではバランスが重要であり、トラブルシューティングを行うのではなく、公開します。
6. コードレビューの自動化
手動レビューは重要ですが、自動化も必要です。 次のような自動化ツール 静的アプリケーション・セキュリティ・テスト(SAST) また、リンターは、人間よりも早く脆弱性やコーディングエラーにフラグを立てます。
これらのツールをCI/CDパイプラインにフックすると、すべてのコード変更がマージされる前に一度やり直されます。 すぐにフィードバックが得られるため、開発者は常に最新情報を入手し、セキュリティのベストプラクティスを最優先に考えることができます。
7. コードの難読化手法を適用する
コードの難読化は、アプリを万全にするわけではありませんが、攻撃者の速度を低下させます。 変数の名前を意味不明な名前に変更したり、文字列をエンコードしたり、コードを再構築したりすると、リバースエンジニアリングや知的財産の盗難が難しくなります。
これはカモフラージュを追加すると考えてください:アプリはまだユーザーにとってスムーズに動作しますが、悪意のある人物は侵入したり、彼らが見ているものを理解したりするのがはるかに難しくなります。 どんなハードルも助けになります。
一般的なコードソフトウェアの脆弱性
ソフトウェア開発者やセキュリティ研究者が特定した一般的なセキュリティの脆弱性を見てみましょう。 メモリの脆弱性などの低レベルの問題から、インジェクション攻撃などの高レベルの問題まで説明します。
バッファオーバーフロー
バッファオーバーフローは、アプリケーションをクラッシュさせたり、攻撃者が他のバッファにデータを書き込んだりする可能性があります。
C/C++ などのシステム プログラミング言語は、この脆弱性の影響を受けやすいです。 メモリ管理を明示的に許可し、要求することさえありますが、手遅れになるまでメモリアクセスをチェックしません。 定義時に割り当てたデータよりも多くのデータをバッファーに書き込むと、C はバッファーの末尾に続くすべてのメモリ データをオーバーライドします。
C 言語でのバッファオーバーフローの例:
int型b[5];
b[5] = 999;buffer は 0 から 4 までしか進みません解放後使用
メモリ解放後使用は、ヒープ上のメモリを解放したが、古いポインターを使用し続ける場合に発生します。
繰り返しになりますが、この脆弱性は、メモリを手動で管理する必要がある C/C++ などのガベージ コレクションのない言語で顕著です。 メモリには、スタックとヒープの 2 種類があります。 この言語はスタックを自動的に管理しますが、スタックはコンパイル時に不明な動的なサイズのデータを保持できません。 ヒープは動的データ用ですが、手動で領域を割り当てて解放する必要があります。 解放とは、メモリが不要になったことをオペレーティングシステムに通知することを意味するため、後でポインタを使用してメモリを使用すると、不正なアクセスは未割り当てのメモリの場所に移動します。
C言語でのメモリ解放後の使用例:
char* p = (char*)malloc (16);
p = strdup("いくつかのテキスト!");
フリー(p);
printf("%s", p);解放されたメモリ内の現在の内容を出力しますダブルフリー
二重解放の場合、ヒープ メモリを解放した後で解放します。
二重解放は、手動メモリ管理を行う言語では問題であり、特定のメモリ範囲が不要になったことをオペレーティングシステムに明示的に通知する必要があります。 これを 2 回行うと、メモリ解放後使用 (Use After Free) の問題と同様のクラッシュが発生します。 これは通常、ある時点で解放される互いへのポインターを持つ複数のオブジェクトがある場合に発生します。 二重解放は、最初の解放の前にポインターが参照したメモリを破損する可能性があります。
C言語のdoublefreeの例:
char* p = (char*)malloc (16);
p = strdup("いくつかのテキスト!");
フリー(p);
フリー(p);解放されたメモリの内容が破損します安全でない逆シリアル化
安全でない逆シリアル化では、外部データ構造(JSON、XMLなど)を内部データ構造(オブジェクト、配列など)に十分なチェックなしで直接変換します。
安全でない逆シリアル化は、あらゆる種類のアプリケーションに共通する脆弱性です。 開発中にサニタイズされていないデータを受け入れるのは良いことかもしれませんが、本番環境で行われると、ユーザーは予告なしに悪意のあるデータを忍び込ませる可能性があります。
JSON での安全でない逆シリアル化の例:
{
"名前": "例",
"電子メール": "email@example.com",
"isAdminです": true // サーバー上で削除する必要があります
}メモリリーク
メモリリークにより、アプリケーションはメモリを際限なく消費します。 使用可能なメモリを使い果たしてさらに要求すると、アプリケーションがクラッシュします。
十分に複雑なアプリケーションはすべてこの脆弱性の影響を受けます。 ガベージ コレクションされた言語でさえ、メモリ リークから安全ではありません。 ガベージ コレクション言語では、ガベージ コレクターが管理できないデータ構造を構築できます。
インジェクションの欠陥
ユーザー入力を検証せずにコードとして実行することは、インジェクションの欠陥として知られています。
この問題は、使用するプログラミング言語に関係なく、すべてのアプリケーションに影響を与える可能性があります。 アプリケーションをインジェクションの欠陥に対して脆弱にする方法の 1 つは、ユーザーがカスタム コードを機能として追加し、実行を適切にサンドボックス化しないようにすることです。 攻撃者が実行可能なメモリの場所にコードを書き込むことを可能にするバッファオーバーフローは、アプリケーションがインジェクションの欠陥に対して脆弱になる可能性がある別の方法です。
クロスサイトスクリプティング(XSS)
クロスサイトスクリプティングは、インジェクションの欠陥のWeb固有のバージョンです。 ここでは、攻撃者はHTMLマークアップ内に隠されたカスタムJavaScriptを挿入します。
XSSはすべてのWebサイトで発生する可能性があります。 マークアップと実行可能コードは Web 上で緊密に統合されているため、JavaScript が HTML に忍び込みやすく、機密データが漏洩します。
HTML と JavaScript での XSS の例:
<--、フェッチ要求が送信されます
マウスが <p> 要素-->
<p onmouseover="fetch('//example.com')">ハローワールド！</p>XML 外部エンティティ (XXE)
XML 外部エンティティは、インジェクションの欠陥の別のインスタンスです。 XML を使用するすべてのアプリケーションがこの攻撃の影響を受けます。 XML の外部エンティティの背後にある考え方は、既存の XML ファイルの再利用を可能にすることです。 ただし、攻撃者はこの機能を使用してプライベート XML ファイルへのリンクを含め、アップロードされた XML ファイルを介して間接的にプライベート データを読み取ることができます。
外部 XML エンティティの挿入の例:
<?xml バージョン="1.0" エンコーディング="ISO-8859から1"?>
<!DOCTYPE a [
<!要素 A ANY >
<--、これはxxeと呼ばれる新しいエンティティを定義します
プライベートファイルから -->
<!エンティティXXEシステム "file:///etc/passwd" >
]>
<--、ここではエンティティがレンダリングされて表示されます
ファイルの内容 -->
<a>&xxe;</a>非セキュア直接オブジェクト参照 (IDOR)
パブリック API が連続した ID を持つオブジェクトを直接参照できるようにすると、IDOR により、攻撃者はサーバー上のすべてのオブジェクトの ID を推測できます。
この問題は、連続した ID を使用してオブジェクトを参照する場所で発生する可能性があり、承認を必要とせずに ID を使用してパブリック オブジェクトとプライベート オブジェクトを参照する場合に特に深刻です。
URL の例:
https://example.com/users/4539
https://example.com/users/4540
https://example.com/users/4541
ディレクトリトラバーサル(別名パストラバーサル)
もう1つのインジェクションの欠陥は、攻撃者がファイル名入力を介してパスやディレクトリ構造をトラバースできることです。
ファイル名の入力を許可するすべてのアプリケーションがこの脆弱性の影響を受ける可能性があります。 ディレクトリトラバーサルは、ユーザーが相対パスを介して相互に参照する複数のファイルをアップロードするときに発生する可能性があります。 攻撃者は、次のようなファイルトラバーサルパスを使用できます ".." をクリックして、サーバー上のアップロードディレクトリから、管理者または他のユーザーからのファイルを含むディレクトリに移動します。
Node.js 上の JavaScript でのディレクトリトラバーサルの例:
これにより、プライベートなjavascriptファイルが読み込まれます
const テンプレート = require("../../../server/config/database")
render(テンプレート)コードのセキュリティ標準
セキュアコーディング標準は、開発者が安全なソフトウェアを作成し、脆弱性を最小限に抑えるために従う一連のガイドラインとベストプラクティスです. これらは、攻撃者に悪用される可能性のある一般的なコーディングの間違いや弱点に対処し、より回復力のある耐性のあるコードを作成することを目的としています。
以下は、従うべき一般的なセキュアコード標準です。
OWASP Secure Coding Practices(SCP)は、Open Web Application Security Projectによるガイドラインであり、入力検証、認証、セッション管理、暗号化、エラー処理など、ソフトウェアセキュリティを向上させるための主要な領域に焦点を当てています。 これは、より安全なコードのためのロードマップです。 最初のコミットから最終デプロイまで.
CERT Secure Coding Standards (SCS) は、カーネギーメロン大学のソフトウェア工学研究所 (SEI) によって開発された一連のガイドラインと推奨事項であり、開発者が安全なコードを作成し、脆弱性を防ぐのに役立ちます。 重点分野:
言語固有のガイドライン:C、C++、Java、Android、Perl の一般的な脆弱性に対処するための推奨事項を提供します。
防御的プログラミング:悪用を防ぐために、エラーの予測と適切な処理を強調します。
メモリ管理:特に C や C++ などの言語でのバッファー オーバーフローとメモリ リークの防止に重点を置きます。
NIST Secure Coding Guidelines (NIST Special Publication 800-218 とも呼ばれます) は、入力の検証、認証、暗号化、エラー処理などの重要な領域に焦点を当てており、インジェクション攻撃、セッション ハイジャック、メモリの問題をソフトウェアから排除するための明確なアドバイスを提供しています。 あなたがあなたの上に政府の支援を受けた承認のスタンプが必要な場合 コードセキュリティの実践、これはあなたの頼みの綱です。
ISO/IEC 27001は、情報セキュリティの国際規格です。 その間、'は、特に安全なコーディング標準ではありませんが、包括的なセキュリティ管理アプローチの一部として、安全なコーディング手法の要件が含まれています。 附属書A「Control 8.28: Secure Coding Practices」では、特に安全なコーディングに焦点を当て、組織が次のことを行う方法を強調しています。
社内開発とサードパーティコードのための安全なコーディングプロセスを開発します。
進化する脅威と脆弱性について常に情報を入手してください。
それらに対処するために、堅牢な安全なコーディングの原則を実装します。
Wizで安全なソフトウェア開発ライフサイクルを確保
セキュアコーディングは、データ形式やプログラミング言語の選択から、入力と出力の計画、実装まで、ソフトウェア開発のあらゆる側面に関わるプラクティスです。
私たち'紹介することに興奮しています Wizコードは、開発者とセキュリティチームがソフトウェア開発ライフサイクル全体を通じて堅牢で安全なコーディングプラクティスを実装および維持できるように設計された最新のイノベーションです。
Wiz Codeは、クラウドセキュリティプラットフォームを開発のあらゆる段階に拡張し、お客様の安全なコーディングイニシアチブをサポートする強力な機能を提供します。
統合されたコードスキャン: 脆弱性、設定ミス、コンプライアンスの問題を IDE とコード リポジトリで直接検出し、潜在的な問題を本番環境に到達する前にキャッチします。
リアルタイムのセキュリティフィードバック: コーディング中にセキュリティに関する洞察を即座に取得できるため、開発者は問題にすぐに対処し、外出先で安全なコーディング手法を学ぶことができます。
クラウドからコードへのトレーサビリティ: 本番環境で検出されたリスクを、そのリスクを導入した特定のコードとチームまでさかのぼって追跡し、迅速な根本原因分析と修復を促進します。
インコード修復ガイダンス: 開発環境内でセキュリティ問題を修正するための、コンテキストに応じた実用的な推奨事項を受け取ります。
包括的な言語サポート: 幅広いプログラミング言語とフレームワークにわたる安全なコーディングのベスト プラクティスを利用できます。
Secure your SDLC from start to finish
See why Wiz is one of the few cloud security platforms that security and devops teams both love to use.
