Tamper Script Erstellen: Anwendung, typische Fehler, Praxiswissen und saubere Workflows

Ein eigenes Tamper Script ist kein Standardwerkzeug für jeden Scan, sondern eine gezielte Antwort auf ein konkretes Problem im Request-Pfad. In der Praxis entsteht dieser Bedarf meist dann, wenn sqlmap grundsätzlich funktioniert, aber einzelne Payloads durch Filterlogik, WAF-Regeln, Proxy-Normalisierung, URL-Rewriting oder serverseitige Vorverarbeitung verändert, blockiert oder unbrauchbar gemacht werden. Wer an dieser Stelle blind neue Optionen kombiniert, verliert Zeit und produziert oft nur Rauschen. Der bessere Ansatz ist, zuerst exakt zu verstehen, an welcher Stelle die Nutzlast scheitert. Tamper Scripts greifen in die Payload-Erzeugung ein. Sie verändern also nicht das Zielsystem, sondern die Art, wie sqlmap seine Test- und Exploit-Strings formt. Genau deshalb ist ihre Wirkung stark, aber auch riskant. Eine unpassende Transformation kann funktionierende Payloads zerstören, Datenbank-spezifische Syntax brechen oder die Erkennung von Injektionspunkten verschlechtern. Besonders häufig passiert das, wenn ein Script pauschal jedes Leerzeichen, jedes Gleichheitszeichen oder jedes Schlüsselwort ersetzt, ohne den Kontext zu berücksichtigen. In realen Assessments zeigt sich oft ein wiederkehrendes Muster: Die Anwendung akzeptiert einfache Requests, aber ein vorgeschalteter Filter reagiert auf typische SQL-Schlüsselwörter, Kommentarzeichen oder bekannte Signaturen wie UNION SELECT, SLEEP, WAITFOR DELAY oder OR 1=1. Genau hier setzen Tamper Scripts an. Sie können Schlüsselwörter anders darstellen, Leerzeichen durch alternative Trennzeichen ersetzen, Zeichen kodieren oder Kommentare so einbauen, dass die Datenbank die Anfrage weiterhin versteht, der Filter aber nicht mehr auf das ursprüngliche Muster matcht. Ein Tamper Script ist jedoch nur dann sinnvoll, wenn die Ursache sauber eingegrenzt wurde. Vorher gehören reproduzierbare Baselines, Request-Vergleiche und ein Blick auf den gesamten Ablauf dazu. Wer noch nicht sauber mit Requests arbeitet, sollte zuerst den Umgang mit Request File und einen stabilen Workflow beherrschen. Ohne diese Grundlage wird ein Tamper Script schnell zum Versuch, Symptome zu kaschieren, statt das eigentliche Problem zu lösen. Typische Auslöser für eigene Scripts sind:

• WAF oder Reverse Proxy blockiert bekannte SQLi-Signaturen, obwohl der Parameter grundsätzlich injizierbar ist.
• Die Anwendung oder Middleware normalisiert bestimmte Zeichenfolgen und zerstört dadurch Standard-Payloads.
• Ein Parameter wird vor der Datenbankverarbeitung speziell kodiert, dekodiert oder umgeschrieben.
• Vorhandene Standard-Tamper-Scripts kommen nahe an das Ziel, brechen aber Syntax oder Logik an entscheidenden Stellen.

Entscheidend ist die Reihenfolge: erst Request verstehen, dann Filterverhalten beobachten, danach Payloads minimal anpassen. Ein gutes Tamper Script ist nie maximal kreativ, sondern minimal invasiv. Es verändert nur das, was für den Bypass nötig ist, und lässt alles andere unangetastet. Genau diese Zurückhaltung trennt brauchbare Scripts von instabilen Bastellösungen.

Wer eigene Tamper Scripts schreibt, muss zuerst verstehen, dass sqlmap diese Module nicht als beliebige Python-Helfer lädt, sondern als definierte Transformationsbausteine. Das Script bekommt typischerweise eine Payload übergeben und liefert eine veränderte Payload zurück. Diese Einfachheit ist trügerisch, denn schon kleine Fehler in Rückgabewerten, Prioritäten oder Importen führen dazu, dass sqlmap das Script ignoriert, falsch einordnet oder mit unerwarteten Nebeneffekten ausführt. Ein typisches Grundgerüst sieht so aus:

