PHP-Code testen - Versucht diese Seite zu hacken
lima-city → Forum → Sonstiges → Spam und sonstiges Unvergütetes
beachten
befehl
beispiel
benutzen
code
datei
entwickeln
fehler
funktion
gefundene sicherheitsprobleme
hacken
http
index
moderator
server
test
testen
url
versuchen
zahl
-
chatter schrieb:
vercetti schrieb:
@chatter:
Du scheinst ja der Inbegriff von kompetentem Fachwissen zu sein.
Interner Server Fehler bedeutet, dass bei dem Vorgang zwischen HTTP Request und Antwort irgendetwas schiefgegangen ist. Das kann durch eine defekte .htaccess etc passieren.
Ich weiß ja nicht wo ich anfangen soll, Spaß zu erklären. Ich glaube aber nicht dass du sie verstanden hast. Der Fehler passte nur eben gerade sehr gut, da ja viele versuchen Lücken zu finden. Ich weiß auch was der Fehler bedeutet ;)
Rausreden kann sich da jeder;) wenn ich mir diene HP ansehe, weiß ich ganz genau, dass du NICHT wusstest, was der fehler bedeutet
chatter schrieb:
Ausserdem, wenn er uns darum bittet, Fehler zu suchen, und uns dazu ein spezielles Skript zur Verfügung stellt, ist das nicht verboten.
Wieder Spaß. Ich habe den ganzen Thread MIT der Überschrift gelesen und weiß dass er uns darum bittet. Trotzdem war das nur eine Anspielung auf den übertriebenen Paragraphen, womit das eindringen in fremde Systeme verboten ist. Ob das ist wirklich zutrifft ist eher eine Diskussionsfrage.
gleiches wie gerade
chatter schrieb:
Ich bin dann auch mal weiter testen :-)
EDIT:
Übrigens ist die header() Funktion noch erlaubt. Die liese sich auch unter Umständen ausnutzen.
ehm nein, ließe sie sich nicht :D da sieht man mal wie viel ahnung du hast :D
@tct: jo xD -
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
-
Was hat meine HP mit dem Fehler zutun????????
Das ist und bleibt eine Bastel- und Testseite.
Versuchst du hier irgendwie zu trollen???
Ich weiß was der Fehler bedeutet. Freu dich oder lass es. -
chatter und vercetti, wenn ihr euch zoffen wollt bitte per PN. Im Forum will das keiner lesen!
-
Nein, wollen wir nicht. Ich sagte nur, dass ich denke, er weiß nicht, was der Fehler bedeutet.
Egal.
@eval-script:
ich würd sagen das script ist schon ZIEMLICH sicher.. aber ich denke morgen abend werd ich noch was finden :P
Ich bin dann mal off :> -
vercetti schrieb:
Nein, wollen wir nicht. Ich sagte nur, dass ich denke, er weiß nicht, was der Fehler bedeutet.
Egal.
@eval-script:
ich würd sagen das script ist schon ZIEMLICH sicher.. aber ich denke morgen abend werd ich noch was finden :P
Ich bin dann mal off :>
Und jetzt sieht es so aus, als würde jemand noch eine Lücke finden.
Ich habe mal ein bisschen geholfen.
-
tct schrieb:
Wir suchen nicht seine Fehler, sondern versuchen das sicherste eval()-Script der Welt zu entwickeln.
Ernsthaft? Dann schlage ich vor, mit dem Unsinn aufzuhören und (wie von trueweb vorgeschlagen) von Black- auf White-Listing umzusteigen. Ansonsten verstärkt ihr meine Zweifel an den geistigen Fähigkeiten der heutigen Informatikstudenten.
Das sicherste eval()-Script (im Rahmen von PHP) sieht übrigens so aus:
// überprüfen der Eingabewerte echo isset($_GET['code']) ? $_GET['code'] : ''; // ausführen des absolut sicheren Codes eval(''); -
alopex schrieb:
tct schrieb:
Wir suchen nicht seine Fehler, sondern versuchen das sicherste eval()-Script der Welt zu entwickeln.
Ernsthaft? Dann schlage ich vor, mit dem Unsinn aufzuhören und (wie von trueweb vorgeschlagen) von Black- auf White-Listing umzusteigen. Ansonsten verstärkt ihr meine Zweifel an den geistigen Fähigkeiten der heutigen Informatikstudenten.
Das sicherste eval()-Script (im Rahmen von PHP) sieht übrigens so aus:
// überprüfen der Eingabewerte echo isset($_GET['code']) ? $_GET['code'] : ''; // ausführen des absolut sicheren Codes eval('');
Eine Whitelist ist eine zu starke Einschränkung bzw. man muss sehr viele Fälle abdecken.
Die Frage ist, geht es nicht mit eine Blacklist. -
ajacr schrieb:
Eine Whitelist ist eine zu starke Einschränkung bzw. man muss sehr viele Fälle abdecken.
Die Frage ist, geht es nicht mit eine Blacklist.
Nein, die Frage ist ein Sicherheitsaspekt. Lieber mehr einschränken als eine Lücke offen haben... Durch die Rückmeldungen der Benutzer (wenn du entsprechende Features dafür zur Verfügung stellst) weißt du dann, in wie fern du diese zu sehr einschränkst. -
Der Vorteil von Whitelisting ist der, dass du für alle zukünftigen Eventualitäten gewappnet bist.
Jedesmal wenn eine neue PHP-Version eine neue Möglichkeit bietet, irgendwas "Böses" auszuführen, die vorherige PHP-Versionen noch nicht kannten, musst du sonst dein bisheriges Script neu anpassen. Mit Blacklisting kannst du nur auf schon bekannte Sicherheitsrisiken reagieren. Damit begibst du dich in die gleiche Falle wie die Hersteller von Antivirensoftware.
Nebenbei kämen bei einer Offenlegung des aktuellen Quellcodes deines Scriptes sicher noch mehr Einbruchsmöglichkeiten zum Vorschein. Closed Source ist dagegen keine gute Idee, wenn man ein wirklich sicheres Script entwickeln will.
--
Beides gilt natürlich nur, falls du das nicht aus Spaß an der Freude und zur allgemeinen Belustigung machst.
-
alopex schrieb:
Nebenbei kämen bei einer Offenlegung des aktuellen Quellcodes deines Scriptes sicher noch mehr Einbruchsmöglichkeiten zum Vorschein. Closed Source ist dagegen keine gute Idee, wenn man ein wirklich sicheres Script entwickeln will.
Niemand spricht von Closed Source. Darum geht show_source("index.php");.
Beides gilt natürlich nur, falls du das nicht aus Spaß an der Freude und zur allgemeinen Belustigung machst.
Ich will es bestimmt nicht auf eine wichtige Seite einsetzen.
Es soll aber dazu dienen Schnell und einfach php zu testen.
Und natürlich soll es auch Spaß machen.
Heute abend schreibe ich noch etwas zu euren Argumenten. ;) -
Also jetzt mal etwas zu euren Argumenten.
Anforderung: Ich suche ein Skript mit den man möglichst viel Code ausprobieren kann.
Dazu gibt es zwei Möglichkeiten.
1. Whitelist, d.h. man erlaubt nur dass was benötigt wird
2. Blacklist , d,h, man verbiete das was man nicht haben möchte
Jetzt kann man auf die Anforderungen schauen.
Dann wird deutlich, dass eine Whitelist sehr komplex wird. Dies bedeuten aber, dass sie sehr Fehleranfällig ist. Somit wird es bei so einer Liste vermutlich Sicherheitslücken geben.
Diese Sicherheitslücken findet man in den man sich überlegt wie eine Angreifer das Script ausnutzen würde.
Aber genau das macht man auch bei einer Blacklist. Man sucht die möglichen Sicherheitslücken und schließt sie.
Der Vorteil bei einer Blacklist ist, es werden mit der Zeit weniger Sicherheitslücken. Bei einer Whitelist kommen Sicherheitslücken hinzu.
Eine Blacklist wird immer sicher und einer Whitelist immer unsicher.
Zudem ist die Einschränkung bei einer Blacklist in der Regel geringer als bei einer Whitelist.
Dieses spricht für eine Blacklist. Allerdings muss man dann alle Möglichen Sicherheitslücken bedenken. Was gegen eine Blacklist spricht. Währe die Anforderung nicht so groß, dann sollte man besser eine Whitelist benutzen.
alopex schrieb: Der Vorteil von Whitelisting ist der, dass du für alle zukünftigen Eventualitäten gewappnet bist.
Jedesmal wenn eine neue PHP-Version eine neue Möglichkeit bietet, irgendwas "Böses" auszuführen, die vorherige PHP-Versionen noch nicht kannten, musst du sonst dein bisheriges Script neu anpassen. Mit Blacklisting kannst du nur auf schon bekannte Sicherheitsrisiken reagieren. Damit begibst du dich in die gleiche Falle wie die Hersteller von Antivirensoftware.
Das ist ein Punkt, den ich auch bedacht habe.
Allerdings ist es nicht gerade Wahrscheinlich, dass Sicherheitsrelevante Funktionen hinzukommen.
Und wenn du Glaubst eine komplexe Whitelist wäre von diesen Änderungen nicht betroffen, dann irrst du.
Denn es kann sein, dass etwas auf der Whitelist erlaubt wurde, was aber später unsicher ist.
Weil die Syntax erweitert wurde. Änderungen in der Syntax dürfte das gefährliche sein.
Ihr Argumentiert, dass eine Blacklist zu unsicher ist.
Vergesst aber die Risiken zu berücksichtigen.
Ein Ereignis, was sehr Wahrscheinlich ist, aber relativ harmlos. Ist durchaus nicht so schlimm wie einer Ereignis, was ab und zu passiert aber einen sehr großen Schaden anrichtet.
Das Skript ist und bleibt auf einen Webspace, auf den nur diese Skript ist.
Ein Angreifer könnte zwar diesen Webspace kontrollieren. Aber was will er damit? Er hat weniger Funktionen als wenn er sich direkt mit falschen Daten bei Lima anmeldet. Also wird keiner versuchen das Skript wegen den Webspace anzugreifen.
Das Skript wird keine Benutzeranmeldung bekommen. Somit kann der Angreifer auch nicht wichtige Benutzerdaten bekommen.
Was beleibt den Angreifer dann noch.
Doch nur die Besucher der Seite, welchen er versuchen kann einen Virus zu installieren oder zu einer bestimmten Seite Locken kann. Aber davor ist keine Seite sicher.
Der Grund ist, dass man oft sich keine Gedanken macht wie ein Angreifer vorgehen könnte. Aber genau diese macht man ja bei der Blacklist.
Jetzt frage ich euch.
Was ist besser Whitelist oder Blacklist?
Bei anderen Anforderungen könnte eine Whitelist besser sein.
Das beste wäre eine Whitelist und eine Blacklist zu benutzen.
Dieser Aufwand ist aber in Verhältnis zum Nutzen in diesen Fall zu gering. -
3. Möglichkeit - noch komplexer - wäre ein eigener Parser, der auch Dateioperationen in einem Virtuellen Dateisystem erlauben würde.
-
vercetti schrieb:
3. Möglichkeit - noch komplexer - wäre ein eigener Parser, der auch Dateioperationen in einem Virtuellen Dateisystem erlauben würde.
Hm, mal schauen.
Zumindest das Speichern wäre noch etwas, was kommen soll.
Da könnte ich dann mein schönes Feuer in einen einfachen Link posten.
http://ajacr.lima-city.de/?i=100&code=show_source("index.php");%0D%0A$zahl%3D10;%0D%0Aif($_GET[i]>0)+$zahl%3D+$_GET[i];%0D%0Afor($count+%3D+1;+$count+<+$zahl;+$count%2B%2B){%0D%0A++++echo+'<div+style%3D"position:fixed;+top:'.rand(1,+99).'%25;+left:'.rand(1,+99).'%25;"><img+src%3D"img/Feuer_008.gif"></p>%0D%0A</div>';%0D%0A%0D%0A}%0D%0A%0D%0A show_source("index.php"); $zahl=10; if($_GET[i]>0) $zahl= $_GET[i]; for($count = 1; $count < $zahl; $count++){ echo '<div style="position:fixed; top:'.rand(1, 99).'%; left:'.rand(1, 99).'%;"><img src="img/Feuer_008.gif"></p> </div>'; }
Beitrag zuletzt geändert: 17.2.2009 18:27:04 von jacr -
mit i= 10000 gefällt mir dein feuer ;D
http://ajacr.lima-city.de/?i=10000&code=show_source("index.php");%0D%0A$zahl%3D10;%0D%0Aif($_GET>0)+$zahl%3D+$_GET;%0D%0Afor($count+%3D+1;+$count+<+$zahl;+$count%2B%2B){%0D%0A++++echo+'<div+style%3D"position:fixed;+top:'.rand(1,+99).'%25;+left:'.rand(1,+99).'%25;"><img+src%3D"img/Feuer_008.gif"></p>%0D%0A</div>';%0D%0A%0D%0A}%0D%0A%0D%0A
-
vercetti schrieb:
mit i= 10000 gefällt mir dein feuer ;D
Wir können ja mal eine Wettbewerb machen.
Wer kann an besten das Skript verbrennen.
Die Anregung dazu kam übrigens von Doener.
Mehr bei Lucas.
-
verschieb das alles ma so dass der abstand von top mindestens so viel is, wie der eingabebereich oben braucht :>
-
vercetti schrieb:
verschieb das alles ma so dass der abstand von top mindestens so viel is, wie der eingabebereich oben braucht :>
Benutz mal run als Parameter.
-
Findet ihr keine Sicherheitslücken mehr?
P.S. es kommen jetzt wieder Funktionen dazu. ;) -
So könntest du die Ausgabe von HTML Unterbinden, damit würde man dann direkt den Quelltext des Ergebnisses sehen:
<?php ob_start("htmlentities"); eval($code); ob_end_flush(); ?>
Bsp. ^^ -
thomasba schrieb:
So könntest du die Ausgabe von HTML Unterbinden, damit würde man dann direkt den Quelltext des Ergebnisses sehen:
<?php ob_start("htmlentities"); eval($code); ob_end_flush(); ?>
Bsp. ^^
welchen Sinn soll das haben? Der, der den Code testet, will doch HTML sehen. Und auf der Startseite wo die letzten Codes gezeigt werden, ist HTML ja schon unterbunden ;) -
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
