公的任務と指針

実践における安全なプログラミング

安全なプログラミングに関するガイドラインを確認し、OWASP Top 10などのソフトウェアの脆弱性を理解して修正する方法を知り、実践的なアプリシミュレーションを練習するためのガイド付きトレーニングミッションに参加しましょう。

デモを予約する
BGを学ぶ
公共ミッション
ガイドライン

すべてのミッションを検索

生産性を向上させましょう
SQLインジェクション
あるユーザーから、インターネットバンキング・ソリューションのトランザクション検索機能にSQLインジェクションの脆弱性があるという報告を受けた。彼らは、他のユーザのトランザクションを見ることができたと述べ、この脆弱性によって、攻撃者はデータベースに対して、テーブルの削除、他のテーブルからのデータの閲覧、データの挿入など、あらゆる種類の厄介なことを行うことができると指摘した。このミッションでユーザーが行ったことを再現してみよう。
今すぐ試してみてくださいブログ記事を読む
生産性を向上させましょう
Spring MvcRequestMatchers
2023年3月、Springは内部で発見された脆弱性CVE-2023-20860の修正版をリリースした。この脆弱性は、mvcRequestMatchersで二重のワイルドカード**を使用することで、Spring SecurityとSpring MVCの間でパターンの不一致を引き起こす可能性があるというものだ。これは最終的に、ユーザーが特定のエンドポイントに不正アクセスすることにつながります。いくつかのエンドポイントを持つ非常に単純化された銀行アプリケーションをセットアップしました。指示に従って、このアクセス制御の脆弱性の影響を再現してみてください。
今すぐ試してみてくださいブログ記事を読む
生産性を向上させましょう
サイキックシグネチャー - 既知の脆弱なコンポーネントの使用
CVE-2022-21449は、Javaにおけるサイキック・シグネチャ（Psychic Signatures in Java）という、脆弱性としては最高にクールな別名を持っている。なぜこの名前がついたのか？ドクター・フーのサイキック・ペーパーにちなんでいる。誰かに見せると、この白紙はその人が期待するもので埋められる。Java（バージョン15から18まで）のECDSAアルゴリズムの実装でも似たようなことが起こり、JWTの署名検証に影響を及ぼしている。私たちは無効な署名を提出することができるが、Javaはそれを有効だと考えてしまう。どのように機能するか見たいですか？さっそく始めましょう。
今すぐ試してみてくださいブログ記事を読む
生産性を向上させましょう
Apache Path Traversal - 既知の脆弱なコンポーネントの使用
2021年10月4日、Apacheチームは、CVE-2021-41773としても知られるApache 2.4.48のパストラバーサルとリモートコード実行の脆弱性に対処するため、Apacheのバージョン2.4.49をリリースした。2021年10月7日、2.4.50のHotfixの修正が完了していないため、バージョン2.4.51をリリースした。この脆弱性はCVE-2021-42013として追跡されました。この脆弱性がどのように悪用されるか、このミッションを試してみてください。
今すぐ試してみてくださいブログ記事を読む
生産性を向上させましょう
Log4j - 既知の脆弱なコンポーネントを使用する
2021年12月初旬、非常に人気のあるロギング・ライブラリLog4jの0日エクスプロイト（CVE-2021-44228）が発表され、Javaコミュニティに爆弾が落とされた。Log4Shellと名付けられたこのエクスプロイトは、Log4j v2のバージョン2.0-beta9から2.14.1に影響し、リモートでコードが実行される可能性があります。私たちは、このエクスプロイトを模擬する環境をセットアップしました。今すぐ試してください。
今すぐ試してみてくださいブログ記事を読む
生産性を向上させましょう
トロイの木馬のソース - 信頼できないソースからのコンポーネントの使用
バイキングバンクの開発者の一人が、クレジットカードを管理するための管理者権限チェックを記述するために、潜在的に脆弱なコンポーネントを含むインターネット上の信頼できないソースからコードをコピーしてしまいました。私たちは、管理者だけがこの権限を持つはずなのに、ユーザーがクレジットカードの限度額を変更していることに気づきました。私たちはこのコードに何か問題があると考えています。コードを調査するミッションを試してください。
今すぐ試してみてくださいブログ記事を読む
生産性を向上させましょう
Codestashbin - 安全でないパスワードリセット機能
CodeStashBinは、世界最大級のコード・バージョン・コントロール・ホスティング会社である。噂によると、パスワード忘れ処理に欠陥があり、安全でないパスワードリセット機能の脆弱性があるとのことです。特権ユーザーのパスワードを変更して、そのアカウントにアクセスすることが可能かもしれません。この問題を調査するために、このミッションに飛び込んでください。
今すぐ試してみてくださいブログ記事を読む
生産性を向上させましょう
ChatterGPT' のクロスサイトスクリプティング (XSS)
このミッションは、人気のあるLLMのおなじみのインターフェイスを明らかにし、2023年11月下旬に生成された実際のコード・スニペットを利用する。ユーザーはこのスニペットを解釈し、意図した目的に使用された場合の潜在的なセキュリティの落とし穴を調査することができる。
今すぐ試してみてくださいブログ記事を読む

