Folgende Lösung nutzt TYPO3: Falls „magic_quotes_gpc“ inaktiv ist, wird einfach simuliert, dass es aktiv ist. Sowohl zu Beginn der Frontend-Page-Generierung als auch der Backend-Page-Generierung wird dafür gesorgt, dass alle Elemente der PHP-Arrays „$_GET[]“ und „$_POST[]“ durch sich selbst überschrieben werden, nachdem „addslashes()“ auf sie angewendet worden ist. Der Grund hierfür ist, dass genau die hinter „addslashes()“ steckende Funktionalität auch im Falle von aktivierten „Magic quotes“ zur Anwendung kommt.

„addslashes()“ bietet aber, wie später noch deutlich wird, nicht immer einen wirksamen Schutz vor SQL-Injections. Um den Inhalt von „$_POST['first_name']“ zu schützen, müsste deshalb – unnötig umständlich – zunächst „stripslashes()“ darauf angewendet werden, um danach noch „quoteStr()“ zur Entschärfung zu nutzen.

Deshalb kann der direkte Zugriff auf Nutzereingaben in TYPO3-Extensions über die PHP-Superglobals $_GET[] und $_POST[] nicht empfohlen werden. Einfacher und weniger fehleranfällig ist hier allemal, die drei von TYPO3 bereitgestellten statischen Methoden zu verwenden:

• t3lib_div::_GET()
• t3lib_div::_POST()
• t3lib_div::_GP()

Darüber bekommt man die Werte der Request-Variablen ohne störende „Magic Quotes“ frei Haus geliefert. Bei der Methode „t3lib_div::_GP()“ erhalten POST-Parameter gegenüber gleichnamigen GET-Parametern den Vorzug. Die Nutzung der Methode bietet sich an, wenn man unabhängig vom tatsächlichen Request-Typ bleiben möchte. Aus Sicherheitsperspektive ist es jedoch besser, sich bei Formularen konsequent auf den Request-Typ „POST“ zu verlassen und daher „t3lib_div::_POST()“ zu verwenden. Somit wird ein Angriff via Cross-Site-Request-Forgery (CSRF) schwieriger: Böswillig manipulierte URIs, die vom ahnungslosen Opfer beispielsweise beim Lesen einer E-Mail angeklickt werden, können dann nicht mehr ohne Weiteres das Versenden eines ausgefüllten Formulars per GET-Parameter imitieren.