Globale Konfigurationsdatei

Die Datei inquiry-global.config enthält die Schutzregeln, die für alle Formulare eines Shops gelten. Jede Regel lässt sich global aktivieren und für einzelne Formulare gezielt ein- oder ausschalten. Die Einstellungen des einzelnen Formulars stehen dagegen in seiner Konfigurationsdatei.

Globale Konfigurationsdatei inquiry-global.config

Zusätzlich zu den individuellen Formular-Konfigurationsdateien kann auch eine globale Konfigurationsdatei angelegt werden, deren Einstellungen sich im Standard auf alle Formulare des Shops beziehen. Innerhalb der Datei kann definiert werden, ob die Einstellungen tatsächlich für alle Formulare des Shops gelten oder nur für bestimmte Formulare. Diese Konfigurationsdatei muss inquiry-global.config heißen. Sie muss im Online Servicebereich im Service Konfiguration unterhalb des Tabs Konfiguration > Shop im Abschnitt Global.

Erklärung und Beschreibung der Parameter

Parameter und Erklärungen für <Protection>

<Protection>
  <+Entry>
      ID =
      Action =
      Standard =
      Type =
      RegEx =
      IPReputationList =
      WAF =
      CheckExtern =
      CheckExternBasicAuth =
      FilterSigns =
   </+Entry>
</Protection>

Über den Abschnitt <Protection> können erweiterte Sicherheitsmechanismen zur Vermeidung von SPAM für die Formulare hinterlegt werden, die über das WEBSALE Formular-Modul Inquiry4 erstellt worden sind.

Parameter	Beschreibung	Werte
+Entry	* Pro Sicherheitsmechanismus-Typ muss ein eigener Abschnitt erstellt werden. * UND-Verknüpfung aller aktiven Sicherheitsmechanismen: Damit das Formular versendet werden kann, müssen alle als aktiv definierten Prüfungen erfolgreich sein * Welche Prüfungen für eine Anfrage aktiv sind, kann zusätzlich über die Konfiguration des jeweiligen Anfrageformulars gesteuert werden * Falls in der Formularkonfiguration keine spezifischen Angaben gemacht wurden, gelten alle als aktiv definierten Prüfungen aus der inquiry-global.config automatisch

Parameter und Erklärungen für +Entry