#!/usr/bin/env python

from lib.core.enums import PRIORITY

__priority__ = PRIORITY.NORMAL

def dependencies():
    pass

def tamper(payload, **kwargs):
    if payload:
        payload = payload.replace(" ", "/**/")
    return payload

Wichtig ist nicht nur die Funktion tamper(), sondern auch das Verständnis für den Lebenszyklus. sqlmap erzeugt Payloads abhängig von Technik, DBMS-Annahme, Kontext und Erkennungsphase. Das Tamper Script sitzt danach als Transformationsschicht auf der Nutzlast. Es ist also kein Parser für komplette HTTP-Requests und auch kein universeller Hook für Header, Cookies oder Body-Strukturen. Wer Request-Teile außerhalb der eigentlichen SQL-Payload manipulieren will, arbeitet oft besser mit Request-Dateien, Proxies oder gezielter Request-Modifikation statt mit Tamper-Logik. Die Priorität bestimmt, wann ein Script in einer Kette angewendet wird. Das ist relevant, wenn mehrere Scripts kombiniert werden. Ein Script, das zuerst URL-kodiert, kann ein nachgelagertes Script unbrauchbar machen, das eigentlich noch auf Klartext-Schlüsselwörter prüfen wollte. Umgekehrt kann ein Script, das Kommentare einfügt, vor einer späteren Kodierung genau richtig sein. Deshalb ist die Reihenfolge kein kosmetisches Detail, sondern funktionaler Kern. Die Funktion dependencies() wird oft ignoriert, kann aber nützlich sein, um Inkompatibilitäten oder Voraussetzungen zu markieren. In komplexeren Fällen lässt sich dort prüfen, ob ein Script nur für bestimmte DBMS-Typen oder nur in bestimmten Modi sinnvoll ist. Das verhindert, dass ein universell gestarteter Scan mit einer Transformation arbeitet, die nur für MySQL gültig ist, aber auf MSSQL oder Oracle Syntaxfehler erzeugt. Ein weiterer häufiger Denkfehler: Das Script transformiert Strings, aber nicht die Semantik der Datenbank. Wenn ein Filter auf das Wort SELECT reagiert, kann eine alternative Schreibweise helfen. Wenn die Anwendung jedoch serverseitig Prepared Statements nutzt, wird kein Tamper Script daraus eine ausnutzbare SQL Injection machen. Tamper Scripts sind Bypass-Werkzeuge für Darstellung und Transport, nicht für das Erzeugen einer Schwachstelle. Für ein tieferes Verständnis der internen Abläufe lohnt sich der Blick auf Funktionsweise, Architektur und auf vorhandene Eigene Tamper Scripts. Dort wird sichtbar, dass gute Scripts nicht nur Payloads verändern, sondern dies konsistent, reproduzierbar und mit Blick auf die nachgelagerten Parser tun.

