Pen Test von Website

[CL90]

Moin!

Ich habe in den letzten Jahren nebenbei eine Website für meine Freunde und mich geschrieben, die bisher nur Offline auf unser Lan-Party lief.
Jetzt ist sie auch online erreichbar.
Ich hab in der Uni viele Vorlesungen zu Security gehört und mir graust es ein bisschen davor, dass ich nicht ansatzweise alles abdecke.
Auf meiner Suche nach Online Penetration Tests bin ich bisher erfolglos geblieben.

Gibt es einen online Test? oder kennt sich jemand von euch gut damit aus?

Die Seite erfüllt eigentlich alle Vorraussetzungen um sicher zu sein, da nur Registrierte Benutzer etwas zu sehen bekommen.
Aber wirklich sicher bin ich da nicht...

Gruß
Chris

 

[bingo88]

So einen richtigen Online Tester kenne ich jetzt auch nicht. Für spezielle Lücken gibt es zwar Seiten, das betrifft dann aber eher so Hintergrunddinge wie SSL oder Webserver. Also nicht den Kram den du da testen willst. Wenn man gezielt die Anwendung testen will, muss man das schon mehr oder weniger manuell machen. Ich bin da jetzt kein Experte auf dem Gebiet, was mir dazu aber an Schlagworten einfällt:

• SQL bzw. Command Injection
• Session Hijacking
• XSS und XSRF
• DOS-Attacken (Unbegrenzter Upload und solche Späße)

 

[rabe08]

Zscaler Zulu URL Risk Analyzer - Zulu
Observatory by Mozilla

Einen vollständigen, individuellen Pen-Test können diese Seiten nicht leisten, aber Hinweise geben. Sind überflüssige Ports offen? Ist die verwendete Software aktuell und gepatched? Vielleicht sogar noch: sind alle Standard-Passwörter geändert, das weiß ich aber nicht.

 

[cann0nf0dder]

Zscaler Zulu URL Risk Analyzer - Zulu
Observatory by Mozilla

Einen vollständigen, individuellen Pen-Test können diese Seiten nicht leisten, aber Hinweise geben. Sind überflüssige Ports offen? Ist die verwendete Software aktuell und gepatched? Vielleicht sogar noch: sind alle Standard-Passwörter geändert, das weiß ich aber nicht.

wow, mein risiko ist erhöht weil mein server deutschland steht und ich mein zuhause mit der subdomain home erreiche ..........

 

[xActionx]

Du kannst vieles selbst testen. (Etwas Knowledge vorrausgesetzt)

Am besten du ziehst dir Kali-Live mal auf einen Usb-Stick und liest dich etwas in SQL-Map und Burpsuite ein. Auch nmap usw. können da ganz hilfreich sein und sind relativ gut dokumentiert und vergleichsweise leicht zu benutzen.
Mit den genannten Applikationen deckst du schon mal SQL-Injections und XSS ab.

MFG

 

[CL90]

Also für meine User ists es nicht so wichtig. Wichtig ist nur das kein anderer was zu sehen bekommt.

Mein Sicherheitskonzept sieht jetzt so aus:
- Jede Seite beginnt mit einem php request ob der user eine valide Session hat.
- Jede Zeile HTML wird nur mit echo generiert. Also ohne Session nur blanke Seiten
- Einzige Seite die sichtbar ist ist Login, und hier wird zuerst mit mysql_escape und danach alles gelöscht was nicht (0-9a-zA-Z) ist.
Wenn ich es richtig geblickt habe ist jetzt nur noch die Session selbst angreifbar. Also cookie steeling oder sowas.
Wie leicht sowas umsetzbar ist weiß ich leider nicht.

 

[fotoman]

- Einzige Seite die sichtbar ist ist Login, und hier wird zuerst mit mysql_escape und danach alles gelöscht was nicht (0-9a-zA-Z) ist.

Letzteres wissen (und akzeptieren) die User dann hoffentlich. Nicht, dass am Ende nur noch 2-3 Zeichen lange Passwörter übrig bleiben.

Und wozu der ganze Aufwand? Nur, um Deine Faulheit zu unterstützen und keine parametrierten Queries nutzen zu müssen? Das kann ich zwar aus eigener Erfahrung verstehen, aber auch daran kann man "arbeiten".

Ansonsten gehe ich davon aus, dass Du in der DB nur PW-Hashes ablegst und nicht die Klartext-Passwörter (falls doch mal jemand an die DB direkt heran kommen sollte). Dazu dann noch eine HTTPS-Verbindung. Sonst kann man das PW im Klartext in der Anfrage lesen, falls das nicht der Client bereits verschlüsselt, was auch nur etwas bringt, wenn das keine statische Verschlüsselung mit immer dem selben Key ist.

 

[xActionx]

Also für meine User ists es nicht so wichtig. Wichtig ist nur das kein anderer was zu sehen bekommt.

Mein Sicherheitskonzept sieht jetzt so aus:
- Jede Seite beginnt mit einem php request ob der user eine valide Session hat.
- Jede Zeile HTML wird nur mit echo generiert. Also ohne Session nur blanke Seiten
- Einzige Seite die sichtbar ist ist Login, und hier wird zuerst mit mysql_escape und danach alles gelöscht was nicht (0-9a-zA-Z) ist.
Wenn ich es richtig geblickt habe ist jetzt nur noch die Session selbst angreifbar. Also cookie steeling oder sowas.
Wie leicht sowas umsetzbar ist weiß ich leider nicht.

