<ph type="x-smartling-placeholder"></ph>
Sie sehen die Dokumentation zu Apigee Edge.
Gehen Sie zur
Apigee X-Dokumentation. Weitere Informationen
Was
Extrahiert Informationen aus einer Nachricht (z. B. URI-Pfad, Abfrageparameter, Header, Formular-Parameter, Variable, XML-Nutzlast oder JSON-Nutzlast) und wertet diesen Inhalt anhand von vordefinierten regulären Ausdrücken aus. Wenn welche der angegebenen regulären Ausdrücke als "true" ausgewertet wird, wird die Nachricht als Bedrohung eingestuft und abgelehnt.
Videos
In den folgenden Videos erfahren Sie mehr über die Richtlinie zum Schutz vor regulären Ausdrücken.
Video | Beschreibung |
---|---|
Schutz gegen SQL-Injection-Angriffe (New Edge) | Schutz vor SQL-Injection-Angriffen mithilfe der Richtlinie zum Schutz vor regulären Ausdrücken in die Benutzeroberfläche von New Edge an. |
Schutz gegen SQL-Injection-Angriffe (Classic Edge) | Schutz vor SQL-Injection-Angriffen mithilfe der Richtlinie zum Schutz vor regulären Ausdrücken in der Classic Edge-Benutzeroberfläche. |
Beispiele
GitHub
Im Beispiel regex-protection auf GitHub wird gezeigt, wie Sie potenzielle SQL-Injection-Angriffe herausgegeben über ein Abfrageparameter abfangen. Darüber hinaus wird im Beispiel gezeigt, wie ein allgemeiner 400-Fehlerstatus festgelegt wird, um zu verhindern, dass Hacker nützliche Informationen aus der Antwort erhalten.
JavaScript mit Angriffsschutz
<RegularExpressionProtection name="JsonPathRegExProtection"> <DisplayName>Regular Expression Protection 1</DisplayName> <Source>request</Source> <JSONPayload escapeSlashCharacter="true"> <JSONPath> <Expression>$</Expression> <Pattern><\s*script\b[^>]*>[^<]+<\s*\/\s*script\s*> </Pattern> <Pattern>n\s*\\\\\s*slash</Pattern> <Pattern>n\s*\/\s*slash</Pattern> <Pattern>n\s*\\"\s*quotes</Pattern> <Pattern>n\s*\\b\s*space</Pattern> <Pattern>n\s*\\f\s*forwardfeed</Pattern> <Pattern>n\s*\\n\s*newline</Pattern> <Pattern>n\s*\\r\s*carria</Pattern> <Pattern>n\s*\\t\s*tab</Pattern> <Pattern>n\s*\\uFFFF\s*hex</Pattern> </JSONPath> </JSONPayload> </RegularExpressionProtection>
Das obige Beispiel veranschaulicht die Verwendung der Richtlinie "RegularExpressionProtection" zur Bewertung von JSON-Nutzlasten hinsichtlich JavaScript-include-Angriffe. Insbesondere wird der von <JSONPath>
/<Expression>
extrahierte Inhalt mit dem regulären Ausdruck in <JSONPath>
/<Pattern>
abgeglichen.
Wenn der reguläre Ausdruck in Ihrem <JSONPath>
/<Pattern>
XML-reservierte Zeichen (", &, ', < oder .) enthält, müssen Sie sie in XML codieren, bevor Sie sie in die XML-Konfigurationsdatei der Richtlinie einfügen. Im obigen Beispiel wurde der reguläre Ausdruck <\s*script\b[^>]*>[^<]+<\s*\/\s*script\s*>
als <\s*script\b[^>]*>[^<]+<\s*\/\s*script\s*>
in XML codiert.
Wenn Ihr regulärer Ausdruck Schrägstriche (/) enthält, müssen Sie diese außerdem maskieren, indem Sie das escapeSlashCharacter
-Attribut <JSONPayload>
auf true
setzen.
Übereinstimmungen ohne Beachtung der Groß-/Kleinschreibung
Dies ist ein häufiger Anwendungsfall, bei dem die Groß- und Kleinschreibung nicht berücksichtigt wird. Dieses Beispiel zeigt, wie Sie dies mit dem Konstrukt (?i)
in einem regulären Ausdruck erreichen. In diesem Beispiel werden beispielsweise DELETE
, delete
und Delete
als wahr ausgewertet.
<Pattern>[\s]*(?i)((delete)|(exec)|(drop\s*table)|(insert)|(shutdown)|(update)|(\bor\b))</Pattern>
Über die Regular Expression Protection-Richtlinie
Mit Apigee Edge können Sie reguläre Ausdrücke konfigurieren, die während der Laufzeit anhand des API-Traffics evaluiert werden, um häufige Bedrohungen auf Inhaltsebene zu identifizieren, Muster erkennen.
Ein regulärer Ausdruck, kurz Regex, ist eine Reihe von Strings, die ein Muster in einem String angeben. Mit regulären Ausdrücken können Inhalte programmatisch nach Mustern ausgewertet werden. Mit regulären Ausdrücken lässt sich beispielsweise eine E-Mail-Adresse auf ihre korrekte Struktur prüfen. Weitere Informationen finden Sie unter Reguläre Ausdrücke in den Java-Anleitungen.
Die häufigste Verwendung von RegularExpressionProtection ist die Auswertung von JSON- und XML-Nutzlasten auf schädliche Inhalte.
Kein regulärer Ausdruck kann alle inhaltsbasierten Angriffe eliminieren und mehrere Mechanismen sollten zu einem umfassenden Schutz kombiniert werden. In diesem Abschnitt werden einige empfohlene Muster zum Ausschließen von Inhalten beschrieben.
Beispiel für Ausschlussmuster
Reguläre Ausdrücke müssen in der XML-Konfigurationsdatei der Richtlinie XML-codiert sein.
Name | Regulärer Ausdruck |
---|---|
SQL-Einschleusung |
[\s]*((delete)|(exec)|(drop\s*table)|(insert)|(shutdown)|(update)|(\bor\b)) |
Server-Side Include-Einschleusung |
<!--#(include|exec|echo|config|printenv)\s+.* XML-codiert: <!--#(include|exec|echo|config|printenv)\s+.* |
XPath-abgekürzte Syntax-Einschleusung |
(/(@?[\w_?\w:\*]+(\[[^]]+\])*)?)+ |
Erweiterte XPath-Syntax-Einschleusung |
/?(ancestor(-or-self)?|descendant(-or-self)?|following(-sibling)) |
JavaScript-Einschleusung |
<\s*script\b[^>]*>[^<]+<\s*/\s*script\s*> XML-codiert: <\s*script\b[^>]*>[^<]+<\s*/\s*script\s*> |
Java-Ausnahme-Einschleusung |
.*?Exception in thread.* |
Content-Type-Header in einer Anfrage mit einer XML- oder JSON-Nutzlast festlegen
Die Nutzlast der Richtlinie zum Schutz vor regulären Ausdrücken kann die folgenden Elemente enthalten:
-
<XMLPayload>
-Element: Gibt an, dass Informationen aus einer XML-Nutzlast extrahiert und mit dem angegebenen regulären Ausdruck abgeglichen werden müssen.Wenn Sie
<XMLPayload>
in der Richtlinie verwenden, muss der HeaderContent-Type
der Anfrage ein XML-Inhaltstyp wieapplication/xml
odertext/xml
sein. -
<JSONPayload>
-Element: Gibt an, dass Informationen aus einer JSON-Nutzlast extrahiert und mit dem angegebenen regulären Ausdruck abgeglichen werden müssen.Wenn Sie
<JSONPayload>
in der Richtlinie verwenden, muss der HeaderContent-Type
der Anfrage ein JSON-Inhaltstyp wieapplication/json
sein.
In der Regel entwerfen Sie eine API, um entweder XML oder JSON zu akzeptieren. Es kann jedoch ein Szenario geben, in dem die API beides akzeptiert. Sie können dann eine Richtlinie für den Schutz vor regulären Ausdrücken definieren, in der die Elemente <XMLPayload>
und <JSONPayload>
verwendet werden.
Basierend auf dem Wert des Headers Content-Type
würde nur ein Element für eine bestimmte Anfrage angewendet werden.
Elementverweis
Der Elementverweis beschreibt die Elemente und Attribute der RegularExpressionProtection-Richtlinie.
<RegularExpressionProtection async="false" continueOnError="false" enabled="true" name="Regular-Expression-Protection-1"> <DisplayName>Regular Expression Protection 1</DisplayName> <Source>response</Source> <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables> <URIPath> <Pattern>REGEX PATTERN</Pattern> <Pattern>REGEX PATTERN</Pattern> </URIPath> <QueryParam name="a-query-param"> <Pattern>REGEX PATTERN</Pattern> <Pattern>REGEX PATTERN</Pattern> </QueryParam> <Header name="a-header"> <Pattern>REGEX PATTERN</Pattern> <Pattern>REGEX PATTERN</Pattern> </Header> <FormParam name="a-form-param"> <Pattern>REGEX PATTERN</Pattern> <Pattern>REGEX PATTERN</Pattern> </FormParam> <Variable name="request.content"> <Pattern>REGEX PATTERN</Pattern> <Pattern>REGEX PATTERN</Pattern> </Variable> <XMLPayload> <Namespaces> <Namespace prefix="apigee">http://www.apigee.com</Namespace> </Namespaces> <XPath> <Expression>/apigee:Greeting/apigee:User</Expression> <Type>string</Type> <Pattern>REGEX PATTERN</Pattern> <Pattern>REGEX PATTERN</Pattern> </XPath> </XMLPayload> <JSONPayload> <JSONPath> <Expression>$.store.book[*].author</Expression> <Pattern>REGEX PATTERN</Pattern> <Pattern>REGEX PATTERN</Pattern> </JSONPath> </JSONPayload> </RegularExpressionProtection>
<RegularExpressionProtection>-Attribute
<RegularExpressionProtection async="false" continueOnError="false" enabled="true" name="Regular-Expression-Protection-1">
In der folgenden Tabelle werden Attribute beschrieben, die für alle übergeordneten Richtlinienelemente gelten:
Attribut | Beschreibung | Standard | Präsenz |
---|---|---|---|
name |
Der interne Name der Richtlinie. Der Wert des Attributs Optional können Sie das Element |
– | Erforderlich |
continueOnError |
Legen Sie Legen Sie |
false | Optional |
enabled |
Setzen Sie den Wert auf Legen Sie |
true | Optional |
async |
Dieses Attribut wurde verworfen. |
false | Veraltet |
<DisplayName>-Element
Wird zusätzlich zum Attribut name
verwendet, um die Richtlinie im Proxy-Editor der Verwaltungs-UI mit einem anderen Namen in einer natürlichen Sprache zu versehen.
<DisplayName>Policy Display Name</DisplayName>
Standardeinstellung |
– Wenn Sie dieses Element weglassen, wird der Wert des Namensattributs |
---|---|
Präsenz | Optional |
Typ | String |
<Source>-Element
Gibt die Nachricht an, aus der Informationen extrahiert werden sollen.
Wenn das Element <Source>
weggelassen wird, wird für den Wert standardmäßig message
eingesetzt. Beispiel: <Source>message</Source>
Wenn message
festgelegt ist, verwendet die Richtlinie die Anfragenachricht als Quelle, wenn sie an einen Anfrageablauf angehängt ist. Ebenso verwendet die Richtlinie die Antwortnachricht, wenn sie an einen Antwortablauf angehängt ist.
Wenn die Quellnachricht nicht aufgelöst werden kann oder in einen Nicht-Nachrichtentyp aufgelöst wird, gibt die Richtlinie einen Fehler zurück.
<Source>response</Source>
Standard: | – |
Präsenz: | Optional |
Typ: | String |
<IgnoreUnresolvedVariables>-Element
Bestimmt, ob die Richtlinie einen Fehler zurückgibt, wenn eine nicht auflösbare Variable gefunden wird.
Wenn auf false
(Standardeinstellung) gesetzt ist, gibt die Richtlinie einen Fehler zurück, wenn eine nicht auflösbare Variable gefunden wird. Wenn true
festgelegt ist, wird die nicht aufgelöste Variable wie ein leerer String (null) behandelt.
<IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
Standard: | false |
Präsenz: | Optional |
Typ: | Boolean |
<URIPath>-Element
Gibt an, dass Informationen aus dem Anfrage-URI-Pfad extrahiert und mit den angegebenen regulären Ausdrücken abgeglichen werden müssen. Sie müssen mindestens ein <Pattern>
-Element angeben, das ein abzugleichendes Muster für reguläre Ausdrücke angibt.
<URIPath> <Pattern>REGEX PATTERN</Pattern> <Pattern>REGEX PATTERN</Pattern> </URIPath>
Standard: | – |
Präsenz: | Optional |
Typ: | – |
<QueryParam>-Element
Gibt an, dass Informationen aus dem Anfrageabfrageparameter extrahiert und mit den angegebenen regulären Ausdrücken abgeglichen werden müssen. Sie müssen mindestens ein <Pattern>
-Element angeben, das ein abzugleichendes Muster für reguläre Ausdrücke angibt.
<QueryParam name="a-query-param"> <Pattern>REGEX PATTERN</Pattern> <Pattern>REGEX PATTERN</Pattern> </QueryParam>
Standard: | – |
Präsenz: | Optional |
Typ: | – |
Attribute
Attribut | Beschreibung | Standard | Präsenz |
---|---|---|---|
Name | Name des Anfrage-Abfrageparameter, aus dem Informationen für den Abgleich mit den angegebenen regulären Ausdrücken extrahiert werden sollen. | – | Erforderlich |
<Header>-Element
Gibt an, dass Informationen aus den Anfrage- und Antwort-Headern extrahiert und mit den angegebenen regulären Ausdrücken abgeglichen werden müssen. Sie müssen mindestens ein <Pattern>
-Element angeben, das ein abzugleichendes Muster für reguläre Ausdrücke angibt.
<Header name="a-header"> <Pattern>REGEX PATTERN</Pattern> <Pattern>REGEX PATTERN</Pattern> </Header>
Standard: | – |
Präsenz: | Optional |
Typ: | – |
Attribute
Attribut | Beschreibung | Standard | Präsenz |
---|---|---|---|
Name |
Name des Anfrage- und Antwortheaders, aus dem Informationen für den Abgleich mit den angegebenen regulären Ausdrücken extrahiert werden müssen. |
– | Erforderlich |
<FormParam>-Element
Gibt an, dass Informationen aus dem Anfrageformularparameter extrahiert und mit den angegebenen regulären Ausdrücken abgeglichen werden müssen. Sie müssen mindestens ein <Pattern>
-Element angeben, das ein abzugleichendes Muster für reguläre Ausdrücke angibt.
<FormParam name="a-form-param"> <Pattern>REGEX PATTERN</Pattern> <Pattern>REGEX PATTERN</Pattern> </FormParam>
Standard: | – |
Präsenz: | Optional |
Typ: | – |
Attribute
Attribut | Beschreibung | Standard | Präsenz |
---|---|---|---|
Name |
Name des Anfrageformularparameters, aus dem Informationen zum Abgleichen mit den angegebenen regulären Ausdrücken extrahiert werden sollen. |
– | Erforderlich |
<Variable>-Element
Gibt an, dass Informationen aus der angegebenen Variable extrahiert und mit den angegebenen regulären Ausdrücken abgeglichen werden müssen.
<Variable name="request.content"> <Pattern>REGEX PATTERN</Pattern> <Pattern>REGEX PATTERN</Pattern> </Variable>
Standard: | – |
Präsenz: | Optional |
Typ: | – |
Attribute
Attribut | Beschreibung | Standard | Präsenz |
---|---|---|---|
Name |
Name der Variable, aus der Informationen für den Abgleich mit den angegebenen regulären Ausdrücken extrahiert werden sollen. |
– | Erforderlich |
<XMLPayload>-Element
Gibt an, dass Informationen aus einer XML-Nutzlast extrahiert und mit den angegebenen regulären Ausdrücken abgeglichen werden müssen.
<XMLPayload> <Namespaces> <Namespace prefix="apigee">http://www.apigee.com</Namespace> </Namespaces> <XPath> <Expression>/apigee:Greeting/apigee:User</Expression> <Type>string</Type> <Pattern>REGEX PATTERN</Pattern> <Pattern>REGEX PATTERN</Pattern> </XPath> </XMLPayload>
Standard: | – |
Präsenz: | Optional |
Typ: | – |
<XMLPayload>/<Namespaces>-Element
Gibt die Namespaces an, die in der XPath-Bewertung verwendet werden sollen.
<XMLPayload> <Namespaces> <Namespace prefix="apigee">http://www.apigee.com</Namespace> </Namespaces> <XPath> <Expression>/apigee:Greeting/apigee:User</Expression> <Type>string</Type> <Pattern>REGEX PATTERN</Pattern> <Pattern>REGEX PATTERN</Pattern> </XPath> </XMLPayload>
Standard: | – |
Präsenz: | Optional |
Typ: | String |
<XMLPayload>/<Namespaces>/<Namespace>-Element
Gibt jeden Namespace an, der in der XPath-Bewertung verwendet werden soll.<Namespaces> <Namespace prefix="apigee">http://www.apigee.com</Namespace> </Namespaces>
Standard: | – |
Präsenz: | Optional |
Typ: | String |
Attribute
Attribut | Beschreibung | Standard | Präsenz |
---|---|---|---|
prefix |
Liefert ein Präfix, um einen bestimmten Namespace zu qualifizieren. |
– | Erforderlich |
<XMLPayload>/<XPath>-Element
Gibt den XPath an, der ausgewertet werden soll.<XPath> <Expression>/apigee:Greeting/apigee:User</Expression> <Type>string</Type> <Pattern>REGEX PATTERN</Pattern> <Pattern>REGEX PATTERN</Pattern> </XPath>
Standard: | – |
Präsenz: | Optional |
Typ: | – |
<XMLPayload>/<XPath>/<Expression>-Element
Gibt den für den Ausdruck definierten XPath an. Es werden nur XPath 1.0-Ausdrücke unterstützt. Beispielsweise extrahiert<Expression>/company/employee[@age>=$request.header.age]</Expression>
Details für Mitarbeiter, deren Alter größer oder gleich dem in request.header.age
angegebenen Wert ist.<XPath> <Expression>/apigee:Greeting/apigee:User</Expression> <Type>string</Type> <Pattern>REGEX PATTERN</Pattern> <Pattern>REGEX PATTERN</Pattern> </XPath>
Standard: | – |
Präsenz: | Optional |
Typ: | String |
<XMLPayload>/<XPath>/<Type>-Element
Gibt den Datentyp an.<XPath> <Expression>/apigee:Greeting/apigee:User</Expression> <Type>string</Type> <Pattern>REGEX PATTERN</Pattern> <Pattern>REGEX PATTERN</Pattern> </XPath>
Standard: | String |
Präsenz: | Optional |
Typ: | String |
Zulässige Werte: |
String. Zulässige Werte |
<XMLPayload>/<XPath>/<Pattern>-Element
Definiert das Muster für reguläre Ausdrücke. Wenn ein regulärer Ausdruck im Element <Pattern>
Zeichen mit XML-Reservierung (", &, ', < oder .) enthält, müssen Sie sie in XML-Code codieren, bevor Sie sie hinzufügen.
<XPath> <Expression>/apigee:Greeting/apigee:User</Expression> <Type>string</Type> <Pattern>REGEX PATTERN</Pattern> <Pattern>REGEX PATTERN</Pattern> </XPath>
Standard: | – |
Präsenz: | Erforderlich |
Typ: | String |
<JSONPayload>-Element
Gibt an, dass Informationen aus einer JSON-Nutzlast extrahiert und mit den angegebenen regulären Ausdrücken abgeglichen werden müssen.
<JSONPayload> <JSONPath> <Expression>$.store.book[*].author</Expression> <Pattern>REGEX PATTERN</Pattern> <Pattern>REGEX PATTERN</Pattern> </JSONPath> </JSONPayload>
Standard: | – |
Präsenz: | Optional |
Typ: | – |
Attribute
Attribut | Beschreibung | Standard | Präsenz |
---|---|---|---|
escapeSlashCharacter |
Legen Sie |
wahr | Optional |
<JSONPayload>/<JSONPath>/<Expression>-Element
Gibt den JSONPath-Ausdruck an, der für die Variable definiert wurde.
<JSONPath> <Expression>$.store.book[*].author</Expression> <Pattern>REGEX PATTERN</Pattern> <Pattern>REGEX PATTERN</Pattern> </JSONPath>
Standard: | – |
Präsenz: | Optional |
Typ: | String |
<JSONPayload>/<JSONPath>/<Pattern>
Definiert das Muster für reguläre Ausdrücke. Wenn ein regulärer Ausdruck im Element <Pattern>
Zeichen mit XML-Reservierung (", &, ', < oder .) enthält, müssen Sie sie in XML-Code codieren, bevor Sie sie hinzufügen.
<JSONPath> <Expression>$.store.book[*].author</Expression> <Pattern>REGEX PATTERN</Pattern> <Pattern>REGEX PATTERN</Pattern> </JSONPath>
Standard: | – |
Präsenz: | Erforderlich |
Typ: | String |
Fehlerreferenz
In diesem Abschnitt werden die zurückgegebenen Fehlercodes und -meldungen sowie die Fehlervariablen beschrieben, die von Edge festgelegt werden, wenn diese Richtlinie einen Fehler auslöst. Diese Informationen sind wichtig, wenn Sie Fehlerregeln zur Verarbeitung von Fehlern entwickeln. Wenn Sie einen Fehler erfassen und einen eigenen benutzerdefinierten Fehler erzeugen möchten, legen Sie das Attribut continueOnError="true"
für das Richtlinien-Stammelement fest.
Weitere Informationen finden Sie unter Was Sie über Richtlinienfehler wissen müssen und Fehler beheben.
Von Edge-Richtlinien zurückgegebene Fehler folgen einem einheitlichen Format, wie in der Fehlercode-Referenz beschrieben.
Laufzeitfehler
Diese Fehler können bei Ausführung der Richtlinie auftreten.
Fehlercode | die Botschaft und |
---|---|
ExecutionFailed | RegularExpressionProtection-StepDefinition konnte nicht ausgeführt werden {0}. Grund: {1} |
InstantiationFailed | RegularExpressionProtection-StepDefinition konnte nicht instanziiert werden {0}. |
NonMessageVariable | Die Variable {0} wird nicht in eine Nachricht aufgelöst. |
SourceMessageNotAvailable | {0} Nachricht für RegularExpressionProtection-StepDefinition nicht verfügbar {1} |
ThreatDetected | Threat von regulärem Ausdruck erkannt in {0}: Regex: {1} Eingabe: {2} |
VariableResolutionFailed | Variable {0} konnte nicht aufgelöst werden |
Bereitstellungsfehler
Fehlercode | die Botschaft und | Beheben |
---|---|---|
CannotBeConvertedToNodeset | RegularExpressionProtection {0}: Ergebnis des xpath {1} kann nicht in einen Knotensatz konvertiert werden. Kontext {2} | build |
DuplicatePrefix | RegularExpressionProtection {0}: Doppeltes Präfix {1} | build |
EmptyJSONPathExpression | RegularExpressionProtection {0}: Leerer JSONPath-Ausdruck | build |
EmptyXPathExpression | RegularExpressionProtection {0}: Leerer XPath-Ausdruck | build |
InvalidRegularExpression | RegularExpressionProtection {0}: Ungültiger regulärer Ausdruck {1}, Kontext {2} | build |
JSONPathCompilationFailed | RegularExpressionProtection {0}: JSON-Pfad konnte nicht kompiliert werden {1}. Kontext {2} | build |
NONEmptyPrefixMappedToEmptyURI | RegularExpressionProtection {0}: Ein nicht leeres Präfix {1} kann keinem leeren URI zugewiesen werden. | build |
NoPatternsToEnforce | RegularExpressionProtection{0}: Keine zu erzwingenden Muster in {1} | build |
NothingToEnforce | RegularExpressionProtection{0}: Mindestens eines der Elemente URIPath, QueryParam, Header, FormParam, XMLPayload, JSONPayload ist obligatorisch | build |
XPathCompilationFailed | RegularExpressionProtection {0}: Xpath konnte nicht kompiliert werden {1}. Kontext {2} | build |
Fehlervariablen
Diese Variablen werden festgelegt, wenn die Richtlinie einen Fehler auslöst. Weitere Informationen finden sich unter Was Sie über Richtlinienfehler wissen müssen.
Variablen | Wo | Beispiel |
---|---|---|
fault.name="fault_name" |
fault_name ist der Name des Fehlers, wie in der obigen Tabelle aufgeführt. | fault.name Matches "ThreatDetected" |
regularexpressionprotection.policy_name.failed |
policy_name ist der benutzerdefinierte Name der Richtlinie, die den Fehler ausgelöst hat. | regularexpressionprotection.Regular-Expressions-Protection-1.failed = true |