Programming Self-Study Notebook

勉強したことを忘れないように!　思い出せるように!!

Programming Self-Study Notebook：目次

目次

言語系

ミドルウェア系

開発支援ツール

OS系

クラウドインフラ系

開発手法について

その他

『OWASP Top 10』 について調べてみた

セキュリティ OWASP



OWASP Top 10とはWebアプリケーションのセキュリティのための啓発文書です。このTop10とは別にAPIに関するTop10もOWASPからリリースされています。 ココはOWASP Top 10を勉強した際の内容を記載します。

参考文献

Top10の詳細

A01:2021-Broken Access Control(アクセス制御の不備)

説明

アクセス制御とは、ユーザーが意図された権限を超えて行動できないようにポリシーを適用することをいう。障害はすべてのデータの不正な情報開示、変更、破壊、またはユーザーの制限を超えたビジネス機能の実行につながります。

一般的な例

詳細

  • 誰でもアクセスできてしまう。
    • 個人ごとにアクセスできる情報は違うはず - アクセス制御チェックをバイパスできてしまう。
    • URL、内部アプリケーションの状態、または HTML ページを変更する
    • API リクエストを変更する攻撃ツールを使用する
  • 他の人のアカウントの表示または編集を許可する
    • 一意の識別子 (安全でない直接オブジェクト参照) を提供してしまう
  • データを変更するAPI（POST、PUT、DELETE等）に対するアクセス制御の欠如
  • 特権の昇格
    • ログインせずにユーザーとして行動できてしまう
    • ユーザーとしてログインしているときに管理者として行動できてしまう
  • メタデータの操作により想定外のアクセスコントロールになる
  • 未承認または信頼できないオリジンからのAPIアクセスが許可されてしまう
    • CORS の構成ミスにより、未承認または信頼できないオリジンからのAPIアクセスが許可されます。
  • 設計ミス
    • 非認証ユーザーとして認証済みページを参照できてしまう
    • 標準ユーザーとして特権ページを強制的に参照できてしまう

予防方法

詳細

  • アクセス制御は、攻撃者がアクセス制御チェックやメタデータを変更できない、信頼できるサーバー側コードまたはサーバーレスAPIでのみ有効にする。
  • 公開リソースへのアクセスを除いて、アクセスを原則として拒否する。
  • アクセス制御メカニズムを一度実装すると、Cross-OriginResourceSharing(CORS)の使用を最小限に抑えるなど、アプリケーション全体で再利用する。
  • モデルのアクセス制御では、ユーザーがレコードを作成、読み取り、更新、削除できることを認めるのではなく、レコードの所有権を強制する。
  • 独自のアプリケーションビジネス制限要件は、ドメインモデルによって強制する。
  • Webサーバーのディレクトリ一覧を無効にし、ファイルのメタデータ(.gitなど)とバックアップファイルがWebルート内に存在しないようにします。
  • アクセス制御の失敗をログに記録し、必要に応じて管理者に警告する(失敗の繰り返しなど)。
  • APIとコントローラーのアクセスをレート制限して、自動化された攻撃ツールによる被害を最小限に抑えます。
  • ステートフルセッションIDは、ログアウト後にサーバー上で無効化する必要があります。ステートレスJWTトークンは、攻撃者が侵入する機会を最小限に抑えるために、有効期間を短くする必要があります。存続期間の長いJWTの場合は、OAuth標準に従ってアクセスを取り消すことを強くお勧めします。

A02:2021-Cryptographic Failures(暗号化の失敗)

説明

送信あるいは保存するデータが保護を必要とするか見極める。 例えば、パスワード、クレジットカード番号、健康記録、個人データやビジネス上の機密は特別な保護が必要になる。

また以下のような場合、データに対して特に注意が必要です

  • EUの一般データ保護規則(GDPR)のようなプライバシー関連の法律が適用される場合
  • PCIデータセキュリティスタンダード(PCI DSS)など金融の情報保護の要求があるような規定がある場合

一般的な例

詳細

  • どんなデータであれ平文で送信していないか。
    • これは、HTTP、SMTP、FTP、あるいはSTARTTLSのようなTLS upgradesのプロトコルを使っている場合に該当する。外部インターネットへのトラフィックだけでなく、ロードバランサー、Webサーバー、バックエンドシステムなどの内部の通信もすべて確認すること。
  • 古いまたは脆弱な暗号アルゴリズムやプロトコルを初期設定のまま、または古いコードで使っていないか。
  • 初期値のままの暗号鍵の使用、弱い暗号鍵を生成または再利用、適切な暗号鍵管理または鍵のローテーションをしていない。暗号鍵がソースコードリポジトリに含まれていないか。
  • HTTPヘッダー（ブラウザ）のセキュリティに関するディレクティブやヘッダーが欠落しているなど、暗号化が強制されていない箇所はないか。
  • 受け取ったサーバー証明書とその信頼チェーンが適切に検証されているか。
  • 初期化ベクトルが無視されたり、再利用されたりしていないか。また、暗号利用モードにとって十分にセキュアではない状態で生成されていないか。 ECBといった安全でないモードが使用されていないか。 認証付き暗号がより適切な場合において、認証付き暗号でない暗号が使用されていないか。
  • 鍵導出関数を使うことなしにパスワードを暗号鍵として使用していないか。
  • 暗号学的要件を満たすように設計されていない目的でランダム性が使用されていないか。 適切な関数が選ばれている場合でも、関数は開発者による初期化が必要か。 必要でない場合、開発者が十分なエントロピーや予測不可能性を欠いたシードを用いて組み込みの強力な初期化機能を上書きしていないか。
  • MD5やSHA1といった非推奨のハッシュ関数が使用されていないか。また暗号学的ハッシュ関数が必要とされる場合において、暗号学的でないハッシュ関数が使用されていないか。
  • PKCS#1 v1.5といった非推奨の暗号学的パディング方式が使用されていないか。
  • 暗号化時のエラーメッセージやサイドチャネルの情報が、パディングオラクル攻撃のような種類の攻撃に利用可能ではないか。