Der häufigste Fehler beim Erstellen eines Tamper Scripts ist zu frühes Coden. In der Praxis muss zuerst geklärt werden, was genau die Payload verändert oder blockiert. Das kann an mehreren Stellen passieren: im Client, im Proxy, im CDN, in der WAF, im Webserver, in Framework-Middleware, in der Applikationslogik oder erst in der Datenbankschicht. Ohne diese Einordnung wird jede Transformation zum Ratespiel. Ein belastbarer Ablauf beginnt mit einer unveränderten Referenzanfrage. Danach werden einzelne Payload-Varianten manuell oder über einen Proxy verglichen. Relevant sind Statuscodes, Response-Länge, Redirect-Verhalten, Header-Unterschiede, Timing und serverseitige Fehlermeldungen. Besonders aufschlussreich ist ein Vergleich zwischen einer harmlosen Zeichenfolge, einer typischen SQLi-Signatur und einer leicht obfuskierten Variante. Wenn nur die Signatur blockiert wird, liegt die Vermutung eines Pattern-basierten Filters nahe. Wenn bereits Sonderzeichen oder Kodierungen Probleme auslösen, ist eher mit Normalisierung oder Parser-Konflikten zu rechnen. Ein klassisches Beispiel: Ein Parameter akzeptiert id=1, reagiert aber auf id=1 AND 1=1 mit 403. Wird stattdessen id=1/**/AND/**/1=1 akzeptiert, ist das ein starkes Indiz für eine regelbasierte Erkennung auf Leerzeichen oder bekannte Tokenfolgen. Wird jedoch auch die kommentierte Variante blockiert, aber eine URL-kodierte Form teilweise akzeptiert, muss geprüft werden, ob die WAF vor oder nach der Dekodierung arbeitet. Genau an diesem Punkt entscheidet sich, ob ein Script für Kommentar-Injektion, URL-Encoding, Double-Encoding oder Keyword-Splitting sinnvoll ist. Ein weiterer Praxisfall betrifft JSON- oder API-Requests. Dort scheitern Payloads nicht selten nicht an SQL-Syntax, sondern an JSON-Escaping, Unicode-Normalisierung oder serverseitiger Deserialisierung. Ein Tamper Script, das blind Anführungszeichen oder Backslashes ersetzt, kann die gesamte Struktur zerstören. In solchen Fällen muss zuerst der Transportkontext verstanden werden, etwa über Json Parameter Testing, Rest API Testing oder gezielte Request Modifikation. Für die Analyse sind drei Fragen zentral:

• Wird die Payload blockiert, umgeschrieben oder nur anders interpretiert?
• Passiert die Veränderung vor der Anwendung, in der Anwendung oder erst in der Datenbanknähe?
• Welche minimale Transformation reicht aus, um denselben semantischen SQL-Ausdruck anders darzustellen?

Wer diese Fragen sauber beantwortet, schreibt deutlich kürzere und stabilere Scripts. Das Ziel ist nicht, möglichst viele Zeichen zu verändern, sondern exakt die Signatur zu brechen, die den Filter triggert. Jede zusätzliche Transformation erhöht die Wahrscheinlichkeit von False Negatives, Syntaxfehlern und schwer reproduzierbaren Ergebnissen.

Die meisten brauchbaren Tamper Scripts lassen sich in wenige funktionale Kategorien einteilen. Diese Einteilung ist wichtig, weil jede Kategorie andere Risiken mitbringt. Ein Script zum Ersetzen von Leerzeichen ist meist relativ kontrollierbar. Ein Script zur vollständigen Kodierung oder zum massiven Umbau von Schlüsselwörtern kann dagegen schnell die Datenbanksyntax beschädigen oder die Erkennungslogik von sqlmap aus dem Tritt bringen. Ein einfacher und oft wirksamer Typ ist das Ersetzen von Leerzeichen durch Inline-Kommentare:

from lib.core.enums import PRIORITY

__priority__ = PRIORITY.NORMAL

def tamper(payload, **kwargs):
    if not payload:
        return payload
    return payload.replace(" ", "/**/")

Das funktioniert häufig gegen Filter, die auf Token mit normalen Leerzeichen prüfen. Es ist aber nicht universell. Manche Parser oder WAFs normalisieren Kommentare zurück zu Leerzeichen, andere blockieren Kommentarzeichen generell. Zudem kann das Ersetzen jedes Leerzeichens in String-Literalen problematisch sein, wenn die Payload Daten enthält, die unverändert bleiben müssen. Ein zweiter Typ ist Keyword-Obfuskation. Dabei werden Schlüsselwörter wie SELECT, UNION oder AND so umgeschrieben, dass die Datenbank sie weiterhin akzeptiert, der Filter aber nicht mehr auf die Standardform matcht. Ein Beispiel:

import re
from lib.core.enums import PRIORITY

__priority__ = PRIORITY.NORMAL

def tamper(payload, **kwargs):
    if not payload:
        return payload

    payload = re.sub(r"(?i)\bSELECT\b", "SeLeCt", payload)
    payload = re.sub(r"(?i)\bUNION\b", "UnIoN", payload)
    payload = re.sub(r"(?i)\bAND\b", "AnD", payload)
    return payload

