XHTMLforum

XHTMLforum (http://xhtmlforum.de/index.php)
-   Serveradministration und serverseitige Scripte (http://xhtmlforum.de/forumdisplay.php?f=80)
-   -   PHP und URL Manipulation (http://xhtmlforum.de/showthread.php?t=71571)

laborix 13.12.2014 16:36

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.

protonenbeschleuniger 13.12.2014 16:43

Zitat:

Zitat von laborix (Beitrag 542481)
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?

Gar keins - das leigt an deinem skript. Bist du sicher, dass du auch die Fehlermeldung immer siehst?

laborix 13.12.2014 17:08

Zitat:

Zitat von protonenbeschleuniger (Beitrag 542482)
... Bist du sicher, dass du auch die Fehlermeldung immer siehst?

Ja, error_reporting(E_ALL) ist in jedem PHP-Modul beim Testen eingestellt.

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.

Praktikant 13.12.2014 18:52

Zitat:

Zitat von laborix (Beitrag 542481)
Ist es möglich das ohne AJAX oder JS oder .NET nur mittels PHP eigener Funktionen zu verhindern?

Du kannst ein erneutes Ausführen bzw. Versenden des Fomulares über einen Redirect (auf eine beliebige Seite) verhindern. Bei dem Redirect gehen die Daten in $_POST oder $_GET aus dem Fomular verloren.

protonenbeschleuniger 13.12.2014 19:54

Zitat:

Zitat von laborix (Beitrag 542483)
Ja, error_reporting(E_ALL) ist in jedem PHP-Modul beim Testen eingestellt.

Dann ist eine leere Seite unwahrscheinlich. Bau mal mit Absicht einen Syntaxfehler ein, wird dieser angezeigt?

laborix 13.12.2014 21:12

Zitat:

Zitat von Praktikant (Beitrag 542484)
Du kannst ein erneutes Ausführen bzw. Versenden des Fomulares über einen Redirect (auf eine beliebige Seite) verhindern. ...

Das muss ich mal recherchieren, ich hatte es über eine Session Variable am Laufen. Leider funktionierte das nicht immer richtig, danach habe ich es sein lassen.

Zitat:

Zitat von protonenbeschleuniger (Beitrag 542485)
... Bau mal mit Absicht einen Syntaxfehler ein, wird dieser angezeigt?

Du bringst mich auf eine Idee. Ich habe einen eigenen URL- und Eingabenfilter geschrieben, also alles manuell und Handbetrieb. Wahrscheinlich filtere ich das "#" zuerst, bevor ich Nullbytes filtere. Ich werde das testen und Bescheid geben.

Das CMS ist nur reines PHP, kein Javascript, kein sonstiges Framework und Eigenentwicklung.

protonenbeschleuniger 13.12.2014 21:32

Zitat:

Zitat von laborix (Beitrag 542486)
Du bringst mich auf eine Idee. Ich habe einen eigenen URL- und Eingabenfilter geschrieben, also alles manuell und Handbetrieb. Wahrscheinlich filtere ich das "#" zuerst, bevor ich Nullbytes filtere. Ich werde das testen und Bescheid geben.

Was heißt filtern?
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.

laborix 13.12.2014 21:58

Zitat:

Zitat von protonenbeschleuniger (Beitrag 542487)
Was heißt filtern? ...

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:

Zitat von protonenbeschleuniger (Beitrag 542487)
Dieser filtert deine Eingabe, ein Hacker macht einen Angriff nicht über den Browser.

Eigentlich habe mich an folgender Seite für das CMS orientiert :
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.

protonenbeschleuniger 13.12.2014 22:59

Zitat:

Zitat von laborix (Beitrag 542488)
Eigentlich habe mich an folgender Seite für das CMS orientiert :
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.

Naja, das ändert nichts an dem was ich gesagt habe, mit dem Browser kannst du sowas nicht simulieren. Der filtert deine Eingabe.

laborix 14.12.2014 13:19

Zitat:

Zitat von protonenbeschleuniger (Beitrag 542490)
... mit dem Browser kannst du sowas nicht simulieren. ...

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>

Test 2:
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 :roll:

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 :D


Alle Zeitangaben in WEZ +2. Es ist jetzt 10:01 Uhr.

Powered by vBulletin® Version 3.8.11 (Deutsch)
Copyright ©2000 - 2024, vBulletin Solutions, Inc.

© Dirk H. 2003 - 2023