Public missions & guidelines

Secure Coding Made Practical

Explore secure coding guidelines to understand and mitigate software vulnerabilities like the OWASP Top 10, and dive into guided training Missions to practices in real-world app simulations.

book a demo
パブリックミッション
ガイドライン

Browse all missions

スケーラブルで魅力的

SQL インジェクション

try now
スケーラブルで魅力的

スプリングMVCリクエストマッチャー

try now
スケーラブルで魅力的

サイキック・シグネチャ-既知の脆弱コンポーネントの使用

try now
スケーラブルで魅力的

Apache パストラバーサル-既知の脆弱なコンポーネントの使用

try now
スケーラブルで魅力的

Log4j-既知の脆弱なコンポーネントの使用

try now
スケーラブルで魅力的

トロイの木馬ソース-信頼できないソースからのコンポーネントの使用

try now
スケーラブルで魅力的

Codestashbin-安全でないパスワードリセット機能

try now
スケーラブルで魅力的

「ChatterGPT」のクロスサイトスクリプティング (XSS)

try now

Browse all guidelines

ブラウズ基準:
フィルターを非表示にする
Selection
フィルターを表示
Selection
フィルターをクリア
[タグ]
Super Icon [★]
トピック
もっと見る

ロギングとモニタリングが不十分

Best practices:

Audit logging for sensitive functions
Error logging
Storing logs in a centralized location
Retain logs for a defined amount of time
Regularly audit logs for PII

ロギングとモニタリングは、すでに何か問題が発生したときには後回しにされることがよくありますが、実際には、適切なロギングと監視が行われていることを確認できないと、非常にコストがかかる可能性があります。極端な例を挙げると、インシデントが発生したとき (セキュリティ関連であろうとなかろうと)、ログがほとんどないか、まったくないと、実際に何が起こったのかを把握することが不可能になります。反対に、ログに記録するデータが多すぎるとプライバシーの問題が発生し、規制当局との問題につながる可能性があります。ロギングやモニタリングが不十分にならないようにするためのベストプラクティスについては、ガイドラインをお読みください。

view guidelines

既知の脆弱性を持つコンポーネントの使用

{
「依存関係」: {
「foo」:「1.0.0-2.9999.9999"、
「バー」:「>=1.0.2 <2.1.2"
}
}

ほとんどのアプリケーションでは、大量のサードパーティ製コンポーネントを使用します。これらのコンポーネントは、ロギング、テンプレート、データベースアクセスなど、あらゆる機能を提供します。これにより、ソフトウェアの開発がはるかに簡単になり、時間を大幅に節約できます。しかし、それらは人によって作られているため、中には必然的に脆弱性が含まれているものもあります。ガイドラインを読んで詳細を調べてください。

view guidelines

SQL インジェクション

import mysql.connector
db = mysql.connector.connect
#Bad Practice. Avoid this! This is just for learning.
(host="localhost", user="newuser", passwd="pass", db="sample")
cur = db.cursor()
name = raw_input('Enter Name: ')
cur.execute("SELECT * FROM sample_data WHERE Name = '%s';" % name) for row in cur.fetchall(): print(row)
db.close()

SQL インジェクション (SQLi) は、SQL ステートメントにコードを挿入して攻撃し、アプリケーションから重要な情報を収集します。これは Web セキュリティの脆弱性です。データベースを操作し、そこから重要な情報を抽出するハッキングの最も一般的な手法です。

view guidelines

セキュリティの設定ミス

多くのフレームワークには、本番環境でもテスト/開発環境でも、アプリケーションの監視を可能にする有効化可能なエンドポイントのセットもあります。これらには以下が含まれます。

メトリクス (プロメテウス)
ログ
環境情報
パス/URL マッピング

セキュリティ設定ミスとは、不適切なコードではなく、アプリケーションの構成設定が原因で発生する一般的な脆弱性を指す包括的な用語です。これは多岐にわたるテーマであり、使用しているテクノロジースタックなどの要因に大きく依存します。多くの場合、これらの問題への対処は、設定ファイルを変更したり、コードを 1 行変更したりするなど、簡単に思えるものですが、これらの脆弱性の影響と結果は深刻な場合があります。この脆弱性の詳細と軽減方法については、ガイドラインをご覧ください。

view guidelines

サーバーサイドリクエストフォージェリ

TS
url = request.params.url としましょう。

レスポンス = http.get (url); とします。
レンダー=レスポンス.render ();

レンダー.export (); を返します。

サーバーサイドリクエストフォージェリの脆弱性は、ユーザーがアプリケーションに攻撃者が指定したドメインに HTTP リクエストを送信させることができる場合に発生します。アプリケーションがプライベート/内部ネットワークにアクセスできる場合、攻撃者はアプリケーションに内部サーバーにリクエストを送信させる可能性もあります。このガイドラインでは、実際の動作がどのようなものかをよりよく理解するために、いくつかの例を挙げて詳しく見ていきます。

view guidelines

パスワードストレージ

Feature Cryptographic hash Password hash Speed Very fast Intentionally slow Work factor can be adjusted No Yes

アプリケーションがユーザーを認証する場合、パスワードも処理する可能性があります。ユーザーパスワードの取り扱いは非常に大変な作業ですが、適切に処理することはさらに重要です。アプリケーションが攻撃され、ユーザーパスワードがインターネット経由で漏洩し、すべての人に見られるようになるほどひどいシナリオは想像できません。パスワードを安全に、そしてベストプラクティスに従って保管するにはどうすればよいのでしょうか。いくつかの方法を見ていきましょう。

