PHP Passwort Seite...

Naja es kommt auf den Programieren an.

Viele wissen nicht, das es schlimm sein kann, wenn man im Adminbereich oder sogar in der URL eine Site für include angeben kann. Sowas mein ich:
index.php?site=downloads.php (sieht man selter *ironie*)


Dort kann man dann auch Passwortdateien vom Server ausspähen oder halt Bösen Code ausführen lassen.

Oder wenn man im Admin bereich angeben kann was am include. Viele Denke es gibt keinen "Bösen Code", vorallem nicht in Text oder HTML Dateien. Aber genau dort ist der böse Code drin, denn wenn dort <?php ... ?> steht, wird der Script ausgeführt.

Dies gilt auch für Templates, die per Include geladen werden.

Oder manche benutzen zum Upload einfach den copy Befehl, und dort kann man alles hochladen, auch PHP dateien die alle anderen Dateien auf dem Server killen.

Grundsetzlich gilt:
Man darf nie angeben, was geladen wird und was nicht. Am besten immer statische Dateien benutzen.
Wenn man Dynamische Seiten benutzen möchte, dann sollte die Werte aus der Datenbank gelesen werden, aber die Tabelle darf nicht per URL angegeben werden, genauso wie die Werte. Man darf höchsten die ID angeben.
 
Original von Elderan
Evt. in einer Textdatei, dann musst du irgendwie an diese Datei kommen, und dann die md5-Hashs per Brute Force knacken. Kann etwas dauern.
Zum Vergrößern anklicken....
die datei ist unerreichbar sobald ein entsprechender .htaccess eintrag vorliegt
Original von Elderan
Wenn es in eine MySQL Datenbank gespeichert wird, dann musst du daran kommen. Meistens ist der Speicherort gesichert, und man kommt so nicht dran.
Dann evt. nach phpMyAdmin (PHP-Script zum Verwalten von MySQL) gucken, den dort hat man normalerweise Zugriff auf die MySQL Datenbank.
Manchmal ist der Bereich nichtmal mit einem Passwort versehen (es gibt solche Admins)
Dann kannst du dir dort die md5-Hashs bzw. die Klartext Passwörter runterladen und einloggen bzw. gleich einen Admin Acc erstellen.
Zum Vergrößern anklicken....
phpmyadmin ist so ein typischer .htaccess kandidat
nen ACCOUNT zu erstellen wäre ein wenig zu auffällig, schliesslich merkt man schnell, dass ausser dem root-account und dem account für die legalen zugriffe noch ein weiterer account existiert. abgesehen davon hinterlässt das spuren.
löscht man den account danach wieder, dann ist trotzdem das zugriffsdatum der user-tabelle das aktuelle und nicht das wann diese eigentlich erstellt wurde!
Original von Elderan
Cookies:
Wird ein Cookie gesetzt? Wenn ja, dann werden bei manchen nur Cookies gesetzt, wo der Username drin steht, und wenn man mit dem Cookie die Site besucht, dann bist du sofort als die Person eingelogt. Kaum sicherheit, gibts aber auch selten.
Zum Vergrößern anklicken....
Was wiederum bedeutet, daß er sich irgendwo ein gültiges cookie klauen muss.
Registierung:
Evt. wird ja im Formular per Hidden Felder übertargen, welche Rang mal als Neu Registiert hat. Leicht zu knacken, deswegen auch selten Anzutraffen.

Original von Elderan
Sessions:
Oft werden nach dem LogIn eine Session gesetzt. Oft wird die Session ID an die URL angehängt (url.de/site.php?PHPSESSID=ecd3...).
Schau mal in den LogDateien danach und gib dann die URL des Geschützen Bereiches + Session ID ein.
Wenn die ID noch aktiv ist, bist du als andere Person eingelogt.
Zum Vergrößern anklicken....
eine session läuft in aller regel ziemich schnell nach verwendung aus. abgesehen davon werden sessions nicht auf dem client, sondern im temp verzeichnis des webservers gespeichert, welches sich in aller regel ausserhalb der document root befindet!
 
eine session läuft in aller regel ziemich schnell nach verwendung aus. abgesehen davon werden sessions nicht auf dem client, sondern im temp verzeichnis des webservers gespeichert, welches sich in aller regel ausserhalb der document root befindet!
Zum Vergrößern anklicken....