予防方法

詳細

最低限実施すべきことを以下に挙る。

  • アプリケーションごとに処理するデータ、保存するデータ、送信するデータを分類する。
    • そして、どのデータがプライバシー関連の法律・規則の要件に該当するか、またどのデータがビジネス上必要なデータか判定する。
  • 必要のない機微な情報を保存しない。
    • できる限りすぐにそのような機微な情報を破棄するか、PCI DSSに準拠したトークナイゼーションまたはトランケーションを行う。
    • データが残っていなければ盗まれない。
  • 保存時にすべての機微な情報を暗号化しているか確認する。
  • 最新の暗号強度の高い標準アルゴリズム、プロトコル、暗号鍵を実装しているか確認する。
    • そして適切に暗号鍵を管理する。
  • 前方秘匿性(FS)を有効にしたTLS、サーバーサイドによる暗号スイートの優先度決定、セキュアパラメータなどのセキュアなプロトコルで、通信経路上のすべてのデータを暗号化する。
    • HTTP Strict Transport Security (HSTS)のようなディレクティブで暗号化を強制する。
  • 機微な情報を含むレスポンスのキャッシングを無効にする。
  • データ分類に応じて必要なセキュリティ制御を適用する。
  • FTPやSMTPといったレガシーなプロトコルを機密データの伝送に使用しない。
  • パスワードを保存する際、Argon2、scrypt、bcrypt、PBKDF2のようなワークファクタ(遅延ファクタ)のある、強くかつ適応可能なレベルのソルト付きハッシュ関数を用いる。
  • 初期化ベクトルは利用モードに応じて適切なものを選択しなければならない。
    • これは多くのモードにおいてCSPRNG(暗号論的擬似乱数生成器)を使用することを意味する。
    • nonceを必要とするモードの場合は、初期化ベクトル(IV)はCSPRNGを必要としない。
    • すべての場合において、IVは単一の固定の鍵に対し二度使ってはならない。
  • 単なる暗号ではなく、認証付き暗号を常に使用する。
  • 鍵は暗号学的にランダムに生成し、またバイト配列としてメモリーに保存する。
    • もしパスワードを使用する場合は、適切な鍵導出関数を用いて鍵へと変換されなければならない。
  • 暗号学的乱数が適切な場所で使用されていること、またそれらが予測可能な方法や低いエントロピーによって初期化されていないことを確認する。
    • 多くのモダンなAPIでは、セキュリティを確保するために開発者がCSPRNGを初期化する必要はない。
  • MD5やSHA1、PKCS#1 v1.5といった非推奨の暗号学的関数やパディング方式の使用を避ける。
  • 設定とその設定値がそれぞれ独立して効果があるか検証する。

A03:2021-Injection(インジェクション)

説明

一般的なインジェクションとしては、SQL、NoSQL、OS コマンド、オブジェクト・リレーショナル・マッピング（ORM）、LDAP、およびEL式（Expression Language）またはOGNL式（Object Graph Navigation Library）のインジェクションがあります。 コンセプトはすべてのインタープリタで同じです。ソースコードをレビューすれば、インジェクションに対してアプリケーションが脆弱であるか最も効果的に検出できます。すべてのパラメータ、ヘッダー、URL、Cookie、JSON、SOAP、およびXMLデータ入力の完全な自動テストが推奨されます。 また、組織は静的 (SAST)、動的 (DAST)、そしてインタラクティブ (IAST) アプリケーションセキュリティテストツールをCI/CDパイプラインに導入できます。 これにより、新たに作られてしまったインジェクション欠陥を稼働環境に展開する前に検出できます。

一般的な例

詳細

次のような状況では、アプリケーションはこの攻撃に対して脆弱です:

  • ユーザが提供したデータが、アプリケーションによって検証、フィルタリング、またはサニタイズされない。
  • コンテキストに応じたエスケープが行われず、動的クエリまたはパラメータ化されていない呼出しがインタープリタに直接使用される。
  • オブジェクト・リレーショナル・マッピング（ORM）の検索パラメータに悪意を持ったデータが使用され、重要なレコードを追加で抽出してしまう。
  • 悪意を持ったデータを直接または連結して使う。動的クエリ、コマンドまたはストアド・プロシージャにおいてSQLやコマンドがそのような構造と悪意を持ったデータを含む。

予防方法

詳細

インジェクションを防止するためにはコマンドとクエリからデータを常に分けておくことが必要

  • 推奨される選択肢は安全なAPIを使用すること。

    • インタープリタの使用を完全に避ける、パラメータ化されたインターフェースを利用する、または、オブジェクト・リレーショナル・マッピング・ツール（ORM）を使用するように移行すること。
    • 注意: パラメータ化されていたとしても、ストアドプロシージャでは、PL/SQLまたはT-SQLによってクエリとデータを連結したり、EXECUTE IMMEDIATEやexec()を利用して悪意のあるデータを実行することによって、SQLインジェクションを発生させることができる。

  • ポジティブな、言い換えると「ホワイトリスト」によるサーバーサイドの入力検証を用いる。

    • 特殊文字を必要とする多くのアプリケーション、たとえばモバイルアプリケーション用のテキスト領域やAPIなどにおいては完全な防御方法とはならない。

  • 上記の対応が困難な動的クエリでは、そのインタープリタ固有のエスケープ構文を使用して特殊文字をエスケープする。

    • 注意: テーブル名やカラム名などのSQLストラクチャに対してはエスケープができない。そのため、ユーザ指定のストラクチャ名は危険である。これはレポート作成ソフトウェアに存在する一般的な問題である。

  • クエリ内でLIMIT句やその他のSQL制御を使用することで、SQLインジェクション攻撃が発生した場合のレコードの大量漏洩を防ぐ。