Parameter	Beschreibung	Werte
`ID`	* Kennung für den +Entry-Eintrag * Kann frei vergeben werden	* Text
`Standard`	* Aktivierung / Deaktivierung des hinterlegten Prüfungsmechanismus für den +Entry-Eintrag * active + Ist der Parameter “active” gesetzt, dann wird die Prüfung automatisch auf alle Formulare angewandt + Die Deaktivierung für einzelne Formulare erfolgt über die individuelle Formular-Konfigurationen * inactive + Ist der Parameter “inactive” gesetzt, dann wird die Prüfung nicht automatisch auf alle Formulare angewandt + Die Aktivierung für einzelne Formulare muss dann über die individuelle Formular-Konfigurationen erfolgen	* active (Standard) * inactive
`Action`	* Der Parameter `Action` legt fest, wie das System mit einer als SPAM oder unerwünscht erkannten Anfrage umgeht. * Diese beiden Mechanismen bieten eine flexible Möglichkeit, Spammer entweder direkt zu blockieren (`Block`) oder sie in eine Schein-Annahme zu führen (`Ignore`), um automatisierte Spam-Versuche wirkungslos zu machen. * block + Die Anfrage kann nicht abgesendet werden. Dies entspricht dem Verhalten bei einer fehlerhaften Eingabe im Formular. + Der Anfragende (beispielsweise ein Spammer) kann optional eine Fehlermeldung angezeigt bekommen, die über die im Template definiert werden kann. * ignore + Der Anfragende erhält eine Erfolgsmeldung, inklusive Referenznummer und sonstiger Bestätigungsinformationen. + Es wird der Eindruck vermittelt, dass die Anfrage erfolgreich abgesendet wurde. + Tatsächlich wird die Anfrage jedoch vom WEBSALE-Shopsystem nicht verarbeitet: - Sie wird nicht an den Shopbetreiber weitergeleitet. - Es werden keine Inquiry-E-Mails versendet. - Die Anfrage ist nicht im Online-Servicebereich einsehbar.	* block (Standard) * ignore
`Type`	* Art des Sicherheitsmechanismus, der hinterlegt werden soll	* RegEx * IPReputationList * RestrictiveWAFPolicies * CheckExtern * FilterSigns
`RegEx`	* Bei `Type = RegEx` * Es wird eine Zeichenkette definiert, die einem regulären Ausdruck (RegEx) entspricht. * Der RegEx gibt vor, was als ungültig gilt. * Wenn die Eingabe mit dem angegebenen regulären Ausdruck übereinstimmt, wird sie als ungültig eingestuft. * Diese Prüfung gilt ausnahmslos für alle Eingabefelder in den Formularen.	* Zeichenkette
`IPReputationList`	* Bei `Type = IPReputationList` * Die IP-Adresse des Nutzers wird mit einer oder mehreren dieser Listen abgeglichen. * Falls die IP-Adresse in einer dieser Listen auftaucht, kann die Anfrage blockiert oder markiert werden. * Folgende Listen werden unterstützt und können angegeben werden: + `blocklist.de` + `firehol.org` + `firehol.org-1` + `firehol.org-2` + `firehol.org-3` + `firehol.org-4` + `stopforumspam.com`	* Kommaseparierte Angabe mehrerer Listen-Anbieter
`WAF`	* Bei `Type = RestrictiveWAFPolicies` * Die aktivierte WAF-Policy setzt die aktuellen Sicherheitsregeln des OWASP Core Rule Set (CRS) ein. * Diese Regeln schützen vor einer Vielzahl von Webangriffen, darunter: + SQL-Injections (SQLi) + Cross-Site Scripting (XSS) + Remote Code Execution (RCE) + Local File Inclusion (LFI) + Command Injection etc. * Da die Sicherheitsregeln regelmäßig aktualisiert werden, empfehlen wir die offizielle Dokumentation des OWASP CRS-Projekts für detaillierte Informationen: 🔗 OWASP Core Rule Set (CRS) Project	* ohne Angaben
`CheckExtern`	* Bei `Type = CheckExtern` * Der Parameter `CheckExtern` ermöglicht die Anbindung einer externen Prüfungs-API, um Formulareingaben vor der Verarbeitung zu validieren. * Angabe einer HTTPS-URL erforderlich, unter der die externe Prüfung durchgeführt wird, zum Beispiel `https://my-own-spam-checker.example.com` * Das System sendet alle relevanten Daten des Formulars als POST-Anfrage in einem JSON-Objekt an die angegebene URL. * Es wird eine entsprechende JSON-Antwort erwartet, die die Gültigkeit der Anfrage bewertet. * Wichtig ist, dass das externe System innerhalb von 3 Sekunden antwortet, ansonsten wird dies als Kommunikationfehler interpretiert.	* Angabe einer HTTPS-URL
`CheckExternBasicAuth`	* Bei `Type = CheckExtern` * Dieser Parameter ermöglicht die Authentifizierung per Basic Authentication (BasicAuth) für den externen Prüfungsdienst, der über `CheckExtern` angebunden ist. * Ermöglicht den Schutz des externen Dienstes durch eine einfache Authentifizierungsmethode. * Der Wert muss in der Form `<Username>:<Passwort>` angegeben werden. + Beispiel: `inquiry:geheim123` + Die Zugangsdaten werden in der HTTP-Request als`Authorization`-Header im Base64-Format gesendet. * Diese Methode stellt eine weit verbreitete und einfache Möglichkeit zur Authentifizierung dar, sollte jedoch bevorzugt in Kombination mit HTTPS genutzt werden, um die Sicherheit der Zugangsdaten zu gewährleisten.	* Zeichenkette (String) * Kombination aus Benutzername und Passwort, getrennt durch einen Doppelpunkt (`:`)
`CheckExternOnErrorBehavior`	* Bei `Type = CheckExtern` * Legt das Verhalten fest, falls die externe Prüfung (`CheckExtern`) technisch fehlschlägt, beispielsweise wenn das externe System nicht erreichbar ist oder keine gültige Antwort zurückliefert. * Mögliche Werte + `block` → Restriktiv: Ohne eine eindeutige Antwort (`ja` oder `nein`) vom externen System wird die Anfrage nicht zugelassen. + `pass` → Fehlertolerant: Falls das externe System nicht erreichbar ist oder keine Antwort liefert, wird die Anfrage trotzdem akzeptiert.	* block (Standard) * pass
`CheckExternBearerToken`	* Bei `Type = CheckExtern` * Dieser Parameter ermöglicht die Authentifizierung per Bearer-Token für den externen Prüfungsdienst, der über `CheckExtern` angebunden ist. * Alternative zu`CheckExternBasicAuth` * Das angegebene Token wird als Authorization-Header (`Authorization: Bearer <Token>`) in der Anfrage mitgesendet. * Funktioniert ähnlich wie ein API-Key, um den Zugriff auf den externen Prüfdienst zu schützen	* Zeichenkette (String) * Gültiges Bearer-Token, beispielsweise `abc123xyz456`
`FilterSigns`	* Bei `Type = FilterSigns` * Liste der Zeichen, die bei Angaben in Formularen entfernt werden sollen * Die Zeichen werden mit dem Absenden einfach entfernt. Der Nutzer, der das Formular auzsfüllt, erhält keine Meldung darüber. * Beim Feld E-Mail-Adresse gibt es eine feste Ausnahmeliste von Zeichen, die niemals entfernt werden, auch wenn sie in `FilterSigns` enthalten sind: @ ! # $ % & \ * + - / = ? ^ _ , ` ~ sowie die geschweiften Klammern * Diese Zeichen gehören zum gültigen Zeichensatz für E-Mail-Adressen gemäß RFC 5322 und sind daher vom Filtermechanismus ausgenommen.	* Zeichen * Mehrere Zeichen werden ohne Trennzeichen angegeben.