すべてのガイドラインを検索する

検索:
フィルターを非表示にする
選択
フィルターを表示
選択
フィルターを削除
キーワード
スーパーアイコン [★]
テーマ
もっと見る

Unzureichende Protokollierung und Überwachung

ベストプラクティス：

機密性の高い機能の監査ロギング
エラーロギング
ログの一元的な場所への保管
決められた期間ログの保管
PIIの定期的な監査ログ

Protokollierung und Überwachung sind oft ein nachträglicher Gedanke, wenn bereits etwas schief gelaufen ist, aber in Wirklichkeit kann es sehr kostspielig sein, wenn nicht sichergestellt wird, dass eine ordnungsgemäße Protokollierung und Überwachung erfolgt. Im Extremfall ist es unmöglich, herauszufinden, was tatsächlich passiert ist, wenn ein Vorfall auftritt (ob sicherheitsrelevant oder nicht), wenn nur wenige oder gar keine Protokolle vorliegen. Auf der anderen Seite kann die Protokollierung zu vieler Daten zu Datenschutzproblemen führen, die dann zu Problemen mit den Aufsichtsbehörden führen können. Lesen Sie unseren Leitfaden für bewährte Verfahren zur Vermeidung einer unzureichenden Protokollierung und Überwachung.

ガイドラインを表示する

既知のセキュリティ脆弱性を持つコンポーネントの使用

{
„Abhängigkeiten“: {
„foo“: „1,0,0-2,9999,9999",
„bar“: „>=1.0.2 <2.1.2"
}
}

Die meisten Anwendungen verwenden große Mengen an Komponenten von Drittanbietern. Diese Komponenten bieten alles, von Logging über Templating bis hin zum Datenbankzugriff und mehr. Dies erleichtert die Softwareentwicklung erheblich und spart viel Zeit. Sie werden aber auch von Menschen gemacht, was bedeutet, dass einige unweigerlich Sicherheitslücken enthalten. Lesen Sie die Richtlinie, um mehr zu erfahren.

ガイドラインを表示する

SQLインジェクション

importiere mysql.connector
db = mysql.connector.connect
#Bad -Praxis. Vermeide das! Das ist nur zum Lernen.
(host="localhost „, user="newuser „, passwd="pass „, db="sample „)
cur = db.cursor ()
name = raw_input ('Name eingeben: ')
cur.execute („SELECT * FROM Sample_DATA WHERE Name = '%s';“% name) für Zeile in cur.fetchall (): print (row)
db.schließen ()

SQL Injection (SQLi) injiziert Code in SQL-Anweisungen, um eine Anwendung aufzurufen und wichtige Informationen von ihnen zu sammeln. Es handelt sich um eine Sicherheitslücke im Internet. Es ist die gebräuchlichste Hacking-Technik, bei der die Datenbank manipuliert und wichtige Informationen daraus extrahiert werden.

ガイドラインを表示する

セキュリティ設定の不備

Viele Frameworks verfügen auch über eine Reihe von Endpunkten, die aktiviert werden können, sodass die Anwendung überwacht werden kann, unabhängig davon, ob sich diese in einer Produktions- oder Test-/Entwicklungsumgebung befindet. Diese können beinhalten:

Metriken (Prometheus)
Logs
Informationen zur Umgebung
Pfad-/URL-Zuordnungen

Sicherheitsfehlkonfiguration ist so etwas wie ein Überbegriff, der häufig auftretende Sicherheitslücken abdeckt, die eher auf die Konfigurationseinstellungen einer Anwendung als auf schlechten Code zurückzuführen sind. Es handelt sich um ein weitreichendes Thema, das stark von Faktoren wie Ihrem Technologie-Stack abhängt. Oft scheint die Behebung dieser Probleme einfach zu sein, wie das Ändern einer Konfigurationsdatei oder sogar einer einzelnen Codezeile, aber die Auswirkungen und Folgen dieser Sicherheitslücken können schwerwiegend sein. Lesen Sie unsere Richtlinie, um mehr über diese Sicherheitsanfälligkeit zu erfahren und zu erfahren, wie Sie sie beheben können.

ガイドラインを表示する

サーバーサイドリクエスト偽装

ts
lass url = request.params.url;

lass response = http.get (url);
let render = response.render ();

render.export () zurückgeben;

Sicherheitslücken durch serverseitige Anforderungsfälschung treten auf, wenn ein Benutzer eine Anwendung veranlassen kann, HTTP-Anfragen an eine vom Angreifer bestimmte Domain zu stellen. Wenn eine Anwendung Zugriff auf private/interne Netzwerke hat, kann ein Angreifer die Anwendung auch veranlassen, Anfragen an interne Server zu stellen. Wir werden uns das anhand einiger Beispiele genauer ansehen, um besser zu verstehen, wie es in dieser Richtlinie in Aktion aussieht.

ガイドラインを表示する

Speicherung von Passwörtern

特徴 暗号ハッシュ パスワードハッシュ 速度 非常に速い 意図的に遅い ワークファクターを調整できる いいえ はい

Wenn Ihre Anwendung Benutzer authentifiziert, wird sie wahrscheinlich auch mit Passwörtern umgehen. Der Umgang mit Benutzerkennwörtern ist eine wirklich große Sache, und der angemessene Umgang mit ihnen ist noch wichtiger. Es ist schwer, sich ein schlimmeres Szenario vorzustellen, als wenn eine Anwendung angegriffen wird und Benutzerkennwörter für alle sichtbar im Internet durchgesickert sind. Wie können Passwörter sicher und gemäß den besten Praktiken gespeichert werden? Schauen wir uns ein paar Möglichkeiten an.

ガイドラインを表示する

Massenzuweisung

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>

Massenzuweisungen sind eine Sicherheitslücke, bei der API-Endpunkte nicht einschränken, welche Eigenschaften des zugehörigen Objekts von einem Benutzer geändert werden können. Diese Sicherheitsanfälligkeit kann auftreten, wenn eine Bibliothek/ein Framework verwendet wird, das die automatische Bindung von HTTP-Parametern an ein Modell ermöglicht, das dann ohne Überprüfung verwendet wird. Die Verwendung der automatischen Bindung von einer Anfrage an ein Objekt kann manchmal äußerst hilfreich sein, kann aber auch zu Sicherheitsproblemen führen, wenn das Modell Eigenschaften hat, auf die der Benutzer nicht zugreifen kann. Lesen Sie die Richtlinie für weitere Informationen.

ガイドラインを表示する

Fehlkonfiguration der Sicherheitseinstellungen — XXE detailliert

xml
<? xml-Version = „1.0"? >
<! DOCTYPE Äußeres Element [
<! ] >
<outerElement>&Externe Entität;</outerElement>

Bei der Schwachstellenklasse „XML eXternal Entities“ (XXE) handelt es sich um eine Sicherheitsfehlkonfiguration, an der XML-Parser beteiligt sind. Der XML-Standard beinhaltet Möglichkeiten, auf „Entitäten“ wie Dateien und URLs zu verweisen. Es ist oft die Standardeinstellung, dass Parser externe Entitäten vollständig auflösen, was bedeutet, dass XML-Dokumente zur Offenlegung von Dateien und anderen vertraulichen Informationen für potenzielle Angreifer führen können. Lesen Sie die vollständige Richtlinie für weitere Informationen.