das ist egal, wenn man die sessions nicht mit cookies macht sondern ueber postvariablen uebergibt und die session aufm server da und gueltig ist, dann gehts, egal wo gespeichert, doch du hast recht dass sessions meist recht schnell ablaufen, aber das ist ja auch schon nicht mehr das thema;)
 
eine session läuft in aller regel ziemich schnell nach verwendung aus. abgesehen davon werden sessions nicht auf dem client, sondern im temp verzeichnis des webservers gespeichert, welches sich in aller regel ausserhalb der document root befindet!
Zum Vergrößern anklicken....

Eine Session läuft eigentlich dann aus, wenn der User sein Browser schließt (ist bei den meisten Servern so)
Ja es stimmt, die werden auf dem Server gespeichert, aber wenn man an die URL ?PHPSESSID=3ff5... anhängt, dann lädt er (der Server) die Daten von der Person, die die Session ID gehört. wenn das der Admin ist, surft man als Admin und nicht als user der man eigentlich sein sollte.
Das kann man in der php.ini ausschalten, das macht aber so gut wie kein Server, denn dann grenzt man die leute aus, die keine Cookies auf dem eigenem PC erlauben.



das ist egal, wenn man die sessions nicht mit cookies macht sondern ueber postvariablen uebergibt und die session aufm server da und gueltig ist, dann gehts, egal wo gespeichert, doch du hast recht dass sessions meist recht schnell ablaufen, aber das ist ja auch schon nicht mehr das thema
Zum Vergrößern anklicken....

Wenn man neu auf eine Session Site geht (wo session_start(); steht), dann wird automatisch an die URL (z.B. bei Links) die Session ID angehängt, weil beim User noch kein Cookie gesetzt wurde.
Zwar kann man das in der php.ini ändern, das machen aber die wenigsten, weil die User dann Cookies akzeptieren müssen.

Und dieser 1 Eintrag steht dann in der Log Datei des Surfers, sofern dort keine Vorkehrungen getroffen wurden. Wenn der Angreifer dann die logdatei sieht, und einen Eintrag wo die Session ID steht, und der Eintrag noch nicht ganz "frisch" ist, ist es wahrscheinlich, das die noch aktiv ist.


nen ACCOUNT zu erstellen wäre ein wenig zu auffällig, schliesslich merkt man schnell, dass ausser dem root-account und dem account für die legalen zugriffe noch ein weiterer account existiert
Zum Vergrößern anklicken....
Beschäftigst du ein Board oder anderen Script mit Admin Login?
Wenn ja, wie oft schaust du in der MySQL Datenbank nach, ob jemand noch Zugriff auf das Admin Menü hat. Vorallem wenn man 1000 oder mehr Mitglieder hat, die alle in der Tabelle stehen?
Und nur ein Wert unterscheidet, ob es ein Admin oder ein User ist.

P.S. Programmiere gerade ein eigenes Board, deswegen kenne ich mich damit aus.


phpmyadmin ist so ein typischer .htaccess kandidat
Zum Vergrößern anklicken....
Es gibt Webserver, wo User phpMyAdmin hochladen, ohne irgend ein Passwort schutz.
Das hatte ich mal bei einem, ich konnte ohne Kontrolle das phpMyAdmin benutzen und hate Zugriff auf sämtliche Tabellen des User, ohne das ich am Server irgendwas machen musste.
Der User wollte aber hilfe von mir.
 
Beschäftigst du ein Board oder anderen Script mit Admin Login?
Wenn ja, wie oft schaust du in der MySQL Datenbank nach, ob jemand noch Zugriff auf das Admin Menü hat. Vorallem wenn man 1000 oder mehr Mitglieder hat, die alle in der Tabelle stehen?
Und nur ein Wert unterscheidet, ob es ein Admin oder ein User ist.

P.S. Programmiere gerade ein eigenes Board, deswegen kenne ich mich damit aus.
Zum Vergrößern anklicken....

es geht um den account des dbms, worüber das php script auf sql zugreift ... da legt man nicht für jeden user einen eigenen account zum zugriff auf die datenbank an, sondern gibt dem script einen account! schliesslich sollen die user nicht direkt auf die dtenbank zugreifen. und dann stehen da ca. 2 accounts in der accountliste für die datenbank ... derjenige für das script und der account für root.

was du meinst ist eine andere tabelle, eine die du selber anlegst wo die user des boards drin stehen .. ich reder von der user-tabelle der DATENBANK. das hast du mich wohl missverstanden.