Aktivierung / Deaktivierung nur für bestimmte Formulare

Aktivierung nur für bestimmte Formulare

Die Einschränkung bestimmter Zeichenfolgen, beispielsweise das Untersagen der Eingabe von „ABCDE“, wird in der Datei inquiry-global.config definiert. Diese Einschränkung ist jedoch standardmäßig nicht für alle Formulare aktiv (Standard = inactive).

<Protection>
...
  <+Entry>
      ID = deleteRule
      Standard = inactive
      Type = FilterSigns
      FilterSigns = ABCDE
  </+Entry>
...
</Protection>

Um die Zeichenfolgenprüfung gezielt für ein bestimmtes Formular, beispielsweise das Kontaktformular (contact.config), zu aktivieren, muss der folgende Eintrag in der zugehörigen Formular-Konfigurationsdatei vorgenommen werden:

<Protection>
  +ID = deleteRule
</Protection>

Innerhalb des <Protection>-Abschnitts können über den Parameter +ID gezielt Sicherheitsmechanismen aus der globalen Konfigurationsdatei eingebunden und aktiviert werden. Dadurch lässt sich flexibel steuern, welche Schutzmaßnahmen für welche Formulare gelten.

Deaktivierung nur für bestimmte Formulare

In der Datei inquiry-global.config wird die Zeichenfolgenprüfung, beispielsweise das Untersagen der Eingabe von „ABCDE“, standardmäßig für alle Formulare aktiviert (Standard = active).

<Protection>
...
  <+Entry>
      ID = deleteRule
      Standard = active
      Type = FilterSigns
      FilterSigns = ABCDE
  </+Entry>
...
</Protection>

Falls diese Zeichenfolgenprüfung für ein bestimmtes Formular, beispielsweise das Kontaktformular (contact.config), deaktiviert werden soll, muss in der jeweiligen Formular-Konfigurationsdatei folgender Eintrag vorgenommen werden:

<Protection>
  -ID = deleteRule
</Protection>

Innerhalb des <Protection>-Abschnitts können über den Parameter -ID gezielt Sicherheitsmechanismen aus der globalen Konfigurationsdatei deaktiviert werden. Dadurch lässt sich flexibel steuern, welche Schutzmaßnahmen für welche Formulare gelten.

