Potenzielle Resourcenfresser oder Sicherheitslücken?
lima-city → Forum → Programmiersprachen → PHP, MySQL & .htaccess
arbeit
bekommen
browser
code
dank
fehler
formular
funktion
http
investieren
jemand
kopieren
limit
moment
nutzer
parameter
testen
url
verwenden
webseite
-
Ich arbeite momentan kontinuierlich an meiner neuen Webseite (braucht nicht zu gucken -- ist noch nichts online) und bin gerade bei der Erstellung einer Seite "Experimente", auf der man einige meiner kleineren PHP Scripte direkt ausprobieren können sollte. Bei einigen ist klar, dass sie sich nicht eignen, um sie auf Lima-City zu hosten, bei anderen ist klar, dass sie unbedenklich sind.
Bei zweien meiner Scripte fällt es mir jedoch schwer, zu entscheiden, ob ich sie hier bedenkenlos hosten kann:
1. Regex http://pastebin.com/nk2LT43A
Das Script "Regex" soll es dem Benutzer ermöglichen, die Auswirkungen von regulären Ausdrücken in PHP direkt zu testen. In der PHP Funktion preg_replace ist durch den Modifier /e jedoch eine potenzielle Sicherheitslücke gegeben. Reicht da mein naiver Ansatz, einfach "e" durch "x" zu ersetzen? Gibt es einen besseren Weg, die Daten zu escapen?
2. Chartable http://pastebin.com/edfAFfAz
Meine kleine PHP-Zeichentabelle ist zwar vor "bösartigen" Nutzereingaben sicher, jedoch könnte der Benutzer über die Parameter leicht sehr hohe Grenzen angeben, wodurch eine unnötig große Seite generiert und zum Nutzer geschickt wird. Ist es OK, die Seite so zu hosten, oder sollte man ein Limit festlegen, wie: Die Ausgabe darf maximal 20.000 Zeichen umfassen oder Ähnliches?
In beiden Fällen würde ich die Scripte entweder so oder geringfügig modifiziert hosten. Es lohnt sich nicht, für derart simple Scripte so viel Zeit zu investieren, um die Zeichentabelle mit "Seiten" auszustatten, die man "durchblättern" kann und es lohnt sich ebensowenig, das Formular für "Regex" großartig anzupassen, um Modifier separat zu erfassen.
Im Zweifel lass ich es lieber bleiben, aber mich interessiert eure Meinung -- vielleicht mache ich mir ja nur unnötig Sorgen. -
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
-
1) "e" ist eh deprecated. Daher IMHO eh besser eine Alternative zu finden. Braucht man für einen einfachen RegEx-Checker meist eh nicht.
2) Naja, wenn was schief geht dann eben die Anzahl. Schaden kann's ja nicht, bevor du Ärger wegen Überlastung bekommst.
-
muellerlukas schrieb:
Das schon, ich will /e ja auch nicht zulassen, sondern verhindern.
1) "e" ist eh deprecated. Daher IMHO eh besser eine Alternative zu finden. Braucht man für einen einfachen RegEx-Checker meist eh nicht.
In die Zeichentabelle habe ich jetzt mal ein Limit auf maximal 20000 Zeichen eingebaut, das wird für normale Anwendungszwecke ausreichen. -
Ah, dann hatte ich das falsch verstanden, dachte hast es aktuell zugelassen und wolltest es gegen das "x" ersetzen.
Da würde ich das endende "e" per Regex raus hauen.
Was ich durch eine Suche mitbekommen habe: "eval" gesperrt = "e"-Parameter nicht möglich. - Allerings ungetestet. -
Nicht ganz... Im Moment habe ich (Zeilen 10 und 11 aus http://pastebin.com/nk2LT43A):
// Workaround to replace an e which could cause php to execute a command $regex = stripslashes(str_replace("e", "x", $_POST['regex']));Das filtert alle "e"s, man kann einen Regex auch mit Wörtern ohne "e" testen. Allerdings schien es mir etwas plump und möglicherweise nicht sicher genug, wenn jemand das e codiert, sodass es PHP noch versteht, min str_replace aber nicht oder Ähnliches (ich kenne mich da nicht so aus, deshalb frag ich ja...).
Dass die Funktion gesperrt sein könnte ist sicher gut im Hinterkopf zu behalten, aber ich will meine Seite natürlich "generell" sicher haben, nicht nur aufgrund einer bestimmten Konfiguration weniger anfällig sein.
Zum Thema Rausschneiden per Regex: Könnte man sicher machen, kann meines erachtens jedoch schnell noch unsicherer werden, als es im Moment ist. Ich würde natürlich den Komfort dazugewinnen, dass der Nutzer auch "e"s in seinen Testdaten verwenden kann. Außerdem: Wie würde man das genau angehen? So (nicht getestet, nur konzeptuell zu verstehen)?if(!preg_match('/\/^(.*)\/[^e]*$/', $_POST["regex"])) die("E NICHT ERLAUBT"); -
eval schaut leint phpinfo() hier auch erlaubt zu sein.
Eventuell kann man das per .htaccess sperren. Da kann nur ein Mod Bescheid wissen.
Mir fällt auch sonst leider nix ein und die Doku gibt auch leider nix her. -
Wenn es keine absolut sichere Lösung gibt, dann bleibt die Regex-Seite eben offline -- ist ja auch nicht tragisch, es gibt schließlich sicher noch Millionen anderer Seiten, wo Leute alle Arten von Regexes testen können...
Diese beiden Links machen mir jedenfalls keine Hoffnung
* http://stackoverflow.com/questions/1865020/php-how-to-disable-dangerous-functions
* http://stackoverflow.com/questions/7243073/how-can-i-disable-the-e-preg-replace-eval-modifier-in-php -
Notfalls nimmst du den Regex an sich und bestimmt die Parameter selbst über eine Checkbox. Damit bist du gut dran.
Das ist hier wohl die beste Lösung. :-) -
Ich hatte auch schon daran gedacht, will in ein derart simples und wirklich nicht schönes Script aber nicht so viel Arbeit investieren. Die Zeit stecke ich lieber in die Inhalte meiner Seite, damit diese bald mal fertig wird und qualitativ überzeugen kann. Ich wollte mit meiner Frage vor Allem sichergehen, dass ich keine offensichtliche Lösung übersehen habe und anscheinend habe ich nichts Offensichtliches übersehen.
Ich stimme aber zu, es sicher die sauberste Lösung ist, getrennte Formularelemente dafür anzulegen. -- Wenn man irgendwo Eingaben zu Sicherheitszwecken prüfen muss ist meistens etwas falsch: Bei SQL gibt es Prepared Statements, bei rohen Benutzereingaben Base64, für Passwörter bcrypt, etc.
masysma schrieb:
...
In beiden Fällen würde ich die Scripte entweder so oder geringfügig modifiziert hosten. Es lohnt sich nicht, für derart simple Scripte so viel Zeit zu investieren, um die Zeichentabelle mit "Seiten" auszustatten, die man "durchblättern" kann und es lohnt sich ebensowenig, das Formular für "Regex" großartig anzupassen, um Modifier separat zu erfassen.
... -
Was dir mit den Checkboxen schief gehen kann: Du kriegst einen PHP-Fehler. Fang den doch ab und gebe eine Fehlermeldung aus. PHP liefert auch dafür Funktionen.
So viel Arbeit ises auch nicht die Checkboxen zusammenzufügen.
-
Fehler kann ich auch ohne Checkboxen bekommen, beispielsweise durch fehlerhafte Regex-Eingabe mit geöffneten und nicht geschlossenen Klammern oder Ähnlichem. Und: Es ist zwar nicht viel Arbeit, aber dennoch Verschwendung für so ein kleines Testprogramm noch mehr als 10 Minuten zu investieren.
Danke trotzdem für die Anregungen.
Das Script wird Open Source auf meiner Webseite zum Download stehen und damit von Jedem selbst lokal testbar sein und natürlich auch Modifikationen erlauben, sodass der interessierte Nutzer/Programmierer (wenn man sich für PHP Regexes interessiert, will man ja etwas programmieren) das Script nach eigenen Wünschen verbessern kann. -
Auswerten ist nicht sinnlos.
Aber wo du Recht hast: Es gibt schon genug solcher Seiten. Da lohnt sichs nicht.
Für die Offline-Verwendung aber nicht schlecht. Bessser als die GUI-Varianten, wenn man eh dauernd im Browser arbeitet. Scripts findet man da wenige. Daher: Danke, dass du dir die Mühe machst. :-)
Würde mich freuen den Link von dir zu Bekommen.
Edit: Mailadresse entfernt.
Beitrag zuletzt geändert: 12.8.2014 1:14:48 von muellerlukas -
Der Link zum Quelltext ist schon online, schließlich wollte ich ja, dass jeder weiß, über welchen Quelltext ich da spreche: http://pastebin.com/nk2LT43A (Ich hoffe ich habe das richtig verstanden und das ist der "Link"). Auf meiner Webseite ist es noch nicht verfügbar, solange man nicht alle meine momentan veröffentlichten Programme herunterladen will, was ich als Übergangslösung eingerichtet habe.
Bezüglich einer "Offline-Verwendung": So richtig offline geht das ja nicht, weil man wenigstens PHP (für das konkrete Script am Besten auch noch einen Webserver) benötigt. Q&D kann man aber auch von der Kommandozeile testen, ganz ohne extra Script (unter Windows ist das möglicherweise umständlicher):
~$ php <?php echo preg_replace('/a/', 'b', 'aaffeebb'); ?> bbffeebb -
Eh, ja. Ich dacht, da steckt noch ein bisschen Optimierung für deine Webseite drin.
Offline meinte ich: Zum Testen auf einem lokal Webserver.
Helfen tuts auf jeden Fall, wenn man im Browser einen Tab auf hat und nicht noch ein weiteres Programm.
Eins muss man hier mal da lassen: Es tut auch super auf schwachen Rechnern, die nur zum Entwickeln gedacht haben. Kein überladener JS-Kram.
Darf man das Script einfach so erweitern?
Simpel, kein JS. Mit 512 MB RAM kannst nicht schaden, dass ins Forensystem einzubinden und auf JS zu verzichten.
Schnell geschrieben wärs auch nett, aber warum selber machen, wenn sich jemand schon die Mühe gemacht hat?
-
Man darf es einfach erweitern. Ich wäre natürlich froh, wenn bei einer modifizierten Version, die online steht (lokal ist es komplett egal) ein kleiner Verweis stünde, dass es auf Code von "Linux-Fan, Ma_Sys.ma <Ma_Sys.ma@web.de>" basiert.
Bzgl Optimierung für meine Webseite: Das Script existierte schon lange vor meiner Webseite und wäre einfach unverändert verlinkt worden, sozusagen als "`Fremdkörper"' auf der ansonsten viel moderner gestalteten Webseite.
Auf JavaScript will ich auf meiner Seite generell möglichst verzichten, weil mich mittlerweile sogar die einfachsten Javascripts nerven. Zum Beispiel versuchen viele Seiten das Kopieren von Links einfacher zu machen, indem sie sie in ein Input-Feld schreiben, welches sich automatisch beim loslassen der Maustaste komplett markiert. Wenn man aber nur einen Teil der URL kopieren will, oder das unter Linux übliche Kopieren mit der mittleren Maustaste für die ganze URL verwenden will, funktioniert es nicht, weil man dazu selbst den Text markieren kann, was dank JavaScript aber nicht geht... -
Sorry, aber was du da vor hast ist einfach nur leichtsinnig, gefährlich und dumm! Besucher sollten niemals fähig sein, nativen PHP Code auszuführen, selbst als Demonstration nicht. Dabei ist es egal welche Vorsichtsmaßnahmen du triffst, es gibt immer eine Lücke, die früher oder später gefunden und ausgenutzt wird.
Wenn du unbedingt Demos haben willst, emuliere diese mit JS! Ausreden wie "Ich möchte JS vermeiden, weil es nervt!" gelten bei Sicherheitsfragen überhaupt nicht. -
Genau deshalb hatte ich ja anfangs gefragt, ob man verhindern kann, dass "e" verwendet wird -- dann könnte der Nutzer kein PHP ausführen. Ich war mir nämlich auch sicher, dass es zu Problemen führt, wenn man so etwas online stellt. Danke für die definitive Bestätigung.
Ich werde auf meiner Seite JS vermeiden, aber generell auch kaum "`aktive"' Inhalte haben, um einfache Wartbarkeit und große Stabilität sicherzustellen. Die einzigen anderen "`Demos"' dieser Art sind tatsächlich auf JavaScript basiert (außer die angesprochene Zeichentabelle, aber da kann der Nutzer ausschließlich Zahlen eingeben). -
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
