{
  "global": {
    "actions": "Aktionen",
    "action.profile": "Profil",
    "action.login": "Einloggen",
    "action.logout": "Ausloggen",
    "action.retry": "Erneut Versuchen",
    "action.info": "Info",
    "action.save": "Speichern",
    "action.confirm": "Bestätigen",
    "action.cancel": "Abbrechen",
    "action.return": "Zurück",
    "action.exit": "Beenden",
    "action.update": "Speichern",
    "action.edit": "Editieren",
    "action.export": "Exportieren",
    "action.download": "Herunterladen",
    "action.report": "Bericht",
    "action.reset": "Zurücksetzen",
    "action.complete": "Fertig",
    "action.disable": "Deaktivieren",
    "action.enable": "Aktivieren",
    "action.close": "Schließen",
    "action.yes": "Ja",
    "action.no": "Nein",
    "username": "Nutzername",
    "password": "Passwort",
    "no.progress": "Kein Fortschritt",
    "project": "Projekt",
    "version": "Version",
    "validationMessage": {
      "inputNotMatching": "Eingabe stimmt nicht überein!"
    },
    "retry.dialog": {
      "title": "Etwas ist schief gelaufen...",
      "information": "Fehler beim verarbeiten Ihrer Anfrage. \nBitte versuchen Sie es erneut oder zu einem späteren Zeitpunkt."
    }
  },
  "languageKeys":{
    "de-DE": "Deutsch",
    "en-US": "Englisch"
  },
  "popup": {
    "success": "✔",
    "failure": "✘",
    "warning": "!",
    "info": "ⓘ",
    "error.position": {
      "permissionDenied": "Berechtigung verweigert",
      "timeout": "Zeitüberschreitung"
    },
    "login": {
      "successful": "Einloggen erfolgreich"
    }
  },
  "login": {
    "title": "Einloggen",
    "failed": "Benutzername oder Passwort falsch",
    "unauthorized": "Benutzer nicht gefunden. Bitte registrieren und erneut versuchen"
  },
  "profile": {
    "header": "Nutzerprofil",
    "username": {
      "title": "Nutzername",
      "placeholder": "Nutzername"
    },
    "firstName": {
      "title": "Vorname",
      "placeholder": "Vorname"
    },
    "lastName": {
      "title": "Nachname",
      "placeholder": "Nachname"
    },
    "eMail": {
      "title": "E-Mail",
      "placeholder": "Keine E-Mail bestätigt."
    },
    "validationMessage": {
      "firstNameRequired": "Vorname ist erforderlich.",
      "lastNameRequired": "Nachname ist erforderlich."
    },
    "languageLabel": "Sprache ändern:",
    "password": {
      "title": "Passwort ändern:",
      "button" : "Passwort ändern",
      "old": "Altes Passwort",
      "new": "Neues Passwort",
      "confirmNew": "Neues Passwort bestätigen",
      "validationMessage": {
        "passwordRequired": "Passwort ist erforderlich."
      }
    }
  },
  "tutorial": {
    "header": "Erste Schritte mit C4PO",
    "carousel": {
      "project_overview": "Die Projektübersicht gibt Ihnen einen Überblick über alle Ihre aktuellen Projekte.\nHier können Sie neue erstellen, bestehende bearbeiten oder löschen oder nach einem bestimmten Projekt filtern.\nSehen Sie den aktuellen Stand Ihrer Projekte sowie den Fortschritt zusammen mit einigen zusätzlichen Informationen wie Name, Kunde, Tester und wann es erstellt wurde.",
      "project_overview_filtered": "Das Filtern in der Projektübersicht kann Ihnen helfen, das/die gesuchte(n) Projekt(e) zu finden.\nGeben Sie bestimmte Schlüsselwörter wie den Titel eines Projekts oder einen speziellen Status wie „Benötigt weitere Informationen“ ein oder suchen Sie nach einem wichtigen Kunden.",
      "create_edit_project": "Erstellen Sie ein neues oder ein bestehendes Projekt, geben Sie ihm einen Titel und einen Kundennamen, weisen Sie einen Tester zu und schreiben Sie eine Zusammenfassung für den Pentest (nur im Bearbeitungsmodus verfügbar).\nDarüber hinaus können Sie auch einen bestimmten Status für das Projekt auswählen, um anzuzeigen, ob der Pentest derzeit „in Arbeit“ ist oder darauf wartet, dass der Kunde den Bericht überprüft.",
      "userprofile": "Ändern Sie Ihre Einstellungen.\nEgal, ob Sie nur die Sprache der Anwendung auswählen oder Ihr Passwort ändern.",
      "category&objective_overview": "Sehen Sie sich hier jedes Ziel jeder Kategorie an.\nDerselbe Inhalt ist auch im OWASP Web Testing Guide enthalten.\nSie können sich einen guten Überblick über alle Ziele verschaffen, die in einer bestimmten Kategorie enthalten sind, sehen, wie viele Ergebnisse und Kommentare hinzugefügt wurden, und sogar bestimmte Ziele deaktivieren, was zur Folge hat, dass sie nicht in den Bericht aufgenommen werden.",
      "objective_info": "Lesen Sie die wichtigsten Informationen zum gewählten Ziel.\nZu diesen Informationen gehört, was am Ziel zu tun ist, welche Probleme am häufigsten auftreten und wie Sie sie ausnutzen können.",
      "objective_finding_overview": "Sehen Sie sich alle Funde an, die sich auf das ausgewählte Ziel beziehen.\nSie können den Titel, den Schweregrad, einen Teil der Beschreibung und die Auswirkung des Befundes sehen.\nDarüber hinaus können Sie einen bestimmten Befund auch bearbeiten oder sogar löschen.",
      "create_edit_finding": "Bearbeiten oder erstellen Sie neue Funde für das Ziel.\nDokumentieren Sie hier den Titel, die Beschreibung, die betroffenen Anwendungsteile, die betroffenen URLs oder APIs und eine Schweregradbewertung zusammen mit Reproduktionsschritten und einem Abhilfevorschlag.\nSie können Befunde erst erstellen, wenn Sie den Timer gestartet haben, damit Ihre Arbeit nachverfolgt wird.",
      "objective_comment_overview": "Sehen Sie sich alle Kommentare an, die sich auf das ausgewählte Ziel beziehen.\nSie können den Titel und einen Teil der Beschreibung des Kommentars sehen.\nDarüber hinaus können Sie einen bestimmten Kommentar auch bearbeiten oder sogar löschen.",
      "create_edit_comment": "Bearbeiten oder erstellen Sie neue Kommentare für das Ziel.\nDokumentieren Sie hier den Titel und eine Beschreibung.\nSie können Kommentare erst erstellen, wenn Sie den Timer gestartet haben, damit Ihre Arbeit nachverfolgt wird.",
      "generate_report": "Generieren und exportieren Sie Ihren Bericht. Sie können den Namen und die Version Ihres Projekts sowie einige Statistiken darüber sehen, wie viele Ihrer Ziele abgeschlossen, in Bearbeitung, pausiert, nicht gestartet oder deaktiviert sind.\nNur Ihre abgeschlossenen Ziele werden in den Abschlussbericht aufgenommen.\nStellen Sie vor dem Exportieren sicher, dass Sie die richtige Sprache für Ihren Bericht auswählen.",
      "report": "Laden Sie Ihren generierten Bericht als PDF herunter und senden Sie ihn direkt an den Kunden.\nDer Bericht enthält alle Informationen, die Sie in der C4PO-Anwendung eingegeben haben.\nDer Bericht besteht aus einem Deckblatt, einem Inhaltsverzeichnis, dem Stand der Vertraulichkeit, einer Zusammenfassung, technischen Details zu den Ergebnissen sowie Kommentaren und Anhängen."
    }
  },
  "state": {
    "new": "Neu",
    "needs_more_info": "Benötigt mehr Informationen",
    "pre_submission": "Voranmeldung",
    "pending": "Pending",
    "triaged": "Ausstehend",
    "retesting": "Erneutes Testen",
    "resolved": "Aufgeklärt",
    "informative": "Informativ",
    "duplicate": "Duplikat",
    "not_applicable": "Unzutreffend",
    "spam": "Spam",
    "out_of_scope": "Außerhalb Anwendungsbereich",
    "accepted_risk": "Akzeptiertes Risiko"
  },
  "report": {
    "dialog": {
      "header": "Penetrationstestbereicht exportieren",
      "formatLabel": "Wählen Sie das Exportformat für den Bericht:",
      "languageLabel": "Wählen Sie die Berichtssprache:"
    },
    "popup": {
      "generation.success": "Bericht erfolgreich generiert",
      "generation.failed": "Bericht konnte nicht generiert werden"
    },
    "generate": "Bericht generieren",
    "hint": "{{completedObjectivesNumber}} Ihrer abgeschlossenen Ziele wird in den Pentestbericht aufgenommen."
  },
  "project": {
    "title.label": "Projekt Titel",
    "client.label": "Name des Auftraggebers",
    "tester.label": "Name des Pentester",
    "state.label": "Penteststatus",
    "summary.label": "Zusammenfassung",
    "summary.placeholder": "Sollte eine Zusammenfassung, einen Ansatz, einen Umfang und eine Bewertungsübersicht sowie allgemeine Empfehlungen enthalten",
    "title": "Titel",
    "client": "Klient",
    "tester": "Tester",
    "state": "Penteststatus",
    "summary": "Zusammenfassung",
    "createdAt": "Erstellt am",
    "overview": {
      "add.project": "Projekt hinzufügen",
      "no.projects": "Keine Projekte verfügbar"
    },
    "filter": {
      "placeholder": "Alle {{allProjectsCount}} Projekt(e) durchsuchen.."
    },
    "create": {
      "header": "Neues Projekt erstellen"
    },
    "edit": {
      "header": "Projekt editieren"
    },
    "delete": {
      "title": "Projekt löschen",
      "key": "Möchten Sie das Projekt \"{{name}}\" unwiderruflich löschen?",
      "confirmStringPlaceholder": "Geben Sie zur Bestätigung den Projekttitel ein",
      "sec.key": "Möchten Sie das Projekt \"{{name}}\" unwiderruflich löschen? \nSie löschen damit auch alle zugehörigen Daten."
    },
    "validationMessage": {
      "titleRequired": "Titel ist erforderlich.",
      "clientRequired": "Klient ist erforderlich.",
      "testerRequired": "Tester ist erforderlich.",
      "stateRequired": "Status ist erforderlich.",
      "summaryRequired": "Zusammenfassung ist erforderlich."
    },
    "popup": {
      "not.found": "Keine Projekte gefunden",
      "save.success": "Projekt erfolgreich gespeichert",
      "save.failed": "Projekt konnte nicht gespeichert werden",
      "update.success": "Projekt erfolgreich aktualisiert",
      "update.failed": "Projekt konnte nicht aktualisiert werden",
      "delete.success": "Projekt erfolgreich gelöscht",
      "delete.failed": "Projekt konnte nicht gelöscht werden"
    }
  },
  "categories": {
    "INFORMATION_GATHERING": "Informationsbeschaffung",
    "CONFIGURATION_AND_DEPLOY_MANAGEMENT_TESTING": "Konfig- & Einsatzmanagement-Testing",
    "IDENTITY_MANAGEMENT_TESTING": "Identitätsmanagement-Testing",
    "AUTHENTICATION_TESTING": "Authentifizierungs-Testing",
    "AUTHORIZATION_TESTING": "Autorisations-Testing",
    "SESSION_MANAGEMENT_TESTING": "Sitzungsmanagement-Testing",
    "INPUT_VALIDATION_TESTING": "Eingabevalidierungs-Testing",
    "ERROR_HANDLING": "Fehlerbehandlung",
    "CRYPTOGRAPHY": "Kryptographie",
    "BUSINESS_LOGIC_TESTING": "Business-Logik-Testing",
    "CLIENT_SIDE_TESTING": "Clientseitiges-Testing"
  },
  "finding": {
    "findingId": "Fund Id",
    "severity": "Schwere",
    "title": "Titel",
    "description": "Beschreibung",
    "impact": "Auswirkung",
    "affectedUrls": "Betroffene URL's / API's",
    "reproduction": "Reproduktion",
    "mitigation": "Minderung",
    "add": "Fund hinzufügen",
    "add.url": "Betroffene URL / API hinzufügen",
    "affectedUrls.placeholder": "Betroffene URL oder API hier eingeben..",
    "create": {
      "header": "Neuen Fund erstellen"
    },
    "edit": {
      "header": "Fund editieren"
    },
    "delete": {
      "title": "Fund löschen",
      "key": "Möchten Sie den Fund \"{{name}}\" unwiderruflich löschen?"
    },
    "severity.label": "Schwere des Funds",
    "title.label": "Fundtitel",
    "description.label": "Beschreibung des Funds",
    "impact.label": "Auswirkung auf Anwendung",
    "affectedUrls.label": "Betroffene URL's / API's",
    "reproduction.label": "Reproduktionsschritte",
    "mitigation.label": "Minderungsvorschlag",
    "no.findings": "Keine Funde verfügbar",
    "validationMessage": {
      "titleRequired": "Titel ist erforderlich.",
      "severityRequired": "Schwere ist erforderlich.",
      "descriptionRequired": "Beschreibung ist erforderlich.",
      "impactRequired": "Auswirkung ist erforderlich.",
      "affectedUrlsRequired": "Betroffene URL's erforderlich.",
      "reproductionRequired": "Reproduktionschritt(e) sind erforderlich.",
      "mitigationRequired": "Minderungsvorschlag ist erforderlich."
    },
    "popup": {
      "not.found": "Keine Funde gefunden",
      "save.success": "Fund erfolgreich gespeichert",
      "save.failed": "Fund konnte nicht gespeichert werden",
      "update.success": "Fund erfolgreich aktualisiert",
      "update.failed": "Fund konnte nicht aktualisiert werden",
      "delete.success": "Fund erfolgreich gelöscht",
      "delete.failed": "Fund konnte nicht gelöscht werden",
      "not.available": "Fund ist nicht mehr verfügbar"
    }
  },
  "severities": {
    "low": "Niedrig",
    "medium": "Mittel",
    "high": "Hoch",
    "critical": "Kritisch"
  },
  "comment": {
    "commentId": "Kommentar Id",
    "title": "Titel",
    "description": "Beschreibung",
    "relatedFindings": "Verbundene Funde",
    "add": "Kommentar hinzufügen",
    "add.finding": "Fund hinzufügen",
    "no.comments": "Keine Kommentare verfügbar",
    "no.relatedFindings": "Nicht verbunden mit einem Fund",
    "relatedFindingsPlaceholder": "Fund auswählen",
    "noFindingsInObjectivePlaceholder": "Ziel hat keine Befunde, auf die es sich beziehen könnte.",
    "create": {
      "header": "Neuen Kommentar erstellen"
    },
    "edit": {
      "header": "Kommentar editieren"
    },
    "delete": {
      "title": "Kommentar löschen",
      "key": "Möchten Sie den Kommentar \"{{name}}\" unwiderruflich löschen?"
    },
    "title.label": "Kommentartitel",
    "description.label": "Beschreibung des Kommentars",
    "relatedFindings.label": "Verbundene Funde",
    "validationMessage": {
      "titleRequired": "Titel ist erforderlich.",
      "descriptionRequired": "Beschreibung ist erforderlich.",
      "relatedFindings": "Verwandte Funde erforderlich."
    },
    "popup": {
      "not.found": "Keine Kommentare gefunden",
      "save.success": "Kommentar erfolgreich gespeichert",
      "save.failed": "Kommentar konnte nicht gespeichert werden",
      "update.success": "Kommentar erfolgreich aktualisiert",
      "update.failed": "Kommentar konnte nicht aktualisiert werden",
      "delete.success": "Kommentar erfolgreich gelöscht",
      "delete.failed": "Kommentar konnte nicht gelöscht werden",
      "not.available": "Kommentar ist nicht mehr verfügbar"
    }
  },
  "pentest": {
    "testId": "Nr.",
    "title": "Titel",
    "findings": "Funde",
    "comments": "Kommentare",
    "findings&comments": "Funde & Kommentare",
    "status": "Status",
    "statusText": {
      "not_started": "Nicht angefangen",
      "disabled": "Deaktiviert",
      "open": "Offen",
      "paused": "Pausiert",
      "in_progress": "In Bearbeitung",
      "completed": "Fertig"
    },
    "disable": {
      "title": "Ziel deaktivieren",
      "key": "Möchten Sie den Pentest \"{{name}}\" deaktivieren?"
    },
    "enable": {
      "title": "Ziel aktivieren",
      "key": "Möchten Sie den Pentest \"{{name}}\" aktivieren?"
    },
    "popup": {
      "not.found": "Keine pentests gefunden",
      "initial.save.success": "Initialer Pentest erfolgreich aufgesetzt",
      "initial.save.failed": "Initialer Pentest konnte nicht aufgesetzt werden",
      "save.success": "Pentest erfolgreich gespeichert",
      "save.failed": "Pentest konnte nicht gespeichert werden",
      "complete.success":  "Pentest erfolgreich vervollständigt",
      "complete.failed": "Pentest konnte nicht vervollständigt werden",
      "update.success": "Pentest erfolgreich aktualisiert",
      "update.failed": "Pentest konnte nicht aktualisiert werden",
      "delete.success": "Pentest erfolgreich gelöscht",
      "delete.failed": "Pentest konnte nicht gelöscht werden",
      "disable.success": "Ziel erfolgreich deaktiviert",
      "disable.failed": "Ziel konnte nicht deaktiviert werden",
      "enable.success": "Ziel erfolgreich aktiviert",
      "enable.failed": "Ziel konnte nicht aktiviert werden"
    },
    "info": {
      "001": "Nutze Suchmaschinenerkennung und -aufklärung für Informationslecks",
      "002": "Fingerabdruck-Webserver",
      "003": "Prüfe Webserver-Metadateien auf Informationslecks",
      "004": "Anwendungen auf dem Webserver auflisten",
      "005": "Prüfe Webseitenkommentare und Metadaten auf Informationslecks",
      "006": "Identifizieren der Einstiegspunkte",
      "007": "Zuordnen von Ausführungspfade der Anwendung",
      "008": "Framework für Fingerabdruck-Webanwendungen",
      "009": "Fingerabdruck-Webanwendungen",
      "010": "Zuordnen der Anwendungsarchitektur"
    },
    "config": {
      "001": "Netzwerk-/Infrastrukturkonfiguration testen",
      "002": "Testen Sie die Konfiguration der Anwendungsplattform",
      "003": "Testen der Behandlung von Dateierweiterungen für vertrauliche Informationen",
      "004": "Backup und nicht referenzierte Dateien für sensible Informationen",
      "005": "Aufzählen der Infrastruktur- und Anwendungsverwaltungsschnittstellen",
      "006": "HTTP-Methoden testen",
      "007": "Testen Sie HTTP Strict Transport Security",
      "008": "Testen der domänenübergreifende RIA-Richtlinie"
    },
    "ident": {
      "001": "Rollendefinitionen testen",
      "002": "Registrierungsprozess testen",
      "003": "Konto-Bereitstellungsprozess testen",
      "004": "Testen auf Kontoaufzählung und erratbares Benutzerkonto",
      "005": "Test auf schwache oder nicht erzwungene Richtlinie für Benutzernamen",
      "006": "Testberechtigungen von Gast-/Schulungskonten",
      "007": "Sperrung/Wiederaufnahme des Kontos testen"
    },
    "authn": {
      "001": "Testen auf Anmeldeinformationen, die über einen verschlüsselten Kanal transportiert werden",
      "002": "Testen auf Standardanmeldeinformationen",
      "003": "Test auf schwachen Sperrmechanismus",
      "004": "Testen auf Umgehung des Authentifizierungsschemas",
      "005": "Testen der Passwort speichern Funktion",
      "006": "Test auf Browser-Cache-Schwäche",
      "007": "Testen auf schwache Richtlinie für Kennwörter",
      "008": "Prüfung auf schwache Sicherheitsfrage/Antwort",
      "009": "Testen auf schwache Passwortänderungs- oder Zurücksetzungsfunktionen",
      "010": "Testen auf schwächere Authentifizierung über alternativen Kanal"
    },
    "authz": {
      "001": "Testen von Directory Traversal/File Include",
      "002": "Testen auf Umgehung des Autorisierungsschemas",
      "003": "Testen auf Rechteausweitung",
      "004": "Testen auf unsichere direkte Objektreferenzen"
    },
    "sess": {
      "001": "Testen auf Umgehung des Sitzungsverwaltungsschemas",
      "002": "Testen auf Cookies-Attribute",
      "003": "Testen auf Sitzungsfixierung",
      "004": "Testen auf sichtbare Sitzungsvariablen",
      "005": "Prüfung auf Cross-Site-Request-Forgery",
      "006": "Testen der Abmeldefunktion",
      "007": "Testen der Sitzungszeitüberschreitung",
      "008": "Testen auf Session-Rätsel"
    },
    "inpval": {
      "001": "Testen auf reflektiertes Cross-Site-Scripting",
      "002": "Testen auf konserviertes Cross Site Scripting",
      "003": "Testen auf HTTP-Verb-Manipulation",
      "004": "Prüfung auf HTTP-Parameterverschmutzung",
      "005": "Testen auf SQL-Injection",
      "005_1": "Oracle-Tests",
      "005_2": "MySQL-Tests",
      "005_3": "SQL Server-Tests",
      "005_4": "Testen von PostgreSQL",
      "005_5": "MS-Access-Tests",
      "005_6": "Testen auf NoSQL-Injection",
      "006": "Testen auf LDAP-Injection",
      "007": "Prüfung auf ORM-Injection",
      "008": "Testen auf XML-Injection",
      "009": "Prüfung auf SSI-Injection",
      "010": "Testen auf XPath-Injection",
      "011": "IMAP/SMTP-Injection",
      "012": "Testen auf Code-Injection",
      "012_1": "Testen der lokalen Dateieinbindung",
      "012_2": "Testen der Remote-Dateieinbindung",
      "013": "Testen auf BefehlInjection",
      "014": "Test auf Pufferüberlauf",
      "014_1": "Test auf Heap-Überlauf",
      "014_2": "Test auf Stack-Überlauf",
      "014_3": "Testen auf Formatzeichenfolge",
      "015": "Testen auf inkubierte Schwachstellen",
      "016": "Testen auf HTTP-Splitting/-Schmuggel"
    },
    "err": {
      "001": "Analyse von Fehlercodes",
      "002": "Analyse von Stack-Traces"
    },
    "crypst": {
      "001": "Testen auf schwache SSL/TSL-Chiffren, unzureichenden Transportschichtschutz",
      "002": "Testen für Padding Oracle",
      "003": "Prüfung auf sensible Informationen, die über unverschlüsselte Kanäle gesendet werden"
    },
    "buslogic": {
      "001": "Testen Sie die Datenvalidierung der Geschäftslogik",
      "002": "Testen Sie die Fähigkeit, Anfragen zu fälschen",
      "003": "Integritätsprüfungen testen",
      "004": "Testen Sie das Prozesstiming",
      "005": "Testen Sie, wie oft eine Funktion verwendet werden kann",
      "006": "Prüfung auf Umgehung von Arbeitsabläufen",
      "007": "Testen Sie Abwehrmaßnahmen gegen Anwendungsmissbrauch",
      "008": "Test-Upload von unerwarteten Dateitypen",
      "009": "Test-Upload schädlicher Dateien"
    },
    "client": {
      "001": "Testen auf DOM-basiertes Cross Site Scripting",
      "002": "Testen auf JavaScript-Ausführung",
      "003": "Testen auf HTML-Injection",
      "004": "Testen der clientseitigen URL-Umleitung",
      "005": "Testen auf CSS-Injektion",
      "006": "Testen auf clientseitige Ressourcenmanipulation",
      "007": "Testen Sie die ursprungsübergreifende Ressourcenfreigabe",
      "008": "Testen auf Cross-Site-Flashing",
      "009": "Test auf Clickjacking",
      "010": "Testen von WebSockets",
      "011": "Testen von Web-Messaging",
      "012": "Lokalen Speicher testen"
    }
  },
  "objectives": {
    "info": {
      "001": "Ziel ist es zu verstehen, welche sensiblen Design- und Konfigurationsinformationen der Anwendung, des Systems oder der Organisation direkt (auf der Website der Organisation) oder indirekt (auf der Website eines Drittanbieters) offengelegt werden.\n\n Es gibt direkte und indirekte Elemente der Suchmaschinenerkennung und -aufklärung.\n Direkte Methoden beziehen sich auf das Durchsuchen der Indizes und der zugehörigen Inhalte aus Caches.\n Indirekte Methoden beziehen sich auf das Sammeln vertraulicher Design- und Konfigurationsinformationen durch das Durchsuchen von Foren, Newsgroups und Ausschreibungswebsites.\n\n Verwenden Sie eine Suchmaschine, um nach Folgendem zu suchen:\n• Netzwerkdiagramme und -konfigurationen\n• Archivierte Beiträge und E-Mails von Administratoren oder anderen wichtigen Mitarbeitern\n• Anmeldeverfahren und Benutzernamenformate\n• Benutzernamen und Passwörter\n• Inhalt der Fehlermeldung\n• Entwicklungs-, Test-, UAT- und Staging-Versionen der Website",
      "002": "Das Ziel besteht darin, die Version und den Typ eines laufenden Webservers zu finden, um bekannte Schwachstellen und die geeigneten Exploits zu ermitteln, die während des Tests verwendet werden können.\n\n Webserver-Fingerprinting ist eine kritische Aufgabe für den Penetrationstester.\nDie Kenntnis der Version und des Typs eines laufenden Webservers ermöglicht es Testern, bekannte Schwachstellen und die geeigneten Exploits zu ermitteln, die während des Tests verwendet werden können.\n\n Es gibt heute mehrere verschiedene Anbieter und Versionen von Webservern auf dem Markt. Die Kenntnis des Typs des getesteten Webservers hilft erheblich beim Testprozess und kann auch den Verlauf des Tests verändern. Die einfachste und grundlegendste Art, einen Webserver zu identifizieren, besteht darin, sich das Serverfeld im HTTP-Antwortheader anzusehen.\n\n Indem der Tester weiß, wie jeder Webservertyp auf bestimmte Befehle reagiert, und diese Informationen in einer Fingerprint-Datenbank des Webservers speichert, kann ein Penetrationstester diese Befehle an den Webserver senden, die Antwort analysieren und sie mit der Datenbank bekannter Signaturen vergleichen.",
      "003": "Das Ziel hier ist, die robots.txt-Datei auf Informationslecks des Verzeichnisses oder der Ordnerpfade der Webanwendung zu überprüfen.\n\n 1. Informationsverlust des Verzeichnisses oder der Ordnerpfade der Webanwendung.\n 2. Erstellen Sie die Liste der Verzeichnisse, die von Spiders, Robots oder Crawlern vermieden werden sollen.\n\n Darüber hinaus kann die Liste der Verzeichnisse, die von Spidern, Robots oder Crawlern vermieden werden sollen, auch als Abhängigkeit für Map execution paths durch die Anwendung erstellt werden.\n Webspider, Robots oder Crawler rufen eine Webseite ab und durchlaufen dann rekursiv Hyperlinks, um weitere Webinhalte abzurufen. Ihr akzeptiertes Verhalten wird durch das Robots Exclusion Protocol der robots.txt-Datei im Web-Root-Verzeichnis angegeben.",
      "004": "Das Ziel besteht darin, die Anwendungen innerhalb des Gültigkeitsbereichs aufzuzählen, die auf einem Webserver vorhanden sind.\n\n Viele Anwendungen haben bekannte Schwachstellen und bekannte Angriffsstrategien, die ausgenutzt werden können, um eine Fernsteuerung zu erlangen oder Daten auszunutzen. Außerdem sind viele Anwendungen oft falsch konfiguriert oder werden nicht aktualisiert.\n Die Erkennung von Webanwendungen ist ein Prozess, der darauf abzielt, Webanwendungen in einer bestimmten Infrastruktur zu identifizieren. Letzteres wird normalerweise als eine Reihe von IP-Adressen (möglicherweise ein Netzblock) angegeben, kann aber auch aus einer Reihe symbolischer DNS-Namen oder einer Mischung aus beiden bestehen.",
      "005": "Ziel ist es, Webseitenkommentare und Metadaten zu überprüfen, um die Anwendung besser zu verstehen und Informationslecks zu finden.\n\n HTML-Kommentare werden häufig von den Entwicklern verwendet, um Debugging-Informationen über die Anwendung einzufügen. Manchmal vergessen sie die Kommentare.\n\n Überprüfen Sie den HTML-Quellcode auf Kommentare mit vertraulichen Informationen, die dem Angreifer helfen können, mehr Einblick in die Anwendung zu gewinnen. Dies können SQL-Code, Benutzernamen und Passwörter, interne IP-Adressen oder Debugging-Informationen sein.",
      "006": "Ziel ist es zu verstehen, wie Anfragen gebildet werden und typische Antworten der Anwendung.\n\n Die Aufzählung der Anwendung und ihrer Angriffsfläche ist ein wichtiger Vorläufer bevor gründliche Tests durchgeführt werden können, da es dem Tester ermöglicht, wahrscheinliche Schwachstellen zu identifizieren. Dies soll dazu beitragen, Bereiche innerhalb der Anwendung zu identifizieren und zu kartieren, die untersucht werden sollten, sobald die Aufzählung und Kartierung abgeschlossen sind.\n\n  Achten Sie beim Durchlaufen der Anwendung besonders auf alle HTTP-Anforderungen (GET- und POST-Methoden, auch bekannt als Verben) sowie auf alle Parameter und Formularfelder, die an die Anwendung übergeben werden.\n Beachten Sie außerdem alle interessanten Parameter in der URL, den benutzerdefinierten Headern oder dem Text der Anfragen/Antworten und speichern Sie sie.\n Sobald jeder Bereich der Anwendung abgebildet ist, gehen Sie die Anwendung durch und testen Sie jeden der identifizierten Bereiche und machen Sie sich Notizen darüber, was funktioniert hat und was nicht.",
      "007": "Ziel ist es, die Zielanwendung abzubilden und die wichtigsten Arbeitsabläufe zu verstehen.\n\n Bevor Sie mit Sicherheitstests beginnen, ist es von größter Bedeutung, die Struktur der Anwendung zu verstehen.\nEs gibt mehrere Möglichkeiten, an das Testen und Messen der Codeabdeckung heranzugehen:\n\n 1. Pfad:\n Testen Sie jeden der Pfade durch eine Anwendung, die kombinatorische und Grenzwertanalysetests für jeden Entscheidungspfad umfasst. Während dieser Ansatz Gründlichkeit bietet, wächst die Anzahl der testbaren Pfade exponentiell mit jedem Entscheidungszweig.\n\n 2. Datenfluss (oder Taint-Analyse):\n Testet die Zuweisung von Variablen durch externe Interaktion (normalerweise Benutzer).\n Konzentriert sich auf die Abbildung des Flusses, der Transformation und der Verwendung von Daten in einer Anwendung.\n\n 3. Rennen:\n Testet mehrere gleichzeitige Instanzen der Anwendung, die dieselben Daten manipulieren.",
      "008": "Ziel ist es, den Typ des verwendeten Web-Frameworks zu definieren, um ein besseres Verständnis der Sicherheitstestmethodik zu erlangen.\n\n Die Art des Frameworks zu kennen, kann automatisch einen großen Vorteil bringen, wenn ein solches Framework bereits vom Penetrationstester getestet wurde. Nicht nur die bekannten Schwachstellen in ungepatchten Versionen, sondern auch spezifische Fehlkonfigurationen im Framework und der bekannten Dateistruktur machen den Fingerprinting-Prozess so wichtig.\n\n Es gibt mehrere gängige Orte, an denen Sie nachsehen können, um den aktuellen Rahmen zu definieren:\n• HTTP-Header\n• Cookies\n• HTML-Quellcode\n• Bestimmte Dateien und Ordner",
      "009": "Ziel ist es, die Webanwendung und -version zu identifizieren, um bekannte Schwachstellen und die geeigneten Exploits zu ermitteln, die während des Tests verwendet werden können.\n\n Bei der großen Anzahl von Free- und Open-Source-Softwareprojekten, die weltweit aktiv entwickelt und eingesetzt werden, ist es sehr wahrscheinlich, dass ein Anwendungssicherheitstest auf eine Zielseite trifft, die ganz oder teilweise von diesen bekannten Anwendungen abhängig ist (z. B. Wordpress, phpBB, Mediawiki usw.).\n\nDie Kenntnis der zu testenden Webanwendungskomponenten hilft erheblich beim Testprozess.\nDiese wohlbekannten Webanwendungen haben bekannte HTML-Kopfzeilen, Cookies und Verzeichnisstrukturen, die aufgezählt werden können, um die Anwendung zu identifizieren.",
      "010": "Die Anwendungsarchitektur muss durch einige Tests abgebildet werden, um festzustellen, welche verschiedenen Komponenten zum Erstellen der Webanwendung verwendet werden.\n\n In kleinen Setups, wie z. B. einer einfachen CGI-basierten Anwendung, kann ein einzelner Server verwendet werden, auf dem der Webserver ausgeführt wird, der die C-, Perl- oder Shell-CGIs-Anwendung und möglicherweise auch den Authentifizierungsmechanismus ausführt.\n Bei komplexeren Setups können mehrere Server beteiligt sein. Dazu können ein Reverse-Proxy, ein Frontend-Webserver, ein Anwendungsserver und ein Datenbankserver oder LDAP-Server gehören.\nJeder dieser Server wird für unterschiedliche Zwecke verwendet und kann sogar in verschiedene Netzwerke mit Firewalls dazwischen (DMZs) unterteilt sein.\n\n Darüber hinaus ist das Verständnis der bereitgestellten Konfiguration des Servers, auf dem die Webanwendung gehostet wird, fast so wichtig wie das Testen der Anwendungssicherheit selbst."
    },
    "config": {
      "001": "Die intrinsische Komplexität einer vernetzten und heterogenen Webserver-Infrastruktur, die Hunderte von Webanwendungen umfassen kann, macht das Konfigurationsmanagement und die Überprüfung zu einem grundlegenden Schritt beim Testen und Bereitstellen jeder einzelnen Anwendung. Es braucht nur eine einzige Schwachstelle, um die Sicherheit der gesamten Infrastruktur zu untergraben. Um diese Probleme anzugehen, ist es von größter Bedeutung, eine gründliche Überprüfung der Konfiguration und bekannter Sicherheitsprobleme durchzuführen.\n\nZum Testen der Konfigurationsmanagement-Infrastruktur müssen die folgenden Schritte ausgeführt werden:\n\nSchritt 1:\n Die verschiedenen Elemente, aus denen die Infrastruktur besteht, müssen bestimmt werden, um zu verstehen, wie sie mit einer Webanwendung interagieren und wie sie sich auf deren Sicherheit auswirken.\n\nSchritt 2:\n Alle Elemente der Infrastruktur müssen überprüft werden, um sicherzustellen, dass sie keine bekannten Schwachstellen enthalten.\n\nSchritt 3:\n Es muss eine Überprüfung der Verwaltungsinstrumente durchgeführt werden, die zur Pflege aller verschiedenen Elemente verwendet werden.\n\nSchritt 4:\n Die Authentifizierungssysteme müssen überprüft werden, um sicherzustellen, dass sie die Anforderungen der Anwendung erfüllen und nicht von externen Benutzern manipuliert werden können, um den Zugriff zu nutzen.\n\nSchritt 5:\n Eine Liste definierter Ports, die für die Anwendung erforderlich sind, sollte gepflegt und unter Änderungskontrolle gehalten werden.",
      "002": "Die Überprüfung und das Testen der Konfiguration ist eine kritische Aufgabe beim Erstellen und Verwalten einer Architektur. Dies liegt daran, dass viele verschiedene Systeme normalerweise mit generischen Konfigurationen bereitgestellt werden, die möglicherweise nicht für die Aufgabe geeignet sind, die sie an dem spezifischen Standort ausführen, an dem sie installiert sind.\n\n Während die typische Web- und Anwendungsserverinstallation viele Funktionen (wie Anwendungsbeispiele, Dokumentation, Testseiten) enthält, sollte das, was nicht unbedingt erforderlich ist, vor der Bereitstellung entfernt werden, um eine Ausnutzung nach der Installation zu vermeiden.\n\nCGI-Scanner enthalten eine detaillierte Liste bekannter Dateien und Verzeichnisbeispiele, die von verschiedenen Web- oder Anwendungsservern bereitgestellt werden.\nAußerdem enthalten Ereignisprotokolle oft Daten, die für einen Angreifer nützlich sind (Information Leakage) oder direkt in Exploits verwendet werden können.",
      "003": "Dateierweiterungen werden häufig in Webservern verwendet, um einfach zu bestimmen, welche Technologien, Sprachen und Plugins verwendet werden müssen, um die Webanforderung zu erfüllen.\nObwohl dieses Verhalten mit RFCs und Webstandards übereinstimmt, liefert die Verwendung von Standarddateierweiterungen dem Penetrationstester nützliche Informationen über die zugrunde liegenden Technologien, die in einer Web-Appliance verwendet werden.\n\n Die Feststellung, wie Webserver Anfragen verarbeiten, die Dateien mit unterschiedlichen Erweiterungen entsprechen, kann helfen, das Verhalten von Webservern in Abhängigkeit von der Art der Dateien, auf die zugegriffen wird, zu verstehen.\n\nDie folgenden Dateierweiterungen sollten niemals von einem Webserver zurückgegeben werden, da sie sich auf Dateien beziehen, die möglicherweise vertrauliche Informationen enthalten:\n • .asa \n• .inc\n\n Die folgenden Dateierweiterungen beziehen sich auf Dateien, die beim Zugriff entweder angezeigt oder vom Browser heruntergeladen werden.\n Daher müssen Dateien mit diesen Erweiterungen überprüft werden, um sicherzustellen, dass sie tatsächlich geliefert werden sollen:\n• .zip, .tar, .gz, .tgz, .rar, ...: (Komprimierte) Archivdateien\n• .java: Kein Grund, Zugriff auf Java-Quelldateien zu gewähren\n• .txt: Textdateien\n• .pdf: PDF-Dokumente\n• .doc, .rtf, .xls, .ppt, ...: Office-Dokumente\n• .bak, .old und andere Erweiterungen, die auf Sicherungsdateien hinweisen\n\n Um Dateien mit bestimmten Erweiterungen zu identifizieren, kann eine Mischung von Techniken eingesetzt werden.\nDiese Techniken können Vulnerability Scanners, Spidering- und Mirroring-Tools, die manuelle Überprüfung der Anwendung oder Abfragen von Suchmaschinen umfassen.",
      "004": "Eine wichtige Schwachstellenquelle sind Dateien, die nichts mit der Anwendung zu tun haben, aber als Folge der Bearbeitung von Anwendungsdateien oder nach dem Erstellen von Sicherungskopien im laufenden Betrieb oder durch das Belassen alter Dateien im Webbaum oder ohne Referenz erstellt wurden Dateien.\n\n Theoretisch sollte die Untersuchung von Hand durchgeführt werden, um gründlich zu sein. Da jedoch in den meisten Fällen Kopien von Dateien oder Backup-Dateien unter Verwendung der gleichen Namenskonventionen erstellt werden, kann die Suche einfach per Skript durchgeführt werden.",
      "005": "Administratorschnittstellen können in der Anwendung oder auf dem Anwendungsserver vorhanden sein, um bestimmten Benutzern zu ermöglichen, privilegierte Aktivitäten auf der Website durchzuführen. Es sollten Tests durchgeführt werden, um festzustellen, ob und wie diese privilegierte Funktionalität von einem nicht autorisierten oder normalen Benutzer abgerufen werden kann.\n\nEine Anwendung erfordert möglicherweise eine Administratorschnittstelle, um einem privilegierten Benutzer den Zugriff auf Funktionen zu ermöglichen, die Änderungen an der Funktionsweise der Site vornehmen können.\nSolche Änderungen können Folgendes umfassen:\n• Bereitstellung von Benutzerkonten\n• Website-Design und -Layout\n• Datenmanipulation\n• Konfigurationsänderungen\n\nIm Folgenden werden Vektoren beschrieben, die zum Testen auf das Vorhandensein von Verwaltungsschnittstellen verwendet werden können:\n• Verzeichnis- und Dateiaufzählung\n• Brute-Forcing-Tools wie THC-HYDRA\n• Kommentare und Links im Quellcode\n• Überprüfung der Server- und Anwendungsdokumentation\n• Öffentlich zugängliche Informationen (z. B. Standardpasswörter)\n• Alternativer Serverport\n• Manipulation von Parametern",
      "006": "Um diesen Test durchzuführen, muss der Tester irgendwie herausfinden, welche HTTP-Methoden werden vom untersuchten Webserver unterstützt. Die HTTP-Methode OPTIONS bietet dem Tester am meisten direkter und effektiver Weg, dies zu tun. RFC 2616 besagt: „Die OPTIONS-Methode stellt eine Anfrage nach Informationen über die verfügbaren Kommunikationsoptionen in der Anfrage-/Antwortkette dar, die durch den Request-URI identifiziert wird“.\n\n Einige der HTTP-Methoden können potenziell ein Sicherheitsrisiko für eine Webanwendung darstellen, da sie es einem Angreifer ermöglichen, die auf dem Webserver gespeicherten Dateien zu ändern und in einigen Szenarien die Anmeldeinformationen legitimer Benutzer zu stehlen. Genauer gesagt, die Methoden, die deaktiviert werden sollten, sind die folgenden:\n• PUT: Ermöglicht dem Client, Dateien auf den Webserver hochzuladen\n• DELETE: Allwas-Client zum Löschen von Dateien vom Webserver\n• CONNECT: ermöglicht dem Client, den Webserver als Proxy zu verwenden\n• TRACE: Gibt an den Client zurück, was er an den Server gesendet hat",
      "007": "Die HTTP Strict Transport Security (HSTS)-Funktion ermöglicht es einer Webanwendung, den Browser durch die Verwendung eines speziellen Antwortheaders darüber zu informieren, dass er niemals eine Verbindung zu den angegebenen Domänenservern über HTTP herstellen sollte.\n\n Der strenge HTTP-Transportsicherheitsheader verwendet zwei Anweisungen:\n• max-age\n• includeSubDomain\n\nDas Testen auf das Vorhandensein des HSTS-Headers kann durchgeführt werden, indem das Vorhandensein des HSTS-Headers in der Antwort des Servers in einem Interception-Proxy überprüft wird, oder indem curl verwendet wird.",
      "008": "Rich Internet Applications (RIA) haben die crossdomain.xml-Richtliniendateien von Adobe übernommen, um einen kontrollierten domänenübergreifenden Zugriff auf Daten und Dienstnutzung mit Technologien wie Oracle Java, Silverlight und Adobe Flash zu ermöglichen. Daher kann eine Domäne den Fernzugriff auf ihre Dienste von einer anderen Domäne aus gewähren.\nOft sind die Richtliniendateien, die die Zugriffsbeschränkungen beschreiben, jedoch schlecht konfiguriert. Eine schlechte Konfiguration der Richtliniendateien ermöglicht Cross-Site Request Forgery-Angriffe.\n\n Um die Schwäche der RIA-Richtliniendatei zu testen, sollte der Tester versuchen, die Richtliniendateien crossdomain.xml und clientaccesspolicy.xml aus dem Stammverzeichnis der Anwendung und aus jedem gefundenen Ordner abzurufen."
    },
    "ident": {
      "001": "Das Ziel besteht darin, die in der Anwendung definierten Systemrollen zu validieren, um jedes System und jede Geschäftsrolle ausreichend zu definieren und zu trennen, um den angemessenen Zugriff auf Systemfunktionen und -informationen zu verwalten.\n\n In modernen Unternehmen ist es üblich, Systemrollen zu definieren, um Benutzer und Berechtigungen für Systemressourcen zu verwalten.\nDenken Sie daran, dass die kalte, harte Autorisierung nicht die einzige Möglichkeit ist, den Zugriff auf Systemobjekte zu verwalten. In vertrauenswürdigeren Umgebungen, in denen die Vertraulichkeit nicht kritisch ist, können weichere Kontrollen wie Anwendungsworkflow und Audit-Protokollierung die Anforderungen an die Datenintegrität unterstützen, ohne den Benutzerzugriff auf Funktionen einzuschränken.\n\n Entwickeln Sie entweder mit oder ohne Hilfe der Systementwickler oder Administratoren eine Rollen-Berechtigungs-Matrix. Die Matrix sollte alle Rollen auflisten, die bereitgestellt werden können, und die zulässigen Berechtigungen untersuchen.",
      "002": "Einige Websites bieten einen Benutzerregistrierungsprozess an, der die Bereitstellung des Systemzugriffs für Benutzer automatisiert (oder halbautomatisiert). Die Identitätsanforderungen für den Zugriff variieren von positiver Identifizierung bis zu überhaupt keiner, abhängig von den Sicherheitsanforderungen des Systems.\n\n Schritt 1:\n Stellen Sie sicher, dass die Identitätsanforderungen für die Benutzerregistrierung mit den Geschäfts- und Sicherheitsanforderungen abgestimmt sind.\n\n Schritt 2:\n Bestätigen Sie den Registrierungsprozess.\n\n Stellen Sie sicher, dass die Identitätsanforderungen für die Benutzerregistrierung mit den Geschäfts- und Sicherheitsanforderungen abgestimmt sind:\n• Kann sich jeder für den Zugang registrieren?\n• Werden Registrierungen von einem Menschen überprüft?\n• Kann sich dieselbe Person oder Identität mehrmals registrieren?\n• Können sich Benutzer für verschiedene Rollen oder Berechtigungen registrieren?\n• Welcher Identitätsnachweis ist für eine Anmeldung erforderlich?\n• Werden registrierte Identitäten verifiziert?\n\n Bestätigen Sie den Registrierungsprozess:\n • Können Identitätsinformationen leicht gefälscht oder gefälscht werden?\n • Kann der Austausch von Identitätsinformationen manipuliert werden?",
      "003": "Überprüfen Sie, welche Konten andere Konten bereitstellen können und welchen Typs.\n\n Die Bereitstellung von Konten bietet einem Angreifer die Möglichkeit, ein gültiges Konto zu erstellen, ohne den ordnungsgemäßen Identifizierungs- und Autorisierungsprozess anzuwenden.\nBestimmen Sie, welche Rollen Benutzer bereitstellen können und welche Art von Konten sie bereitstellen können.",
      "004": "Der Zweck dieses Tests besteht darin, zu überprüfen, ob es möglich ist, eine Reihe gültiger Benutzernamen zu sammeln, indem mit dem Authentifizierungsmechanismus der Anwendung interagiert wird.\nDieser Test ist für Brute-Force-Tests nützlich, bei denen der Tester überprüft, ob es möglich ist, bei einem gültigen Benutzernamen das entsprechende Passwort zu finden.\n\nIn einigen Fällen wird eine Nachricht empfangen, die anzeigt, ob die bereitgestellten Anmeldeinformationen falsch sind, weil ein ungültiger Benutzername oder ein ungültiges Passwort verwendet wurde. Manchmal können Tester die vorhandenen Benutzer aufzählen, indem sie einen Benutzernamen und ein leeres Passwort senden.\n Wenn die Anwendung angreifbar ist, erhält der Tester eine Antwortnachricht, die direkt oder indirekt einige nützliche Informationen zum Aufzählen von Benutzern enthält.",
      "005": "Das Ziel besteht darin, festzustellen, ob eine konsistente Kontonamenstruktur die Anwendung anfällig für eine Kontoaufzählung macht. Stellen Sie fest, ob die Fehlermeldungen der Anwendung eine Kontoaufzählung zulassen.\n\n Benutzerkontonamen sind oft stark strukturiert (z. B. lautet der Kontoname von Joe Bloggs jbloggs und der Kontoname von Fred Nurks fnurks) und gültige Kontonamen können leicht erraten werden.\n • Bestimmen Sie die Struktur von Kontonamen.\n• Bewerten Sie die Antwort der Anwendung auf gültige und ungültige Kontonamen.\n• Verwenden Sie unterschiedliche Antworten auf gültige und ungültige Kontonamen, um gültige Kontonamen aufzuzählen.\n• Verwenden Sie Wörterbücher für Kontonamen, um gültige Kontonamen aufzuzählen.",
      "006": "Gast- und Schulungskonten sind nützliche Möglichkeiten, potenzielle Benutzer mit den Systemfunktionen vertraut zu machen, bevor sie den für den Zugriff erforderlichen Autorisierungsprozess abschließen. \n\n Bewerten Sie die Konsistenz zwischen Zugriffsrichtlinie und Zugriffsberechtigungen für Gast-/Schulungskonten.",
      "007": "Überprüfen Sie, ob die Identitätsanforderungen für die Benutzerregistrierung mit den Geschäfts-/Sicherheitsanforderungen übereinstimmen.\n\nBestätigen Sie den Registrierungsprozess."
    },
    "authn": {
      "001": "Die Analyse konzentriert sich einfach darauf, zu verstehen, ob die Daten unverschlüsselt vom Webbrowser zum Server übertragen werden oder ob die Webanwendung mithilfe eines Protokolls wie HTTPS die geeigneten Sicherheitsmaßnahmen ergreift.\n\n Das Testen auf den Transport von Anmeldeinformationen bedeutet, dass überprüft wird, ob die des Benutzers\nAuthentifizierungsdaten werden über einen verschlüsselten Kanal übertragen, um zu verhindern, dass sie von böswilligen Benutzern abgefangen werden.\n\n Sie können WebScarab oder einen beliebigen Web-Proxy verwenden, um Paket-Header zu erfassen und zu untersuchen.\n Überprüfen Sie, ob HTTPS in jeder sensiblen Anfrage verwendet wird, wie z. B. in Anmeldeseiten, um zu verhindern, dass unbefugte Benutzer die Daten abfangen.",
      "002": "Häufig sind Anwendungen nach der Installation nicht ordnungsgemäß konfiguriert, und die für die anfängliche Authentifizierung und Konfiguration bereitgestellten Standardanmeldeinformationen werden nie geändert.\n\n Wenn Sie eine Anwendungsschnittstelle identifiziert haben, beispielsweise eine Cisco-Router-Webschnittstelle oder ein Weblogic-Administratorportal, prüfen Sie, ob die bekannten Benutzernamen und Kennwörter für diese Geräte nicht zu einer erfolgreichen Authentifizierung führen. Dazu können Sie die Dokumentation des Herstellers konsultieren oder, viel einfacher, allgemeine Anmeldeinformationen mithilfe einer Suchmaschine oder einer der im Abschnitt „Referenz“ aufgeführten Websites oder Tools finden.\n\n Wenn wir mit Anwendungen konfrontiert werden, für die wir keine Liste mit Standard- und allgemeinen Benutzerkonten haben, können wir versuchen, gültige Standardanmeldeinformationen zu erraten.\n Viele Anwendungen haben ausführliche Fehlermeldungen, die die Site-Benutzer über die Gültigkeit der eingegebenen Benutzernamen informieren. Diese Informationen sind beim Testen auf standardmäßige oder erratbare Benutzerkonten hilfreich.\n\nDa diese Arten von Standardanmeldeinformationen häufig an Administratorkonten gebunden sind, können Sie zunächst die folgenden Benutzernamen ausprobieren: \n• admin \n• administrator \n• root \n• system \n• guest \n• operator \n• super",
      "003": "Kontosperrmechanismen werden verwendet, um Brute-Force-Angriffe zum Erraten von Passwörtern abzuschwächen. Konten werden in der Regel nach 3 bis 5 erfolglosen Anmeldeversuchen gesperrt und können erst nach einem festgelegten Zeitraum über einen Self-Service-Entsperrmechanismus oder den Eingriff eines Administrators entsperrt werden.\n\n Um die Stärke von Sperrmechanismen zu testen, benötigen Sie in der Regel Zugriff auf ein Konto, das Sie sperren möchten oder sich leisten können:\n\n Schritt 1:\n Bewerten Sie die Fähigkeit des Kontosperrmechanismus, das Erraten von Brute-Force-Passwörtern zu mindern.\n\n Schritt 2:\nBewerten Sie die Widerstandsfähigkeit des Entsperrmechanismus gegen das unbefugte Entsperren von Konten.\n\n Ohne einen starken Sperrmechanismus ist die Anwendung möglicherweise anfällig für Brute-Force-Angriffe. Nach einem erfolgreichen Brute-Force-Angriff könnte ein böswilliger Benutzer Zugriff auf Folgendes haben:\n• Vertrauliche Informationen oder Daten\n• Administratoroberflächen\n• Möglichkeiten für weitere Angriffe",
      "004": "Während die meisten Anwendungen eine Authentifizierung erfordern, um Zugriff auf private Informationen zu erhalten oder Aufgaben auszuführen, ist nicht jede Authentifizierungsmethode in der Lage, angemessene Sicherheit zu bieten.\n\n Es gibt mehrere Methoden zum Umgehen des Authentifizierungsschemas, das von einer Webanwendung verwendet wird:\n• Direkter Seitenaufruf (Forced Browsing)\n• Parameteränderung\n• Session-ID-Vorhersage\n• SQL-Injektion",
      "005": "Browser fragen einen Benutzer manchmal, ob er sich das soeben eingegebene Passwort merken möchte.\n\n Das Speichern von Passwörtern im Browser ist nicht nur für Endbenutzer, sondern auch für Angreifer praktisch. Wenn ein Angreifer Zugriff auf den Browser des Opfers erlangen kann (z. B. XSS-Angriff), kann er die gespeicherten Passwörter abrufen.\n Wenn benutzerdefinierte „Remember Me“-Funktionen eingerichtet werden, können außerdem Schwachstellen bei der Speicherung des Tokens auf dem Client-PC die Passwörter der Benutzer offenlegen.\n\n Stellen Sie sicher, dass keine Zugangsdaten im Klartext gespeichert oder in verschlüsselter oder verschlüsselter Form in Cookies leicht abrufbar sind:\n• Suchen Sie nach Passwörtern, die in Cookies gespeichert sind\n• Untersuchen Sie den Hashing-Mechanismus\n• Stellen Sie sicher, dass Anmeldeinformationen nur während der Anmeldung gesendet werden\n• Berücksichtigen Sie sensible Formularfelder",
      "006": "Browser können Informationen für Caching- und Verlaufszwecke speichern. Caching dient der Leistungssteigerung, sodass zuvor angezeigte Informationen nicht erneut heruntergeladen werden müssen.\n Wenn dem Benutzer sensible Informationen angezeigt werden, können diese Informationen zu Cache- oder Verlaufszwecken gespeichert und daher durch Überprüfen des Cache des Browsers oder durch einfaches Drücken der Schaltfläche „Zurück“ des Browsers abgerufen werden.\n\n Technisch gesehen ist die Schaltfläche „Zurück“ ein Verlauf und kein Cache. Der Cache und der Verlauf sind zwei verschiedene Entitäten. Sie teilen jedoch die gleiche Schwäche, zuvor angezeigte sensible Informationen zu präsentieren.\n\nDie Schaltfläche „Zurück“ kann daran gehindert werden, sensible Daten anzuzeigen.\nDies kann erfolgen durch:\n• Bereitstellung der Seite über HTTPS.\n• Einstellung Cache-Control: must-re-validate",
      "007": "Der am weitesten verbreitete und am einfachsten zu verwaltende Authentifizierungsmechanismus ist ein statisches Passwort. Es wird bedauert, dass die gängigsten Passwörter immer noch sind: 123456, Passwort und qwerty.\n\nBestimmen Sie den Widerstand der Anwendung gegen Brute-Force-Passworterraten mithilfe verfügbarer Passwortwörterbücher, indem Sie die Anforderungen an Länge, Komplexität, Wiederverwendung und Alterung von Passwörtern bewerten.\n\n Schritt 1:\n Welche Zeichen sind in einem Passwort erlaubt und welche verboten?\nMuss der Benutzer Zeichen aus unterschiedlichen Zeichensätzen wie Klein- und Großbuchstaben, Ziffern und Sonderzeichen verwenden?\n\n Schritt 2:\n Wie oft kann ein Benutzer sein Passwort ändern?\nWie schnell kann ein Benutzer sein Passwort nach einer vorherigen Änderung ändern?\n Benutzer können die Anforderungen des Passwortverlaufs umgehen, indem sie ihr Passwort fünfmal hintereinander ändern.\n\n Schritt 3:\n Wann muss ein Benutzer sein Passwort ändern?\nNach 90 Tagen?\nNach Kontosperrung wegen übermäßiger Anmeldeversuche?\n\n Schritt 4:\n Wie oft kann ein Benutzer ein Passwort wiederverwenden?\n Verwaltet die Anwendung einen Verlauf der zuvor verwendeten 8 Passwörter des Benutzers?\n\n Schritt 5:\n Wie unterschiedlich muss das nächste Passwort vom letzten Passwort sein?\n\n Schritt 6:\nWird der Benutzer daran gehindert, seinen Benutzernamen oder andere Kontoinformationen (z. B. Vor- oder Nachname) im Passwort zu verwenden?",
      "008": "Oft als „geheime“ Fragen und Antworten bezeichnet, werden Sicherheitsfragen und -antworten oft verwendet, um vergessene Passwörter wiederherzustellen, oder als zusätzliche Sicherheit zusätzlich zum Passwort.\n\n Sie werden normalerweise bei der Kontoerstellung generiert und erfordern, dass der Benutzer aus einigen vorgenerierten Fragen eine Auswahl trifft und eine entsprechende Antwort liefert. Sie können dem Benutzer ermöglichen, seine eigenen Frage-Antwort-Paare zu generieren.\n Beide Methoden sind anfällig für Unsicherheiten. Im Idealfall sollten Sicherheitsfragen Antworten generieren, die nur dem Benutzer bekannt und nicht erratbar oder auffindbar sind.\n\n Der Schlüssel zum erfolgreichen Ausnutzen und Umgehen eines schwachen Sicherheitsfrageschemas besteht darin, eine Frage oder eine Reihe von Fragen zu finden, die die Möglichkeit bieten, die Antworten leicht zu finden. \n\n Schritt 1:\nVersuchen Sie, eine Liste mit Sicherheitsfragen zu erhalten, indem Sie ein neues Konto erstellen oder dem „Ich erinnere mich nicht an mein Passwort“-Prozess folgen.\n\n Schritt 2:\n Versuchen Sie, Sicherheitsfragen zu erstellen, indem Sie ein neues Konto erstellen oder die Kennwortwiederherstellungseigenschaften Ihres vorhandenen Kontos konfigurieren.\nWenn das System dem Benutzer erlaubt, seine eigenen Sicherheitsfragen zu generieren, ist es anfällig dafür, dass unsichere Fragen erstellt werden.\n\n Schritt 3:\n Stellen Sie fest, ob eine Reihe falsch eingegebener Sicherheitsantworten einen Sperrmechanismus auslösen.",
      "009": "Die Funktion zum Ändern und Zurücksetzen von Kennwörtern einer Anwendung ist ein Self-Service-Mechanismus zum Ändern oder Zurücksetzen von Kennwörtern für Benutzer.\n Dieser Self-Service-Mechanismus ermöglicht es Benutzern, ihr Passwort schnell zu ändern oder zurückzusetzen, ohne dass ein Administrator eingreifen muss.\n\n Schritt 1:\n Bestimmen Sie den Widerstand der Anwendung gegen die Subversion des Kontoänderungsprozesses, der es jemandem ermöglicht, das Kennwort eines Kontos zu ändern.\n\n Schritt 2:\nBestimmen Sie die Widerstandsfähigkeit der Funktion zum Zurücksetzen von Passwörtern gegen Erraten oder Umgehen.\n\n Sowohl für die Passwortänderung als auch für das Zurücksetzen des Passworts ist es wichtig, dies zu überprüfen.\n\n.. wenn andere Benutzer als Administratoren Kennwörter für andere Konten als ihre eigenen ändern oder zurücksetzen können.\n.. wenn Benutzer den Prozess zum Ändern oder Zurücksetzen von Passwörtern manipulieren oder untergraben können.\n.. wenn der Prozess zum Ändern oder Zurücksetzen des Passworts anfällig für CSRF ist.",
      "010": "Auch wenn die primären Authentifizierungsmechanismen keine Schwachstellen enthalten, kann es sein, dass Schwachstellen in alternativen legitimen Benutzerkanälen für die Authentifizierung für dieselben Benutzerkonten vorhanden sind.\n\n Es sollten Tests durchgeführt werden, um alternative Kanäle zu identifizieren und, vorbehaltlich des Testumfangs, Schwachstellen zu identifizieren.\n Einige dieser Kanäle können selbst separate Webanwendungen sein, die unterschiedliche Hostnamen oder Pfade verwenden. Zum Beispiel:\n• Standard-Website\n• Mobile Website\n• Zugänglichkeitsoptimierte Website\n• Parallele Websites, die dieselben Benutzerkonten verwenden\n• Entwicklung, UAT und Versionen der Standard-Website\n\n Es könnten aber auch andere Arten von Anwendungen oder Geschäftsprozessen sein:\n• App für mobile Geräte\n• Desktopanwendung\n• Call-Center-Betreiber\n• Interaktive Sprachantwort oder Telefonbaumsysteme"
    },
    "authz": {
      "001": "Viele Webanwendungen verwenden und verwalten Dateien im Rahmen ihres täglichen Betriebs. Durch die Verwendung von Eingabevalidierungsmethoden, die nicht gut entwickelt oder eingesetzt wurden, könnte ein Angreifer das System ausnutzen, um Dateien zu lesen oder zu schreiben, auf die nicht zugegriffen werden soll. In bestimmten Situationen kann es möglich sein, beliebigen Code oder Systembefehle auszuführen.\n\n Bei Webservern und Webanwendungen tritt diese Art von Problem bei Path Traversal/File Include-Angriffen auf. Während einer Bewertung müssen Tester zwei verschiedene Phasen durchführen, um Path Traversal und File Include-Fehler zu entdecken:\n\n Stufe 1:\n Input Vectors Enumeration (eine systematische Auswertung jedes Input-Vektors)\n\n Stufe 2:\n Testtechniken (eine methodische Bewertung jeder Angriffstechnik, die von einem Angreifer verwendet wird, um die Schwachstelle auszunutzen)\n\n Die nächste Testphase besteht in der Analyse der in der Webanwendung vorhandenen Eingabevalidierungsfunktionen. Unter Verwendung des vorherigen Beispiels lädt die dynamische Seite namens getUserProfile.jsp statische Informationen aus einer Datei und zeigt Benutzern den Inhalt an. Ein Angreifer könnte die böswillige Zeichenfolge „../../../../etc/passwd“ einfügen, um die Passwort-Hash-Datei einzufügen.\n Es ist ein häufiger Fehler von Entwicklern, nicht jede Form der Codierung zu erwarten und daher nur grundlegende codierte Inhalte zu validieren. Wenn die Testzeichenfolge zunächst nicht erfolgreich ist, versuchen Sie es mit einem anderen Codierungsschema.",
      "002": "Diese Art von Test konzentriert sich darauf, zu überprüfen, wie das Autorisierungsschema für jede Rolle oder jedes Privileg implementiert wurde, um Zugriff auf reservierte Funktionen und Ressourcen zu erhalten.\n\nFür jede spezifische Rolle, die der Tester während der Bewertung innehat, für jede Funktion und Anforderung, die die Anwendung während der Phase nach der Authentifizierung ausführt, muss Folgendes überprüft werden:\n • Ist es möglich, auf diese Ressource zuzugreifen, selbst wenn der Benutzer nicht authentifiziert ist?\n • Kann nach dem Abmelden auf diese Ressource zugegriffen werden?\n • Ist es möglich, auf Funktionen und Ressourcen zuzugreifen, die einem Benutzer mit einer anderen Rolle oder Berechtigung zugänglich sein sollten?\n\n Versuchen Sie, als Administrator auf die Anwendung zuzugreifen, und verfolgen Sie alle Verwaltungsfunktionen:\n • Ist der Zugriff auf Verwaltungsfunktionen auch dann möglich, wenn der Tester als Benutzer mit Standardrechten angemeldet ist?\n• Ist es möglich, diese Verwaltungsfunktionen als Benutzer mit einer anderen Rolle zu verwenden, und wem sollte diese Aktion verweigert werden?",
      "003": "Eine Rechteausweitung tritt auf, wenn ein Benutzer Zugriff auf mehr Ressourcen oder Funktionen erhält, als ihm normalerweise gestattet sind.\n\n Während dieser Phase sollte der Tester sicherstellen, dass es einem Benutzer nicht möglich ist, seine Berechtigungen oder Rollen innerhalb der Anwendung auf eine Weise zu ändern, die Angriffe zur Rechteausweitung ermöglichen könnte.\n Der Grad der Eskalation hängt davon ab, welche Privilegien der Angreifer besitzen darf und welche Privilegien bei einem erfolgreichen Exploit erworben werden können.\n\n In jedem Teil der Anwendung, in dem ein Benutzer Informationen in der Datenbank erstellen (z. B. eine Zahlung vornehmen oder eine Nachricht senden), Informationen empfangen (Kontoauszug, Bestelldetails usw.) oder Informationen löschen (Benutzer löschen, Nachrichten usw.), ist es notwendig, diese Funktionalität aufzuzeichnen.\n Versuchen Sie, als anderer Benutzer auf solche Funktionen zuzugreifen, um zu überprüfen, ob es möglich ist, auf eine Funktion zuzugreifen, die aufgrund der Rolle/Berechtigung des Benutzers nicht zulässig sein sollte.",
      "004": "Unsichere direkte Objektverweise treten auf, wenn eine Anwendung basierend auf Benutzereingaben direkten Zugriff auf Objekte bereitstellt.\n Durch diese Schwachstelle können Angreifer die Autorisierung umgehen und direkt auf Ressourcen im System zugreifen, beispielsweise Datenbankeinträge oder Dateien.\n\n Unsichere direkte Objektreferenzen ermöglichen es Angreifern, die Autorisierung zu umgehen und direkt auf Ressourcen zuzugreifen, indem sie den Wert eines Parameters ändern, der verwendet wird, um direkt auf ein Objekt zu verweisen.\n\n Um diese Schwachstelle zu testen, muss der Tester zunächst alle Stellen in der Anwendung abbilden, an denen Benutzereingaben verwendet werden, um direkt auf Objekte zu verweisen.\n Der beste Weg, um auf direkte Objektreferenzen zu testen, wäre, mindestens zwei (häufig mehr) Benutzer zu haben, um verschiedene Objekte und Funktionen im Besitz abzudecken.\n Indem er mehrere Benutzer hat, spart der Tester wertvolle Testzeit beim Erraten unterschiedlicher Objektnamen, da er versuchen kann, auf Objekte zuzugreifen, die dem anderen Benutzer gehören."
    },
    "sess": {
      "001": "Um eine kontinuierliche Authentifizierung für jede Seite einer Website oder eines Dienstes zu vermeiden, implementieren Webanwendungen verschiedene Mechanismen, um Anmeldeinformationen für einen festgelegten Zeitraum zu speichern und zu validieren.\n Diese Mechanismen werden als Sitzungsverwaltung bezeichnet.\n\n In diesem Test möchte der Tester überprüfen, ob Cookies und andere Sitzungstoken auf sichere und unvorhersehbare Weise erstellt werden. Ein Angreifer, der in der Lage ist, ein schwaches Cookie vorherzusagen und zu fälschen, kann leicht die Sitzungen legitimer Benutzer kapern.\n Aufgrund der Bedeutung der von ihnen gespeicherten Daten sind Cookies daher für die Gesamtsicherheit der Anwendung von entscheidender Bedeutung. Bei diesem Test muss der Tester überprüfen, ob die an Clients ausgegebenen Cookies einer Vielzahl von Angriffen widerstehen können, die darauf abzielen, die Sitzungen legitimer Benutzer und die Anwendung selbst zu stören.\n\n Normalerweise sind die Hauptschritte des Angriffsmusters die folgenden:\n• Cookie-Sammlung\n• Cookie-Reverse-Engineering\n• Cookie-Manipulation\n\n Ein weiteres Angriffsmuster besteht darin, einen Cookie zum Überlaufen zu bringen. Genau genommen hat dieser Angriff einen anderen Charakter, da Tester hier nicht versuchen, ein vollkommen gültiges Cookie nachzubilden. Stattdessen besteht das Ziel darin, einen Speicherbereich zum Überlaufen zu bringen und dadurch das korrekte Verhalten der Anwendung zu stören.",
      "002": "Cookies sind oft ein wichtiger Angriffsvektor für böswillige Benutzer, und die Anwendung sollte immer die gebotene Sorgfalt walten lassen, um Cookies zu schützen. In diesem Abschnitt wird erläutert, wie eine Anwendung beim Zuweisen von Cookies die erforderlichen Vorkehrungen treffen und testen kann, ob diese Attribute korrekt konfiguriert wurden.\n\n Aufgrund der sensiblen Natur von Informationen in Cookies werden diese typischerweise kodiert oder verschlüsselt, um die darin enthaltenen Informationen zu schützen.\n Sobald der Tester verstanden hat, wie Cookies gesetzt werden, wann sie gesetzt werden, wofür sie verwendet werden, warum sie verwendet werden und welche Bedeutung sie haben, sollten sie sich ansehen, welche Attribute für ein Cookie gesetzt werden können und wie sie getestet werden wenn sie sicher sind.\n\nDurch die Verwendung eines abfangenden Proxys oder eines Browser-Plug-ins zum Abfangen von Datenverkehr fangen Sie alle Antworten ab, bei denen ein Cookie von der Anwendung gesetzt wird (unter Verwendung der Set-cookie-Anweisung), und untersuchen Sie das Cookie auf Folgendes:\n• Secure-Attribut\n• HttpOnly-Attribut\n• Domain-Attribut\n• Path-Attribut\n• Expires-Attribut",
      "003": "Wenn eine Anwendung ihre Sitzungscookies nach einer erfolgreichen Benutzerauthentifizierung nicht erneuert, könnte es möglich sein, eine Schwachstelle bei der Sitzungsfixierung zu finden und einen Benutzer zu zwingen, ein dem Angreifer bekanntes Cookie zu verwenden. In diesem Fall könnte ein Angreifer die Benutzersitzung stehlen (Session-Hijacking).\n\n Sicherheitslücken bei der Sitzungsfixierung treten auf, wenn..\n ... eine Webanwendung einen Benutzer authentifiziert, ohne zuerst die vorhandene Sitzungs-ID ungültig zu machen, wodurch die bereits mit dem Benutzer verknüpfte Sitzungs-ID weiterhin verwendet wird\n.. ein Angreifer in der Lage ist, einem Benutzer eine bekannte Sitzungs-ID aufzuzwingen, sodass der Angreifer nach der Authentifizierung des Benutzers Zugriff auf die authentifizierte Sitzung hat.\n\n Beim generischen Exploit von Sicherheitslücken zur Sitzungsfixierung erstellt ein Angreifer eine neue Sitzung in einer Webanwendung und zeichnet die zugehörige Sitzungskennung auf. Der Angreifer veranlasst dann das Opfer, sich mit derselben Sitzungskennung beim Server zu authentifizieren, wodurch der Angreifer während der aktiven Sitzung Zugriff auf das Konto des Benutzers erhält.",
      "004": "Die Sitzungstoken (Cookie, Sitzungs-ID, verborgenes Feld) ermöglichen es einem Angreifer normalerweise, sich als Opfer auszugeben und unrechtmäßig auf die Anwendung zuzugreifen, wenn sie offengelegt werden. Es ist wichtig, dass sie jederzeit vor Abhören geschützt sind, insbesondere während der Übertragung zwischen dem Client-Browser und den Anwendungsservern.\n\n Über einen persönlichen Proxy kann zu jeder Anfrage und Antwort Folgendes festgestellt werden:\n • Verwendetes Protokoll (z. B. HTTP vs. HTTPS)\n • HTTP-Header\n • Nachrichtentext (z. B. POST oder Seiteninhalt)\n\n Schutz vor Lauschangriffen wird oft durch SSL-Verschlüsselung bereitgestellt, kann aber auch andere Tunnel oder Verschlüsselung beinhalten. Wenn die Sitzungs-ID von einem Angreifer der Anwendung präsentiert werden könnte, um sich Zugriff zu verschaffen, muss sie während der Übertragung geschützt werden, um dieses Risiko zu mindern. Daher sollte sichergestellt werden, dass die Verschlüsselung für alle Anfragen oder Antworten, bei denen die Sitzungs-ID übergeben wird, sowohl standardmäßig als auch durchgesetzt wird, unabhängig vom verwendeten Mechanismus.\n\n Jedes Mal, wenn die Authentifizierung erfolgreich ist, sollte der Benutzer Folgendes erwarten:\n• Ein anderes Sitzungstoken\n• Ein Token, das für jede HTTP-Anforderung über einen verschlüsselten Kanal gesendet wird",
      "005": "CSRF ist ein Angriff, der einen Endbenutzer dazu zwingt, unerwünschte Aktionen auf einer Webanwendung auszuführen, in der er/sie gerade authentifiziert ist.\nEin erfolgreicher CSRF-Exploit kann die Daten und den Betrieb von Endbenutzern gefährden, wenn er auf einen normalen Benutzer abzielt. Wenn der Zielbenutzer das Administratorkonto ist, kann ein CSRF-Angriff die gesamte Webanwendung gefährden.\n CSRF stützt sich auf Folgendes:\n\n Punkt 1:\n Verhalten des Webbrowsers in Bezug auf den Umgang mit sitzungsbezogenen Informationen wie Cookies und HTTP-Authentifizierungsinformationen;\n\n Punkt 2:\n Kenntnis des Angreifers von gültigen Webanwendungs-URLs;\n\n Punkt 3:\n Anwendungssitzungsverwaltung, die sich nur auf Informationen stützt, die dem Browser bekannt sind;\n\n Punkt 4:\n Vorhandensein von HTML-Tags, deren Vorhandensein einen sofortigen Zugriff auf eine http[s]-Ressource bewirkt; zum Beispiel das Image-Tag img\n\n Der Tester muss URLs im eingeschränkten (authentifizierten) Bereich kennen. Wenn sie über gültige Anmeldeinformationen verfügen, können sie beide Rollen einnehmen – Angreifer und Opfer. In diesem Fall kennen Tester die zu testenden URLs, indem sie sich einfach umsehen.\n\n  Wenn sich die Sitzungsverwaltung nur auf clientseitige Werte stützt (Informationen, die dem Browser zur Verfügung stehen), ist die Anwendung anfällig.\n Damit eine Anwendung nicht anfällig ist, muss sie sitzungsbezogene Informationen in der URL enthalten, und zwar in einer Form, die für den Benutzer nicht identifizierbar oder unvorhersehbar ist.",
      "006": "Die Sitzungsbeendigung ist ein wichtiger Teil des Sitzungslebenszyklus. Das Verkürzen der Lebensdauer der Sitzungstoken auf ein Minimum verringert die Wahrscheinlichkeit eines erfolgreichen Sitzungs-Hijacking-Angriffs. Dies kann als Kontrolle gegen andere Angriffe wie Cross Site Scripting und Cross Site Request Forgery angesehen werden. Es ist bekannt, dass solche Angriffe darauf beruhen, dass ein Benutzer eine authentifizierte Sitzung hat.\n\n Eine sichere Sitzungsbeendigung erfordert mindestens die folgenden Komponenten:\n • Verfügbarkeit von Steuerelementen der Benutzeroberfläche, mit denen sich der Benutzer manuell abmelden kann\n • Sitzungsbeendigung nach einer bestimmten Zeit ohne Aktivität (Session-Timeout)\n • Ordnungsgemäße Invalidierung des serverseitigen Sitzungsstatus\n\n Der richtige Wert für das Sitzungs-Timeout hängt vom Zweck der Anwendung ab und sollte ein Gleichgewicht zwischen Sicherheit und Benutzerfreundlichkeit darstellen.",
      "007": "In dieser Phase überprüfen Tester, ob die Anwendung einen Benutzer automatisch abmeldet, wenn dieser Benutzer eine bestimmte Zeit lang inaktiv war, um sicherzustellen, dass dieselbe Sitzung nicht „wiederverwendet“ werden kann und dass keine sensiblen Daten im Browser-Cache gespeichert bleiben .\n\n Das Leerlaufzeitlimit schränkt die Wahrscheinlichkeit ein, dass ein Angreifer eine gültige Sitzungs-ID eines anderen Benutzers erraten und verwenden muss, und könnte unter bestimmten Umständen öffentliche Computer vor der Wiederverwendung von Sitzungen schützen. Verwaltung und Ablauf von Sitzungszeitüberschreitungen müssen serverseitig erzwungen werden. Wenn einige Daten unter der Kontrolle des Clients verwendet werden, um das Sitzungs-Timeout zu erzwingen, könnte ein Angreifer diese manipulieren, um die Sitzungsdauer zu verlängern.\n\n Schritt 1:\nTester müssen prüfen, ob ein Timeout vorliegt, indem sie sich beispielsweise anmelden und auf das Auslösen des Timeout-Logouts warten. Wie bei der Abmeldefunktion sollten nach Ablauf des Timeouts alle Sitzungstoken zerstört oder unbrauchbar sein.\n\n Schritt 2:\n Wenn das Timeout konfiguriert ist, müssen Tester verstehen, ob das Timeout vom Client oder vom Server erzwungen wird.\n\n Generell sollte serverseitig alles überprüft werden und es sollte nicht möglich sein, durch Zurücksetzen der Session-Cookies auf vorherige Werte wieder auf die Anwendung zuzugreifen.",
      "008": "Das Überladen von Sitzungsvariablen (Session Puzzling) ist eine Schwachstelle auf Anwendungsebene, die es einem Angreifer ermöglichen kann, eine Vielzahl von böswilligen Aktionen auszuführen, einschließlich, aber nicht beschränkt auf ...\n.. effiziente Mechanismen zur Durchsetzung der Authentifizierung umgehen und sich als legitime Benutzer ausgeben.\n.. erhöhen der Rechte eines böswilligen Benutzerkontos in einer Umgebung, die ansonsten als narrensicher gelten würde.\n.. Qualifizierungsphasen in mehrphasigen Prozessen überspringen, selbst wenn der Prozess Einschränkungen auf Codeebene enthält.\n.. serverseitige Werte mit indirekten Methoden manipulieren, die nicht vorhergesagt oder erkannt werden können.\n.. herkömmliche Angriffe an Orten ausführen, die zuvor unerreichbar waren oder sogar als sicher galten.\n\n Diese Schwachstelle tritt auf, wenn eine Anwendung dieselbe Sitzungsvariable für mehr als einen Zweck verwendet. Es kann erkannt und ausgenutzt werden, indem alle Sitzungsvariablen, die von der Anwendung verwendet werden, und in welchem \u200B\u200BKontext sie gültig sind, aufgelistet werden. Dies ist insbesondere möglich, indem auf eine Folge von Einstiegspunkten zugegriffen und dann Ausstiegspunkte untersucht werden."
    },
    "inpval": {
      "001": "Reflected Cross-Site Scripting (XSS) tritt auf, wenn ein Angreifer ausführbaren Browsercode in eine einzelne HTTP-Antwort einfügt.\nDer eingeschleuste Angriff wird nicht in der Anwendung selbst gespeichert; Es ist nicht dauerhaft und wirkt sich nur auf Benutzer aus, die einen in böser Absicht erstellten Link oder eine Webseite eines Drittanbieters öffnen.\nDie Angriffszeichenfolge ist Teil der präparierten URI- oder HTTP-Parameter, wird von der Anwendung nicht ordnungsgemäß verarbeitet und an das Opfer zurückgegeben. Eine der Hauptschwierigkeiten beim Verhindern von XSS-Schwachstellen ist die richtige Zeichencodierung.\n In einigen Fällen filtert der Webserver oder die Webanwendung möglicherweise einige Zeichencodierungen nicht, sodass die Webanwendung beispielsweise „<script>“ herausfiltert, aber nicht %3cscript%3e filtert, das einfach eine andere Codierung enthält von Tags. Ein Test umfasst mindestens drei Phasen:\n\n Phase 1:\nEingabevektoren erkennen. Für jede Webseite muss der Tester alle benutzerdefinierten Variablen der Webanwendung und deren Eingabe bestimmen. Dazu gehören versteckte oder nicht offensichtliche Eingaben wie HTTP-Parameter, POST-Daten, versteckte Formularfeldwerte und vordefinierte Radio- oder Auswahlwerte. In der Regel werden HTML-Editoren im Browser oder Web-Proxys verwendet, um diese versteckten Variablen anzuzeigen.\n\n Phase 2:\n Analysieren Sie jeden Eingabevektor, um potenzielle Schwachstellen zu erkennen. dUm eine XSS-Schwachstelle zu erkennen, verwendet der Tester normalerweise speziell gestaltete Eingabedaten mit jedem Eingabevektor. Solche Eingabedaten sind in der Regel harmlos, lösen jedoch Reaktionen des Webbrowsers aus, der die Schwachstelle manifestiert. Testdaten können mithilfe eines Webanwendungs-Fuzzers, einer automatisierten vordefinierten Liste bekannter Angriffszeichenfolgen oder manuell generiert werden.\n\n Phase 3:\n Für jede Testeingabe, die in der vorherigen Phase versucht wurde, analysiert der Tester das Ergebnis und bestimmt, ob es sich um eine Schwachstelle handelt, die realistische Auswirkungen auf die Sicherheit der Webanwendung hat. Dazu muss der HTML-Code der resultierenden Webseite untersucht und nach der Testeingabe gesucht werden. Einmal gefunden, identifiziert der Tester alle Sonderzeichen, die nicht richtig codiert, ersetzt oder herausgefiltert wurden.",
      "002": "Stored Cross Site Scripting (XSS) ist die gefährlichste Art von Cross Site Scripting.\n\n Gespeichertes XSS tritt auf, wenn eine Webanwendung Eingaben von einem Benutzer sammelt, die möglicherweise böswillig sind, und diese Eingaben dann zur späteren Verwendung in einem Datenspeicher speichert. Die gespeicherte Eingabe wird nicht korrekt gefiltert. Infolgedessen scheinen die schädlichen Daten Teil der Website zu sein und werden im Browser des Benutzers unter den Rechten der Webanwendung ausgeführt.\n\n Eine erfolgreiche Ausnutzung liegt vor, wenn ein Benutzer eine Seite mit einem gespeicherten XSS besucht.\nDie folgenden Phasen beziehen sich auf ein typisches Szenario eines gespeicherten XSS-Angriffs:\n • Der Angreifer speichert schädlichen Code auf der anfälligen Seite\n • Der Benutzer authentifiziert sich in der Anwendung\n • Benutzer besucht anfällige Seite\n • Schädlicher Code wird vom Browser des Benutzers ausgeführt\n\n Diese Schwachstelle kann verwendet werden, um eine Reihe von browserbasierten Angriffen durchzuführen, darunter:\n • Hijacking des Browsers eines anderen Benutzers\n • Erfassen vertraulicher Informationen, die von Benutzern angezeigt werden\n • Pseudo-Verunstaltung der Anwendung\n • Port-Scanning interner Hosts\n • Gezielte Bereitstellung browserbasierter Exploits\n • Andere böswillige Aktivitäten",
      "003": "Die HTTP-Spezifikation enthält andere Anforderungsmethoden als die standardmäßigen GET- und POST-Anforderungen. Ein standardkonformer Webserver kann auf diese alternativen Methoden auf eine Weise reagieren, die von Entwicklern nicht erwartet wurde.\n\n Da der HTML-Standard keine anderen Anfragemethoden als GET oder POST unterstützt, müssen wir benutzerdefinierte HTTP-Anfragen erstellen, um die anderen Methoden zu testen.\n\n Die vollständige HTTP 1.1-Spezifikation definiert die folgenden gültigen HTTP-Anforderungsmethoden oder Verben: \n • OPTIONS \n • GET \n • HEAD \n • POST \n • PUT \n • DELETE \n • TRACE \n • CONNECT \n\n Wenn diese Option aktiviert ist, lassen die Erweiterungen Web Distributed Authoring and Version (WebDAV) mehrere weitere HTTP-Methoden zu: \n • PROPFIND \n • PROPPATCH \n • MKCOL \n • COPY \n • MOVE \n • LOCK \n • UNLOCK",
      "004": "Das Bereitstellen mehrerer HTTP-Parameter mit demselben Namen kann dazu führen, dass eine Anwendung Werte auf unerwartete Weise interpretiert. Durch Ausnutzen dieser Effekte kann ein Angreifer möglicherweise die Eingabevalidierung umgehen, Anwendungsfehler auslösen oder interne Variablenwerte ändern. Da HTTP Parameter Pollution (kurz HPP) einen Baustein aller Webtechnologien betrifft, existieren server- und clientseitige Angriffe.\n\n Da die Zuweisung von HTTP-Parametern in der Regel über den Webanwendungsserver und nicht über den Anwendungscode selbst erfolgt, sollte das Testen der Reaktion auf Parameterverschmutzung zum Glück Standard für alle Seiten und Aktionen sein.\n Da jedoch fundierte Kenntnisse der Geschäftslogik erforderlich sind, erfordert das Testen von HPP manuelles Testen.\n Automatische Tools können Prüfer nur teilweise unterstützen, da sie dazu neigen, zu viele Fehlalarme zu generieren. Darüber hinaus kann sich HPP in clientseitigen und serverseitigen Komponenten manifestieren.",
      "005": "SQL-Injection-Angriffe sind eine Art von Injection-Angriffen, bei denen SQL-Befehle in Eingaben auf Datenebene eingeschleust werden, um die Ausführung vordefinierter SQL-Befehle zu beeinflussen.\n\n Der Tester kann präparierte Eingaben liefern, die versuchen, die ursprüngliche SQL-Anweisung dazu zu bringen, weitere Aktionen nach Wahl des Testers auszuführen. \n Beispielsweise könnte der Tester eine Anweisung in „$password = 1“ oder „1“ = „1“ ändern, die Logik der SQL-Anweisung ändern und die WHERE-Klausel ändern, indem er eine Bedingung hinzufügt „oder „1“ = „1“.\n\n SQL-Injection-Angriffe können in die folgenden drei Klassen eingeteilt werden: \n • Inband \n • Out-of-band \n • Inferential or Blind \n\n Bei den Techniken zum Ausnutzen von SQL-Injection-Fehlern gibt es fünf gängige Techniken. Diese Techniken können manchmal auch kombiniert verwendet werden:\n • Union Operator \n • Boolean \n • Error based \n • Out-of-band \n • Time delay",
      "005_1": "Webbasierte PL/SQL-Anwendungen werden durch das PL/SQL-Gateway ermöglicht, das die Komponente ist, die Webanforderungen in Datenbankabfragen übersetzt. Oracle hat eine Reihe von Softwareimplementierungen entwickelt.\n Zu den Produkten, die das PL/SQL-Gateway verwenden, gehören unter anderem Oracle HTTP Server, eBusiness Suite, Portal, HTMLDB, WebDB und Oracle Application Server.\n\n Im Wesentlichen fungiert das PL/SQL-Gateway einfach als Proxy-Server, der die Webanfrage des Benutzers entgegennimmt und an den Datenbankserver weiterleitet, wo sie ausgeführt wird.\n\n Schritt 1:\n Der Webserver akzeptiert eine Anfrage von einem Webclient und bestimmt, ob sie vom PL/SQL-Gateway verarbeitet werden soll.\n\n Schritt 2:\n Das PL/SQL-Gateway verarbeitet die Anfrage, indem es den angeforderten Paketnamen, die Prozedur und die Variablen extrahiert.\n\n Schritt 3:\n Das angeforderte Paket und die Prozedur werden in einen anonymen PL/SQL-Block verpackt und an den Datenbankserver gesendet.\n\n Schritt 4:\n Der Datenbankserver führt die Prozedur aus und sendet die Ergebnisse als HTML an das Gateway zurück\n\n Schritt 5:\n Das Gateway sendet die Antwort über den Webserver zurück an den Client.\n\n Es ist wichtig, diesen Punkt zu verstehen – der PL/SQL-Code existiert nicht auf dem Webserver, sondern auf dem Datenbankserver.\n Das bedeutet, dass jede Schwachstelle im PL/SQL-Gateway oder jede Schwachstelle in der PL/SQL-Anwendung, wenn sie ausgenutzt wird, einem Angreifer direkten Zugriff auf den Datenbankserver verschafft.",
      "005_2": "SQL-Injection-Schwachstellen treten immer dann auf, wenn Eingaben beim Erstellen einer SQL-Abfrage verwendet werden, ohne dass sie angemessen eingeschränkt oder bereinigt wurden.\n Der MySQL-Server weist einige Besonderheiten auf, sodass einige Exploits speziell für diese Anwendung angepasst werden müssen.\n\n Wenn eine SQL-Injection-Schwachstelle in einer Anwendung gefunden wird, die von einer MySQL-Datenbank unterstützt wird, gibt es eine Reihe von Angriffen, die je nach MySQL-Version und Benutzerberechtigungen auf DBMS durchgeführt werden können.\n\n MySQL wird mit mindestens vier Versionen geliefert, die weltweit in der Produktion verwendet werden. Jede Version hat eine Reihe von Funktionen, die proportional zur Versionsnummer sind:\n • Ab Version 4.0: UNION\n • Ab Version 4.1: Subqueries\n • Ab Version 5.0: Stored Procedures, Stored Functions und die View mit dem Namen INFORMATION_SCHEMA\n • Ab Version 5.0.2: Trigger\n\n Es ist zu beachten, dass für MySQL-Versionen vor 4.0.x nur Boolean- oder zeitbasierte Blind-Injection-Angriffe verwendet werden konnten, da die Subquery-Funktionalität oder UNION-Anweisungen nicht implementiert waren.",
      "005_3": "SQL-Injection ermöglicht einem Angreifer den Zugriff auf die SQL-Server und die Ausführung von SQL-Code unter den Rechten des Benutzers, der für die Verbindung zur Datenbank verwendet wird. SQL-Injection-Techniken für Microsoft SQL Server verwenden spezifische Features.\n\n Wie in SQL-Injection erläutert, erfordert ein SQL-Injection-Exploit zwei Dinge: einen Einstiegspunkt und einen Exploit zum Eintreten.\n Jeder benutzergesteuerte Parameter, der von der Anwendung verarbeitet wird, kann eine Schwachstelle verbergen. Das beinhaltet:\n • Anwendungsparameter in Abfragezeichenfolgen (z. B. GET-Anfragen)\n • Anwendungsparameter, die Teil des Hauptteils einer POST-Anfrage sind\n • Browserbezogene Informationen (z. B. User-Agent, Referrer)\n • Hostbezogene Informationen (z. B. Hostname, IP)\n • Sitzungsbezogene Informationen (z. B. Benutzer-ID, Cookies)\n\n  Einige Microsoft SQL Server-Operatoren und -Befehle sind:\n • Kommentaroperator --\n • Abfragetrennzeichen ;\n\n Zu den nützlichen gespeicherten Prozeduren gehören:\n • xp_cmdshell\n • xp_regread\n • xp_regwrite\n • sp_configure\n • sp_ makewebtask\n • sp_sendmail",
      "005_4": "Wenn eine SQL-Injection gefunden wurde, müssen Sie die Backend-Datenbank-Engine sorgfältig mit einem Fingerabdruck versehen. Sie können feststellen, dass die Back-End-Datenbank-Engine PostgreSQL ist, indem Sie den :: cast-Operator verwenden.\n Außerdem kann die Funktion version() verwendet werden, um das PostgreSQL-Banner abzurufen. Dies zeigt auch den Typ und die Version des zugrunde liegenden Betriebssystems an.\n\n SQL-Injection-Techniken für PostgreSQL haben die folgenden Merkmale:\n • PHP Connector ermöglicht die Ausführung mehrerer Anweisungen mit ; als Anweisungstrenner\n • SQL-Anweisungen können durch Anhängen des Kommentarzeichens abgeschnitten werden: --\n • LIMIT und OFFSET können in einer SELECT-Anweisung verwendet werden, um einen Teil der von der Abfrage generierten Ergebnismenge abzurufen\n\n Bei blinden SQL-Injection-Angriffen sollten Sie die folgenden integrierten Funktionen berücksichtigen:\n • Zeichenfolgenlänge - LENGTH(str)\n • Einen Teilstring aus einem gegebenen String extrahieren – SUBSTR(str,index,offset)\n • Zeichenfolgendarstellung ohne einfache Anführungszeichen – CHR(101)||CHR(108)||CHR(111)",
      "005_5": "Microsoft Access kann bestimmte Features für SQL-Injection-Techniken nutzen.\n Leider unterstützt MS Access keine typischen Operatoren, die traditionell bei SQL-Injection-Tests verwendet werden, einschließlich:\n• Keine Kommentarzeichen\n• Keine gestapelten Abfragen\n• Kein LIMIT-Operator\n• Keine SLEEP- oder BENCHMARK-ähnlichen Operatoren\n• und viele andere\n\n Es gibt jedoch auch viele andere Funktionen, die beim Testen der SQL-Injection verwendet werden können, einschließlich, aber nicht beschränkt auf:\n • ASC: Ruft den ASCII-Wert eines als Eingabe übergebenen Zeichens ab\n • CHR: Ruft das Zeichen des als Eingabe übergebenen ASCII-Werts ab\n • LEN: Gibt die Länge des als Parameter übergebenen Strings zurück\n • IIF: Ist das IF-Konstrukt, z. IIF(1=1, 'a', 'b') gibt 'a' zurück\n • MID: Mit dieser Funktion können Sie Teilstrings extrahieren\n • TOP: Mit dieser Funktion können Sie die max. Anzahl der Ergebnisse\n • LAST: Diese Funktion wird verwendet, um nur die letzte Zeile eines Satzes auszuwählen\n\n In MS Access sind standardmäßig verschiedene Systemtabellen vorhanden, die möglicherweise zum Abrufen von Tabellennamen und Spalten verwendet werden können.\n Leider sind diese Tabellen in der Standardkonfiguration neuerer Versionen von MS Access-Datenbanken nicht zugänglich. Trotzdem ist es immer einen Versuch wert:\n • MSysObjects\n • MSysACEs\n • MSysAccessXML",
      "005_6": "NoSQL-Datenbanken bieten lockerere Konsistenzbeschränkungen als herkömmliche SQL-Datenbanken. Da weniger relationale Einschränkungen und Konsistenzprüfungen erforderlich sind, bieten NoSQL-Datenbanken häufig Leistungs- und Skalierungsvorteile.\n Da diese NoSQL-Injection-Angriffe jedoch in einer prozeduralen Sprache und nicht in der deklarativen SQL-Sprache ausgeführt werden können, sind die potenziellen Auswirkungen größer als bei herkömmlicher SQL-Injection.\n\n NoSQL-Datenbankaufrufe werden in der Programmiersprache der Anwendung, einem benutzerdefinierten API-Aufruf oder gemäß einer gängigen Konvention (z. B. XML, JSON, LINQ usw.) formatiert.\n\n Typischerweise werden NoSQL-Injection-Angriffe ausgeführt, bei denen die Angriffszeichenfolge analysiert, ausgewertet oder zu einem NoSQL-API-Aufruf verkettet wird.\n Zusätzliche Timing-Angriffe können für das Fehlen von Parallelitätsprüfungen innerhalb einer NoSQL-Datenbank relevant sein. Diese werden nicht von Injektionstests abgedeckt.\n\n Mittlerweile sind über 150 NoSQL-Datenbanken verfügbar, aber zum Zeitpunkt der Erstellung dieses Artikels ist MongoDB die am weitesten verbreitete NoSQL-Datenbank.\n\n Die MongoDB-API erwartet BSON-Aufrufe (Binary JSON) und enthält ein sicheres Tool zum Zusammenstellen von BSON-Abfragen. Laut MongoDB-Dokumentation sind jedoch deserialisierte JSON- und JavaScript-Ausdrücke in mehreren alternativen Abfrageparametern zulässig.\n Wenn ein Angreifer beispielsweise in der Lage wäre, die an den $where-Operator übergebenen Daten zu manipulieren, könnte dieser Angreifer willkürliches JavaScript einbinden, das als Teil der MongoDB-Abfrage ausgewertet wird.",
      "006": "Das Lightweight Directory Access Protocol (LDAP) wird verwendet, um Informationen über Benutzer, Hosts und viele andere Objekte zu speichern. Die LDAP-Injection ist ein serverseitiger Angriff, bei dem sensible Informationen über Benutzer und Hosts, die in einer LDAP-Struktur dargestellt sind, offengelegt, geändert oder eingefügt werden können. Dies erfolgt durch Manipulieren von Eingabeparametern, die anschließend an interne Such-, Hinzufügungs- und Änderungsfunktionen übergeben werden.\n Eine Webanwendung könnte LDAP verwenden, damit sich Benutzer innerhalb einer Unternehmensstruktur authentifizieren oder die Informationen anderer Benutzer durchsuchen können.\n\n Das Ziel von LDAP-Injection-Angriffen besteht darin, Metazeichen von LDAP-Suchfiltern in eine Abfrage einzufügen, die von der Anwendung ausgeführt wird.\n [Rfc2254] definiert eine Grammatik zum Aufbau eines Suchfilters auf LDAPv3 und erweitert [Rfc1960] (LDAPv2).\nEin LDAP-Suchfilter wird in polnischer Schreibweise erstellt, die auch als [Präfixschreibweise] bekannt ist.\n\n Eine erfolgreiche Ausnutzung einer LDAP-Injection-Schwachstelle könnte dem Tester Folgendes ermöglichen:\n • Greifen Sie auf nicht autorisierte Inhalte zu\n • Anwendungseinschränkungen umgehen\n • Sammeln Sie nicht autorisierte Informationen\n • Hinzufügen oder Ändern von Objekten innerhalb der LDAP-Baumstruktur",
      "007": "ORM Injection ist ein Angriff mit SQL Injection gegen ein ORM-generiertes Datenzugriffsobjektmodell. Aus Sicht eines Testers ist dieser Angriff praktisch identisch mit einem SQL-Injection-Angriff.\nDie Injection-Schwachstelle existiert jedoch in Code, der vom ORM-Tool generiert wird.\n\n Ein ORM ist ein objektrelationales Mapping-Tool.\nEs wird verwendet, um die objektorientierte Entwicklung innerhalb der Datenzugriffsschicht von Softwareanwendungen, einschließlich Webanwendungen, zu beschleunigen. Zu den Vorteilen der Verwendung eines ORM-Tools gehören die schnelle Generierung einer Objektschicht zur Kommunikation mit einer relationalen Datenbank, standardisierte Codevorlagen für diese Objekte und normalerweise eine Reihe sicherer Funktionen zum Schutz vor SQL-Injection-Angriffen. Von ORM generierte Objekte können SQL oder in einigen Fällen eine Variante von SQL verwenden, um CRUD-Operationen auf einer Datenbank auszuführen.\n\n Zu den ORM-Tools gehören Hibernate für Java, NHibernate für .NET, ActiveRecord für Ruby on Rails, EZPDO für PHP und viele andere.\n\n ORM-Injection-Schwachstellen sind identisch mit SQL-Injection-Tests. In den meisten Fällen ist die Schwachstelle in der ORM-Schicht das Ergebnis von benutzerdefiniertem Code, der Eingabeparameter nicht ordnungsgemäß validiert.\n Die meisten ORM-Tools bieten sichere Funktionen, um Benutzereingaben zu umgehen.\nWenn diese Funktionen jedoch nicht verwendet werden und der Entwickler benutzerdefinierte Funktionen verwendet, die Benutzereingaben akzeptieren, kann es möglich sein, einen SQL-Injection-Angriff auszuführen.\n\n Zu den Mustern, nach denen im Code gesucht werden muss, gehören:\n • Mit SQL-Strings verkettete Eingabeparameter",
      "008": "Beim XML-Injektionstest versucht ein Tester, ein XML-Dokument in die Anwendung einzufügen. Wenn der XML-Parser die Daten nicht kontextbezogen validieren kann, ergibt der Test ein positives Ergebnis.\n\n Schritt 1:\n Um eine Anwendung auf das Vorhandensein einer XML-Injection-Schwachstelle zu testen, besteht der Versuch, XML-Metazeichen einzufügen.\n\n XML-Metazeichen sind:\n • Einfaches Anführungszeichen: ‘ \n • Doppeltes Anführungszeichen: “ \n • Spitze Klammern: > und <\n • Kommentar-Tag: <!--/-->\n • Et-Zeichen: &\n • Trennzeichen für CDATA-Abschnitte: <![CDATA[ / ]]>\n\n Ein weiterer Test bezieht sich auf das CDATA-Tag. Angenommen, das XML-Dokument wird verarbeitet, um eine HTML-Seite zu generieren. In diesem Fall können die CDATA-Abschnittsbegrenzer einfach eliminiert werden, ohne ihren Inhalt weiter zu prüfen. Dann ist es möglich, HTML-Tags einzufügen, die in die generierte Seite eingefügt werden, wobei vorhandene Bereinigungsroutinen vollständig umgangen werden.\n\n Schritt 2:\n Sobald der erste Schritt abgeschlossen ist, verfügt der Tester über einige Informationen über die Struktur des XML-Dokuments. Anschließend kann versucht werden, XML-Daten und -Tags einzufügen (Tag Injection).",
      "009": "Webserver geben Entwicklern normalerweise die Möglichkeit, kleine Teile dynamischen Codes in statische HTML-Seiten einzufügen. Diese Funktion wird durch die Server-Side Includes (SSI) verkörpert.\nBeim SSI-Injection-Test testen wir, ob es möglich ist, Daten in die Anwendung einzuspeisen, die von SSI-Mechanismen interpretiert werden. Eine erfolgreiche Ausnutzung dieser Schwachstelle ermöglicht es einem Angreifer, Code in HTML-Seiten einzuschleusen oder sogar eine Remotecodeausführung durchzuführen.\n\n In Bezug auf die SSI-Injektion könnte der Angreifer Eingaben bereitstellen, die, wenn sie von der Anwendung (oder vielleicht direkt vom Server) in eine dynamisch generierte Seite eingefügt würden, als eine oder mehrere SSI-Anweisungen geparst würden.\n\n Schritt 1:\n Was wir herausfinden müssen, ist, ob der Webserver tatsächlich SSI-Anweisungen unterstützt. Um das herauszufinden, müssen wir nur herausfinden, welche Art von Webserver auf unserem Ziel läuft.\n Hinweis: Wenn die Site .shtml-Dateien enthält, werden wahrscheinlich SSI unterstützt, da diese Erweiterung verwendet wird, um Seiten zu identifizieren, die diese Anweisungen enthalten.\n\n Schritt 2:\n Der nächste Schritt besteht darin, festzustellen, ob ein SSI-Injection-Angriff tatsächlich möglich ist und wenn ja, über welche Eingabepunkte können wir unseren Schadcode einschleusen.\n Wir müssen jede Seite finden, auf der der Benutzer Eingaben vornehmen darf, und überprüfen, ob die Anwendung die übermittelten Eingaben korrekt validiert.\n Wenn die Bereinigung unzureichend ist, müssen wir testen, ob wir Daten bereitstellen können, die unverändert angezeigt werden.\n Neben den üblichen vom Benutzer bereitgestellten Daten sind HTTP-Anforderungsheader und Cookie-Inhalte Eingabevektoren, die immer berücksichtigt werden sollten.\n\n Schritt 3:\n Sobald wir eine Liste möglicher Injektionspunkte haben, können wir überprüfen, wie die Eingabe behandelt wird, welche Art von Filterung durchgeführt wird, welche Zeichen die Anwendung nicht durchlässt und wie viele Codierungsarten berücksichtigt werden.",
      "010": "Webanwendungen verwenden Datenbanken stark zum Speichern und Zugreifen auf die Daten, die sie für ihren Betrieb benötigen.\n So wie auf relationale Datenbanken über die SQL-Sprache zugegriffen wird, verwenden XML-Datenbanken XPath als Standardabfragesprache.\n\n XPath ist eine Sprache, die hauptsächlich entworfen und entwickelt wurde, um Teile eines XML-Dokuments zu adressieren. Beim XPath-Injection-Test testen wir, ob es möglich ist, XPath-Syntax in eine von der Anwendung interpretierte Anfrage einzufügen, sodass ein Angreifer benutzergesteuerte XPath-Abfragen ausführen kann.\n XPath ist sogar noch leistungsfähiger als Standard-SQL, da seine gesamte Leistungsfähigkeit bereits in seinen Spezifikationen vorhanden ist, während eine große Anzahl der Techniken, die bei einem SQL-Injection-Angriff verwendet werden können, von den Eigenschaften des SQL-Dialekts abhängen, der von der Zieldatenbank verwendet wird.\n\n Das XPath-Angriffsmuster ist der üblichen SQL-Injektion sehr ähnlich, und wie bei einem gewöhnlichen SQL-Injection-Angriff besteht der erste Schritt bei der XPath-Injektion darin, ein einfaches Anführungszeichen (') in das zu testende Feld einzufügen, wodurch ein Syntaxfehler in das Feld eingeführt wird abzufragen und zu prüfen, ob die Anwendung eine Fehlermeldung zurückgibt.",
      "011": "Diese Bedrohung betrifft alle Anwendungen, die mit Mailservern (IMAP/SMTP) kommunizieren, im Allgemeinen Webmail-Anwendungen. Das Ziel dieses Tests besteht darin, die Fähigkeit zu überprüfen, beliebige IMAP/SMTP-Befehle in die Mailserver einzufügen, da Eingabedaten nicht ordnungsgemäß bereinigt werden.\n\n Eine IMAP/SMTP-Injection ermöglicht den Zugriff auf einen Mailserver, der sonst nicht direkt aus dem Internet erreichbar wäre. In einigen Fällen verfügen diese internen Systeme nicht über das gleiche Maß an Infrastruktursicherheit und Härtung, das auf die Front-End-Webserver angewendet wird. Daher sind Mailserver-Ergebnisse möglicherweise anfälliger für Angriffe durch Endbenutzer.\n\n Die Standardangriffsmuster sind:\n • Identifizieren anfälliger Parameter\n • Verstehen des Datenflusses und der Bereitstellungsstruktur des Clients\n • IMAP/SMTP-Befehlsinjektion\n\n Diese letzte Phase hat zwei mögliche Ergebnisse:\n\n Ergebnis 1:\n Die Injektion ist in einem nicht authentifizierten Zustand möglich: Die betroffene Funktionalität erfordert keine Authentifizierung des Benutzers.\n Die verfügbaren injizierten (IMAP)-Befehle sind beschränkt auf: \nCAPABILITY, NOOP, AUTHENTICATE, LOGIN und LOGOUT.\n\n Ergebnis 2:\n Die Injektion ist nur in einem authentifizierten Zustand möglich: Die erfolgreiche Ausnutzung erfordert, dass der Benutzer vollständig authentifiziert ist, bevor der Test fortgesetzt werden kann.\n\n In jedem Fall sieht der typische Aufbau einer IMAP/SMTP-Injection wie folgt aus:\n • Header: Ende des erwarteten Befehls;\n • Body: Injektion des neuen Befehls;\n • Footer: Anfang des erwarteten Befehls.",
      "012": "Beim Code-Injection-Test übermittelt ein Tester Eingaben, die vom Webserver als dynamischer Code oder als eingebundene Datei verarbeitet werden. Diese Tests können auf verschiedene serverseitige Scripting-Engines abzielen, z. B. ASP oder PHP. Zum Schutz vor diesen Angriffen müssen eine ordnungsgemäße Eingabevalidierung und sichere Codierungspraktiken angewendet werden.\n\n Testen auf PHP-Injection-Schwachstellen\n Unter Verwendung der Abfragezeichenfolge kann der Tester Code einfügen, der als Teil der enthaltenen Datei verarbeitet werden soll. Die schädliche URL wird als Parameter für die PHP-Seite akzeptiert, die später den Wert in einer eingebundenen Datei verwendet.\n\n Testen auf ASP-Code-Injection-Schwachstellen\n Untersuchen Sie den ASP-Code auf Benutzereingaben, die in Ausführungsfunktionen verwendet werden.\nKann der Benutzer Befehle in das Dateneingabefeld eingeben?",
      "012_1": "Die Schwachstelle „File Inclusion“ ermöglicht es einem Angreifer, eine Datei einzufügen, wobei er normalerweise einen „dynamischen Dateieinschluss“-Mechanismus ausnutzt, der in der Zielanwendung implementiert ist. Die Sicherheitsanfälligkeit tritt aufgrund der Verwendung von Benutzereingaben ohne ordnungsgemäße Überprüfung auf.\n\n Dies kann dazu führen, dass der Inhalt der Datei ausgegeben wird, aber je nach Schweregrad kann es auch zu Folgendem führen:\n • Codeausführung auf dem Webserver\n • Code-Ausführung auf der Client-Seite wie JavaScript, was zu anderen Angriffen wie Cross-Site-Scripting (XSS) führen kann.\n • Dienstverweigerung (DoS)\n • Offenlegung sensibler Informationen\n\n Local File Inclusion (auch bekannt als LFI) ist der Prozess des Einschließens von Dateien, die bereits lokal auf dem Server vorhanden sind, durch Ausnutzung von angreifbaren Einschlussverfahren.\n Da LFI auftritt, wenn Pfade, die an „include“-Anweisungen übergeben werden, nicht ordnungsgemäß bereinigt werden, sollten wir in einem Blackbox-Testansatz nach Skripten suchen, die Dateinamen als Parameter verwenden.",
      "012_2": "Die Schwachstelle „File Inclusion“ ermöglicht es einem Angreifer, eine Datei einzufügen, wobei er normalerweise einen „dynamischen Dateieinschluss“-Mechanismus ausnutzt, der in der Zielanwendung implementiert ist. Die Sicherheitsanfälligkeit tritt aufgrund der Verwendung von Benutzereingaben ohne ordnungsgemäße Überprüfung auf.\n\n Dies kann dazu führen, dass der Inhalt der Datei ausgegeben wird, aber je nach Schweregrad kann es auch zu Folgendem führen:\n • Codeausführung auf dem Webserver\n • Code-Ausführung auf der Client-Seite wie JavaScript, was zu anderen Angriffen wie Cross-Site-Scripting (XSS) führen kann.\n • Dienstverweigerung (DoS)\n • Offenlegung sensibler Informationen\n\n Remote File Inclusion (auch bekannt als RFI) ist der Prozess des Einschließens von Remote-Dateien durch die Ausnutzung von anfälligen Einschlussverfahren.\n\n Da RFI auftritt, wenn Pfade, die an „include“-Anweisungen übergeben werden, nicht ordnungsgemäß bereinigt werden, sollten wir in einem Blackbox-Testansatz nach Skripten suchen, die Dateinamen als Parameter verwenden.",
      "013": "OS Command Injection ist eine Technik, die über eine Webschnittstelle verwendet wird, um OS-Befehle auf einem Webserver auszuführen. Der Benutzer liefert Betriebssystembefehle über eine Webschnittstelle, um OS-Befehle auszuführen. Jede nicht ordnungsgemäß bereinigte Weboberfläche ist von diesem Exploit betroffen.\n\n Beim Anzeigen einer Datei in einer Webanwendung wird der Dateiname häufig in der URL angezeigt. Perl ermöglicht die Weiterleitung von Daten aus einem Prozess in eine offene Anweisung. Der Benutzer kann einfach das Pipe-Symbol „|“ anhängen. am Ende des Dateinamens.\n Das Anhängen eines Semikolons an das Ende einer URL für eine .PHP-Seite, gefolgt von einem Betriebssystembefehl, führt den Befehl aus. %3B ist URL-kodiert und wird in Semikolon dekodiert.",
      "014": "Verschiedene Arten von Pufferüberlauf-Schwachstellen haben unterschiedliche Testmethoden. Hier sind die Testmethoden für die häufigsten Arten von Pufferüberlauf-Schwachstellen.\n\n • Testen auf Heap-Overflow-Schwachstelle\n • Testen auf Stack-Overflow-Schwachstellen\n • Testen auf Sicherheitslücken bei Format-Strings",
      "014_1": "Bei diesem Test überprüft der Penetrationstester, ob er einen Heap-Überlauf erzeugen kann, der ein Speichersegment ausnutzt.\n\n Heap ist ein Speichersegment, das zum Speichern dynamisch zugewiesener Daten und globaler Variablen verwendet wird. Jeder Speicherblock im Heap besteht aus Begrenzungs-Tags, die Speicherverwaltungsinformationen enthalten.\n\n Wenn ein Heap-basierter Puffer überläuft, werden die Steuerinformationen in diesen Tags überschrieben. Wenn die Heap-Verwaltungsroutine den Puffer freigibt, findet ein Überschreiben der Speicheradresse statt, was zu einer Zugriffsverletzung führt. Wenn der Überlauf auf kontrollierte Weise ausgeführt wird, würde die Schwachstelle es einem Angreifer ermöglichen, einen gewünschten Speicherplatz mit einem benutzergesteuerten Wert zu überschreiben.\n\n Es gibt zahlreiche Varianten der Schwachstelle Heap Overflow (Heap Corruption), die vom Überschreiben von Funktionszeigern bis zum Ausnutzen von Speicherverwaltungsstrukturen für die Ausführung willkürlichen Codes alles ermöglichen kann.\n\n Der Schlüssel liegt darin, als Eingabezeichenfolgen bereitzustellen, die länger als erwartet sind. Obwohl der Testprozess derselbe bleibt, unterscheiden sich die in einem Debugger sichtbaren Ergebnisse erheblich. Während im Fall eines Stapelüberlaufs ein Befehlszeiger oder ein SEH-Überschreiben offensichtlich wäre, gilt dies nicht für einen Stapelüberlaufzustand.\n Beim Debuggen eines Windows-Programms kann ein Heap-Überlauf in verschiedenen Formen auftreten, wobei die häufigste Form ein Zeigeraustausch ist, der stattfindet, nachdem die Heap-Verwaltungsroutine in Aktion tritt.\n\n Statische Code-Analyse-Tools können auch dabei helfen, Heap-bezogene Schwachstellen wie „Double Free“ usw. zu lokalisieren. Eine Vielzahl von Tools wie RATS, Flawfinder und ITS4 stehen zur Analyse von Sprachen im C-Stil zur Verfügung.",
      "014_2": "Stack-überläufe treten auf, wenn Daten mit variabler Größe in Puffer mit fester Länge kopiert werden, die sich auf dem Programmstapel befinden, ohne dass eine Begrenzungsprüfung erfolgt.\n Schwachstellen dieser Klasse werden im Allgemeinen als hochgradig eingestuft, da ihre Ausnutzung meist die Ausführung willkürlichen Codes oder Denial of Service ermöglichen würde. In interpretierten Plattformen selten anzutreffen, ist Code, der in C und ähnlichen Sprachen geschrieben wurde, oft mit Instanzen dieser Schwachstelle gespickt.\n\n  Tatsächlich ist fast jede Plattform anfällig für Stack-überläufe, mit den folgenden bemerkenswerten Ausnahmen:\n • J2EE – solange keine nativen Methoden oder Systemaufrufe aufgerufen werden\n • .NET – solange /unsafe oder nicht verwalteter Code nicht aufgerufen wird\n • PHP – solange externe Programme und angreifbare Erweiterungen nicht aufgerufen werden\n\n Stack-überlauf-Schwachstellen ermöglichen es einem Angreifer häufig, direkt die Kontrolle über den Befehlszeiger zu übernehmen und somit die Ausführung des Programms zu ändern und beliebigen Code auszuführen.\n\n Der Schlüssel zum Testen einer Anwendung auf Stack-überlauf-Schwachstellen liegt darin, im Vergleich zu dem, was erwartet wird, übermäßig große Eingabedaten bereitzustellen.\n Es reicht jedoch nicht aus, die Anwendung beliebig großen Datenmengen auszusetzen. Es wird notwendig, den Ausführungsablauf und die Antworten der Anwendung zu überprüfen, um festzustellen, ob tatsächlich ein Überlauf ausgelöst wurde oder nicht.\n Daher wären die erforderlichen Schritte zum Auffinden und Validieren von Stack-überläufen, einen Debugger an die Zielanwendung oder den Zielprozess anzuhängen, fehlerhafte Eingaben für die Anwendung zu generieren, die Anwendung fehlerhaften Eingaben auszusetzen und Antworten in einem Debugger zu untersuchen.",
      "014_3": "Verschiedene Sprachen im C-Stil bieten die Formatierung der Ausgabe mittels Funktionen wie printf( ), fprintf( ) usw. Die Formatierung wird durch einen Parameter für diese Funktionen geregelt, der als Formattypbezeichner bezeichnet wird, typischerweise %s, %c usw.\n Die Schwachstelle entsteht, wenn Formatierungsfunktionen mit unzureichender Parametervalidierung und benutzergesteuerten Daten aufgerufen werden.\n\n Ein einfaches Beispiel wäre printf(argv[1]). In diesem Fall wurde der Typbezeichner nicht explizit deklariert, sodass ein Benutzer Zeichen wie %s, %n, %x mithilfe des Befehlszeilenarguments argv[1] an die Anwendung übergeben kann.\n\n Diese Situation wird tendenziell prekär, da ein Benutzer, der Formatbezeichner bereitstellen kann, die folgenden böswilligen Aktionen ausführen kann:\n • Prozessstapel aufzählen\n • Steuerungsausführungsablauf\n • Denial of Service\n\n Der Schlüssel zum Testen von Sicherheitslücken in Formatzeichenfolgen ist die Bereitstellung von Formattypbezeichnern in der Anwendungseingabe.\n\n Sicherheitslücken im Format-String treten hauptsächlich in Webservern, Anwendungsservern oder Webanwendungen auf, die C/C++-basierten Code oder in C geschriebene CGI-Skripte verwenden. In den meisten dieser Fälle wurde eine Fehlerberichterstattungs- oder Protokollierungsfunktion wie syslog( ) unsicher aufgerufen.\n Beim Testen von CGI-Skripten auf Sicherheitslücken im Formatstring können die Eingabeparameter so manipuliert werden, dass sie die Typbezeichner %x oder %n enthalten.\n\n Bei der Durchführung von Code-Reviews können fast alle Sicherheitslücken in Format-Strings mithilfe statischer Code-Analyse-Tools erkannt werden.\n Die Funktionen, die hauptsächlich für Sicherheitslücken in Formatzeichenfolgen verantwortlich sind, behandeln Formatbezeichner als optional. Daher kann bei der manuellen Überprüfung von Code der Schwerpunkt auf Funktionen gelegt werden wie:\n • printf\n • fprintf\n • sprintf\n • snprintf\n • vfprintf\n • vprintf",
      "015": "Inkubationstests werden auch oft als dauerhafte Angriffe bezeichnet und sind eine komplexe Testmethode, die mehr als eine Schwachstelle zur Datenvalidierung benötigt, um zu funktionieren.\n Inkubierte Schwachstellen werden normalerweise verwendet, um „Watering Hole“-Angriffe gegen Benutzer legitimer Webanwendungen durchzuführen.\n\n Inkubierte Schwachstellen haben die folgenden Merkmale:\n\n Zuerst:\n Der Angriffsvektor muss in erster Linie persistiert werden, er muss in der Persistenzschicht gespeichert werden, und dies würde nur auftreten, wenn eine schwache Datenvalidierung vorhanden wäre oder die Daten über einen anderen Kanal wie eine Verwaltungskonsole oder direkt in das System gelangen über einen Backend-Batch-Prozess.\n\n Zweitens:\n  Sobald der Angriffsvektor „zurückgerufen“ wurde, musste der Vektor erfolgreich ausgeführt werden. Beispielsweise würde ein inkubierter XSS-Angriff eine schwache Ausgabevalidierung erfordern, damit das Skript in seiner ausführbaren Form an den Client geliefert wird.\n\n Die Ausnutzung einiger Schwachstellen oder sogar Funktionsmerkmale einer Webanwendung ermöglicht es einem Angreifer, Daten einzuschleusen, die später abgerufen werden.\n In einem Penetrationstest können inkubierte Angriffe verwendet werden, um die Kritikalität bestimmter Fehler zu bewerten, die normalerweise verwendet werden, um eine große Anzahl von Opfern gleichzeitig anzugreifen.\n\n Diese Art von asynchronen Angriffen deckt ein großes Spektrum an Angriffsvektoren ab, darunter die folgenden:\n • Datei-Upload-Komponenten in einer Webanwendung\n • Cross-Site-Scripting-Probleme in öffentlichen Forenbeiträgen\n • SQL/XPATH-Injection, die es dem Angreifer ermöglicht, Inhalte in eine Datenbank hochzuladen\n • Falsch konfigurierte Server, die die Installation von Paketen oder Komponenten ermöglichen\n\n Schritt 1:\n Überprüfen Sie den Inhaltstyp, der zum Hochladen in die Webanwendung zugelassen ist, und die resultierende URL für die hochgeladene Datei.\n\n Schritt 2:\n Laden Sie eine Datei hoch, die eine Komponente auf der lokalen Benutzerarbeitsstation ausnutzt, wenn sie vom Benutzer angezeigt oder heruntergeladen wird.\n\n Schritt 3:\n Senden Sie Ihrem Opfer eine E-Mail oder eine andere Art von Benachrichtigung, um ihn/sie dazu zu bringen, die Seite zu durchsuchen.\n\n Das erwartete Ergebnis ist, dass der Exploit ausgelöst wird, wenn der Benutzer die resultierende Seite durchsucht oder die Datei von der vertrauenswürdigen Site herunterlädt und ausführt.",
      "016": "Es gibt zwei verschiedene Angriffe, die auf bestimmte HTTP-Header abzielen:\n• HTTP-Splitting\n• HTTP-Smuggling\n\n Der erste Angriff nutzt einen Mangel an Eingabebereinigung aus, wodurch ein Eindringling CR- und LF-Zeichen in die Header der Anwendungsantwort einfügen und diese Antwort in zwei verschiedene HTTP-Nachrichten „aufteilen“ kann.\n Das Ziel des Angriffs kann von Cache-Poisoning bis hin zu Cross-Site-Scripting reichen.\n\n Beim zweiten Angriff nutzt der Angreifer die Tatsache aus, dass einige speziell gestaltete HTTP-Nachrichten je nach Agent, der sie empfängt, auf unterschiedliche Weise analysiert und interpretiert werden können.\nHTTP-Schmuggel erfordert ein gewisses Maß an Wissen über die verschiedenen Agenten, die die HTTP-Nachrichten verarbeiten (Webserver, Proxy, Firewall).\n\n HTTP-Splitting\n Einige Webanwendungen verwenden einen Teil der Benutzereingaben, um die Werte einiger Header ihrer Antworten zu generieren. Das einfachste Beispiel sind Umleitungen, bei denen die Ziel-URL von einem vom Benutzer übermittelten Wert abhängt.\n Die Header, die die wahrscheinlichsten Kandidaten für diesen Angriff sind, sind:\n• Location\n• Set-Cookie\n\n  HTTP-Smuggling\n Dies nutzt die verschiedenen Möglichkeiten, wie eine speziell gestaltete HTTP-Nachricht von verschiedenen Agenten (Browsern, Webcaches, Anwendungsfirewalls) analysiert und interpretiert werden kann."
    },
    "err": {
      "001": "Während eines Penetrationstests für Webanwendungen stoßen wir häufig auf viele Fehlercodes, die von Anwendungen oder Webservern generiert werden.\n Es ist möglich, dass diese Fehler angezeigt werden, indem bestimmte Anfragen verwendet werden, die entweder speziell mit Tools erstellt oder manuell erstellt wurden. Diese Codes sind für Penetrationstester bei ihren Aktivitäten sehr nützlich, da sie viele Informationen über Datenbanken, Fehler und andere technologische Komponenten preisgeben, die direkt mit Webanwendungen verknüpft sind.\n\n  Eine gute Sammlung von Fehlerinformationen kann die Bewertungseffizienz verbessern, indem die Gesamtzeit für die Durchführung des Penetrationstests verkürzt wird.\n Angreifer verwenden manchmal Suchmaschinen, um Fehler zu finden, die Informationen preisgeben. Es können Suchvorgänge durchgeführt werden, um fehlerhafte Websites als zufällige Opfer zu finden, oder es ist möglich, mit den Filterwerkzeugen der Suchmaschine nach Fehlern auf einer bestimmten Website zu suchen.\n\n Nachfolgend sind einige Bereiche aufgeführt, die dem Benutzer detaillierte Fehlermeldungen zurückgeben könnten. Jeder der Bereiche enthält spezifische Informationen über das Betriebssystem, die Anwendungsversion usw.\n • Webserverfehler (HTTP-Antworten)\n • Anwendungsserverfehler (Framework-Meldungen)\n • Datenbankfehler (Datenbanksystemmeldungen)",
      "002": "Stack-Traces sind an sich keine Schwachstellen, aber sie offenbaren oft Informationen, die für einen Angreifer interessant sind. Angreifer versuchen, diese Stack-Traces zu generieren, indem sie die Eingabe in die Webanwendung mit fehlerhaften HTTP-Anforderungen und anderen Eingabedaten manipulieren.\n\n Wenn die Anwendung mit nicht verwalteten Stack-Traces antwortet, können für Angreifer nützliche Informationen preisgegeben werden. Diese Informationen könnten dann für weitere Angriffe verwendet werden.\n\n Es gibt eine Vielzahl von Techniken, die dazu führen, dass Ausnahmemeldungen in einer HTTP-Antwort gesendet werden. Beachten Sie, dass dies in den meisten Fällen eine HTML-Seite ist, aber Ausnahmen können auch als Teil von SOAP- oder REST-Antworten gesendet werden.\nEinige Tests zum Ausprobieren umfassen:\n • Ungültige Eingabe\n • Eingaben, die nicht alphanumerische Zeichen oder Abfragesyntax enthalten\n • leere Eingänge\n • zu lange Eingaben\n • Zugriff auf interne Seiten ohne Authentifizierung\n • Umgehung des Anwendungsflusses\n\n Alle oben genannten Tests können zu Anwendungsfehlern führen, die Stack-Traces enthalten können. Es wird empfohlen, zusätzlich zu manuellen Tests einen Fuzzer zu verwenden.\n\n Wenn der SSL/TLS-Dienst vorhanden ist, ist er gut, aber er erhöht die Angriffsfläche und die folgenden Schwachstellen bestehen:\n • SSL/TLS-Protokolle, Chiffren, Schlüssel und Neuverhandlung müssen ordnungsgemäß konfiguriert sein\n • Zertifikatsgültigkeit muss gewährleistet sein"
    },
    "crypst": {
      "001": "Sensible Daten müssen geschützt werden, wenn sie durch das Netzwerk übertragen werden. \nAls Faustregel gilt: Wenn Daten bei der Speicherung geschützt werden müssen, müssen sie auch während der Übertragung geschützt werden.\n\n Verschiedene Arten von zu schützenden Informationen können auch im Klartext übertragen werden. Es kann überprüft werden, ob diese Informationen über HTTP statt HTTPS übertragen werden.\n\n HTTP ist ein Klartextprotokoll und wird normalerweise über einen SSL/TLS-Tunnel gesichert, was zu HTTPS-Datenverkehr führt. Server werden mit digitalen Zertifikaten authentifiziert, und es ist auch möglich, Client-Zertifikate für die gegenseitige Authentifizierung zu verwenden.\n Selbst wenn heute hochwertige Chiffren unterstützt und normalerweise verwendet werden, kann eine Fehlkonfiguration im Server dazu verwendet werden, die Verwendung einer schwachen Chiffre – oder schlimmstenfalls gar keine Verschlüsselung – zu erzwingen, die es einem Angreifer ermöglicht, Zugang zu dem vermeintlich sicheren Kommunikationskanal zu erhalten.\n\n Häufige Probleme:\n Wenn der SSL/TLS-Dienst vorhanden ist, ist er gut, aber er erhöht die Angriffsfläche und die folgenden Schwachstellen bestehen:\n • SSL/TLS-Protokolle, Chiffren, Schlüssel und Neuverhandlung müssen ordnungsgemäß konfiguriert sein\n • Zertifikatsgültigkeit muss gewährleistet sein\n • Offengelegte Software muss aufgrund möglicher bekannter Schwachstellen aktualisiert werden\n • Verwendung des Secure-Flags für Sitzungscookies\n • Verwendung von HTTP Strict Transport Security (HSTS)\n • Das Vorhandensein von HTTP und HTTPS, die zum Abfangen von Datenverkehr verwendet werden können\n • Das Vorhandensein gemischter HTTPS- und HTTP-Inhalte auf derselben Seite, die zum Leaking von Informationen verwendet werden können \n\n Prüfung auf sensible Daten, die im Klartext übertragen werden\n Ein typisches Beispiel ist die Verwendung der Basisauthentifizierung über HTTP, da bei der Basisauthentifizierung die Anmeldeinformationen nach der Anmeldung in HTTP-Header codiert – und nicht verschlüsselt – werden.\n\n Testen auf schwache SSL/TLS-Chiffren/Protokolle/Schlüssel-Schwachstellen\n Die große Anzahl verfügbarer Cipher Suites und der schnelle Fortschritt in der Kryptoanalyse machen das Testen eines SSL-Servers zu einer nicht trivialen Aufgabe. Zum Zeitpunkt des Schreibens sind diese Kriterien eine allgemein anerkannte Checkliste:\n • Schwache Chiffren dürfen nicht verwendet werden (z. B. weniger als 128 Bit)\n • Keine NULL-Ciphers-Suite, da keine Verschlüsselung verwendet wird\n • Schwache Protokolle müssen deaktiviert werden (z. B. muss SSLv2 deaktiviert werden)\n • Die Neuverhandlung muss ordnungsgemäß konfiguriert sein (z. B. muss die unsichere Neuverhandlung deaktiviert sein).\n • Keine Verschlüsselungssammlungen auf Exportebene (EXP), da diese leicht geknackt werden können\n • Die Schlüssellänge von X.509-Zertifikaten muss stark sein\n • X.509-Zertifikate dürfen nur mit sicheren Hash-Algorithmen signiert werden\n • Schlüssel müssen mit der richtigen Entropie generiert werden\n • Sichere Neuverhandlung sollte aktiviert sein.\n • MD5 sollte aufgrund bekannter Kollisionsangriffe nicht verwendet werden\n • RC4 sollte wegen kryptoanalytischer Angriffe nicht verwendet werden\n • Der Server sollte vor BEAST-Angriffen geschützt werden\n • Der Server sollte vor CRIME-Angriffen geschützt werden, die TLS-Komprimierung muss deaktiviert werden\n • Der Server sollte Forward Secrecy unterstützen",
      "002": "Ein Padding-Oracle ist eine Funktion einer Anwendung, die vom Client bereitgestellte verschlüsselte Daten entschlüsselt, z. interner Sitzungsstatus, der auf dem Client gespeichert ist, und gibt den Status der Gültigkeit der Auffüllung nach der Entschlüsselung preis.\n\n Die Existenz eines Padding-Oracles ermöglicht es einem Angreifer, verschlüsselte Daten zu entschlüsseln und willkürliche Daten zu verschlüsseln, ohne den Schlüssel zu kennen, der für diese kryptografischen Operationen verwendet wird.\n\n Blockchiffren verschlüsseln Daten nur in Blöcken bestimmter Größe. Die von gängigen Chiffren verwendeten Blockgrößen sind 8 und 16 Bytes. Daten, deren Größe nicht mit einem Vielfachen der Blockgröße der verwendeten Chiffre übereinstimmt, müssen auf bestimmte Weise aufgefüllt werden, damit der Entschlüsseler die Auffüllung entfernen kann.\n\n Der Padding-Oracle-Angriff ermöglicht es einem Angreifer, verschlüsselte Daten ohne Kenntnis des Verschlüsselungsschlüssels und der verwendeten Chiffre zu entschlüsseln, indem er geschickt manipulierte Chiffriertexte an das Padding-Oracle sendet und die von ihm zurückgegebenen Ergebnisse beobachtet. Dies führt zu einem Verlust der Vertraulichkeit der verschlüsselten Daten.\n Ein Padding-Oracle-Angriff ermöglicht es einem Angreifer auch, beliebige Klartexte ohne Kenntnis des verwendeten Schlüssels und der Chiffre zu verschlüsseln.\n\n Zunächst müssen die möglichen Eingabepunkte für ein Padding-Oracle identifiziert werden. Generell müssen folgende Bedingungen erfüllt sein:\n\n Bedingung 1:\n Die Daten sind verschlüsselt. Gute Kandidaten sind Werte, die zufällig erscheinen.\n\n Bedingung 2:\n Es wird eine Blockchiffre verwendet. Die Länge des decodierten (z. B. Base64) Chiffriertextes ist ein Vielfaches der üblichen Chiffrierblockgrößen wie 8 oder 16 Bytes. Verschiedene Chiffriertexte haben einen gemeinsamen Teiler in der Länge.\n\n Wenn ein solcher Eingabewertkandidat identifiziert wird, sollte das Verhalten der Anwendung gegenüber einer bitweisen Manipulation des verschlüsselten Werts überprüft werden.\n Die Tests und der Basiswert sollten mindestens drei verschiedene Zustände während und nach der Entschlüsselung bewirken:\n • Geheimtext wird entschlüsselt, Ergebnisdaten sind korrekt\n • Chiffrierter Text wird entschlüsselt, resultierende Daten werden verstümmelt und verursachen eine Ausnahme- oder Fehlerbehandlung in der Anwendungslogik\n • Die Chiffretext-Entschlüsselung schlägt aufgrund von Padding-Fehlern fehl\n\n Suchen Sie insbesondere nach Ausnahmen und Meldungen, die besagen, dass etwas mit dem Padding nicht stimmt. Wenn die drei oben beschriebenen unterschiedlichen Zustände implizit beobachtbar sind (unterschiedliche Fehlermeldungen, Timing-Seitenkanäle), liegt mit hoher Wahrscheinlichkeit an dieser Stelle ein Padding-Oracle vor. Beispiele:\n • ASP.NET löst „System.Security.Cryptography.Cryptographic Exception: Padding is invalid and can not be remove“ aus.\n • In Java wird in diesem Fall eine javax.crypto.BadPaddingException geworfen\n • Entschlüsselungsfehler oder ähnliches können mögliche padding oracles sein",
      "003": "Sensible Daten müssen geschützt werden, wenn sie durch das Netzwerk übertragen werden. Wenn Daten über HTTPS übertragen oder auf andere Weise verschlüsselt werden, darf der Schutzmechanismus keine Einschränkungen oder Schwachstellen aufweisen.\n\n Als Faustregel gilt: Wenn Daten bei der Speicherung geschützt werden müssen, müssen diese Daten auch bei der Übertragung geschützt werden. \n Einige Beispiele für sensible Daten sind:\n • Bei der Authentifizierung verwendete Informationen (z. B. Anmeldeinformationen, PINs, Tokens, Cookies …)\n • Informationen, die durch Gesetze, Vorschriften oder spezifische Unternehmensrichtlinien geschützt sind (z. B. Kreditkarten, Kundendaten)\n\n Verschiedene Arten von Informationen, die geschützt werden müssen, könnten von der Anwendung im Klartext übertragen werden. Es kann überprüft werden, ob diese Informationen über HTTP statt HTTPS übertragen werden oder ob schwache Chiffren verwendet werden.\n\n 1. Basisauthentifizierung über HTTP\n Ein typisches Beispiel ist die Verwendung von Basic Authentication über HTTP. Bei Verwendung der Standardauthentifizierung werden Benutzeranmeldeinformationen codiert und nicht verschlüsselt und als HTTP-Header gesendet.\n\n 2. Formularbasierte Authentifizierung über HTTP durchgeführt\n Ein weiteres typisches Beispiel sind Authentifizierungsformulare, die Anmeldeinformationen zur Benutzerauthentifizierung über HTTP übertragen. Es ist möglich, dieses Problem zu sehen, indem Sie den HTTP-Datenverkehr mit einem Interception-Proxy untersuchen.\n\n 3. Cookie mit Sitzungs-ID, das über HTTP gesendet wird\n Das Session-ID-Cookie muss über geschützte Kanäle übertragen werden. Wenn für das Cookie kein sicheres Flag gesetzt ist, ist es der Anwendung gestattet, es unverschlüsselt zu übertragen."
    },
    "buslogic": {
      "001": "Die Anwendung muss sicherstellen, dass nur logisch gültige Daten sowohl am Frontend als auch direkt auf der Serverseite eines Anwendungssystems eingegeben werden können. Daten nur lokal zu verifizieren, kann Anwendungen anfällig für Serverinjektionen durch Proxys oder bei Übergaben an andere Systeme machen. Dies unterscheidet sich von der einfachen Durchführung einer Boundary Value Analysis (Grenzwertanalyse) dadurch, dass sie schwieriger ist und in den meisten Fällen nicht einfach am Eingangspunkt überprüft werden kann, sondern normalerweise die Überprüfung eines anderen Systems erfordert.\n\n Schwachstellen im Zusammenhang mit der Geschäftsdatenvalidierung sind insofern einzigartig, als sie anwendungsspezifisch sind und sich von den Schwachstellen im Zusammenhang mit gefälschten Anforderungen darin unterscheiden, dass sie sich mehr um logische Daten kümmern, anstatt einfach den Arbeitsablauf der Geschäftslogik zu unterbrechen.\n\n Das Front-End und das Back-End der Anwendung sollten überprüfen und validieren, dass die Daten, die sie hat, verwendet und weitergibt, logisch gültig sind. Selbst wenn der Benutzer einer Anwendung gültige Daten bereitstellt, kann die Geschäftslogik dazu führen, dass sich die Anwendung je nach Daten oder Umständen anders verhält.\n\n Generische Testmethode\n • Überprüfen Sie die Projektdokumentation und verwenden Sie explorative Tests, um nach Dateneingangspunkten oder Übergabepunkten zwischen Systemen oder Software zu suchen\n • Versuchen Sie, einmal gefundene logisch ungültige Daten in die Anwendung/das System einzufügen\n\n Spezifische Testmethode\n • Führen Sie funktional gültige Front-End-GUI-Tests für die Anwendung durch, um sicherzustellen, dass nur „gültige“ Werte akzeptiert werden.\n • Beobachten Sie bei Verwendung eines abfangenden Proxys HTTP POST/GET und suchen Sie nach Stellen, an denen Variablen wie Kosten und Qualität übergeben werden. Suchen Sie insbesondere nach „Übergaben“ zwischen Anwendungen/Systemen, bei denen möglicherweise Manipulationspunkte injiziert werden.\n • Sobald Variablen gefunden wurden, beginnen Sie damit, das Feld mit logisch „ungültigen“ Daten abzufragen, wie z. B. Sozialversicherungsnummern oder eindeutige Kennungen, die nicht existieren oder die nicht zur Geschäftslogik passen.\n Dieser Test überprüft, ob der Server ordnungsgemäß funktioniert und keine logisch ungültigen Daten akzeptiert.",
      "002": "Das Fälschen von Anfragen ist eine Methode, mit der Angreifer die Front-End-GUI-Anwendung umgehen, um Informationen direkt für die Back-End-Verarbeitung zu übermitteln. Das Ziel des Angreifers besteht darin, HTTP-POST/GET-Anforderungen über einen abfangenden Proxy mit Datenwerten zu senden, die von der Geschäftslogik der Anwendung nicht unterstützt, geschützt oder erwartet werden.\n\n Schwachstellen im Zusammenhang mit der Fähigkeit, Anforderungen zu fälschen, sind für jede Anwendung einzigartig und unterscheiden sich von der Datenvalidierung der Geschäftslogik dadurch, dass der Schwerpunkt darauf liegt, den Geschäftslogik-Workflow zu unterbrechen.\n\n Die Anwendung muss intelligent genug sein und mit einer Geschäftslogik entworfen werden, die Angreifer daran hindert, Parameter vorherzusagen und zu manipulieren, um den Programm- oder Geschäftslogikfluss zu untergraben oder versteckte/undokumentierte Funktionen wie Debugging auszunutzen.\n\n Generische Testmethode\n • Überprüfen Sie die Projektdokumentation und verwenden Sie explorative Tests, um nach erratenden, vorhersagbaren oder verborgenen Funktionen von Feldern zu suchen.\n • Versuchen Sie, einmal gefundene logisch gültige Daten in die Anwendung/das System einzufügen, damit der Benutzer die Anwendung/das System gegen den normalen Arbeitsablauf der Geschäftslogik durchlaufen kann.\n\n Spezifische Testmethode 1\n • Beobachten Sie bei Verwendung eines abfangenden Proxys HTTP POST/GET und suchen Sie nach Hinweisen darauf, dass Werte in regelmäßigen Abständen inkrementiert werden oder leicht zu erraten sind.\n • Wenn sich herausstellt, dass ein Wert erraten werden kann, kann dieser Wert erraten werden\ngeändert und man kann unerwartete Sichtbarkeit erlangen.\n\n Spezifische Testmethode 2\n • Beobachten Sie bei Verwendung eines abfangenden Proxys HTTP POST/GET und suchen Sie nach Hinweisen auf versteckte Funktionen wie Debug, die ein- oder aktiviert werden können.\n • Wenn welche gefunden werden, versuchen Sie, diese Werte zu erraten und zu ändern, um eine andere Antwort oder ein anderes Verhalten der Anwendung zu erhalten.",
      "003": "Viele Anwendungen sind so konzipiert, dass sie je nach Situation des Benutzers unterschiedliche Felder anzeigen, indem einige Eingaben ausgeblendet bleiben.\nIn vielen Fällen ist es jedoch möglich, versteckte Feldwerte mithilfe eines Proxys an den Server zu senden. In diesen Fällen müssen die serverseitigen Steuerelemente intelligent genug sein, um relationale oder serverseitige Bearbeitungen durchzuführen, um sicherzustellen, dass die richtigen Daten auf der Grundlage der benutzer- und anwendungsspezifischen Geschäftslogik für den Server zugelassen werden.\n\n Darüber hinaus darf die Anwendung nicht von nicht bearbeitbaren Steuerelementen, Dropdown-Menüs oder verborgenen Feldern für die Verarbeitung der Geschäftslogik abhängen, da diese Felder nur im Kontext der Browser nicht bearbeitbar bleiben. Benutzer können ihre Werte möglicherweise mit Proxy-Editor-Tools bearbeiten und versuchen, die Geschäftslogik zu manipulieren.\n\nSchwachstellen bei der Integritätsprüfung der Geschäftslogik sind insofern einzigartig, als diese Missbrauchsfälle anwendungsspezifisch sind und wenn Benutzer in der Lage sind, Änderungen vorzunehmen, sollten sie nur in der Lage sein, bestimmte Artefakte zu bestimmten Zeiten gemäß der Geschäftsprozesslogik zu schreiben oder zu aktualisieren/bearbeiten.\nDie Anwendung muss intelligent genug sein, um auf relationale Bearbeitungen zu prüfen, und Benutzern nicht erlauben, Informationen direkt an den Server zu senden, die ungültig sind, vertrauenswürdig sind, weil sie von nicht bearbeitbaren Steuerelementen stammen oder der Benutzer nicht berechtigt ist, sie über das Front-End zu senden.\n\n Generische Testmethode\n • Überprüfen Sie die Projektdokumentation und führen Sie explorative Tests durch, um nach Teilen der Anwendung/des Systems (z. B. Eingabefelder, Datenbanken oder Protokolle) zu suchen, die Daten/Informationen verschieben, speichern oder verarbeiten.\n • Bestimmen Sie für jede identifizierte Komponente, welche Art von Daten/Informationen logisch akzeptabel ist und vor welchen Arten die Anwendung/das System schützen sollte. Überlegen Sie auch, wer gemäß der Geschäftslogik in jeder Komponente Daten/Informationen einfügen, aktualisieren und löschen darf.\n • Versuchen Sie, die Daten-/Informationswerte mit ungültigen Daten/Informationen in jede Komponente (d. h. Eingabe, Datenbank oder Protokoll) von Benutzern einzufügen, zu aktualisieren oder zu bearbeiten, die gemäß dem Geschäftslogik-Workflow nicht zulässig sein sollten. \n\n Spezifische Testmethode 1\n • Verwenden einer Proxy-Erfassung und von HTTP-Verkehr, die nach verborgenen Feldern suchen.\n • Wenn ein verborgenes Feld gefunden wird, sehen Sie, wie sich diese Felder mit der GUI-Anwendung vergleichen, und beginnen Sie, diesen Wert über den Proxy abzufragen, indem Sie verschiedene Datenwerte senden, um den Geschäftsprozess zu umgehen und Werte zu manipulieren, auf die Sie keinen Zugriff haben sollten.\n\n Spezifische Testmethode 2\n • Verwenden einer Proxy-Erfassung und von HTTP-Verkehr, um einen Ort zu suchen, an dem Informationen in Bereiche der Anwendung eingefügt werden können, die nicht bearbeitet werden können.\n • Wenn es gefunden wird, vergleichen Sie diese Felder mit der GUI-Anwendung und beginnen Sie, diesen Wert über den Proxy abzufragen, indem Sie verschiedene Datenwerte senden, um den Geschäftsprozess zu umgehen und Werte zu manipulieren, auf die Sie keinen Zugriff haben sollten.\n\n Spezifische Testmethode 3\n • Komponenten der Anwendung oder des Systems auflisten, die bearbeitet werden könnten, z. B. Protokolle oder Datenbanken.\n • Versuchen Sie für jede identifizierte Komponente, ihre Informationen zu lesen, zu bearbeiten oder zu entfernen. Beispielsweise sollten Protokolldateien identifiziert werden und Tester sollten versuchen, die gesammelten Daten/Informationen zu manipulieren.",
      "004": "Es ist möglich, dass Angreifer Informationen über eine Anwendung sammeln, indem sie die Zeit überwachen, die zum Ausführen einer Aufgabe oder zum Geben einer Antwort benötigt wird.\n Darüber hinaus können Angreifer möglicherweise entworfene Geschäftsprozessabläufe manipulieren und unterbrechen, indem sie einfach aktive Sitzungen offen halten und ihre Transaktionen nicht im „erwarteten“ Zeitrahmen übermitteln.\n\n Schwachstellen in der Prozesstiming-Logik sind insofern einzigartig, als diese manuellen Missbrauchsfälle unter Berücksichtigung des anwendungs-/systemspezifischen Ausführungs- und Transaktionstimings erstellt werden sollten.\nDas Verarbeitungstiming kann Informationen darüber geben/durchsickern lassen, was in den Hintergrundprozessen der Anwendung/des Systems getan wird. Wenn eine Anwendung es Benutzern ermöglicht, durch die Verarbeitung von Zeitvariationen zu erraten, was das nächste Ergebnis sein wird, können Benutzer sich entsprechend anpassen und das Verhalten ändern.\n\n So testen Sie #1 \n Überprüfen Sie die Projektdokumentation und verwenden Sie explorative Tests, um nach Anwendungs-/Systemfunktionen zu suchen, die sich mit der Zeit auswirken könnten. Beispielsweise die Ausführungszeit oder Aktionen, die Benutzern helfen, ein zukünftiges Ergebnis vorherzusagen, oder die es einem ermöglichen, einen Teil der Geschäftslogik oder des Workflows zu umgehen.\n Zum Beispiel Transaktionen nicht in einer erwarteten Zeit abschließen.\n\n So testen Sie #2 \n Entwickeln Sie Missbrauchsfälle und führen Sie sie aus, um sicherzustellen, dass Angreifer keinen Vorteil basierend auf einem beliebigen Timing erlangen können.",
      "005": "Viele der Probleme, die Anwendungen lösen, erfordern Begrenzungen der Häufigkeit, mit der eine Funktion verwendet oder eine Aktion ausgeführt werden kann. Anwendungen müssen „intelligent genug“ sein, um es dem Benutzer nicht zu erlauben, sein Limit für die Nutzung dieser Funktionen zu überschreiten, da der Benutzer in vielen Fällen bei jeder Verwendung der Funktion einen Vorteil erlangen kann, der berücksichtigt werden muss, um den Eigentümer angemessen zu entschädigen .\n\n Schwachstellen im Zusammenhang mit dem Testen der Funktionsgrenzen sind anwendungsspezifisch und es müssen Missbrauchsfälle erstellt werden, die darauf abzielen, Teile der Anwendung/Funktionen/oder Aktionen mehr als die zulässige Anzahl von Malen auszuführen.\nAngreifer können möglicherweise die Geschäftslogik umgehen und eine Funktion häufiger als „zulässig“ ausführen, indem sie die Anwendung zum persönlichen Vorteil ausnutzen.\n\n So testen Sie #1\n Überprüfen Sie die Projektdokumentation und verwenden Sie explorative Tests, um nach Funktionen oder Merkmalen in der Anwendung oder dem System zu suchen, die während des Geschäftslogik-Workflows nicht mehr als einmal oder eine bestimmte Anzahl von Malen ausgeführt werden sollten.\n\n So testen Sie #2\n Entwickeln Sie für jede der gefundenen Funktionen und Merkmale, die während des Geschäftslogik-Workflows nur einmal oder eine bestimmte Anzahl von Malen ausgeführt werden sollten, Missbrauchs-/Missbrauchsfälle, die es einem Benutzer ermöglichen können, mehr als die zulässige Anzahl von Malen auszuführen.\n Kann ein Benutzer zum Beispiel mehrmals durch die Seiten vor und zurück navigieren und eine Funktion ausführen, die nur einmal ausgeführt werden sollte, oder kann ein Benutzer Einkaufswagen laden und entladen, was zusätzliche Rabatte ermöglicht.",
      "006": "Workflow-Schwachstellen umfassen jede Art von Schwachstelle, die es dem Angreifer ermöglicht, eine Anwendung/ein System so zu missbrauchen, dass er den entworfenen/beabsichtigten Workflow umgehen (nicht befolgen) kann.\n\n „Ein Workflow besteht aus einer Abfolge verbundener Schritte, wobei jeder Schritt ohne Verzögerung oder Lücke folgt und endet, kurz bevor der nächste Schritt beginnen kann. Workflow kann als jede Abstraktion von echter Arbeit angesehen werden.“\n\n Die Geschäftslogik der Anwendung muss erfordern, dass der Benutzer bestimmte Schritte in der richtigen/bestimmten Reihenfolge ausführt, und wenn der Workflow ohne korrekten Abschluss beendet wird, werden alle Aktionen und hervorgebrachten Aktionen „zurückgesetzt“ oder abgebrochen.\n\n Generische Testmethode\n • Überprüfen Sie die Projektdokumentation und verwenden Sie explorative Tests, um nach Methoden zu suchen, um Schritte im Anwendungsprozess in einer anderen Reihenfolge als dem entworfenen/beabsichtigten Ablauf der Geschäftslogik zu überspringen oder fortzusetzen.\n • Entwickeln Sie für jede Methode einen Missbrauchsfall und versuchen Sie, eine Aktion zu umgehen oder auszuführen, die gemäß dem Geschäftslogik-Workflow „nicht akzeptabel“ ist.\n\n Testmethode 1\n • Starten Sie eine Transaktion, die die Anwendung hinter den Punkten durchläuft, die Gutschriften/Punkte auf dem Benutzerkonto auslöst.\n • Stornieren Sie die Transaktion oder reduzieren Sie das endgültige Angebot, sodass die Punktewerte verringert werden sollten, und überprüfen Sie das Punkte-/Credit-System, um sicherzustellen, dass die richtigen Punkte/Credits erfasst wurden.\n\n Testmethode 2\n • Auf einem Content-Management- oder Bulletin-Board-System gültige Anfangstexte oder -werte eingeben und speichern.\n • Versuchen Sie dann, Daten anzuhängen, zu bearbeiten und zu entfernen, die die vorhandenen Daten in einem ungültigen Zustand oder mit ungültigen Werten belassen würden, um sicherzustellen, dass der Benutzer nicht berechtigt ist, die falschen Informationen zu speichern.\n Bei einigen „ungültigen“ Daten oder Informationen kann es sich um bestimmte Wörter (Obszönitäten) oder bestimmte Themen (z. B. politische Themen) handeln.",
      "007": "Der Missbrauch und die ungültige Verwendung einer gültigen Funktionalität kann Angriffe identifizieren, die versuchen, die Webanwendung aufzulisten, Schwachstellen zu identifizieren und Schwachstellen auszunutzen. Es sollten Tests durchgeführt werden, um festzustellen, ob Abwehrmechanismen auf Anwendungsebene vorhanden sind, um die Anwendung zu schützen.\n\n Der Mangel an aktiver Abwehr ermöglicht es einem Angreifer, ohne Rückgriff nach Schwachstellen zu suchen. Der Eigentümer der Anwendung weiß daher nicht, dass seine Anwendung angegriffen wird.\n\n Dieser Test ist insofern ungewöhnlich, als das Ergebnis aus allen anderen Tests gezogen werden kann, die gegen die Webanwendung durchgeführt wurden.\n Beachten Sie bei der Durchführung aller anderen Tests Maßnahmen, die darauf hindeuten könnten, dass die Anwendung über einen integrierten Selbstschutz verfügt:\n • Geänderte Antworten\n • Blockierte Anfragen\n • Aktionen, die einen Benutzer abmelden oder sein Konto sperren\n\n Diese dürfen nur lokalisiert werden. Übliche lokalisierte (pro Funktion) Abwehrmaßnahmen sind:\n • Ablehnen von Eingaben, die bestimmte Zeichen enthalten\n • Vorübergehendes Sperren eines Kontos nach einer Reihe von Authentifizierungsfehlern\n\n Lokale Sicherheitskontrollen sind nicht ausreichend. Gegen allgemeinen Missbrauch wie z. B.:\n • Erzwungenes Browsen\n • Umgehen der Eingabeüberprüfung der Präsentationsschicht\n • Mehrfachzugriffskontrollfehler\n • Zusätzliche, doppelte oder fehlende Parameternamen\n • Mehrere Fehler bei der Eingabeüberprüfung oder Überprüfung der Geschäftslogik\n • Es werden strukturierte Daten (z. B. JSPN, XML) in einem ungültigen Format empfangen\n • Eklatante Cross-Site-Scripting- oder SQL-Injection-Payloads werden empfangen\n • Nutzung der Anwendung schneller als möglich\n • Änderung des kontinentalen Standorts eines Benutzers\n • Änderung des Benutzeragenten\n • Zugriff auf einen mehrstufigen Geschäftsprozess in der falschen Reihenfolge\n • Große Anzahl oder hohe Nutzungsrate anwendungsspezifischer Funktionalität\n\n Nicht alle oben genannten müssen von der Anwendung überwacht werden, aber es gibt ein Problem, wenn dies nicht der Fall ist. Wurde durch das Testen der Webanwendung durch Ausführen der oben genannten Aktionen eine Reaktion gegen den Tester vorgenommen?\n Ist dies nicht der Fall, sollte der Tester melden, dass die Anwendung offenbar keine anwendungsweite aktive Abwehr gegen Missbrauch zu haben scheint.",
      "008": "Die Geschäftsprozesse vieler Anwendungen ermöglichen das Hochladen und Bearbeiten von Daten, die über Dateien übermittelt werden.\n Das Risiko besteht darin, dass Angreifer, indem sie Benutzern erlauben, Dateien hochzuladen, einen unerwarteten Dateityp übermitteln, der ausgeführt werden und die Anwendung oder das System durch Angriffe beeinträchtigen könnte, die die Website verunstalten, Remote-Befehle ausführen, die Systemdateien durchsuchen, die lokale Ressourcen, greifen andere Server an oder nutzen die lokalen Schwachstellen aus, um nur einige zu nennen.\n\n Schwachstellen im Zusammenhang mit dem Hochladen unerwarteter Dateitypen sind insofern einzigartig, als der Upload eine Datei schnell zurückweisen sollte, wenn sie keine bestimmte Erweiterung hat. Außerdem unterscheidet sich dies vom Hochladen bösartiger Dateien darin, dass in den meisten Fällen eine falsche Datei die gespeicherten Daten schädigen kann.\n\n Generische Testmethode\n • Überprüfen Sie die Projektdokumentation und führen Sie einige explorative Tests durch, um nach Dateitypen zu suchen, die von der Anwendung/dem System „nicht unterstützt“ werden sollten.\n • Versuchen Sie, diese „nicht unterstützten“ Dateien hochzuladen, und vergewissern Sie sich, dass sie ordnungsgemäß abgelehnt werden.\n • Wenn mehrere Dateien gleichzeitig hochgeladen werden können, müssen Tests durchgeführt werden, um sicherzustellen, dass jede Datei ordnungsgemäß bewertet wird.\n\n Spezifische Testmethode\n • Studieren Sie die logischen Anforderungen der Anwendung\n • Bereiten Sie eine Bibliothek mit Dateien vor, die zum Hochladen „nicht genehmigt“ wurden und möglicherweise Dateien wie jsp-, exe- oder html-Dateien enthalten, die Skripte enthalten.\n • Navigieren Sie in der Anwendung zum Dateiübermittlungs- oder Upload-Mechanismus.\n • Reichen Sie die „nicht genehmigte“ Datei zum Hochladen ein und vergewissern Sie sich, dass sie ordnungsgemäß am Hochladen gehindert werden.",
      "009": "Die Geschäftsprozesse vieler Anwendungen ermöglichen das Hochladen von Daten/Informationen.\n Um das Risiko zu verringern, akzeptieren wir möglicherweise nur bestimmte Dateierweiterungen, aber Angreifer sind in der Lage, bösartigen Code in inaktive Dateitypen einzukapseln.\n\n Schwachstellen im Zusammenhang mit dem Hochladen bösartiger Dateien sind insofern einzigartig, als diese „bösartigen“ Dateien leicht zurückgewiesen werden können, indem eine Geschäftslogik integriert wird, die Dateien während des Hochladevorgangs scannt und die als bösartig wahrgenommenen zurückweist.\nDarüber hinaus unterscheidet sich dies vom Hochladen unerwarteter Dateien darin, dass der Dateityp zwar akzeptiert werden kann, die Datei aber dennoch für das System schädlich sein kann.\n\n Allgemeine Testmethode\n • Überprüfen Sie die Projektdokumentation und verwenden Sie explorative Tests, die die Anwendung/das System untersuchen, um festzustellen, was eine „bösartige“ Datei in Ihrer Umgebung darstellt.\n • Entwickeln oder erwerben Sie eine bekannte „bösartige“ Datei.\n • Versuchen Sie, die bösartige Datei in die Anwendung/das System hochzuladen, und vergewissern Sie sich, dass sie korrekt abgelehnt wird.\n • Wenn mehrere Dateien gleichzeitig hochgeladen werden können, müssen Tests durchgeführt werden, um sicherzustellen, dass jede Datei ordnungsgemäß bewertet wird.\n\n Spezifische Testmethode 1\n • Die Verwendung der Metasploit-Nutzlastgenerierungsfunktion generiert einen Shellcode als ausführbare Windows-Datei mit dem Metasploit-Befehl „msfpayload“.\n • Senden Sie die ausführbare Datei über die Upload-Funktion der Anwendung und prüfen Sie, ob sie akzeptiert oder ordnungsgemäß abgelehnt wird.\n\n Spezifische Testmethode 2\n • Entwickeln oder erstellen Sie eine Datei, die den Malware-Erkennungsprozess der Anwendung nicht bestehen sollte.\n (es gibt viele im Internet verfügbar wie ducklin.htm oder ducklin-html.htm)\n • Senden Sie die ausführbare Datei über die Upload-Funktion der Anwendung und prüfen Sie, ob sie akzeptiert oder ordnungsgemäß abgelehnt wird.\n\n Spezifische Testmethode 3\n • Richten Sie den abfangenden Proxy ein, um die „gültige“ Anfrage für eine akzeptierte Datei zu erfassen.\n • Senden Sie eine „ungültige“ Anfrage mit einer gültigen/akzeptablen Dateierweiterung durch und prüfen Sie, ob die Anfrage angenommen oder ordnungsgemäß abgelehnt wird."
    },
    "client": {
      "001": "DOM-based Cross-Site Scripting ist der De-facto-Name für XSS-Bugs, die das Ergebnis aktiver browserseitiger Inhalte auf einer Seite sind, typischerweise JavaScript, die Benutzereingaben erhalten und dann etwas Unsicheres damit machen, was zur Ausführung von eingeschleusten Codes führt .\n\nDas DOM oder Document Object Model ist das Strukturformat, das zur Darstellung von Dokumenten in einem Browser verwendet wird. Das DOM ermöglicht es dynamischen Skripten wie JavaScript, auf Komponenten des Dokuments wie ein Formularfeld oder ein Sitzungscookie zu verweisen.\n Eine DOM-basierte XSS-Schwachstelle kann auftreten, wenn aktiver Inhalt, z. B. eine JavaScript-Funktion, durch eine speziell gestaltete Anforderung so geändert wird, dass ein DOM-Element von einem Angreifer gesteuert werden kann.\n\n Nicht alle XSS-Fehler erfordern, dass der Angreifer den vom Server zurückgegebenen Inhalt kontrolliert, sondern können stattdessen schlechte JavaScript-Codierungspraktiken missbrauchen. Im Vergleich zu anderen Cross-Site-Scripting-Schwachstellen, bei denen ein nicht bereinigter Parameter vom Server übergeben, an den Benutzer zurückgegeben und im Kontext des Browsers des Benutzers ausgeführt wird, steuert eine DOM-basierte XSS-Schwachstelle den Fluss des Codes mithilfe von Elementen der Document Object Model (DOM) zusammen mit Code, der vom Angreifer erstellt wurde, um den Fluss zu ändern.\n Aufgrund ihrer Natur können DOM-basierte XSS-Schwachstellen in vielen Fällen ausgeführt werden, ohne dass der Server feststellen kann, was tatsächlich ausgeführt wird.\n\n Ein Angreifer kann #<script>alert(‘xss’)</script> an die betroffene Seiten-URL anhängen, was bei Ausführung das Warnfeld anzeigen würde. In diesem Fall würde der angehängte Code nicht an den Server gesendet, da alles nach dem #-Zeichen vom Browser nicht als Teil der Abfrage, sondern als Fragment behandelt wird.\n\n Testen auf DOM-basierte XSS-Schwachstellen:\n Blackbox-Tests für DOM-basiertes XSS werden normalerweise nicht durchgeführt, da der Zugriff auf den Quellcode immer verfügbar ist, da er zur Ausführung an den Client gesendet werden muss.\n Viele Websites verlassen sich auf große Funktionsbibliotheken, die sich oft über Hunderttausende von Codezeilen erstrecken und nicht selbst entwickelt wurden. In diesen Fällen wird das Top-Down-Testen oft zur einzig wirklich praktikablen Option.\n Dasselbe gilt auch für Top-Down-Tests, wenn die Eingaben oder deren Fehlen nicht von vornherein identifiziert werden. Benutzereingaben erfolgen in zwei Hauptformen:\n • Eingaben, die vom Server auf eine Weise auf die Seite geschrieben werden, die kein direktes XSS zulässt\n • Von clientseitigen JavaScript-Objekten erhaltene Eingaben\n\n Automatisiertes Testen hat nur sehr begrenzten Erfolg beim Identifizieren und Validieren von DOM-basiertem XSS, da es XSS normalerweise identifiziert, indem es eine bestimmte Nutzlast sendet und versucht, es in der Serverantwort zu beobachten.\n Daher sollten manuelle Tests durchgeführt werden, die durch Untersuchen von Bereichen im Code durchgeführt werden können, in denen auf Parameter verwiesen wird, die für einen Angreifer nützlich sein können.",
      "002": "Eine JavaScript-Injection-Schwachstelle ist eine Unterart von Cross Site Scripting (XSS), bei der beliebiger JavaScript-Code injiziert werden kann, der von der Anwendung im Browser des Opfers ausgeführt wird.\n Diese Sicherheitsanfälligkeit kann viele Konsequenzen haben, wie die Offenlegung von Sitzungscookies eines Benutzers, die verwendet werden könnten, um sich als das Opfer auszugeben, oder allgemeiner kann es dem Angreifer ermöglichen, den von den Opfern gesehenen Seiteninhalt oder das Anwendungsverhalten zu ändern.\n\n Eine solche Schwachstelle tritt auf, wenn der Anwendung eine ordnungsgemäße vom Benutzer bereitgestellte Eingabe- und Ausgabevalidierung fehlt. JavaScript wird verwendet, um Webseiten dynamisch zu füllen, diese Injektion erfolgt während dieser Inhaltsverarbeitungsphase und wirkt sich folglich auf das Opfer aus.\n Wenn Sie versuchen, diese Art von Problemen auszunutzen, bedenken Sie, dass einige Zeichen von verschiedenen Browsern unterschiedlich behandelt werden.",
      "003": "HTML-Injektion ist eine Art von Injektionsproblem, das auftritt, wenn a\nDer Benutzer kann einen Eingabepunkt steuern und beliebigen HTML-Code in eine anfällige Webseite einfügen.\nDiese Schwachstelle kann viele Konsequenzen haben, wie z. B. die Offenlegung\nvon Sitzungscookies eines Benutzers, die verwendet werden könnten, um sich als das auszugeben\nOpfer, oder allgemeiner kann es dem Angreifer ermöglichen, die zu ändern\nSeiteninhalte, die von den Opfern gesehen wurden.\n\n Diese Sicherheitsanfälligkeit tritt auf, wenn die Benutzereingabe nicht ordnungsgemäß bereinigt und die Ausgabe nicht codiert ist. Eine Injektion ermöglicht es dem Angreifer, eine bösartige HTML-Seite an ein Opfer zu senden. Der angegriffene Browser ist nicht in der Lage, die legitimen von den bösartigen Teilen zu unterscheiden (zu vertrauen) und wird folglich alle im Opferkontext als legitim analysieren und ausführen.\n\n Es gibt eine breite Palette von Methoden und Attributen, die zum Rendern von HTML-Inhalten verwendet werden können. Wenn diese Methoden mit einer nicht vertrauenswürdigen Eingabe versehen sind, besteht ein hohes XSS-Risiko.\n Bösartiger HTML-Code könnte beispielsweise über innerHTML eingeschleust werden, das verwendet wird, um vom Benutzer eingefügten HTML-Code wiederzugeben. Eine unsachgemäße Verwendung dieser Eigenschaft bedeutet mangelnde Bereinigung durch nicht vertrauenswürdige Eingaben und fehlende Ausgabecodierung.\n Wenn Zeichenfolgen nicht korrekt bereinigt werden, kann das Problem zu einer XSS-basierten HTML-Injektion führen.\n Eine andere Methode könnte document.write() sein.\n\nWenn Sie versuchen, diese Art von Problemen auszunutzen, bedenken Sie, dass einige Zeichen von verschiedenen Browsern unterschiedlich behandelt werden.",
      "004": "Die clientseitige URL-Umleitung, auch bekannt als offene Umleitung, ist ein Eingabevalidierungsfehler, der auftritt, wenn eine Anwendung eine benutzergesteuerte Eingabe akzeptiert, die einen Link angibt, der zu einer externen URL führt, die bösartig sein könnte.\nDiese Art von Schwachstelle könnte verwendet werden, um einen Phishing-Angriff durchzuführen oder ein Opfer auf eine infizierte Seite umzuleiten.\n\nDiese Schwachstelle tritt auf, wenn eine Anwendung nicht vertrauenswürdige Eingaben akzeptiert, die einen URL-Wert enthalten, ohne sie zu bereinigen. Dieser URL-Wert könnte dazu führen, dass die Webanwendung den Benutzer auf eine andere Seite umleitet, beispielsweise eine bösartige Seite, die vom Angreifer kontrolliert wird.\n\n Durch das Ändern einer nicht vertrauenswürdigen URL-Eingabe zu einer bösartigen Website kann ein Angreifer erfolgreich einen Phishing-Betrug starten und Benutzeranmeldeinformationen stehlen.\n Darüber hinaus könnten offene Umleitungen auch verwendet werden, um böswillig eine URL zu erstellen, die die Zugriffskontrollprüfungen der Anwendung umgeht und den Angreifer dann zu privilegierten Funktionen weiterleitet, auf die er normalerweise keinen Zugriff hätte.\n\n Testen auf Sicherheitslücken bei der Client-seitigen URL-Umleitung:\nWenn Tester manuell nach dieser Art von Schwachstelle suchen müssen, müssen sie feststellen, ob clientseitige Umleitungen im clientseitigen Code implementiert sind.\n Diese Umleitungen könnten beispielsweise in JavaScript über das Objekt „window.location“ implementiert werden, mit dem der Browser durch einfaches Zuweisen eines Strings auf eine andere Seite geleitet werden kann. Wenn das Skript keine Validierung der Variablen „redir“ durchführt, wird diese nicht validierte Eingabe an das windows.location-Objekt weitergeleitet, wodurch eine URL-Umleitungs-Schwachstelle entsteht.",
      "005": "Eine CSS-Injection-Schwachstelle beinhaltet die Möglichkeit, beliebigen CSS-Code im Kontext einer vertrauenswürdigen Website einzufügen, und dieser wird im Browser des Opfers gerendert.\nDie Auswirkungen einer solchen Schwachstelle können je nach bereitgestellter CSS-Payload variieren: Sie könnte unter Umständen zu Cross-Site Scripting, zu Datenexfiltration im Sinne des Extrahierens sensibler Daten oder zu UI-Modifikationen führen.\n\n Eine solche Schwachstelle tritt auf, wenn die Anwendung die Bereitstellung von benutzergeneriertem CSS zulässt oder es möglich ist, irgendwie in die legitimen Stylesheets einzugreifen.\n Das Einfügen von Code in den CSS-Kontext gibt dem Angreifer die Möglichkeit, JavaScript unter bestimmten Bedingungen auszuführen sowie sensible Werte durch CSS-Selektoren und Funktionen zu extrahieren, die HTTP-Anforderungen generieren können.\n\n Insbesondere könnte der Angreifer das Opfer angreifen, indem er es auffordert, die folgenden URLs zu besuchen:\n • www.victim.com/#red;-o-link:’javascript:alert(1)’;-o-linksource:current; (Oper [8,12])\n • www.victim.com/#red;-:expression(alert(URL=1)); (IE 7/8)\n\n Viel interessantere Angriffsszenarien beinhalten die Möglichkeit, Daten durch die Übernahme reiner CSS-Regeln zu extrahieren.\nSolche Angriffe können über CSS-Selektoren durchgeführt werden und zum Beispiel dazu führen, Anti-CSRF-Token zu stehlen.\n\n Testen auf CSS-Injection-Schwachstellen:\n Es müssen manuelle Tests durchgeführt und der JavaScript-Code analysiert werden, um zu verstehen, ob die Angreifer eigene Inhalte im CSS-Kontext einfügen können. Insbesondere sollte uns interessieren, wie die Website CSS-Regeln auf Basis der Eingaben zurückgibt.",
      "006": "Eine ClientSide Resource Manipulation-Schwachstelle ist ein Fehler bei der Eingabevalidierung, der auftritt, wenn eine Anwendung eine benutzergesteuerte Eingabe akzeptiert, die den Pfad einer Ressource angibt (d. h. die Quelle eines Iframes, js, Applets).\nEine solche Schwachstelle besteht insbesondere in der Möglichkeit, die URLs zu kontrollieren, die auf einige auf einer Webseite vorhandene Ressourcen verweisen.\n Die Auswirkungen können je nach Art des Elements variieren, dessen URL vom Angreifer kontrolliert wird, und es wird normalerweise verwendet, um Cross-Site-Scripting-Angriffe durchzuführen.\n\n Eine solche Schwachstelle tritt auf, wenn die Anwendung Benutzer verwendet\nkontrollierte URLs zum Verweisen auf externe/interne Ressourcen.\n Unter diesen Umständen ist es möglich, das Verhalten der erwarteten Anwendung zu beeinträchtigen, indem schädliche Objekte geladen und wiedergegeben werden.\n\n Testen auf Sicherheitslücken in Bezug auf clientseitige Ressourcenmanipulation:\nUm manuell nach dieser Art von Schwachstelle zu suchen, müssen wir feststellen, ob die Anwendung Eingaben verwendet, ohne sie korrekt zu validieren. Diese stehen unter der Kontrolle des Benutzers, der möglicherweise die URL einiger Ressourcen angeben kann.\n Da es viele Ressourcen gibt, die in die Anwendung aufgenommen werden könnten, sollten clientseitige Skripts, die die zugehörigen URLs verarbeiten, auf mögliche Probleme untersucht werden. \n\n Nachfolgend sind die möglichen Injektionsstellen (Sink) aufgeführt, die überprüft werden sollten: \n • Ressource: Frame \n • Tag/Methode: iframe \n • Sink: src \n\n • Ressource: Link \n • Tag/Methode: a \n • Sink: href\n\n • Ressource: AJAX Request \n • Tag/Methode: xhr.open(method, [url], true); \n • Sink: URL  href\n\n • Ressource: CSS \n • Tag/Methode: link \n\n • Ressource: Image \n • Tag/Methode: img \n\n • Ressource: Object \n • Tag/Methode: object \n • Sink: src\n\n • Ressource: Script \n • Tag/Methode: script \n • Sink: data  src",
      "007": "Cross Origin Resource Sharing oder CORS ist ein Mechanismus, der es einem Webbrowser ermöglicht, „domänenübergreifende“ Anforderungen mithilfe der XMLHttpRequest L2-API auf kontrollierte Weise auszuführen.\n In der Vergangenheit erlaubte die XMLHttpRequest L1-API nur das Senden von Anforderungen innerhalb desselben Ursprungs, da sie durch dieselbe Ursprungsrichtlinie eingeschränkt war.\n\n Cross-Origin-Anfragen haben einen Origin-Header, der die Domäne identifiziert, die die Anfrage initiiert, und immer an den Server gesendet wird. CORS definiert das Protokoll, das zwischen einem Webbrowser und einem Server verwendet werden soll, um festzustellen, ob eine Cross-Origin-Anforderung zulässig ist.\n Um dieses Ziel zu erreichen, sind an diesem Prozess einige HTTP-Header beteiligt, die von allen gängigen Browsern unterstützt werden, darunter:\n • Origin \n • Access-Control-Request-Method \n • Access-Control-Request-Headers \n • Access-Control-Allow-Origin \n • Access-Control-Allow-Credentials \n • Access-Control-Allow-Methods \n • Access-Control-Allow-Headers\n\n Die CORS-Spezifikation schreibt vor, dass für nicht einfache Anforderungen, wie z. B. andere Anforderungen als GET oder POST oder Anforderungen, die Anmeldeinformationen verwenden, im Voraus eine OPTIONS-Anforderung vor dem Flug gesendet werden muss, um zu prüfen, ob sich der Anforderungstyp negativ auf die Daten auswirkt .\n Die Preflight-Anforderung prüft die vom Server zugelassenen Methoden und Header, und wenn Anmeldeinformationen zulässig sind, entscheidet der Browser basierend auf dem Ergebnis der OPTIONS-Anforderung, ob die Anforderung zugelassen wird oder nicht.\n\n Überprüfen Sie die HTTP-Header, um zu verstehen, wie CORS verwendet wird, insbesondere sollten wir uns sehr für den Origin-Header interessieren, um zu erfahren, welche Domänen zulässig sind.\n Außerdem ist eine manuelle Überprüfung des JavaScripts erforderlich, um festzustellen, ob der Code aufgrund einer unsachgemäßen Handhabung von Benutzereingaben anfällig für Code-Injection ist.",
      "008": "ActionScript ist die auf ECMAScript basierende Sprache, die von Flash-Anwendungen verwendet wird, wenn es um interaktive Anforderungen geht.\n Dort sind drei\nVersionen der ActionScript-Sprache. ActionScript 1.0 und ActionScript 2.0 sind sich sehr ähnlich, wobei ActionScript 2.0 eine Erweiterung von ActionScript 1.0 ist. ActionScript 3.0, eingeführt mit Flash Player 9, ist eine Neufassung der Sprache, um objektorientiertes Design zu unterstützen.\n\n ActionScript hat wie jede andere Sprache einige Implementierungsmuster, die zu Sicherheitsproblemen führen können.\n Da Flash-Anwendungen oft in Browser eingebettet sind, können Schwachstellen wie DOM-basiertes Cross-Site Scripting (XSS) in fehlerhaften Flash-Anwendungen vorhanden sein.\n\n Dekompilierung\n Da SWF-Dateien von einer im Player selbst eingebetteten virtuellen Maschine interpretiert werden, können sie möglicherweise dekompiliert und analysiert werden. Der bekannteste und kostenlosste ActionScript 2.0-Decompiler ist Flare.\n Die Dekompilierung hilft Testern, da sie ein quellcodegestütztes oder White-Box-Testen der Flash-Anwendungen ermöglicht. Das kostenlose Tool SWFScan von HP kann sowohl ActionScript 2.0 als auch ActionScript 3.0 dekompilieren.\n\n Angriffe und Flash-Player-Version Seit Mai 2007 wurden drei neue Versionen des Flash-Players von Adobe veröffentlicht. Jede neue Version schränkt einige der Angriffe ein.\n\n Player-Version: v9.0 r47/48\n • asfunction: Ja\n • Externe Schnittstelle: Ja\n • GetURL: Ja\n • HTML-Injektion: Ja\n\n Player-Version: v9.0 r115\n • asfunction: Nein\n • Externe Schnittstelle: Ja\n • GetURL: Ja\n • HTML-Injektion: Ja\n\n Player-Version: v9.0 r124\n • asfunction: Nein\n • Externe Schnittstelle: Ja\n • GetURL: Ja\n • HTML-Injection: Teilweise",
      "009": "„Clickjacking“ (das eine Teilmenge des „UI-Redressing“ ist) ist eine bösartige Technik, die darin besteht, einen Webbenutzer dazu zu verleiten, mit etwas zu interagieren, das anders ist als das, womit der Benutzer glaubt, dass er interagiert.\n Diese Art von Angriff, der allein oder in Kombination mit anderen Angriffen verwendet werden kann, könnte möglicherweise nicht autorisierte Befehle senden oder vertrauliche Informationen preisgeben, während das Opfer auf scheinbar harmlosen Webseiten interagiert.\n\n Ein Clickjacking-Angriff verwendet scheinbar harmlose Funktionen von HTML und Javascript, um das Opfer zu unerwünschten Aktionen zu zwingen, wie z. B. das Klicken auf eine Schaltfläche, die scheinbar eine andere Operation ausführt.\n\n Um diese Art von Technik auszuführen, muss der Angreifer eine scheinbar harmlose Webseite erstellen, die die Zielanwendung durch die Verwendung eines Iframes lädt.\n Sobald dies geschehen ist, könnte der Angreifer das Opfer dazu bringen, mit seiner fiktiven Webseite zu interagieren.\nSobald das Opfer auf der fiktiven Webseite surft, denkt es, dass es mit der sichtbaren Benutzeroberfläche interagiert, tatsächlich führt es jedoch Aktionen auf der versteckten Seite aus.\n\nDiese Art von Angriff ist häufig darauf ausgelegt, einer angreifenden Website zu ermöglichen, Benutzeraktionen auf der Ziel-Website zu veranlassen, selbst wenn Anti-CSRF-Token verwendet werden. . Daher ist es wichtig, wie beim CSRF-Angriff, Webseiten der Zielseite so zu kennzeichnen, dass sie Eingaben des Benutzers entgegennehmen.\n\nWir müssen herausfinden, ob die Website, die wir testen, keinen Schutz vor Clickjacking-Angriffen hat oder, ob die Entwickler Schutzmaßnahmen implementiert haben, ob diese Techniken umgangen werden können.\nMethoden zum Schutz einer Webseite vor Clickjacking können in zwei Makrokategorien unterteilt werden:\n • Clientseitiger Schutz: Frame Busting\n • Serverseitiger Schutz: X-Frame-Optionen\n\n Einige Frame-Busting-Techniken versuchen, Frames zu unterbrechen, indem sie dem Attribut „parent.location“ in der „counter-action“-Anweisung einen Wert zuweisen. Solche Aktionen sind zum Beispiel:\n • self.parent.location = document.location\n • parent.location.href = self.location\n • parent.location = self.location",
      "010": "Traditionell erlaubt das HTTP-Protokoll nur eine Anfrage/Antwort pro TCP-Verbindung. Asynchronous JavaScript and XML (AJAX) ermöglicht es Clients, Daten asynchron an den Server zu senden und zu empfangen, AJAX erfordert jedoch, dass der Client die Anforderungen initiiert und auf die Serverantworten wartet (Halbduplex).\n\n HTML5-WebSockets ermöglichen es dem Client/Server, „Vollduplex“-Kommunikationskanäle (zwei Wege) zu erstellen, sodass Client und Server wirklich asynchron kommunizieren können. WebSockets führen ihren anfänglichen „Upgrade“-Handshake über HTTP durch und von da an wird die gesamte Kommunikation über TCP-Kanäle unter Verwendung von Frames ausgeführt.\n\n 1: Identifizieren Sie, dass die Anwendung WebSockets verwendet\n • Untersuchen Sie den clientseitigen Quellcode auf das URI-Schema ws:// oder wss://\n • Verwenden Sie Browser Developer Tools, um die Netzwerk-WebSocket-Kommunikation anzuzeigen\n • Verwenden Sie die WebSocket-Registerkarte von OWASP Zed Attack Proxy (ZAP).\n\n 2: Ursprung\n • Versuchen Sie mithilfe eines WebSocket-Clients, eine Verbindung zum Remote-WebSocket-Server herzustellen\n • Wenn eine Verbindung hergestellt wird, überprüft der Server möglicherweise nicht den Ursprungsheader des WebSocket-Handshakes\n\n 3: Vertraulichkeit und Integrität\n • Überprüfen Sie, ob die WebSocket-Verbindung SSL verwendet, um vertrauliche Informationen zu übertragen (wss://)\n • Überprüfen Sie die SSL-Implementierung auf Sicherheitsprobleme (gültiges Zertifikat, BEAST, CRIME, RC4 usw.).\n\n 4: Authentifizierung\n • WebSockets führen keine Authentifizierung durch, es sollten normale Blackbox-Authentifizierungstests durchgeführt werden\n\n 5: Autorisierung\n • WebSockets behandeln keine Autorisierung, es sollten normale Blackbox-Autorisierungstests durchgeführt werden\n\n 6: Eingangsbereinigung\n • Verwenden Sie die WebSocket-Registerkarte von OWASP Zed Attack Proxy (ZAP), um WebSocket-Anforderungen und -Antworten wiederzugeben und zu fuzzen",
      "011": "Web Messaging (auch bekannt als Cross Document Messaging) ermöglicht Anwendungen, die auf verschiedenen Domänen ausgeführt werden, auf sichere Weise zu kommunizieren.\n Diese Einschränkung im Browser dient dazu, eine böswillige Website daran zu hindern, vertrauliche Daten von anderen iFrames, Registerkarten usw. zu lesen. Es gibt jedoch einige legitime Fälle, in denen zwei vertrauenswürdige Websites Daten untereinander austauschen müssen. Um diesem Bedarf gerecht zu werden, wurde Cross Document Messaging innerhalb der WHATWG-HTML5-Entwurfsspezifikation eingeführt und in allen gängigen Browsern implementiert.\n Es ermöglicht eine sichere Kommunikation zwischen mehreren Ursprüngen über iFrames, Registerkarten und Fenster hinweg.\n\n Die Messaging-API führte die Methode postMessage() ein, mit der Klartext-Nachrichten ursprungsübergreifend versendet werden können. Es besteht aus zwei Parametern, Nachricht und Domäne.\n\n Es gibt einige Sicherheitsbedenken bei der Verwendung von „*“ als Domain, die wir unten besprechen. Um dann Nachrichten zu empfangen, muss die empfangende Website einen neuen Event-Handler hinzufügen und hat die folgenden Attribute:\n • data: Der Inhalt der eingehenden Nachricht\n • Herkunft: Die Herkunft des Absenderdokuments\n • Quelle: Quellfenster\n\nEs müssen manuelle Tests durchgeführt und der JavaScript-Code analysiert werden, um herauszufinden, wie Web Messaging implementiert ist.\nInsbesondere sollte uns interessieren, wie die Website Nachrichten von nicht vertrauenswürdigen Domänen einschränkt und wie die Daten selbst für vertrauenswürdige Domänen gehandhabt werden.",
      "012": "Lokaler Speicher, auch als Webspeicher oder Offlinespeicher bekannt, ist ein Mechanismus zum Speichern von Daten als Schlüssel/Wert-Paare, die an eine Domäne gebunden sind und durch dieselbe Ursprungsrichtlinie (SOP) erzwungen werden.\n Es gibt zwei Objekte, localStorage, das persistent ist und Neustarts des Browsers/Systems überstehen soll, und sessionStorage, das temporär ist und nur existiert, bis das Fenster oder die Registerkarte geschlossen wird.\n Im Durchschnitt erlauben Browser in diesem Speicher etwa 5 MB pro Domain zu speichern, was im Vergleich zu den 4 KB Cookies ein großer Unterschied ist, aber der Hauptunterschied aus Sicherheitsperspektive besteht darin, dass die in diesen beiden Objekten gespeicherten Daten im Client und niemals gespeichert werden an den Server gesendet.\n\n Zunächst müssen wir prüfen, ob der Local Storage verwendet wird. Dies kann überprüft werden, wenn Sie das Browser-Tool verwenden, und dann unter Ressourcen zu „Lokaler Speicher“ und „Webspeicher“ gehen.\n\n Als nächstes müssen manuelle Tests durchgeführt werden, um festzustellen, ob die Website sensible Daten im Speicher speichert, die ein Risiko darstellen und die Auswirkungen eines Informationslecks dramatisch erhöhen werden.\n Überprüfen Sie auch den Code, der den Speicher verarbeitet, um festzustellen, ob er anfällig für Injektionsangriffe ist, ein häufiges Problem, wenn der Code der Eingabe oder Ausgabe nicht entkommt."
    },
    "no_info": "Kein Informationen für die gegebene Referenznummer gefunden."
  }
}