Das wirkt nur gegen primitive, case-sensitive Filter. Gegen moderne WAFs reicht das selten. Trotzdem ist es in internen Anwendungen, Legacy-Proxies oder schlecht konfigurierten Regex-Filtern erstaunlich oft erfolgreich. Ein dritter Typ betrifft Kodierung. Hier wird mit URL-Encoding, doppelter Kodierung oder selektiver Zeichenersetzung gearbeitet. Das ist deutlich heikler, weil die Reihenfolge von Dekodierung und Filterung entscheidend ist. Wenn ein Proxy zuerst dekodiert und dann prüft, bringt einfaches Encoding nichts. Wenn die WAF vor der finalen Dekodierung prüft, kann selektives Encoding helfen. Wer in diesem Bereich arbeitet, sollte die Zusammenhänge mit Url Encoding Bypass, Double Encoding Bypass und Obfuscation Techniken sauber beherrschen. Ein vierter Typ ist kontextabhängige Transformation. Hier wird nicht global ersetzt, sondern nur unter bestimmten Bedingungen, etwa nur außerhalb von Quotes, nur bei bestimmten Keywords oder nur in numerischen Payloads. Genau dort beginnt die Qualität eines guten Scripts. Statt blind replace() auf den gesamten String anzuwenden, wird gezielt geprüft, ob die Änderung im aktuellen Kontext syntaktisch sicher ist. Diese Form ist aufwendiger, aber deutlich robuster und in realen Projekten fast immer die bessere Wahl.

Blindes String-Replacement ist der Hauptgrund für unzuverlässige Tamper Scripts. In einer SQL-Payload haben dieselben Zeichen je nach Position völlig unterschiedliche Bedeutung. Ein Leerzeichen zwischen SQL-Tokens ist etwas anderes als ein Leerzeichen innerhalb eines String-Literals. Ein Gleichheitszeichen in einer Bedingung ist etwas anderes als ein Gleichheitszeichen in Base64-Daten oder in einem JSON-Wert. Wer diese Unterschiede ignoriert, produziert Payloads, die zwar anders aussehen, aber nicht mehr dieselbe SQL-Semantik tragen. Ein robustes Script arbeitet deshalb kontextsensitiv. Das kann bereits mit einfachen Zustandsautomaten beginnen. Ein Beispiel: Leerzeichen sollen nur außerhalb von Single- und Double-Quotes ersetzt werden.

from lib.core.enums import PRIORITY

__priority__ = PRIORITY.NORMAL

def tamper(payload, **kwargs):
    if not payload:
        return payload

    result = []
    in_single = False
    in_double = False

    for ch in payload:
        if ch == "'" and not in_double:
            in_single = not in_single
            result.append(ch)
            continue
        if ch == '"' and not in_single:
            in_double = not in_double
            result.append(ch)
            continue

        if ch == " " and not in_single and not in_double:
            result.append("/**/")
        else:
            result.append(ch)

    return "".join(result)

Dieses Beispiel ist noch nicht perfekt, aber deutlich sicherer als ein globales replace(). Es berücksichtigt allerdings noch keine Escapes, keine DBMS-spezifischen Quote-Regeln und keine Sonderfälle wie verschachtelte Konstrukte. Genau hier zeigt sich der Unterschied zwischen Demo-Code und produktionsnaher Nutzung. Ein Script muss nicht maximal komplex sein, aber es muss die relevanten Kontexte des Zielsystems respektieren. Besonders wichtig wird das bei datenbankspezifischen Payloads. MySQL toleriert manche Kommentarformen und Keyword-Darstellungen, die auf MSSQL oder Oracle anders behandelt werden. Ein Script, das für Mysql Injection gut funktioniert, kann bei Mssql Injection oder Oracle Injection sofort scheitern. Deshalb sollte jedes Script entweder bewusst generisch bleiben oder klar auf ein DBMS zugeschnitten sein. Ein weiterer Punkt ist die Interaktion mit sqlmap-Techniken. Time-based Payloads, Boolean-basierte Tests, Error-based Varianten und UNION-basierte Ansätze erzeugen unterschiedliche Strukturen. Eine Transformation, die bei Time Based Sql Injection funktioniert, kann Error-based Tests unbrauchbar machen, weil Fehlermeldungen nicht mehr sauber ausgelöst werden. Ebenso kann ein aggressives Keyword-Splitting UNION-basierte Enumeration zerstören, obwohl die Erkennung noch funktioniert. Gute Tamper Scripts werden daher immer gegen mehrere Techniken getestet, nicht nur gegen einen einzelnen Proof of Concept.