A04:2021-Insecure Design(安全が確認されない不安な設計)

説明

安全が確認されない不安な設計とは、様々な脆弱性を表す広範なカテゴリーであり、「欠落した、あるいは不十分な制御設計」とも表される。 安全でない設計と安全でない実装は異なる。設計上の欠陥と実装上の欠陥を区別するのには理由は、根本的な原因と改善方法が異なるから。 安全な設計であっても、実装上の欠陥があると、それが悪用される可能性のある脆弱性につながる。 安全でない設計は、完璧な実装によって修正することができない。というのも、定義上、特定の攻撃を防御するために必要なセキュリティ制御が作成されたことはない。 安全でない設計の要因の一つとして、開発するソフトウェアやシステムに内在するビジネスリスクのプロファイリングが行われていないために、どのレベルのセキュリティ設計が必要なのかを判断できないことが挙げられる。

一般的な例

詳細

  • 要件とリソースマネジメント

    • すべてのデータ資産の機密性、完全性、可用性、そして真正性に関する保護要件および、期待されるビジネスロジックなど、アプリケーションのビジネス要件を収集し、事業部門と協議する。
    • アプリケーションが公開される程度に応じて、（アクセス制御に加えて）テナントを分離する必要があるか検討する。
    • 機能的および非機能的なセキュリティ要件を含む、技術的な要件をまとめる。
    • セキュリティ活動を含む設計、構築、テストおよび、運用のすべてをカバーする予算を計画し、事業部門と協議する。

  • 安全が確認された安心な設計

    • 「安全が確認された安心な設計」とは、常に脅威を評価し、既知の攻撃方法を防ぐためにコードを堅牢に設計し、テストする文化と方法論のこと。
    • データフローやアクセスコントロールなどのセキュリティコントロールの変更を確認するセッション（または同様の活動）に脅威のモデル化を統合するべき。
    • ユーザストーリーの開発においては、正常なフロー及び障害の状態を決定し、責任者および、影響を受ける当事者がそれらを十分に理解し合意していることを確認する。
    • 正常系と異常系のフローの仮説と条件を分析し、それらが正確であり期待される物であることを確認します。
    • 仮説を検証し、適切な動作に必要な条件を実行する方法を決定し、結果をユーザーストーリーとして確実に文書化する。
    • 失敗から学び、改善を促進するための積極的なインセンティブを提供していくことが肝要。
    • 「安全が確認された安心な設計」とは、ソフトウェアに追加できるアドオンでもツールでもありません。

  • Secure Development Lifecycle

    • 「安全が確認された安心なソフトウェア」を実現するには、セキュア開発ライフサイクル、何らかのセキュアデザインパターン、「ペイブド・ロード」方法論、安全なコンポーネントライブラリ、ツール、および脅威のモデル化が必要。
    • 全てのソフトウェアの開発プロジェクトとメンテナンス期間を通して、ソフトウェアプロジェクトの開始時にセキュリティの専門家に声をかける。
    • OWASP ソフトウエアセキュリティ保証成熟度モデル(OWASP SAMM) を活用して、安全なソフトウェア開発に取り組む。

予防方法

詳細

  • セキュリティおよびプライバシー関連の管理策の評価および設計を支援するために、アプリケーションセキュリティの専門家とともにセキュアな開発ライフサイクルを確立し使用する
  • セキュアなデザインパターンまたは、信頼性が高く安全性も検証されているコンポーネントライブラリを構築し使用する
  • 重要な認証、アクセスコントロール、ビジネスロジック、および暗号鍵の管理フローに脅威モデルを使用する
  • ユーザーストーリーにセキュリティ言語とコントロールを組み込む
  • (フロントエンドからバックエンドまで)アプリケーションの各層に妥当性チェックを統合する
  • ユニットテストおよび統合テストを実施し、すべての重要なフローが脅威モデルに対して耐性があることを検証する。アプリケーションの各階層のユースケースとミスユースケースをまとめる。
  • リスク管理における保護の必要性に応じて、システム層とネットワーク層の階層を分ける
  • すべての階層でテナントを分離した堅牢な設計を行う
  • ユーザーやサービスによる過剰なリソース消費を制限する

A05:2021-Security Misconfiguration(セキュリティの設定ミス)

説明

アプリケーションのセキュリティを設定するプロセスを協調して繰り返すことができなければ、システムはより高いリスクにさらされる。

一般的な例

詳細

