Idee zu einer neuen Klasse: PenTest

[Dennis Wronka]

Nachdem ich nun alle meine Klassen der Oeffentlichkeit zur Verfuegung gestellt hab wird es Zeit ueber neuen Code nachzudenken. Immerhin moechte ich ja nicht, dass mein SourceForge-Projekt einschlaeft und zumindest von Zeit zu Zeit mal was neuen raushauen.
Da ja Sicherheit eine wichtige Sache ist hatte ich dabei an eine Klasse gedacht die verschiedene uebliche Angriffe automatisiert probieren kann. Der Vorteil der Geschichte ist dabei, dass es dabei egal ist in welcher Sprache die Website gescriptet ist, ob nun PHP, ASP, Perl, Ruby, ..., das macht keinen Unterschied. Es wird dabei einfach nur getestet ob bestimmte Aktionen ausgefuehrt werden koennen. Das ganze wird dann am Ende des Tests alles schoen protokolliert.
Ich hatte ja bereits ein Script angefangen welches PHP-Scripts anhand des Quellcodes auf bestimmte Probleme analysiert, aber da ist auch recht viel Ungewissheit dabei und es gibt recht viele "Es koennte unter Umstaenden sein, dass..."-Meldungen. Weiterhin funktioniert das ganze ja auch nur fuer PHP-Scripts. Und diese Punkte will ich mit einem gezielten Test der Website ueber HTTP eliminieren.

Es waere nett dazu ein paar Kommentare zu hoeren.

 

[Dr Dau]

Hallo!

Hmm, ich sehe das Problem darin dass es kein "all in one" Script sein kann.
Ich will damit sagen, wenn ich mir z.b. einen Windows-Server mit ASP hinstelle, dann nicht um PHP nutzen zu können..... das Script soll doch in PHP geschrieben werden?
Ich stelle mir ja schliesslich auch nicht einen Kasten Bier in den Keller, obwohl ich garkein Alkohol trinke.

Gruss Dr Dau

 

[Dennis Wronka]

Das Script selbst soll schon in PHP geschrieben sein. Aber worin die zu testende Seite geschrieben ist ist dabei egal. Der Browser kriegt ja eh nur HTML geliefert, und das gleiche bekommt halt das Script zu sehen.
Die zu testende Seite muss ja nichtmal auf dem gleichen Rechner sein wie das Testscript, da ja alles ueber HTTP laeuft.

 

[Dr Dau]

*ups*
"über HTTP" habe ich doch glatt überlesen. :-(

Nagut, entweder solltest Du dazu schreiben welche Funktionen benötigt werden..... oder Du machst gleich ein Testscript welches an Hand der Serverkonfiguration prüft ob es überhaupt eingesetzt werden kann.
Ggf. mit Hinweisen welche Tests auf Grund der Serverkonfiguration ausgelassen werden.

 

[Dennis Wronka]

Ich denke nicht, dass irgendwelche Beschraenkungen auftreten duerften durch das System von dem aus getestet wird. Ich plane die Kommunikation ueber meine HTTP-Klasse laufen zu lassen und somit duerfte das ganze recht flexibel sein da dort ja im Grunde nur fsockopen() benoetigt wird, welches eigentlich so gut wie ueberall verfuegbar sein duerfte.

 

[Dr Dau]

Ich habe Deine HTTP-Klasse mal grob überflogen.
So wie ich es sehe werden da soweit nur "Standard" Funktionen genutzt..... wenn von denen welche deaktiviert sind, dürfte wohl eher ein Wechsel des Hosters fällig sein.
Ein kurzer Check ob fsockopen() zur Verfügung steht, dürfte demnach ausreichend sein.

 

[Dennis Wronka]

Seh ich auch so.
Und bei einem Hoster der sogar fsockopen() deaktiviert duerfte man wohl per PHP keinerlei Verbindung zur Aussenwelt haben. Es waere auf jeden Fall sehr sehr laecherlich fsockopen() zu deaktivieren aber allow_url_fopen auf on zu setzen.