Die meisten Fehler entstehen nicht durch Python-Syntax, sondern durch falsche Annahmen über Payloads, Filter und Datenbankverhalten. Ein Script kann technisch korrekt laufen und trotzdem fachlich schlecht sein. Genau diese Fehler kosten in Pentests am meisten Zeit, weil sie nicht sofort als Defekt sichtbar werden. Statt eines klaren Absturzes entstehen inkonsistente Ergebnisse, scheinbar zufällige Timeouts oder fehlgeschlagene Enumeration. Ein klassischer Fehler ist die globale Ersetzung kritischer Tokens. Wer jedes Leerzeichen, jedes Komma oder jedes Gleichheitszeichen ersetzt, verändert oft auch Teile, die sqlmap für interne Logik oder DBMS-spezifische Syntax benötigt. Das führt zu False Negatives: Die Schwachstelle existiert, aber die transformierte Payload trifft sie nicht mehr sauber. Ebenso problematisch ist das Gegenteil: Ein Script verändert zu wenig und umgeht den Filter nur in einem Testfall, nicht aber in späteren Enumerations- oder Dump-Phasen. Sehr häufig sind auch Probleme in der Script-Kette. Mehrere Tamper Scripts können sich gegenseitig neutralisieren oder zerstören. Ein Script fügt Kommentare ein, ein späteres Script kodiert die Kommentarzeichen, ein drittes normalisiert wieder Teile zurück. Das Ergebnis sieht komplex aus, ist aber funktional schlechter als eine einzelne gezielte Transformation. Wer mit mehreren Scripts arbeitet, muss die Reihenfolge bewusst planen und jede Stufe einzeln validieren. Weitere typische Fehler:

• Transformationen werden nicht gegen verschiedene SQLi-Techniken getestet und funktionieren nur in einer frühen Erkennungsphase.
• Das Script ignoriert DBMS-Unterschiede und erzeugt Payloads, die nur auf einem System syntaktisch gültig sind.
• Response-Verhalten wird nicht sauber verglichen, wodurch Blockaden, Timeouts und echte Treffer verwechselt werden.
• Das Script wird als Ersatz für saubere Request-Reproduktion genutzt, obwohl das eigentliche Problem in Session, Token oder Headern liegt.

Gerade der letzte Punkt ist in realen Umgebungen entscheidend. Viele vermeintliche Tamper-Probleme sind in Wahrheit Authentifizierungs-, Session- oder Header-Probleme. Wenn Requests ohne gültige Cookies, CSRF-Token oder Header-Kontext laufen, wird jede Payload scheitern, egal wie gut sie obfuskiert ist. In solchen Fällen helfen eher Authentifizierung, Auth Cookie Session oder Header Manipulation als ein weiteres Tamper Script. Ein weiterer häufiger Fehler ist fehlendes Logging. Ohne nachvollziehbare Testreihen bleibt unklar, welche Änderung tatsächlich wirksam war. Wer drei Scripts, zwei Header-Anpassungen und geänderte Timeouts gleichzeitig einführt, kann den Effekt nicht mehr sauber zuordnen. Sauberes Arbeiten bedeutet deshalb: immer nur eine Variable ändern, Requests mitschneiden, Unterschiede dokumentieren und erfolgreiche Transformationen reproduzierbar halten.

