|
||||
PHP und URL Manipulation
Hallo,
nach einigem Studieren von PHP, Prüfung Übergabe Parameter und was alles "andere" so tun könnten, habe ich in einer Testumgebung mit PHP 5.6 angefangen zu experimentieren. Frage 1: Ich übergebe mehrere Parameter mit $_GET["xyz"] und prüfe diese auf Korrektheit im PHP Modul. Alles I.O. und funktioniert, keine anderen als die erlaubten Parameter werden akzeptiert. Verändere ich jetzt die aufrufende URL mit (den gängigen) Nullbyte Definitionen ist auch alles I.O. Die Fehlerroutinen fangen das hervorragend ab. Verändere ich jetzt die aufrufende URL mit unsinnigen Werten ist auch alles I.O. Die Fehlerroutinen fangen das hervorragend ab. Verändere ich jetzt die aufrufende URL mit "#00" bekomme ich nur eine leere weiße Seite in verschiedenen Browsern? Was ist "#00" für ein Problem in der URL? Frage 2: Gibt es einen Weg nur mit PHP ein Formular Reload mit veränderter URL zu verhindern. Beispiel: Admin Interface, Benutzer ist angemeldet und löscht eine Inhaltsseite die er löschen will und darf. Verändert man die URL auf eine andere Inhaltsseite, die der Benutzer ebenfalls löschen darf aber nicht löschen will und drückt im Browser F5 wird diese Inhaltsseite nach dem Reload gelöscht. Ist es möglich das ohne AJAX oder JS oder .NET nur mittels PHP eigener Funktionen zu verhindern? Gruß PS: Es geht um die Portierung eines CMS-System von PHP 5.2 auf PHP 5.6 mit kompletter Überarbeitung des Administration Interfaces.
__________________
Personal stuff Geändert von laborix (13.12.2014 um 16:38 Uhr) |
Sponsored Links |
|
||||
Zitat:
Das interessante hierbei ist dass das nur im Backend (Administration Interface) auftritt, im Frontend wird diese URL mit #00 vom CMS eigenen Fehlersystem auf eine CMS eigene 404er Seite geleitet. Das mit der URL Manipulation ist ein schöner Müll, noch mehr wenn man es versucht alles zu verhindern.
__________________
Personal stuff |
|
||||
Zitat:
Zitat:
Das CMS ist nur reines PHP, kein Javascript, kein sonstiges Framework und Eigenentwicklung.
__________________
Personal stuff |
|
||||
Zitat:
Wenn du das im Browser eingibst schickt er das Zeichen nicht zum Server, d.h. du musst es muss URL kodiert eingeben. Aber das erklärt nicht die weisse Seite. Das ist ein Zeichen, dass der Server Fehler nicht anzeigt. U.u. ist das überschrieben von error_reporting zur Laufzeit nicht erlaubt. Daher meine vorschlag, dass du einen Fehler einbaust. Das du aber mit dem Browser sowas nicht testen kannst ist dir aber auch bewußt? Dieser filtert deine Eingabe, ein Hacker macht einen Angriff nicht über den Browser. |
|
||||
Jede Eingabe, jeder GET/POST, jeder dynamisch generierte Link im Admin Interface und jede direkte Aktion wie Inhalte laden, bearbeiten, schreiben, verschieben oder löschen. Nur beim Hochladen von Dokumenten, Bildern oder Multimedia Inhalte gibt es Lücken die man mit reinem PHP nicht eindeutig überprüfen kann.
Zitat:
https://www.owasp.org/index.php/PHP_...ty_Cheat_Sheet sowie einige Seiten von IBM und MS. Irgendwie so alles was mir mitteilt, was "andere" mit dem CMS/Server tun könnten.
__________________
Personal stuff Geändert von laborix (13.12.2014 um 22:02 Uhr) Grund: Textkorrektur |
|
||||
Zitat:
|
Sponsored Links |
|
||||
Zur Info: nachdem ich heute Morgen meinen Filter umgeschrieben habe, passiert mit dem #00 nichts mehr. Wird sauber abgefangen und auf die CMS eigene 404er Seite geleitet. Diese Fälle passieren nur im Admin Interface, also wenn man angemeldet ist. Im Frontend ohne Anmeldung wird alles auch auf die CMS eigene 404er Seite geleitet
Lustig dabei, ein neuer Umstand mit Internet Explorer 11 und SeaMonkey 2.31. Test URL: http:/../rev37/admin/panel.trashmgmt.php?page=code-samples.txt%00&action=sendtotrash&lang=en Test 1: Server: Windows Server 2012 R2 mit Apache 2.4 und PHP 5.6 Client: Internet Explorer 11 Windows 8.1 Mit %00 jetzt eine weiße Seite und mit Logeintrag HTTP/1.1" 200 und Quellcode der weißen Seite: HTML-Code:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv="Content-Type" content="text/html; charset=utf-8"></HEAD> <BODY></BODY></HTML> Server: Ein Provider mit Linux, Apache und PHP 5.6 Client: SeaMonkey 2.31 ohne Javascript Mit %00 jetzt eine weiße Seite und kein Quellcode Egal, ich werde weiter testen/entwickeln bis das alles sauber läuft. PHP 5.6 EOL ist erst Mitte 2017, bis dahin geht noch viel Zeit ins Land
__________________
Personal stuff Geändert von laborix (14.12.2014 um 13:24 Uhr) Grund: Ergänzung: PHP 5.6 vergessen beim Provider |
Sponsored Links |
Themen-Optionen | |
Ansicht | |
|
|
Ähnliche Themen | ||||
Thema | Autor | Forum | Antworten | Letzter Beitrag |
Darstellungsprobleme im IE | lea11011989 | CSS | 17 | 05.11.2010 10:44 |
Frage zu horizontalen Linien | marvin1989 | CSS | 3 | 30.12.2009 00:35 |
Dateien auslagern - Include und PHP | ArcVieh | Serveradministration und serverseitige Scripte | 17 | 27.03.2008 19:09 |
Problem mit Layout .. vermute: float | Küspert | CSS | 3 | 09.12.2006 18:09 |
Bilder werden überlagert und verschoben. | Küspert | CSS | 5 | 07.12.2006 18:15 |