Konfiguration von IP-Reputationslisten

Die IPReputationList ermöglicht den Abgleich eingehender Anfragen mit bekannten IP-Reputationslisten.Dadurch können Anfragen von als schädlich oder verdächtig eingestuften IP-Adressen automatisch blockiert werden. In der globalen Konfigurationsdatei inquiry-global.configmuss der folgende +Entry hinzugefügt werden, um die Überprüfung gegen bestimmte IP-Reputationslisten zu aktivieren.

<Protection>
  ...
  <+Entry>
      ID = IPListValditation
      Standard = active
      Action = block
      Type = IPReputationList
      IPReputationList = blocklist.de, firehol.org-1, firehol.org-2, firehol.org-3, firehol.org-4, stopforumspam.com
  </+Entry>
  ...
</Protection>

Attribute
- ID = IPListValidation: Eindeutige ID für diesen Sicherheitsmechanismus.
- Standard = active: Die Regel ist standardmäßig aktiv, sofern sie nicht explizit in einem bestimmten Formular deaktiviert wird.
- Action = block: Gibt an, dass Anfragen von einer gelisteten IP blockiert werden. Alternativ kann ignore gesetzt werden
- Type = IPReputationList: Definiert den Sicherheitsmechanismus als IP-Reputationsprüfung.
- IPReputationList =: Liste der externen IP-Blocklisten, die zur Prüfung herangezogen werden. Mehrere Werte werden durch Kommas getrennt.

Alle Parameter und deren Beschreibung sind unter “Parameter und Erklärungen für+Entry” noch einmal ausführlich aufgeführt.

Konfiguration Web Application Firewall (WAF)-Prüfungen

Die Web Application Firewall (WAF) schützt vor bekannten Angriffsvektoren, indem verdächtige oder schädliche Anfragen automatisch erkannt und blockiert werden. In der globalen Konfigurationsdatei inquiry-global.config muss der folgende +Entry hinzugefügt werden, um die WAF-Prüfung zu aktivieren:

<Protection>
...
  <+Entry>
      ID = WAFValidation
      Standard = active
      Action = block
      Type = RestrictiveWAFPolicies
      WAF =
  </+Entry>
...
</Protection>

Attribute
- ID = WAFValidation: Eindeutige ID für diesen Sicherheitsmechanismus.
- Standard = active: Die Regel ist standardmäßig aktiv, sofern sie nicht explizit in einem bestimmten Formular deaktiviert wird.
- Action = block: Gibt an, dass Anfragen, die gegen WAF-Regeln verstoßen, blockiert werden. Alternativ kann ignore gesetzt werden.
- Type = RestrictiveWAFPolicies: Definiert den Sicherheitsmechanismus als restriktive WAF-Policy.
- WAF =: Platzhalter für zukünftige spezifische WAF-Regeln. Aktuell leer, da die Standardregeln des OWASP Core Rule Set angewendet werden (Stand: 03/2025)

Alle Parameter und deren Beschreibung sind unter “Parameter und Erklärungen für+Entry” noch einmal ausführlich aufgeführt.

Konfiguration eigener Prüfungsmechanismen über REST-Schnittstelle

Die CheckExtern-Funktion ermöglicht es, eine externe Prüfungs-API einzubinden, um Formulareingaben vor der Verarbeitung zu validieren. Alle relevanten Eingabedaten werden per Server-zu-Server-POST-Anfrage als JSON an die angegebene URL gesendet. Die Antwort entscheidet, ob die Anfrage weiterverarbeitet oder blockiert wird. In der globalen Konfigurationsdatei inquiry-global.config muss der folgende +Entry hinzugefügt werden, um eine externe Prüfung zu aktivieren:

<Protection>
  ...
  <+Entry>
      ID = externValidation
      Standard = active
      Action = block
      Type = CheckExtern
      CheckExternURL = https://example.com/api/check
      CheckExternOnErrorBehavior = block
      CheckExternBasicAuth = user:pass
      CheckExternBearerToken = secrettoken123
  </+Entry>
  ...
</Protection>