Ein Tamper Script ist erst dann brauchbar, wenn seine Wirkung nachvollziehbar validiert wurde. Dazu reicht es nicht, dass sqlmap plötzlich weniger 403-Antworten sieht. Entscheidend ist, ob die transformierten Payloads noch dieselbe fachliche Aussage transportieren und ob sqlmap damit konsistent erkennen, enumerieren und extrahieren kann. Debugging bedeutet daher immer zweigleisig zu arbeiten: syntaktische Korrektheit der Payload und operative Wirkung im Zielpfad. Der erste Schritt ist die Sichtbarkeit der transformierten Nutzlast. Dazu wird sqlmap mit höherer Verbosität, Proxy oder Request-Mitschnitt betrieben. Nur so lässt sich prüfen, ob das Script tatsächlich das verändert, was beabsichtigt war. In vielen Fällen zeigt sich dabei sofort, dass eine Transformation zu früh, zu spät oder auf den falschen Teil der Payload angewendet wurde. Besonders hilfreich ist ein Vergleich zwischen Original-Payload, transformierter Payload und dem, was am Server tatsächlich ankommt. Ein sinnvoller Testablauf sieht so aus:

sqlmap -r request.txt -p id --tamper=mein_script --proxy=http://127.0.0.1:8080 -v 6

Mit Proxy und hoher Verbosität lässt sich nachvollziehen, ob sqlmap die Payload wie erwartet erzeugt und ob nachgelagerte Komponenten sie weiter verändern. Gerade bei WAFs, CDNs und API-Gateways ist dieser Vergleich unverzichtbar. Wer tiefer in Fehlerbilder einsteigen will, sollte zusätzlich Debugging Advanced, Error Analyse und Logging Auswertung beherrschen. Validierung bedeutet außerdem, nicht nur den ersten Treffer zu prüfen. Ein Script kann Detection verbessern, aber Enumeration verschlechtern. Es kann Boolean-basierte Tests ermöglichen, aber Time-based Payloads unbrauchbar machen. Deshalb sollten mindestens folgende Phasen separat geprüft werden: Erkennung des Parameters, Bestätigung der Technik, einfache Enumeration wie Banner oder Current User, danach erst tiefere Datenbankabfragen. Wenn ein Script nur in der ersten Phase funktioniert, ist es kein belastbares Werkzeug. Ein praxisnaher Ansatz ist, zunächst mit minimalen Testpayloads zu arbeiten und erst danach komplexere Abfragen zuzulassen. So wird schneller sichtbar, welche Transformation wirklich nötig ist. Wer direkt mit aggressiven Dump- oder Enumeration-Optionen startet, erzeugt unnötig viel Verkehr und erschwert die Ursachenanalyse. Für die operative Seite helfen dabei auch saubere Befehle und reproduzierbare Beispiele. Ein gutes Debugging endet nicht bei Erfolg. Auch erfolgreiche Scripts müssen auf Nebenwirkungen geprüft werden: Verändert sich das Timing stark? Steigt die Fehlerrate? Werden bestimmte Payload-Typen systematisch beschädigt? Erst wenn diese Fragen beantwortet sind, ist das Script stabil genug für längere Läufe oder wiederholte Nutzung in ähnlichen Umgebungen.

