Silke Schümann wrote this 15:44:
Editland verwendet eine Whitelist, so dass, wenn Editland und Plugins über die index.php im Root aufgerufen wird, nichts passieren kann, dennoch kann es nicht schaden ein wenig Vorsicht walten zu lassen. Auch wenn man Plugins programmiert ist die folgende Prüfung kein Fehler.
if (!ereg("^[()A-Za-z0-9_-]+$",$_GET['s'])) {callError("illegalPagenameChars","$_GET['s']");}if (!ereg("^[()A-Za-z0-9_-]+$",$_GET['c'])) {callError("illegalOrdChars","$_GET['c']");}
In der Funktion callError() werden alle Variablen in dem kommenden Update durch einige Filter laufen, bevor der Inhalt dieser Variablen im in einer Fehlerseite angezeigt wird.
Seiten zur Sicherheit in PHP ist sicherlich eine Seite, die man sich früh zu Gemüte führen sollte.
Zum Beispiel: php-faq: Wie unterscheide ich böse Variablen von guten?
Mir fallen hierzu folgende Maßnahmen ein, wenn man beliebige Eingaben als harmlosen String ausgeben will, wie z.B. in einer Fehlermeldung.
- In http:// und ../ Leerschritte einfügen, bzw. / durch / ersetzen
- < und > durch < und > ersetzen
- Die Variable durch die Filterfunktion addslashes() jagen
und ein Vorkommen der Funktion strippslashes durch anfügen von fkt_ vor stripslashes verhindern, dass addslashes neutralisiert wird.
- Die vier Funktionen (include, include_once, require, require_once) um Dateien in PHP einzufügen ebenfalls durch das anfügen von fkt_ funktionslos auszugeben.
Habe ich eine Möglichkeit vergessen, wie über eine der Variablen der $_REQUEST[]-Familie sich ausführender Programmcode ins Programm schleichen kann?
PS: strip_tags() kommt nicht in Frage, weil, damit alles zwischen den spitzen Klammern entfernt wird und das ist nicht gewollt.
Update: Claudia Reiser machte mich in einem kleinen Maildialog drauf aufmerksam, dass ereg() ein Auslaufmodell sei. Preg_match sei ereg vorzuziehen. Aha. Ausprobiert. Nur !preg_match("^[()A-Za-z0-9_-]+$",$_GET['s']) funktioniert nicht. Die Syntax für preg_match() ist anders. Preg_match bemötigt Delimiter. Nach einigem hin und her, Frustration über die Doku, die meines Erachtens einen im Regen stehen lässt, fand ich es aber dann doch heraus:
if (!preg_match("/^[()0-9a-z_-]+$/i",$_GET['s']) {callError("illegalPagenameChars","$_GET['s']");}
Die Syntax ist wie folgt:
- Funktion: preg_match(”Pattern”, “String”)
Ich brauche nur ein true oder false, das heißt ich kann auf die Teile in den eckigen Klammern in der Doku auf php.net verzichten.
- Pattern: ‘/’ Delimiter ‘^’Anfang ‘[' gesuchte Zeichen Start ']‘ gesuchte Zeichen Ende ‘0-9′ Alle Zeichen zwischen 0 und 9 (a bis z dito) und das Minuszeichen als letztes vor die eckige Klammer gesetzt, erspart einem das Minus zu escapen ‘+$’ Prüfen bis zum bitteren Ende, ‘/’ Delimiter am Ende und ‘i’ auf Groß und Kleinschreibung muss nicht geachtet werden.
Hilfen, die ich benötigte, um auf die Lösung zu kommen: Reguläre Ausdrücke und meine Notiz vom November 06 auf Silkester: PHP: regex kurz notiert
PPS: Mein Kampffile mit dem ich mich dem Regulären Ausdruck näherte, ist hier zu finden: Pregmatch-Schlachtfeld und der Quelltext: preg_match.phps
Übel aber lieber Jetzt als Später … Sorry: Das Post-Slug in Wordpress nach der Veröffentlichung zu ändern ist nicht gerade der Hit. Aber lieber solange es nur ein paar RSS-Reader betrifft als später, wenn der Post verlinkt ist. Ich hatte hier die Wörter mehr als unglücklich im Titel verdreht. Das konnte so nicht bleiben. “via $_GET” musste einfach vor “in Editland” und nicht dahinter stehen. Ich entschuldige mich hiermit bei allen, die mit murren oder sonstwie vom Feeder über den alten Slug ins Leere gelaufen sind.
Filed under: Webmarketing
1 Comment