Parameter Tampering

Warum es wichtig ist

Der Großteil der sensiblen Arbeit einer Anwendung passiert in Parametern, die der Nutzer in der Adresszeile nie sieht. POST- und PUT-Bodys tragen IDs, Flags, API-Keys und Action-Namen, und weil sie nicht in der URL auftauchen, validieren Entwickler sie oft weniger streng. Genau diese Lücke ist es, wo Parameter Tampering Bugs findet.

Tampering ist selten ein einzelner Bug. Es ist eine Sonde. Ein einziger veränderter Wert kann eine Information Disclosure, eine SQL Injection, ein IDOR oder eine Schwachstelle in der Geschäftslogik aufdecken, weshalb es eine der wertvollsten Gewohnheiten ist, die ein Tester aufbauen kann. Es braucht zudem kein besonderes Werkzeug über einen abfangenden Proxy wie Burp Suite hinaus, was es zu einer der ersten Fähigkeiten macht, die ein Einsteiger in echte Funde verwandeln kann.

Wo Parameter leben

Eine Anwendung sendet Parameter an mehreren Stellen an den Server, und jede davon ist mit einem Proxy editierbar:

• URL-Query-String: ?page=1&sort=price, sichtbar in der Adresszeile.
• POST- und PUT-Body: formularkodierte oder JSON-Werte, vor der URL verborgen und oft locker validiert.
• Cookies und Header: Session-Status, Rollen, Feature-Flags und IP-Hinweise, allesamt vom Angreifer kontrolliert.

Wie es funktioniert

Der Tester fängt einen Request ab, ändert einen Parameter nach dem anderen, sendet ihn erneut und liest die rohe Response. Die Disziplin besteht darin, pro Request nur eine Sache zu ändern, damit die Ursache jeder Verhaltensänderung eindeutig ist. Die Sonden unterscheiden sich nach Datentyp:

• Numerische Werte: probiere ein einzelnes Anführungszeichen, eine negative Zahl, eine Null, eine sehr große Zahl und die ID eines anderen Nutzers. Ein einzelnes Anführungszeichen, das einen Datenbankfehler erzeugt, deutet auf SQL Injection; zurückkommende Daten eines anderen Nutzers deuten auf IDOR.
• Boolean-Flags: schalte isAdmin=false auf true, verified=no auf yes oder entferne den Parameter ganz, um zu sehen, ob der Server auf einen unsicheren Default zurückfällt.
• Preis- und Mengenfelder: setze einen Preis herab, vergib eine negative Menge oder ändere eine Währung, um die Checkout-Logik zu testen.
• Strings: probiere Anführungszeichen, Backslashes, Null-Bytes und Path-Traversal-Sequenzen wie ../../etc/passwd.

Auswirkungen in der Praxis

Parameter Tampering hat von kostenlosen Käufen über ein manipuliertes price-Feld über Kontoübernahmen durch eine vertauschte Benutzer-ID bis hin zur vollständigen Extraktion einer Datenbank, die mit einem einzigen Anführungszeichen in einem numerischen Parameter begann, alles hervorgebracht. Weil es auf Vertrauen statt auf eine bestimmte Technologie zielt, taucht es in klassischen Web-Apps, modernen Single-Page-Applications und APIs gleichermaßen auf.

Prävention

Behandle jeden Parameter als feindlich. Nutze parametrisierte Abfragen, um Injection zu verhindern, erzwinge eine Autorisierung auf Objektebene bei jeder Referenz, berechne Preise und Summen serverseitig neu und weise unerwartete Felder ab, statt sie automatisch zu binden. Wo ein Wert zwingend durch den Client zurücklaufen muss, signiere oder verschlüssele ihn, damit Manipulation erkennbar ist, und protokolliere Anomalien wie negative Preise oder Zugriffe, die Nutzergrenzen überschreiten.