Beim Thema WAF-Bypass werden Tamper Scripts oft überschätzt. Viele erwarten, dass ein kreatives Script jede Blockade umgeht. In realen Umgebungen funktioniert das selten. Moderne WAFs analysieren nicht nur rohe Strings, sondern dekodieren, normalisieren, tokenisieren und bewerten Anomalien über mehrere Ebenen. Ein erfolgreicher Bypass entsteht deshalb meist nicht durch maximale Obfuskation, sondern durch eine präzise Anpassung an die konkrete Erkennungslogik. Ein typischer Fehler ist der Versuch, mit einem universellen Script alle bekannten Signaturen zu verschleiern. Das erzeugt auffällige Requests, erhöht die Komplexität und kann zusätzliche Regeln triggern. Besser ist ein minimalinvasiver Ansatz: Nur das Token oder Muster verändern, das tatsächlich blockiert wird. Wenn eine WAF auf UNION SELECT reagiert, muss nicht die gesamte Payload kodiert werden. Oft reicht es, nur die Trennzeichen oder die Darstellung einzelner Keywords zu variieren. Praxisnah ist auch die Kombination aus Tamper Script und sauberem Request-Kontext. Eine WAF bewertet häufig nicht nur die Payload, sondern auch Header, Session-Konsistenz, Request-Frequenz und Client-Verhalten. Ein technisch gutes Script bringt wenig, wenn Requests ohne gültige Session, mit verdächtigem User-Agent oder in unnatürlicher Frequenz gesendet werden. In solchen Fällen gehören Themen wie Waf Bypass, Waf Bypass Allgemein und Rate Limit Bypass in denselben Arbeitskontext. Ein realistisches Beispiel: Eine Anwendung blockiert Standard-Boolean-Payloads mit 403, lässt aber leicht veränderte Time-based Payloads durch. Daraus folgt nicht automatisch, dass Time-based die bessere Technik ist. Es kann auch bedeuten, dass die WAF auf bestimmte boolesche Muster trainiert ist, während Zeitfunktionen in diesem Kontext weniger streng geprüft werden. Ein gutes Tamper Script würde dann nicht wahllos alles obfuskieren, sondern gezielt die booleschen Trigger brechen oder sqlmap auf eine passendere Technik lenken. Wichtig ist außerdem, zwischen Bypass und Stabilität zu unterscheiden. Ein Script, das in 2 von 10 Requests durchkommt, ist für reproduzierbare Arbeit kaum brauchbar. Gerade bei WAFs zählt Konsistenz. Deshalb sollte jede erfolgreiche Transformation über längere Serien geprüft werden. Wenn Responses schwanken, Blockraten steigen oder Sessions invalidiert werden, liegt das Problem oft nicht mehr in der Payload selbst, sondern im Gesamtverhalten des Scans. Dann sind ergänzende Maßnahmen wie Proxy-Steuerung, Timing-Anpassung oder Request-Replay oft wirksamer als weitere String-Manipulation.

Ein gutes Tamper Script entsteht nicht in einem einzelnen Lauf, sondern in einem sauberen Workflow. Dazu gehört zuerst eine stabile Ausgangsbasis: reproduzierbarer Request, klar definierter Zielparameter, bekannte Session-Lage und dokumentiertes Response-Verhalten ohne Tamper. Erst danach beginnt die eigentliche Entwicklung. Wer diese Reihenfolge einhält, spart später massiv Zeit bei Fehlersuche und Anpassungen. In der Praxis hat sich ein vierstufiger Ablauf bewährt. Zuerst wird der Request isoliert und mit minimalen Payloads getestet. Danach folgt eine erste, bewusst kleine Transformation. Im dritten Schritt wird die Wirkung gegen mehrere Techniken und Response-Muster geprüft. Erst im vierten Schritt wird das Script in längere sqlmap-Läufe übernommen. Dieser Ablauf verhindert, dass ein scheinbar funktionierendes Script zu früh in komplexe Enumeration oder Dump-Prozesse eingebaut wird. Ein sauberer Workflow umfasst auch Versionierung. Schon kleine Änderungen an Regex, Priorität oder Kontextlogik können das Verhalten stark verändern. Deshalb sollten Scripts mit klaren Namen, Änderungsnotizen und Testfällen gepflegt werden. Das gilt besonders dann, wenn mehrere ähnliche Zielsysteme geprüft werden. Ein Script, das für eine bestimmte WAF-Regel geschrieben wurde, ist nicht automatisch auf andere Anwendungen übertragbar, selbst wenn die Blockade oberflächlich ähnlich aussieht. Für wiederverwendbare Qualität helfen folgende Regeln:

1. Ausgangsrequest unverändert sichern
2. Nur eine Transformation pro Testschritt einführen
3. Wirkung gegen Detection und Enumeration getrennt prüfen
4. Mitschnitte und Response-Metriken dokumentieren
5. Script erst nach stabilen Serienläufen produktiv nutzen