Theoretisch sollte es möglich sein dann die Session-Tokens zu stehlen und selbst zu verwenden.

Wie ist das MySQL-backend gesichert? Verwendest du einen Hash-Algorithmus oder speicherst du die Passwörter im Klartext ab?

 

[CL90]

natürlich als hash.
und nicht als MD5 oder so. ich nutze die neue password_hash() funtktion von php5.

Auf der Seite gibts ja auch nichts was brisant wäre. Es soll bloß nicht einsehbar sein.
Zumindest nicht für jeden 0815 Spinner. Wenn irgendwer den ServerHoster hackt um belanglose gifs von Katzen und so zeug zu sehen, bitte... aber das muss ja nicht jeder schaffen können.

 

[DataDino]

Also für meine User ists es nicht so wichtig. Wichtig ist nur das kein anderer was zu sehen bekommt.

Mein Sicherheitskonzept sieht jetzt so aus:
- Jede Seite beginnt mit einem php request ob der user eine valide Session hat.
- Jede Zeile HTML wird nur mit echo generiert. Also ohne Session nur blanke Seiten
- Einzige Seite die sichtbar ist ist Login, und hier wird zuerst mit mysql_escape und danach alles gelöscht was nicht (0-9a-zA-Z) ist.
Wenn ich es richtig geblickt habe ist jetzt nur noch die Session selbst angreifbar. Also cookie steeling oder sowas.
Wie leicht sowas umsetzbar ist weiß ich leider nicht.

1. Ich würde das entfernen von Sonderzeichen in den Strings definitiv weglassen. Damit limittierst du die Anzahl möglicher Passwörter stark und erhöhst bei Bruteforce-Angriffen die Kollisionswahrscheinlichkeit. Das Escapen der für SQL-Injection verantwortlichen Zeichen reicht vollkommen aus. Allerdings würde ich eher MySQLi oder PDO zusammen mit Prepared Statements verwenden. Da musst du nicht extra escapen, da der Query vorkompilliert wird und dann erst im zweiten Schritt die Daten angehängt bekommt. Dadurch ignoriert Das System alle SQL-Kommandos, die in den Strings enthalten sein könnten und du brauchst keine ANgst haben, das dir da wer etwas durchschummelt.

2. Erhöhe den Kostenfaktor der Password_Hash Bibliothek. Wenn der Login eine Sekunde dauert, wird dir kein Nutzer dafür den Kopf abreißen. Aber je länger die Funktion (durch wiederholtes hashen) benötigt, das Passwort zu verifizieren, um so sicherer ist es, da diese Kosten auch auf einen Angreifer zukommen.

3. Gegen Session-Hijacking gibt es mehrere Möglichkeiten. Zum einen kannst du bei jedem Aufruf eine neue ID für die Session erzeugen. Das erhöht die Wahrscheinlichkeit ungemein, das beim Abgreifen der ID/des Tokens dieser bereits bei der nächsten Verwendung ungültig ist. Du kannst die Session an IP und User-Agent binden. Dadurch muss der Angreifer zum einen den gleichen Browser und zum anderen auch die gleiche IP haben. Allerdings ist dauerhaftes einloggen so nicht mehr möglich, da die IP mindestens alle 24 Stunden wechselt. Der beste Schutz stellt also eigentlich die Verschlüssellung des Client-/Servertraffics mit SSL-Zertifikat dar. Ein Netzwerksniffer würde die Daten nur verschlüsselt abgreifen können und in den Daten stehen die Session-ID bzw. der Token. Und da SSL-Zertifikate mittlerweile für lau zu haben sind, sollte man auch nicht mehr darauf verzichten. Außerdem verwende ich für die Session-ID meist Base64, um die Zeichenbandbreite zu erhöhen. Ein Hash besteht aus 15 verschiedenen Zeichen und hat eine feste Länge, das grenzt mögliche Kombinationen stark ein.

 

[lowskill]

da die IP mindestens alle 24 Stunden wechselt

Nein.

 

[DataDino]

Nein.

OMG! Sorry ich vergaß zu spezifizieren. Bei "Standard Privatkunden DSL-Tarifen" wechselt die IP mindestens alle 24 Stunden bei Zwangstrennung. Ausnahmen, wo keine freie IP im Pool übrig war, spezielle Tarife, die eine dauerhafte IP-Bindung beinhalten, Standleitungen sowie direkter Netzwerkzugang zu einem Datenknoten sind davon natürlich ausgenommen. Sind diese Ausnahmen jetzt der Grund, den IP-Wechsel bei der Mehrheit zu ignorieren?

 

[lowskill]

Bei "Standard Privatkunden DSL-Tarifen" wechselt die IP mindestens alle 24 Stunden bei Zwangstrennung.

Nein.

 

[DataDino]

Nein.

JA!!!

 

[lowskill]

Meine Fritz!Box sagt heute (06.10.2016)

verbunden seit 28.07.2016

MagentaZuhause M

Vollzitat vom direkt vorangegangenen Beitrag ist übrigens echt sinnvoll.