Attribute
- ID = externValidation: Eindeutige ID für diesen Sicherheitsmechanismus.
- Standard = active: Die Regel ist standardmäßig aktiv, sofern sie nicht explizit in einem bestimmten Formular deaktiviert wird
- Action = block: Gibt an, dass Anfragen, die gegen WAF-Regeln verstoßen, blockiert werden. Alternativ kann ignore gesetzt werden
- Type = CheckExternDefiniert den Sicherheitsmechanismus als externe Prüfungsanfrage per REST-API
- CheckExternURL =: Ziel-URL für die externe Prüfung. Muss eine gültige HTTPS-Adresse sein
- CheckExternOnErrorBehavior =: Fehlverhalten der externen Prüfung: block (Standard) verhindert Anfragen bei technischen Fehlern, pass erlaubt sie trotzdem
- CheckExternBasicAuth =: Optionale Basic Authentication für die API (Format: user:pass).
- CheckExternBearerToken =: Optionaler Bearer-Token für API-Authentifizierung. Wird im Header als Authorization: Bearer <Token> gesendet.

Alle Parameter und deren Beschreibung sind unter “Parameter und Erklärungen für+Entry” noch einmal ausführlich aufgeführt. Das Modul sendet alle erfassten Eingaben sowie zusätzliche Informationen als JSON-Objekt per POST an die konfigurierte URL (CheckExternURL), beispielsweise

{
  "IPAddress": "",
  "Referer": "",
  "SubReferer": "",
  "CustomerAddress": {
    ...
  },
  "DeliveryAddress": {
    ...
  },
  "CommonInput": {
    ...
  },
  "Upload": {
    "UploadID": "",
    "FileNames": [
      {
        "FileName": ""
      },
      ...
    ]
  }
}

Parameter oder Strukturen können fehlen, wenn sie nicht für das Formular vorhanden oder definiert sind. Die externe API muss eine gültige JSON-Antwort mit einem HTTP-Statuscode 200 OK zurückgeben. Wichtig ist, dass das externe System innerhalb von 3 Sekunden antwortet, ansonsten wird dies als Kommunikationfehler interpretiert. Die Anfrage wird als erfolgreich gewertet und weiterverarbeitet:

{ "result": "OK" }

Die Anfrage wird blockiert:

{ "result": "failed" } -> oder beliebiger anderer Wert

Andere HTTP-Statuscodes oder ungültige Antworten werden als Kommunikationsfehler betrachtet, und das Verhalten wird gemäß CheckExternOnErrorBehavior angewendet (block oder pass).

Konfiguration für das Herausfiltern bestimmter Zeichen aus Eingaben

Die FilterSigns-Funktion ermöglicht das automatische Entfernen unerwünschter Zeichen aus Benutzereingaben. Dadurch können unerwünschte oder sicherheitskritische Zeichen gefiltert werden, bevor die Eingaben weiterverarbeitet werden. In der globalen Konfigurationsdatei inquiry-global.config muss der folgende +Entry hinzugefügt werden, um eine externe Prüfung zu aktivieren:

<Protection>
...
<+Entry>
    ID = deleteSignsValidation
    Standard = active
    Active = block
    Type = FilterSigns
    FilterSigns = !$%
</+Entry>
...
</Protection>

Attribute
- ID = deleteSignsValidation: Eindeutige ID für diesen Sicherheitsmechanismus.
- Standard = active: Die Regel ist standardmäßig aktiv, sofern sie nicht explizit in einem bestimmten Formular deaktiviert wird
- Action = block: Gibt an, dass Anfragen, die gegen WAF-Regeln verstoßen, blockiert werden. Alternativ kann ignore gesetzt werden
- Type = FilterSigns: Definiert den Sicherheitsmechanismus als Zeichenfilterung.
- FilterSigns = !$%: Liste der zu entfernenden Zeichen. Mehrere Zeichen werden ohne Trennzeichen angegeben.

Alle Parameter und deren Beschreibung sind unter “Parameter und Erklärungen für+Entry” noch einmal ausführlich aufgeführt.

Konfiguration zusätzlicher Inhaltsfilter mittels Regular Expressions