view guidelines

一括割り当て

html
<form method="POST">
<input name="Id" type="hidden" value="666">
<input name="Name" type="text" value="Bad guy">
<input name="EmailAddress" type="text" value="hacker@attacker.com">
<input name="IsAdmin" type="hidden" value="true">
<input type="submit">
</form>

Mass Assignmentは、APIエンドポイントが関連オブジェクトのどのプロパティをユーザーが変更できるかを制限しない脆弱性です。この脆弱性は、HTTP パラメーターをモデルに自動的にバインドし、検証なしでそのまま使用できるようにするライブラリ/フレームワークを利用する場合に発生する可能性があります。リクエストからオブジェクトへの自動バインドを使用すると非常に役立つ場合がありますが、ユーザーがアクセスできないように意図されたプロパティがモデルにあると、セキュリティ上の問題が発生する可能性もあります。詳細についてはガイドラインをお読みください。

view guidelines

セキュリティ設定ミス-XXE 詳細

xml
<?xml バージョン= "1.0"?>
<!DOCTYPE アウターエレメント [
<!] >
<outerElement>&外部エンティティ;</outerElement>

「XML 外部エンティティ」(XXE) 脆弱性クラスは、XML パーサーが関与するセキュリティ設定ミスです。XML 標準には、ファイルや URL などの「エンティティ」を参照する方法が含まれています。多くの場合、パーサーは外部エンティティを完全に解決するのがデフォルトです。つまり、XML 文書によって、潜在的な攻撃者にファイルやその他の機密情報が漏洩する可能性があります。詳細についてはガイドライン全文をお読みください。

view guidelines

インジェクション-パストラバーサル

擬似
baseFolder =「/var/www/api/documents/」とします。
パス = ベースフォルダ + request.params.filename; とします。

ファイル.read (パス) を返します。

パストラバーサルは、インジェクションの脆弱性としてよく見られるもう 1 つのタイプです。URI の構築 (URL、ファイルパスなど) で、完全に解決されたパスが目的のパスのルートの外側を指していないことが適切に保証されない場合に起こりがちです。パストラバーサル脆弱性の影響は、トラバーサルが発生する場所や、トラバーサルが行われた全体的な強化方法に大きく依存します。詳しくはガイドラインをお読みください。

view guidelines

認証と承認

cs

//デフォルトの動作がリクエストの認証であることを確認し、リクエストが管理者かどうか確認する
[認証]
[承認 (「管理者」)]
パブリッククラスセキュアコントローラ:コントローラ
{

}

パブリッククラスMyController: セキュアコントローラ
{

//継承された Authorize 属性を上書きして、すべてのユーザーがページにアクセスできるようにします

view guidelines

インジェクション-XSS

```html
<!---UNSAFE: The htmlSnippet will get interpreted without any escaping--->
@Html .Raw (HTML スニペット)
``

XSSとも呼ばれるクロスサイトスクリプティングは、攻撃者が制御するスクリプトを他のユーザーのブラウザで評価する原因となる別のタイプのインジェクション脆弱性です。XSS は HTML/JavaScript インジェクションの脆弱性と見なすこともできます。発生する可能性のある XSS の種類を見てみましょう。

view guidelines

インジェクション 101

最も一般的な注射タイプには次のものがあります。

SQL インジェクション
クロスサイトスクリプティング (HTML/JavaScript インジェクション)
パストラバーサル (パス/URL インジェクション)
コマンド・インジェクション
コード・インジェクション

最もよく知られている脆弱性のクラスの 1 つは、インジェクションの脆弱性です。特に、誰もが疑う余地のない存在である SQL インジェクションは、誰も驚かないでしょう。テクノロジーの世界で SQL インジェクションについて耳にするのは避けられないので、ここではそのことについて話すことにします。この記事を読んで、インジェクションの欠陥について簡単に紹介しましょう。

view guidelines

ファイルアップロード

public string UploadProfilePicture(FormFile uploadedFile)
{
    // Generate path to save the uploaded file at
    var path = $"./uploads/avatars/{request.User.Id}/{uploadedFile.FileName}";

    // Save the file
    var localFile = File.OpenWrite(path);
    localFile.Write(uploadedFile.ReadToEnd());
    localFile.Flush();
    localFile.Close();

    // Update the profile picture 
    UserProfile.UpdateUserProfilePicture(request.User, path)

    return path;
}

アプリケーションがどこかの時点で、アプリケーション内のどこかにファイルを (使用用または保存用に) アップロードできるようにする必要があるのはよくあることです。一見簡単そうに見えますが、ファイルのアップロードの処理方法には潜在的なリスクが伴うため、この機能の実装方法は非常に重要です。詳細についてはガイドラインをお読みください。

view guidelines

コマンド・インジェクション

IP = request.Params.IPAddress; とします。

システム (「ping」+ IP);

コマンド・インジェクションそのものを見てみましょう。主にいくつかの異なる例に焦点を当てて、実際にどのように見えるかをわかりやすくします。簡単に説明しておきますが、コマンドインジェクションの脆弱性は、ユーザー入力がオペレーティングシステムのコマンドの一部を使用する場合に発生します。詳細については、ガイドラインをお読みください。

view guidelines