Wer regelmäßig mit sqlmap arbeitet, profitiert davon, Tamper-Entwicklung nicht isoliert zu betrachten, sondern in den Gesamtprozess einzubetten. Dazu gehören Scan Ablauf, Pentest Workflow Komplett und saubere Best Practices Advanced. Ein Tamper Script ist nur ein Baustein. Seine Qualität zeigt sich daran, wie gut es sich in reproduzierbare Tests, nachvollziehbare Ergebnisse und stabile Folgeaktionen einfügt. Wiederverwendung bedeutet außerdem, Scripts modular zu halten. Ein Script für Kommentar-Injektion sollte nicht gleichzeitig Header-Logik, Session-Annahmen und DBMS-Sonderfälle vermischen. Kleine, klar abgegrenzte Scripts sind leichter zu testen, besser kombinierbar und schneller anpassbar. Genau das macht sie in realen Assessments wertvoll.

Ein realistischer Fall aus der Praxis: Ein numerischer GET-Parameter reagiert auf Standardtests mit 403, während normale Werte sauber verarbeitet werden. Ein manueller Vergleich zeigt, dass einfache numerische Eingaben akzeptiert werden, aber typische Muster wie AND 1=1 oder UNION SELECT sofort blockiert werden. Ein Proxy-Mitschnitt zeigt außerdem, dass URL-Encoding einzelner Zeichen keine Änderung bringt, kommentierte Leerzeichen jedoch teilweise akzeptiert werden. Gleichzeitig bleiben manche Payloads instabil, weil die WAF auf bestimmte Keyword-Folgen reagiert. Die erste naive Lösung wäre ein globales Ersetzen aller Leerzeichen durch Kommentare und aller Keywords durch gemischte Groß-/Kleinschreibung. Genau das führt oft zu instabilen Ergebnissen. Besser ist ein schrittweiser Ansatz. Zuerst wird nur das Leerzeichenproblem adressiert. Danach wird geprüft, ob die WAF weiterhin auf Schlüsselwörter reagiert. Erst wenn das bestätigt ist, wird eine zweite, gezielte Transformation ergänzt. Ein mögliches Script:

import re
from lib.core.enums import PRIORITY

__priority__ = PRIORITY.NORMAL

KEYWORDS = ("AND", "UNION", "SELECT", "WHERE", "FROM")

def tamper(payload, **kwargs):
    if not payload:
        return payload

    result = []
    in_single = False
    in_double = False

    for ch in payload:
        if ch == "'" and not in_double:
            in_single = not in_single
            result.append(ch)
            continue
        if ch == '"' and not in_single:
            in_double = not in_double
            result.append(ch)
            continue

        if ch == " " and not in_single and not in_double:
            result.append("/**/")
        else:
            result.append(ch)

    payload = "".join(result)

    for keyword in KEYWORDS:
        payload = re.sub(r"(?i)\b%s\b" % keyword, lambda m: "".join(
            c.upper() if i % 2 == 0 else c.lower()
            for i, c in enumerate(m.group(0))
        ), payload)

    return payload

Dieses Script ist nicht perfekt, aber es illustriert einen sauberen Denkansatz: erst Kontext beachten, dann nur definierte Keywords verändern. Danach wird nicht sofort ein kompletter Dump gestartet, sondern zunächst mit kleinen Tests geprüft, ob Detection, Boolean-basierte Bestätigung und einfache Enumeration stabil laufen. Wenn etwa Banner-Abfragen funktionieren, aber UNION-basierte Enumeration instabil bleibt, ist das ein Hinweis darauf, dass die Keyword-Transformation noch zu grob ist oder die WAF speziell auf UNION-Muster reagiert. Genau an diesem Punkt trennt sich brauchbare Praxis von blindem Probieren. Ein belastbares Script entsteht durch wiederholtes Messen, Vergleichen und Reduzieren. Wenn eine Transformation keinen klaren Mehrwert bringt, wird sie entfernt. Wenn ein Script nur mit bestimmten Headern oder Sessions funktioniert, wird das dokumentiert und in den Workflow integriert. Wer so arbeitet, baut nicht nur ein funktionierendes Script, sondern ein reproduzierbares Werkzeug für reale Assessments.