ガイドラインを表示する

Injektion — Pfaddurchquerung

Pseudo-
lass BaseFolder = „/var/www/api/documents/“;
let path = BaseFolder + request.params.filename;

gib file.read (Pfad) zurück;

Path Traversal ist eine weitere ziemlich häufige Art von Injektionsanfälligkeit. Sie treten in der Regel auf, wenn durch die Erstellung einer URI (sei es für eine URL, einen Dateipfad oder etwas anderes) nicht ordnungsgemäß sichergestellt wird, dass der vollständig aufgelöste Pfad nicht außerhalb des Stammverzeichnisses des vorgesehenen Pfads zeigt. Die Auswirkungen einer Sicherheitslücke durch Pfaddurchquerung hängen stark vom Kontext ab, in dem die Traversierung stattfindet, und von der Art der Absicherung, die insgesamt vorgenommen wurde. Lesen Sie die Richtlinie, um mehr zu erfahren.

ガイドラインを表示する

Authentifizierung und Autorisierung

cs

// Ensure the default behaviour is to authenticate requests, and check if they are admin
[Authenticate]
[Authorize("Admin")]
public class SecureController : Controller
{

}

public class MyController : SecureController
{

    // Overrides the Authorize attribute inherited to allow any user to access the page

ガイドラインを表示する

Injektion - XSS

```html
<!--- UNSAFE: The htmlSnippet will get interpreted without any escaping --->
@Html .Raw (HTML-Ausschnitt)
```

Cross-Site Scripting, auch bekannt als XSS, ist eine weitere Art von Injection-Schwachstelle, die zur Auswertung eines vom Angreifer gesteuerten Skripts im Browser eines anderen Benutzers führt. XSS kann auch als HTML/JavaScript-Injection-Schwachstelle betrachtet werden. Schauen wir uns an, auf welche XSS-Typen Sie stoßen können.

ガイドラインを表示する

Injektion 101



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

Eine der bekanntesten Klassen von Sicherheitslücken sind in der Regel Injection-Schwachstellen, insbesondere, und das überrascht niemanden, das unbestrittene Aushängeschild: SQL Injection. Es ist schwer zu vermeiden, in der Technologiewelt von SQL-Injection zu hören, also werden wir einfach darüber sprechen. Lesen Sie weiter, um eine kurze Einführung in Injektionsfehler zu erhalten.

ガイドラインを表示する

Datei hochladen

öffentliche Zeichenfolge uploadProfilePicture (formFile uploadedFile)
{
//Generieren Sie den Pfad zum Speichern der hochgeladenen Datei unter
var-Pfad = $“. /uploads/avatare/ {request.user.ID}/{uploadedFile.filename}“;

//Speichere die Datei
var LocalFile = file.openWrite (Pfad);
Lokaldatei.write (hochgeladene Datei.readToEnd ());
Lokaldatei.flush ();
Lokaldatei.close ();

//Aktualisiere das Profilbild
userProfile.updateUserProfilePicture (request.User, Pfad)

Rückweg;
}

Es kommt sehr häufig vor, dass Anwendungen irgendwann Benutzern erlauben müssen, eine Datei (entweder zur Verwendung oder nur zur Speicherung) irgendwo in der Anwendung hochzuladen. Es scheint zwar einfach zu sein, aber die Art und Weise, wie diese Funktion implementiert wird, kann aufgrund der potenziellen Risiken, die mit der Handhabung von Datei-Uploads verbunden sind, ziemlich wichtig sein. Lesen Sie die Richtlinie für weitere Informationen.

ガイドラインを表示する

Befehlsinjektion

let ip = request.params.IPAddress;

system („ping" + ip);

Schauen wir uns Command Injection selbst an. Wir werden uns hauptsächlich auf einige verschiedene Beispiele konzentrieren, damit es einfacher ist, zu sehen, wie es in Aktion aussieht. Zur kleinen Auffrischung: Command Injection-Schwachstellen treten auf, wenn Benutzereingaben einen Teil eines Betriebssystembefehls verwenden. Lesen Sie die Richtlinie für weitere Informationen.

ガイドラインを表示する