アプリケーションが下記のようなら、恐らく脆弱です:

  • アプリケーションスタックのいずれかの部分におけるセキュリティ堅牢化の不足、あるいはクラウドサービスでパーミッションが不適切に設定されている
  • 必要のない機能が有効、あるいはインストールされている(例えば、必要のないポートやサービス、ページ、アカウント、特権)
  • デフォルトのアカウントとパスワードが有効になったまま変更されていない
  • エラー処理がユーザに対して、スタックトレースやその他余計な情報を含むエラーメッセージを見せる
  • アップグレードしたシステムでは、最新のセキュリティ機能が無効になっているか正しく設定されていない
  • アプリケーションサーバやアプリケーションフレームワーク(例えば、Struts、Spring、 ASP.NET)、ライブラリ、データベース等のセキュリティの設定が、安全な値に設定されていない
  • サーバがセキュリテイヘッダーやディレクティブを送らなかったり、安全な値に設定されていなかったりする
  • ソフトウェアが古いか脆弱である。(# A06:2021 – 脆弱で古くなったコンポーネント を参照)

予防方法

詳細
安全にインストールするプロセスにおいて、以下のことを実施すべきです:

  • 繰り返し堅牢化するプロセスは、素早くかつ容易に他の環境に展開され、正しくロックダウンする。
    • 開発やQA、本番環境は完全に同じように設定し、それぞれの環境で別々の認証情報を使用する。
    • このプロセスを自動化し、新しい安全な環境をセットアップする際には、手間を最小限にする。
  • プラットフォームは最小限のものとし、必要のない機能やコンポーネント、ドキュメント、サンプルを除く。
    • 使用しない機能とフレームワークは、削除もしくはインストールしないこと。
  • レビューを実施して、セキュリティ関連の記録と更新の全てに加え、パッチを管理するプロセスの一環としてパッチの設定を適切に更新すること(# A06:2021 – 脆弱で古くなったコンポーネント を参照)。
  • セグメント化したアプリケーションアーキテクチャは、セグメンテーションやコンテナリゼーション、クラウドのセキュリティグループ(ACL)をともなったコンポーネントやテナント間に、効果的で安全な仕切りをもたらす。
  • セキュリティディレクティブをクライアントへ送ること。
    • 例としては セキュリティヘッダー が挙げられる。
  • プロセスを自動化して設定の有効性を検証し、環境すべてに適用すること。

A06:2021-Vulnerable and Outdated Components(脆弱で古くなったコンポーネント)

一般的な例

詳細

以下に該当する場合、脆弱と言えます。

  • 使用しているすべてのコンポーネントのバージョンを知らない場合（クライアントサイド・サーバサイドの両方について）。 これには直接使用するコンポーネントだけでなく、ネストされた依存関係も含む。
  • ソフトウェアが脆弱な場合やサポートがない場合、また使用期限が切れている場合。 これには、OSやWebサーバ、アプリケーションサーバ、データベース管理システム（DBMS）、アプリケーション、API、すべてのコンポーネント、ランタイム環境とライブラリを含む。
  • 脆弱性スキャンを定期的にしていない場合や、使用しているコンポーネントに関するセキュリティ情報を購読していない場合。
  • 基盤プラットフォームやフレームワークおよび依存関係をリスクに基づきタイムリーに修正またはアップグレードしない場合。 パッチ適用が変更管理の下、月次や四半期のタスクとされている環境でよく起こる。 これにより、当該組織は、解決済みの脆弱性について、何日も、場合によっては何ヶ月も不必要な危険にさらされることになる。
  • ソフトウェア開発者が、更新やアップグレードまたはパッチの互換性をテストしない場合。
  • コンポーネントの設定をセキュアにしていない場合。（A05-2021: セキュリティの設定ミス 参照）

予防方法

詳細

以下に示すパッチ管理プロセスが必要です。

  • 未使用の依存関係、不要な機能、コンポーネント、ファイルや文書を取り除く。
  • Versions Maven Plugin, OWASP Dependency Check, Retire.jsなどのツールを使用して、クライアントおよびサーバの両方のコンポーネント（フレームワークやライブラリなど）とその依存関係の棚卸しを継続的に行う。
  • 安全なリンクを介し、公式ソースからのみコンポーネントを取得する。
    • 変更された悪意あるコンポーネントを取得する可能性を減らすため、署名付きのパッケージを選ぶようにする。 (A08-2021: ソフトウェアとデータの整合性の不具合 参照)
  • メンテナンスされていない、もしくはセキュリティパッチが作られていない古いバージョンのライブラリとコンポーネントを監視する。
    • パッチ適用が不可能な場合は、発見された問題を監視、検知または保護するために、仮想パッチの適用を検討する。

いかなる組織も、アプリケーションまたはポートフォリオの存続期間は、モニタリングとトリアージを行い更新または設定変更を行う継続的な計画があることを確認する必要があります。

A07:2021-Identification and Authentication Failures(識別と認証の失敗)

説明

ユーザーのアイデンティ確認、認証そしてセッション管理は、認証関連の攻撃対策として極めて重要です。

一般的な例

詳細
もしアプリケーションに次に記載するような問題があれば、認証に問題があると言えます。

  • パスワードリスト攻撃（クレデンシャル・スタッフィング攻撃）のような自動化された攻撃が出来てしまう。パスワードリスト攻撃とは、攻撃者が正当なユーザー名とパスワードの組み合わせを入手して行う攻撃手法のことです。
  • ブルートフォース攻撃（総当たり攻撃）などの自動化された攻撃が出来てしまう。
  • デフォルトのパスワード、弱いパスワード、良く使われるパスワードが利用できてしまう。たとえば「Password1」や「admin/admin」などです。
  • クレデンシャルの復旧やパスワードを忘れた場合のプロセスが弱い、あるいは効果がない。
    • たとえば「秘密の質問」のようなやり方は安全とは言えません。
  • パスワードをデータストアに保存する際に、プレーンテキストのままで保存している、または暗号化して保存している。
    • あるいはハッシュ化して保存していたとしても脆弱なハッシュ関数を利用している。（A02:2021-暗号化の失敗を参照）
  • 多要素認証を採用していない。あるいは間違った使い方をしている。
  • セッション識別子がURLの一部として露出してしまっている。
  • ログイン後にセッション識別子を使いまわしている。
  • セッションIDを正しく無効化していない。

予防方法

詳細

  • 多要素認証を可能な限り実装する。これにより、パスワードリスト攻撃、ブルートフォース攻撃、盗用したクレデンシャルの再利用など多くの自動化された攻撃を防ぐことができる。
  • デフォルトのクレデンシャルのままプログラム（サービス）をデプロイしない。
    • 特に管理者ユーザーのパスワードをデフォルト設定のままデプロイするのは言語道断です。
  • 弱いパスワードを設定していないかチェックする機能を実装する。
    • たとえばパスワードの新規設定や更新時には、「弱いパスワード トップ10,000」などのリストを使って検証する。
  • パスワードの「長さ」や「複雑さ」そして「定期的な変更」などのパスワードポリシーについては、米国国立標準技術研究所 (NIST) ガイドライン（800-63b セクション5.1.1:記憶シークレット）や、近代的で根拠に基づくポリシーに沿うようにする。
  • 新規登録の場合、クレデンシャルリカバリーの場合、またAPI経由の場合など、どのような場合であってもアカウント列挙攻撃に対して強化されていることを確認する。
    • 認証の際にはどのような結果であれ（成功でも失敗でも）同じメッセージを使うようにする。
  • ログイン試行回数に制限を設けるか、ログインに繰り返し失敗するようなら徐々に処理を遅延させる。
    • その際、サービス拒否の機会を作らないよう注意する。ログインの失敗はすべてログに記録する。
    • そしてパスワードリスト攻撃やブルートフォース攻撃などの攻撃を検知した際には管理者に通知する。
  • セッション管理はサーバ側で行い、安全でプログラム言語などに内蔵されているものを使います。
    • ログイン毎にエントロピーの高いランダムなセッションIDを発行するセッション管理機構を利用する。
    • セッション識別子はURLに含まれるべきではなく、安全に保管されなければなりません。また、セッション識別子はログアウトした際、一定期間アクセスが無い場合、タイムアウト時間を経過した場合には無効にしなければなりません。

A08:2021-Software and Data Integrity Failures(ソフトウェアとデータの整合性の不具合)

概要

説明

ソフトウェアとデータの整合性の不具合は、コードやインフラストラクチャが整合性違反から保護されていないことに関連しています。

一般的な例

詳細

例として、

  • アプリケーションが信頼されていないソースに由来するプラグインやライブラリ、モジュール、コンテンツデリバリーネットワーク (CDNs) に依存している場合が挙げられる。
  • 安全でないCI/CDパイプラインも、権限のないアクセスや悪意のあるコード、システムののっとりの可能性を高める。
  • 今では多くのアプリケーションが自動更新の機能を備えていますが、そこで、十分な整合性の検証を行うことなくアップデートがダウンロードされ、信頼済みアプリケーションに対して適用される。
    • 攻撃者は自前のアップデートをアップロードし、全てのインストール対象に対して配信を行う可能性があります。
  • オブジェクトやデータが攻撃者が目で見て修正することが可能な構造としてエンコードまたはシリアライズされるような場合は、安全でないデシリアライゼーションに対して脆弱であると言える。

予防方法

詳細

  • 署名あるいは類似のメカニズムを用いて、ソフトウェアやデータが意図されたソースから取得されたものであることを検証する。
  • npmやMavenなど、ライブラリや依存関係が信頼されたリポジトリを使用していることを確認する。
  • コンポーネントが既知の脆弱性を含まないことを検証するために、OWASP Dependency CheckやOWASP CycloneDXといったソフトウェアサプライチェーンセキュリティツールが使用されていることを確認する。
  • 悪意のあるコードや設定がソフトウェアパイプラインに組み込まれる機会を最小化するために、コードや設定の変更に対するレビュープロセスが確立されていることを確認する。
  • CI/CDパイプラインが適切に分離され、設定され、アクセス制御が行われていること、また、ビルドやデプロイのプロセスに至るコードフローの整合性が確保されていることを確認する。
  • シリアライズされたデータの改ざんや再生成を検出する何らかの整合性確認やデジタル署名を行うことなしに、信頼されていないクライアントに対して未署名もしくは暗号化されていないシリアライズされたデータを送信しない。

A09:2021-Security Logging and Monitoring Failures(セキュリティログとモニタリングの失敗)

説明

アクティブな違反の検出、エスカレーション、および対応を支援するものです。 ロギングとモニタリングがなければ、侵害を検知することはできない。

一般的な例

詳細
ロギングや検知、モニタリング、適時の対応が十分に行われないという状況は、いつでも発生します:

  • ログイン、失敗したログイン、重要なトランザクションなどの監査可能なイベントがログに記録されていない。
  • 警告とエラーが発生してもログメッセージが生成されない、または不十分、不明確なメッセージが生成されている。
  • アプリケーションとAPIのログが、疑わしいアクティビティをモニタリングしていない。
  • ログがローカルにのみ格納されている。
  • アラートの適切なしきい値とレスポンスのエスカレーションプロセスが整えられていない、または有効ではない。
  • ペネトレーションテストやDAST(dynamic application security testing)ツール（OWASP ZAPなど）によるスキャンがアラートをあげない。
  • アプリケーションがリアルタイム、準リアルタイムにアクティブな攻撃を検知、エスカレート、またはアラートすることができない。

予防方法

詳細

アプリケーションによって保存または処理されるデータのリスクに応じて対応する：

  • ログイン、アクセス制御の失敗、サーバサイドの入力検証の失敗を全てログとして記録するようにする。
    • ログは、不審なアカウントや悪意のあるアカウントを特定するために十分なユーザコンテキストを持ち、 後日、フォレンジック分析を行うのに十分な期間分保持するようにする。
  • 統合ログ管理ソリューションで簡単に使用できる形式でログが生成されていることを確認する。
  • 価値の高いトランザクションにおいて、監査証跡が取得されていること。
    • その際、追記型データベースのテーブルなどのような、完全性を保つコントロールを用いて、改ざんや削除を防止する。
  • DevSecOps チームが疑わしい活動をタイムリーに検知して対応できるように、効果的なモニタリングとアラートを確立する。
  • NIST(National Institute of Standards and Technology) 800-61 rev 2（またはそれ以降）のような、インシデント対応および復旧計画を策定または採用する。

OWASP AppSensor、OWASP ModSecurity Core Rule Setを使用したModSecurityなどのWebアプリケーションファイアウォール、 カスタムダッシュボードとアラートを使用したログ相関分析ソフトウェア（Elasticsearch, Logstash, Kibana (ELK) ）など、商用およびオープンソースのアプリケーション保護フレームワークがある。

A10:2021-Server-Side Request Forgery(サーバーサイドリクエストフォージェリ(SSRF))

説明

SSRFの欠陥は、Webアプリケーション上からリモートのリソースを取得する際に、ユーザーから提供されたURLを検証せずに使用することで発生します。 ファイアウォールやVPNあるいはその他の種類のネットワークアクセス制御リスト(ACL)によってアプリケーションが保護されている場合であっても、SSRFによりアプリケーションに対して意図しない宛先へ細工されたリクエストを強制的に発行させることができる。 モダンなアプリケーションではエンドユーザーに便利な機能を提供するようになり、アプリケーション側でURLを取得することは珍しい状況ではなくなった。 そのためSSRFの発生が増加している。 またSSRFの深刻度も、クラウドサービスやアーキテクチャの複雑性を背景として、段々と大きくなりつつある。

一般的な例

詳細

予防方法

詳細
開発者は以下の多層防御の制御の一部ないし全てを実装することにより、SSRFを防ぐことができる。

  • ネットワーク層から

    • SSRFの影響を減らすために、リモートのリソースへアクセスする機能を分離されたネットワークに切り出す。
    • 必須のイントラネット通信を除き全ての通信をブロックするよう、「デフォルト拒否」のファイアウォールポリシーまたはネットワークアクセス制御を強制する。
      • ヒント:
        • ~ アプリケーションに応じて、ファイアウォールルールの所有権とライフサイクルを明確化する。
        • ~ ファイアウォールにおいて許可されたネットワークフロー、そしてブロックされたネットワークフローを全てログとして記録します (A09:2021-セキュリティログとモニタリングの失敗を参照)。

  • アプリケーション層から:

    • クライアントが提供した全ての入力データをサニタイズし、検証する。
    • 明確な許可リスト用いてURLスキーム、ポート、宛先を強制する。
    • 生のレスポンスをクライアントに送信しないようにする。
    • HTTPのリダイレクトを無効化する。

    • DNSリバインディングや"time of check, time of use" (TOCTOU) 競合状態といった攻撃を防ぐために、URLの整合性に注意する。

    • 拒否リストや正規表現を用いてのSSRF対策を実装する。攻撃者は拒否リストを回避するためのペイロードのリスト、ツール、そして技術を備えている。

  • 検討すべき追加の対策:

    • Don't deploy other security relevant services on front systems (e.g. OpenID). Control local traffic on these systems (e.g. localhost)
    • For frontends with dedicated and manageable user groups use network encryption (e.g. VPNs) on independant systems to consider very high protection needs

自分がよく使うMarkdown記法

Markdown



markdownの記法で自分がよく使う、モノを自分用のチートとして集めました。

見栄えの調整

目次の自動生成

  • 見え方
---

[:contents]

---

表示の折りたたみ

  • 見え方

    ここをクリック

    (空行) 折りたたまれる内容が記述されるエリア

  • 記述方法

<details><summary>ここをクリック</summary>

 (空行)
折りたたまれる内容が記述されるエリア

</details>

コードブロック内部に色を付ける（シンタックスハイライト）

  • 各コードブロック領域毎に言語を指定すると自動でそれっぽい色付けをしてくれます。
<span style="color:#ff0000;font-weight:bold;">色がついているほうが、読みやすいことが多い</span>

 ```html
<span style="color:#ff0000;font-weight:bold;">色がついているほうが、読みやすいことが多い</span>
 ```

色のついたメッセージ領域（Hatena未対応）

:::message ここにメッセージを記入する :::

:::message alert ここに警告メッセージを記入する :::

:::message
ここにメッセージを記入する
:::

:::message alert
ここに警告メッセージを記入する
:::

文字の加工

赤い太字

  • 見え方

    • 赤い太字

  • 記述方法

<span style="color:#ff0000;font-weight:bold;">赤い太字</span>

リンクの作成

[ブログのTopページ](https://overworker.hatenablog.jp/)

画像の処理

画像の貼り付け（一般）

  • 見え方

プロフィール画像

  • 記述方法
![プロフィール画像](https://~省略~.png)

画像の貼り付け（サイズ指定・センター配置（HatenaBlog））

  • 見え方

　縦幅50を指定：


　縦幅100を指定：


  • 記述方法
縦幅50を指定：<br>
<div align="center">
[f:id:~省略~:plain:h50]<br>
</div>

縦幅100を指定：<br>
<div align="center">
[f:id:~省略~:plain:h100]<br>
</div>

mermaid関連

OWASP トップ 10の種類について調べてみた

セキュリティ OWASP



概要

The OWASP Top 10 is the reference standard for the most critical web application security risks. Adopting the OWASP Top 10 is perhaps the most effective first step towards changing your software development culture focused on producing secure code.（Projects | OWASP Foundation）

『最も重大な Web アプリケーションのセキュリティ リスクの参照標準』とあるので、各システムに対するセキュリティリスク面のチェック項目と考えてよいと思います。

OWASP Top TenとOWASP Top 10 API Security Risksの違い

対象と焦点:

OWASP Top Ten

Webアプリケーションの主要なセキュリティリスクに焦点を当てています。これには、SQLインジェクション、認証の問題、感覚データの漏洩などが含まれます。

OWASP Top 10 API Security Risks

API（Application Programming Interface）セキュリティの主要なリスクに焦点を当てています。APIは、異なるソフトウェアコンポーネント間でデータや機能を共有するための手段です。このプロジェクトでは、APIに関連する脆弱性と攻撃手法に焦点を当てています。

技術の進展:

OWASP Top Ten

Webアプリケーションセキュリティの観点から、主にWebアプリケーションに特有の攻撃や脆弱性を取り上げています。

OWASP Top 10 API Security Risks

近年、APIの普及が進んでおり、そのセキュリティも重要な問題となっています。このプロジェクトは、APIに関連する新たな脅威や対策に焦点を当てています。

内容:

OWASP Top Ten

具体的な脆弱性や攻撃手法に焦点を当てており、例えばSQLインジェクションやクロスサイトスクリプティングなどのリスクが挙げられます。

OWASP Top 10 API Security Risks

APIセキュリティの特定の課題に焦点を当て、例えば不適切な認証、不十分なアクセス制御、データの不適切な処理などが挙げられます。

リリースサイクル:

二つのリリースサイクルは同期していないようです。

OWASP Top Ten

Webアプリケーションのセキュリティリスクのアップデートは、一定のサイクルで行われます。

OWASP Top 10 API Security Risks

APIセキュリティのプロジェクトも定期的にアップデートされ、API関連の新しい脆弱性や対策が反映されます。

最新版（2023/11/23時点）

多分、現時点（2023/11/22）での最新版は以下になります。

OWASP Top Ten

OWASP Top 10 API Security Risks

参考文献

「セキュリティ関連のノート」のまとめ

セキュリティ


自分がセキュリティに関して学んだ内容の一覧です。

OWASP

OWASPって何？と思ったので調べてみた

セキュリティ OWASP



皆さんはOWASPと言う組織を聞いたことがありますでしょうか？ 私は仕事でWeb開発を行っているので、『なんとなく』知っていたですが、 なんとなくより『一歩深めよう』と思い少し調べてみました。

概要

Open Worldwide Application Security Project( OWASP ) は、Webアプリケーションセキュリティに関するオンラインコミュニティ。

プロジェクト

OWASP Projects are a collection of related tasks that have a defined roadmap and team members. Our projects are open source and are built by our community of volunteers - people just like you! OWASP project leaders are responsible for defining the vision, roadmap, and tasks for the project. The project leader also promotes the project and builds the team. OWASP currently has over 100 active projects, and new project applications are submitted every week.

セキュリティを向上させたいと思うボランティアのコミュニティです。

その中で実施されている活動のことをプロジェクトと呼んでいて、プロジェクトはロードマップとチームメンバーを持ちます。 「プロジェクトリーダーがビジョン、ロードマップ、タスクを定義する。」とあるので、オンラインコミュニティを推進するための強いリーダーシップが求められるのではないかと思います。

プロジェクトにどんな人が参加する？

主な参加者

  • アプリケーション開発者
  • ソフトウェアアーキテクト
  • 情報セキュリティの著者
  • アイデアを開発またはテストするために、世界規模の専門コミュニティのサポートを希望する人

プロジェクトの分類

OWASP内のプロジェクトは以下のいずれかに分類されます。

種類 説明 補足
Flagship Projects フラッグシップ プロジェクト
OWASP およびアプリケーション セキュリティ全体にとって戦略的価値を実証したプロジェクト		 TopTenを含む
Production Projects 実稼働プロジェクト
実稼働準備が整ったプロジェクト
Other Projects その他のプロジェクト
Lab プロジェクトと Incubator プロジェクト

フラッグシップ プロジェクトについて

フラッグシップ プロジェクトの一覧を知ることがOWASPの活動内容の概要を把握するのに役立ちそうなので一覧化してみました。

OWASP Amass（OWASP アマス）

情報セキュリティの専門家が、オープンソースのインテリジェンス収集および偵察技術を使用して、攻撃対象領域のネットワークマッピングと外部資産の検出を実行できるようにするオープンソースフレームワーク。

OWASP Application Security Verification Standard
（OWASP アプリケーションセキュリティ検証標準）

最新のWebアプリケーションとWebサービスを設計、開発、テストする際に必要なセキュリティ制御の定義に焦点を当てたセキュリティ要件のフレームワーク

OWASP Cheat Sheet Series（OWASP チートシートシリーズ）

アプリケーション開発者と防御者が従うべき一連の簡潔なグッドプラクティスガイドを提供

OWASP CycloneDX（OWASP サイクロンDX）

サイバーリスク削減のための高度なサプライチェーン機能を提供するフルスタックの部品表(BOM)標準

OWASP Defectdojo（OWASP 欠陥道場）

DevOpsと継続的なセキュリティ統合のために構築された、最先端のオープンソースアプリケーション脆弱性管理ツール

OWASP Dependency-Check（OWASP 依存関係チェック）

プロジェクトの依存関係を特定し、既知の公開された脆弱性が存在するかどうかをチェックするソフトウェア構成分析(SCA)ツールスイート

OWASP Dependency-Track（OWASP 依存関係追跡）

組織がソフトウェアサプライチェーンのリスクを特定して軽減できるようにするインテリジェントコンポーネント分析プラットフォーム

OWASP Juice Shop（OWASP ジュースショップ）

セキュリティトレーニング、意識向上デモ、CTF用の最も最新かつ洗練された安全でないWebアプリケーション。セキュリティツールやDevSecOpsパイプラインの自主的なモルモットとしても最適

OWASP Mobile Application Security（OWASP モバイルアプリケーションセキュリティ）

MAS（MobileApplicationSecurity）はモバイルアプリのセキュリティ標準を確立する一連の文書と、モバイルアプリケーションのセキュリティ評価中に使用されるプロセス、技術、ツールをカバーする包括的なテストガイドで構成されています。テスト担当者が一貫した完全な結果を提供できるようにする一連のテストケース。

OWASP ModSecurity Core Rule Set（OWASP ModSecurityコアルールセット）

ModSecurityCoreRuleSet(CRS)は、ModSecurityまたは互換性のあるWebアプリケーションファイアウォールで使用するための一連の汎用攻撃検出ルールです。CRSは、誤った警告を最小限に抑えながら、OWASPトップ10を含む幅広い攻撃からWebアプリケーションを保護することを目的としている。

OWASP OWTF（OWASP OWTF）

OWTF(OffensiveWebTestingFramework)は、優れたツールを統合してペネトレーションテストをより効率的にすることを目的としたOWASP+PTESに焦点を当てたもので、主にPythonで書かれている。

OWASP SAMM（OWASP サム）

SAMM(ソフトウェアアシュアランス成熟度モデル)は、あらゆる種類の組織がソフトウェアセキュリティ体制を分析および改善するための効果的かつ測定可能な方法を提供する。

OWASP Security Shepherd（OWASP セキュリティシェパード）

Webおよびモバイルアプリケーションのセキュリティトレーニングプラットフォームです。SecurityShepherdは、さまざまなスキルセットを持つ層の間でセキュリティ意識を促進し、向上させるように設計されています。このプロジェクトの目的は、AppSecの初心者または経験豊富なエンジニアを受け入れ、侵入テストのスキルセットを強化してセキュリティの専門家の地位を確立することです。

OWASP Top Ten（OWASPトップ10）

最も重大なWebアプリケーションのセキュリティリスクの参照標準です。OWASP Top10を採用することは、おそらく、安全なコードの作成に重点を置いたソフトウェア開発文化を変えるための最も効果的な第一歩です。

OWASP Web Security Testing Guide（OWASP Webセキュリティテストガイド）

Webセキュリティテストガイド(WSTG)プロジェクトは、Webアプリケーション開発者およびセキュリティ専門家向けの最高のサイバーセキュリティテストリソースを作成します。

終わりに

今まではOWASP Top Tenくらいしか意識していませんでしたが、そのほかにもセキュリティを軸に様々な活動が実施されていることを知りました。別の機会に以下の深堀をしていければと考えています。

  • OWASP Cheat Sheet Series（OWASP チートシートシリーズ）
  • OWASP Mobile Application Security（OWASP モバイルアプリケーションセキュリティ）
  • OWASP Top Ten（OWASPトップ10）

参考にしたサイト

コマンド実行時間を可視化してみた

Linux WSL



Linux上で開発をしているときに「コマンド実行時間が前より長くなってないか？」と思うことがあったので、常日頃からコマンド実行時間を認知できるように表示を残すようにしてみました。

概要

  • よく実施するコマンドをbashスクリプト経由で実行するようにスクリプト化
  • 対象コマンド開始前に開始時刻をターミナル上に出力
  • 対象コマンド終了後に終了時刻をターミナル上に出力
  • 終了時刻と開始時刻の差分を計算
  • 開始時刻と処理時間をログファイルに出力

スクリプトの中身

  • サンプルとしてtime.shというファイル名でスクリプトを作成します
#!/bin/bash

### StartTime
echo 
echo StartTime `date`                       # ターミナル表示
startTime=`date +%s`                        # 計算用（%s：日時表示のフォーマット/UNIX時刻 (1970年1月1日0時UTCからのうるう秒を考慮しない秒数)）
startTimeFile=`date "+%Y/%m/%d %H:%M:%S"`   # ファイル出力用
echo 

### 時間計測したい処理
sleep 3

### EndTime
echo 
echo EndTime `date`                 # ターミナル表示
endTime=`date +%s`                  # 計算用（%s：日時表示のフォーマット/UNIX時刻 (1970年1月1日0時UTCからのうるう秒を考慮しない秒数)）
echo 

### 差分
time=$((endTime - startTime))       # 処理時間
echo $time s                        # ターミナル表示

### 結果をファイルに出力する
echo "$startTimeFile,$time" >> CommandExecutionTimeLog.csv

スクリプト（コマンド）実行方法

bash time.sh