Die RegEx-Filterung ermöglicht das Blockieren oder Ignorieren von Anfragen, wenn eine bestimmte Zeichenfolge oder ein bestimmtes Muster in den Eingaben erkannt wird. Dies dient zum Schutz vor Injection-Angriffen, Spam oder unerwünschten Eingaben. In der globalen Konfigurationsdatei inquiry-global.config muss der folgende +Entry hinzugefügt werden, um eine externe Prüfung zu aktivieren:

<Protection>
...
  <+Entry>
      ID = RegExValidation
      Standard = active
      Action = block
      Type = RegEx
      RegEx = (if\(|\bsysdate\b|sleep\(|SELECT\(|SELECT\s\*|PG_SLEEP|example\.com)
  </+Entry>
  ...
</Protection>

Attribute
- ID = RegExValidation: Eindeutige ID für diesen Sicherheitsmechanismus.
- Standard = active: Die Regel ist standardmäßig aktiv, sofern sie nicht explizit in einem bestimmten Formular deaktiviert wird
- Action = block: Gibt an, dass Anfragen, die gegen WAF-Regeln verstoßen, blockiert werden. Alternativ kann ignore gesetzt werden
- Type = RegEx: Definiert den Sicherheitsmechanismus als Regulären Ausdruck zur Inhaltsprüfung
- RegEx =: Regulärer Ausdruck, der auf die Eingabe angewendet wird. Wird ein Treffer gefunden, wird die Anfrage gemäß Action behandelt

Alle Parameter und deren Beschreibung sind unter “Parameter und Erklärungen für+Entry” noch einmal ausführlich aufgeführt. Die im Beispiel verwendete RegEx prüft auf typische SQL-Injection- und Spam-Muster:

RegEx-Ausdruck	Erklärung
`if\(`	Erkennt die Verwendung von `if(`, oft genutzt in bösartigen Skripten.
`\bsysdate\b`	Erkennt `sysdate`, ein Hinweis auf SQL-Manipulation.
`sleep\(`	Erkennt die `sleep()`-Funktion, häufig bei SQL-Time-Based-Blind-Injections.
`SELECT\(`	Erkennt SQL-`SELECT()`-Befehle, die für Datenbankabfragen missbraucht werden können.
`SELECT\s\*`	Erkennt `SELECT *`, eine häufige SQL-Injection-Methode.
`PG_SLEEP`	Erkennt PostgreSQL-spezifische `PG_SLEEP()`-Angriffe.
`example\.com`	Erkennt Referenzen zu `example.com`, oft in Spam enthalten.

Fehlermeldungsausgabe der Protection-Regeln im Template

Falls eine Anfrage aufgrund einer Protection-Regel blockiert wurde, kann eine entsprechende Fehlermeldung im InquiryPage-Template ausgegeben werden. Allgemeine Fehlerausgabe für alle Protection-Regeln:

...
{INQUIRY-ProtectionTriggered}
   <!-- Liste der fehlgeschlagenen IDs aus den +Entry Abschnitten -->
   ~INQUIRY-ProtectionTriggered~
{/INQUIRY-ProtectionTriggered}
...

Das Einzeltag gibt die Liste der IDs aus den +Entry-Einträgen aus, die zur Ablehnung der Anfrage geführt haben. Die Ausgabe gilt für alle Sicherheitsmechanismen Falls eine spezifische Fehlermeldung für eine bestimmte Regel erwünscht ist, muss dies über eine dedizierte ID im Template definiert werden, beispielsweise über einen DC-(DesignControl)-Tags, beispielsweise

...
{INQUIRY-ProtectionTriggered}
   <!-- Liste der fehlgeschlagenen IDs aus den +Entry Abschnitten -->
   ~DC-FPProtectionID_set($INQUIRY-ProtectionTriggered$)~
   ...
   {DC-FPProtectionID(RegExValidation)}
      Fehlermeldung für RegEx Regel
   {/DC-FPProtectionID(RegExValidation)}
   ...
   {DC-FPProtectionID(deleteSignsValidation)}
      Fehlermeldung für FilterSigns-Regel
   {/DC-FPProtectionID(deleteSignsValidation)}
   ...
{/INQUIRY-ProtectionTriggered}
...

Wegweiser