phpmyadmin ist so ein typischer .htaccess kandidat
Zum Vergrößern anklicken....
Es gibt Webserver, wo User phpMyAdmin hochladen, ohne irgend ein Passwort schutz.[/quote]

:D das is aber dann schuld eigen, nur wenn die seiten die er meinte schon so programmiert sind, dass bots keine chance haben, dann werden die macher schliesslich nicht so eine krasse lücke pffen halten
 
es geht um den account des dbms, worüber das php script auf sql zugreift ... da legt man nicht für jeden user einen eigenen account zum zugriff auf die datenbank an, sondern gibt dem script einen account! schliesslich sollen die user nicht direkt auf die dtenbank zugreifen. und dann stehen da ca. 2 accounts in der accountliste für die datenbank ... derjenige für das script und der account für root.

was du meinst ist eine andere tabelle, eine die du selber anlegst wo die user des boards drin stehen .. ich reder von der user-tabelle der DATENBANK. das hast du mich wohl missverstanden.
Zum Vergrößern anklicken....

Ich hab an die Acc's für den Admin Bereich gedacht, so wie hier im Board.

Naja um einen Acc dafür anzulegen, braucht man i.d.R. Root Rechte für den Sever, denn mit phpMyAdmin kann man die Tabelle für die Username's nicht ändern.

Denn die stehen meistens in einer Tabelle (oder Datei) wo nur der Server Admin drauf zugriff hat.

Aber den Root Zugang zu "cracken" ist eigentlich schwer als Admin zugriff auf ein Board zu bekommen
 
:)

Voll geil hier :)
Echt.. ich raff zwar noch nicht viel von dem gazzen php und sql kram, aber hab nächstes semester sql, php, jsund pearl....
und kanns KAUM erwarten :)
Vielleicht kann ich dann ja auch mal einen nützlichen Beitrag leisten.

Nebenbei :
Wie aufwendig ist es, eine Homepage, die bei T-Online gehostet wird zu knacken, um die Inhalte zu verändern, ohne großartig Spuren zu hinterlassen?

Und warum ist die Methode "get" unsicherer als "Post"?
Danke
 
@ "Seite knacken":
Definitiv ist der Aufwand zu hoch, abgesehen davon glaube ich nicht wirklich das dieses Forum dazu da ist den Leuten beizubringen wie man in Systeme eindringt.
Mal abgesehen von der rechtlichen Lage.

Außerdem kann man grundsätzlich schon einmal alles zurückverfolgen und nachvollziehen was im Netz passiert.
Grad neulich hatte ein Bekannter von mir groß rumgeredet, daß er nur noch über einen Bouncer in den irc geht und jetzt nicht mehr aufzuspüren ist. Das Problem bei einem Bouncer ist aber, daß er die Client-IP kennen muß um die Daten vom irc-Server an den Client zu senden. Somit ist die Verbindung definitiv zurückzuverfolgen, wenn auch erschwert. Genau so verhält es sich mit Proxys.

@GET vs. POST:

Schau mal in die Adressleiste deines Browsers während du diesen Artikel liest. Da steht die Domain der Seite, und dahinter ein Fragezeichen. Danach folgt die Bezeichnung threadid. Das ist eine Variable und hinter dem Gleichheitszeichen folgt der Wert den diese Variable hat. Wenn Du nun eine beliebige andere Zahl hinter das "=" schreibst, dann weist Du der Variablen "threadid" einen anderen Wert zu. An sich stellt das noch kein Sicherheitsproblem dar. Allerdings wird es in dem Moment problematisch, in dem Du Usernamen und/oder Passwörter per GET übergibst, die stehen dann nämlich auch in der Adressleiste. Die Daten werden als im Header des HTTP-Paketes übergeben

POST hingegen übergibt die Varaiablen nicht, wie GET, offen, sondern übergibt Daten im body vom HTTP. Daher sind Übergaben via POST nicht in der URL sichtbar.

Das ist aber nicht der Hauptunterscheidungspunkt der beiden globalen Variablen (GET und POST sind globale PHP-Variablen, oder besser gesagt es sind Arrays). Leider verwenden viele Webseitenprogrammierer die beiden Arrays je nach dem ob die URL modifiziert werden soll (GET) oder nicht (POST). Der eigentlich Grund das es die beiden Arrays gibt ist aber eigentlich ein ganz anderer:

GET soll in der Regel immer dann verwendet werden, wenn ein GET Request für eine Seite immer das gleiche Ergebnis bringt. Beispielsweise wenn eine Rechenaufgabe gelöst werden soll, bei der auf der ersten Seite die Zahlen eingegeben werden, und diese dann mittels GET an die nächste Seite weitergegeben werden, bei der das Ergebnis der Berechnung, bei gleichen Zahlen, immer das gleiche ist (1 + 4 ist eben immer 5). Das bedeutet, dass diese Seite (Also zum Beispiel die Seite:
http://www.rechenaufgabe.de?zahla=1&zahlb=4) immer auf die Seite führt auf der das Ergebnis 5 steht. Das wiederum ergibt die Konsequenz, daß die Ergebnisseite von Proxys oder Browsern gecached werden kann, da sich die ja nie ändert. Im Fachbegriff bedeutet dies das GET-Requests idempotent sind. (Nach HTTP-Spezifikation)

Anders sieht es bei POST aus.
Da hier ja die Variablen nicht in der URL erscheinen, können diese auch nicht gecached werden. POST ist also nicht idempotent. Das bedeutet, dass die gleiche Eingabe von Daten jedesmal zu anderen Ergebnissen führen kann. (Beispielweise wenn man ein Forum nach Schlagwörtern durchsuchen lässt, denn es kommen ja immer neue Postings dazu, als verändert sich das Ergebnis der Abfrage). Es wäre als grundlegend FALSCH bei eine Suche GET-Abfragen zu verwenden, da sonst die Ergebnisseite gecached wird, und die Suchfunktion quasi so lange "falsche" Ergebnisse liefert, bis der Cache geleert wird.

EDIT --- ANFANG:
Mir ist grad noch eingefallen wie man das Problem gecacheter GET-Requests noch deutlicher darstellen kann:

Stellt Euch vor ihr bestellt online eine CD, und die Bestelldaten werden dann via GET an der Server gesendet. Diese Seite wird gecached, und wenn ihr diese Seite das nächste mal aufruft, dann wird die Bestellung ein zweites mal ausgelöst.

EDIT --- ENDE

Ich hoffe das konnte einiges klären.

Frohe Ostern Euch allen.
 
Danke für die Info :)
Ok, das war wohl nicht besonders klug nach dem Knacken einer Homepage zu fragen, sorry.
Aber Dein Beitrag war sehr aufschlussreich.
Danke
Ach...und Frohe Ostern :))
 
Also knacken geht leicht, wenn du sein Passwort kennst ^^

Also der große Vorteil von Get ist, man kann halt mit normalen Links werte übergeben, dies ist mit POST problematischer.

Z.B. im diesem Board.
Wenn du auf ein Thema klickst, werden immer werte per GET übertragen z.B. die Threadid

Macht man dies per POST, dann müsste dort immer ein Formular sein und eine Art Button.

Auch per GET kann man die Links einfach an seine freunde senden.

Da liegt der Nachteil bei PW-Abfragen:
Man kann dann den Username + PW einfach per URL weitergeben. Per POST muss man die Werte erst wieder ein ein Formular eintragen.

Also POST wird meistens benutzt, wenn man etwas Speichern möchte (z.B. diesen Post)

Und GET meistens wenn man etwas dynamisch ausgeben möchte
 
Hallo,
hmm häcken, hash daten ?(

Verstehe nicht ganz was du meinst.

Also bei schlechte Algorithmen kann man Kollisionen vorraussagen/berechnen, aber bei wirklich guten Algorithmen hilft nur das gute alte Brute Force, und bei PW's mit z.B. 15 stellen macht das kein Spaß mehr....
 
Original von BlackMarvel
Mich würde interessieren, wie diese PHP-Passwortabfragen funktionen und vorallen, wie man sie umgehen oder gar das Passwort rausbekommen kann...
Zum Vergrößern anklicken....

technisch gesehen haben hier sich ja alle schon ueberschlagen.

mein vorschlag gliedert sich in zwei teile:

a) du bist eine frau
mach dich sexy und schlaf mit einem, der zugang zu dem passwortgeschuetzten bereich hat. lass dir dafuer login und passwort geben.

b) du bist ein mann
fuer den wahrscheinlichen fall, dass es keine frau gibt, die als opfer von a)-umgedreht taugt:
bezahl eine frau, damit sie a) tut.

das beschriebene verfahren ist eine sehr spezielle von social-engeneering und kommt besonders dort zum einsatz, wo passwoerter und zugangsdaten wichtiger sind als bei umsonst-browsergames: in hollywood filmen.
 
Um antworten zu können musst du eingeloggt sein.
Zurück
Oben