Danke Danke:  0
Gefällt mir Gefällt mir:  0
Dislikes Dislikes:  0
Seite 1 von 2 12 LetzteLetzte
Ergebnis 1 bis 15 von 21

Thema: PHP uns sein Login

  1. #1

    Registriert seit
    30.03.07
    Danke (erhalten)
    0
    Gefällt mir (erhalten)
    35

    Standard PHP uns sein Login

    Anzeige
    Erstmal einen guten Tag an alle...

    Ich bin momentan bei der Rechere für einen "sicheren" Login Bereich in PHP.
    Der Bereich soll die Zugangskontrolle sein für eine Kontaktseite.

    Jetzt gibt es vor und Nachteile, ob man PHP nutzen sollte oder nicht, Ich weis.

    Habe mir, so denke ich jetzt einigermaßen wissen angelesen, und wollte mal nach Eurer Meinung fragen. Ich denke das viele Leute auch mehr sehen...

    Habe mir jetzt ein Script herausgesucht ("BasisScript"), welches als Grundlage dienen sollte. Wo würdet Ihr bedenken dabei haben, bzw. um was sollte man es erweitern.
    Hier der Link:
    http://tut.php-quake.net/login.html

    Für mich gilt soweit:

    1. Alles was der Benutzer eingibt sollte auf alles geprüft werden.
    2. Eventuell, wenn Möglich SQL Fehlermeldung umleiten in .txt Datei und nicht am Screen zeigen.
    3. 3x PW falsch, IP sperren
    4. SQL Abfrage in der DB oder in einer Datei Speichern und von dort abrufen.
    5. Select prüfen, und auswerten bevor er an dei DB geht

    Ist das spweit ansatzweise richtig?

    Wäre super wenn Ihr Euch kurz die Zeit nehmen könntet um das Script zu analisieren...
    Ich weis es ist Aufwendig...

    Vielleicht kann man hier ja daraus auch ein Beispiel Example entwickeln,
    Was andere User helfen könnte... <-- Nur als Vorschlag... soll nicht heißen das ich zu faul bin... ;-)

    Ok Danke soweit...

    ByteSurfer
    Bleib wer Du bist !
    Es sei denn Du kannst Superman sein, dann
    sei Superman ...

  2. #2
    Moderator Avatar von Elderan
    Registriert seit
    30.03.04
    Danke (erhalten)
    0
    Gefällt mir (erhalten)
    26

    Standard RE: PHP uns sein Login

    Hallo,
    Original von ByteSurfer
    1. Alles was der Benutzer eingibt sollte auf alles geprüft werden.
    Hoffe du hast das Konzept richtig verstanden

    2. Eventuell, wenn Möglich SQL Fehlermeldung umleiten in .txt Datei und nicht am Screen zeigen.
    Gibt ne Einstellung in der php.ini, screen errors oder so ähnlich.

    4. SQL Abfrage in der DB oder in einer Datei Speichern und von dort abrufen.
    Macht gar keinen Sinn, kann sogar gefährlich werden wenn sie in einer Db stehen.

    5. Select prüfen, und auswerten bevor er an dei DB geht
    Ein escapen mit mysql_escape_string() der User-Parameter reicht vollkommen aus.


    Ist das spweit ansatzweise richtig?
    Viel wichtiger ist die sichere Programmierun, dazu gibts aber im Netz (auch hier) genug zu lesen

  3. #3
    Avatar von metax.
    Registriert seit
    22.01.07
    Danke (erhalten)
    0
    Gefällt mir (erhalten)
    10

    Standard

    Ich arbeite auch gerade an einem PHP-Projekt, in dem ich versuche, die Sicherheit zu maximieren. Dabei bin ich auf zwei Sachen gestoßen:

    1) Lege einen extra Speicher für Benutzervariablen an, den du nur im Bedarfsfall befüllst:
    Script benötigt GET-Variable $x -> befülle $Uservars mit $_GET['x'] (gleichzeitig exscapen, evtl. sogar Typencheck auf Integer o.ä.) -> Lese $Uservars['x'].
    Wenn du niemals Variablen diurekt ansprichst (am ende sogar über register_globals!), kann es nur schwer passieren, dass dir jemand da was ungewolltes untermogelt.

    2) Wenn du PHP >= 5 und MySQL >= 4.2 hast, kannst du statt der mysql die mysqli-Erweiterung von PHP nehmen (falls sie auf deinem Host vorhanden ist). Dort kannst du statt normalen Queries sogenannte "Prepared Statements" absetzen, welche von MySQL selbst gegegn MySql-Injections geschützt werden.
    PHP-Code:
    <?php
    $db 
    = new mysqli($host$user$password$db);
    if (
    mysqli_connect_errno()) {
      die(
    __("Fatal Error: MySQL connection refused. Error Code:<br>\n") . mysqli_connect_error());
    }
    $stmt =  $db->stmt_init();
    $success $stmt->prepare('select feld1, feld2 from table where feld3 = ?');
    // ? = Statement-Platzhalter
    $wert $Uservars['userwert'];
    $stmt->bind_param("s"$wert);
    $stmt->bind_result($feld1$feld2);
    $stmt->execute();
    $stmt->store_result();
    for (
    $i 0$i $stmt->num_rows$i++) {
      
    $stmt->fetch();
      echo 
    "Feld1: $feld1, Feld2: $feld2 \n";
    }
    ?>
    Genaueres findest du in Netz.

    mfg, metax.
    Wenn keiner zuschaut, teile ich heimlich durch Null!
    Meine Homepage: Planet Metax | meine Bilder: DeviantArt | Twitter

  4. #4
    Avatar von Harry Boeck
    Registriert seit
    17.02.06
    Danke (erhalten)
    0
    Gefällt mir (erhalten)
    5

    Standard

    Was ich auf http://tut.php-quake.net/login.html finde, sieht korrekt aus:
    - Parameter an den richtigen Stellen escaped
    - nichts Uninitialisiertes
    - korrekte Logik

    Wenn Du daran denkst, daß das Zeug auch öffentlich verbreitet wird (wobei ich z.B. an die PHP-Sonntags-Coder in einer Firma meiner Stadt denke, die mit einiger Wahrscheinlichkeit irgendwann über sowas stolpern könnten), würde ich noch empfehlen, in den Code eine Zeile zur Sicherung gegen falsch konfigurierte Server einzubauen, die dem unbedarften Anfänger dennoch einen einigermaßen sinnvollen Kommentar in das ausgelieferte Dokument setzt.

  5. #5

    Registriert seit
    30.03.07
    Danke (erhalten)
    0
    Gefällt mir (erhalten)
    35

    Standard

    Danke Harry Boeck das du dir die zeit genommen hast das script anzusehen...

    Hilft mir sehr...

    nochmals danke!
    Bleib wer Du bist !
    Es sei denn Du kannst Superman sein, dann
    sei Superman ...

  6. #6
    Avatar von BasicAvid
    Registriert seit
    17.03.04
    Danke (erhalten)
    3
    Gefällt mir (erhalten)
    9

    Standard

    PHP-Code:
    if($_SESSION['IP'] != $_SERVER['REMOTE_ADDR']) {
                echo 
    "<p class=\"error\">\n";
                echo 
    "    Sie dürfen nicht die Session von einem\n";
                echo 
    "    anderen user Benutzten. Bitte benutzen sie\n";
                echo 
    "    folgenden Link um zur Homepage zu gelangen.\n";
                echo 
    "    <a href=\"/\">Zurück zur Homepage</a>\n";
                echo 
    "</p>\n";
                die(); 
    // Aus Sicherheitsgründen die Abarbeitung sofort beenden

    Wobei ich diesen Teil überdenken würde, da man sich mit dieser Methode auch User aussperren kann. Es gibt Provider die Ihre Kunden über verschiedene Proxys schicken, so z.B. AOL, mit dieser Methode würdest Du diese User einfach aussperren. Klar, die Sicherheit wird mit dieser Methode erhöht, man sollte aber auch an evtl. auftretende Probleme denken.
    Mfg Basic Avid
    - Use it or be used! -

  7. #7
    Avatar von Harry Boeck
    Registriert seit
    17.02.06
    Danke (erhalten)
    0
    Gefällt mir (erhalten)
    5

    Standard

    Das interessiert mich jetzt nochmal: AOL schickt seine Benutzer WÄHREND einer Einwahlperiode über verschiedene Proxys (so daß zwei verschiedene Klicks im Browser über zwei verschiedene IPs vermittelt werden können)?

    Falls das stimmt, könnte dieser Schutz gegen Session-Klau aber auch optional gemacht werden. Immerhin geht es dabei darum, einen UNBEDARFTEN DAU vor dem versehentlichen Preisgeben seiner Session (durch dummes Surf-Verhalten) zu schützen. Ein Benutzer, der es anders benötigt (z.B. TOR-Benutzer), sollte den Schutz bewußt abschalten dürfen. Und falls gewisse Provider so eine Proxy-Streuung zwangsweise anwenden, könnte man für genau deren IP-Bereiche das Zeug umgehen.

    Lange Rede, kurzer Sinn: einfach zwei Zusatzbedingungen in das if-Konstrukt aufnehmen: Einmal für eine User-Präferenz, einmal für einen preg_match gegen einen Remote-IP-Bereichs-Ausdruck!

  8. #8
    Avatar von BasicAvid
    Registriert seit
    17.03.04
    Danke (erhalten)
    3
    Gefällt mir (erhalten)
    9

    Standard

    Das interessiert mich jetzt nochmal: AOL schickt seine Benutzer WÄHREND einer Einwahlperiode über verschiedene Proxys (so daß zwei verschiedene Klicks im Browser über zwei verschiedene IPs vermittelt werden können)?
    Ein AOL User wird/kann während seiner Session über verschiedene AOL-Proxys geschickt werden. Es gibt auch noch ein weiteres Problem mit dieser Art, nehmen wir z.B. mal ein Labor, in dem 100 Leute arbeiten und alle auf der gleichen Plattform angemeldet sind, hier wäre ein Sessionklau auch sehr einfach.

    Immerhin geht es dabei darum, einen UNBEDARFTEN DAU vor dem versehentlichen Preisgeben seiner Session (durch dummes Surf-Verhalten) zu schützen.
    Tja, leider ist das nicht so einfach, denn wenn Du mit dieser Methode einen User aussperrst wird sich dieser User beim Betreiber beschweren und dieser beschwert sich bei der Firma die das ganze entwickelt hat.

    Und falls gewisse Provider so eine Proxy-Streuung zwangsweise anwenden, könnte man für genau deren IP-Bereiche das Zeug umgehen.
    Was ein ziehmlicher Aufwand werden kann, da man ja vorher noch nicht weiss woher der User kommt, er könnte ja genau so gut in einer Firma hinter einem Proxy sitzen.

    Und ich spreche hier aus Erfahrung, da wir gerade ein Social Network Portal programmieren und genau diese Problematik hatten.

    Für eine kleine private Seite oder einen Adminbereich ist diese Methode schon ok, aber wenn es größer wird bekommst damit nur Probleme.
    Mfg Basic Avid
    - Use it or be used! -

  9. #9
    Avatar von Harry Boeck
    Registriert seit
    17.02.06
    Danke (erhalten)
    0
    Gefällt mir (erhalten)
    5

    Standard

    Gute Diskussion zum Thema...

    Wenn eine Gruppe von Benutzern hinter einem Proxy sitzt, bedeutet das nicht ein Wechseln der Adresse. Sondern halt nur, daß mehrere Benutzer dieselbe Adresse verwenden. Also ist das KEIN Gegenargument gegen diese Sicherungsmaßnahme. Sondern nur ein Fall, in dem diese Sicherungsmaßnahme gerade nicht zur Wirkung kommt (ohne positive, aber auch ohne negative Wirkung).

    Ich würde nicht deswegen, weil sie eventuell in dem einen oder anderen Detailbereich NICHT wirksam werden könnte, ALLEN usern der Welt diese Unterstützung verweigern. Immerhin geht es darum, diese anderen Leute da draußen zu unterstützen. Selbst wenn das nur für 10% wirksam wäre (während die restlichen 90% unberührt bleiben würden), wären diese 10% dann schon dankbar (oder zumindest gut bedient).
    Und ich denke nicht, daß diese 5...6 Zeilen PHP-Code - die ja eh schon existieren - überhaupt als Belastung diskussionswürdig sind.

    Zu AOL: Die dürften doch aber mit dieser Vorgehensweise recht einsam dastehen, oder? Und die haben doch für diese Zuweisungsmethode einen konkreten, fest definierten Bereich von Adressen, oder? Also sollte das doch durch einen einfache Testausdruck abzufangen sein, oder?

    Als Boardbetreiber kann ich mir zwei Methoden zur Einrichtung dieses Ausdrucks vorstellen:
    1) Für AOL-User einen extra Text auf die Seite stellen, daß sie ein Häckchen in einer Checkbox setzen mögen (und diesen Parameter einfach in den Session-Daten hinterlegen).
    2) Die Zugriffe mit diesem Parameter protokollieren lassen. Das führt in kürzester Zeit zu einer Übersicht eben jenes - aktuell verwendeten - Adreßbereiches und kann auch in Zukunft helfen, eventuelle Änderungen dieses Bereiches mitzukriegen.

  10. #10

    Registriert seit
    10.04.07
    Danke (erhalten)
    0
    Gefällt mir (erhalten)
    0

    Standard

    hmm. komisch ich dachte immer sichere logins wären garnicht schwierig. o.O

    Ich hab die bis jetzt immer so verwirklicht, dass ich nach dem formular mit name + pw geprüft hab ob zum passenden mysql_escape_string(name) das passwort das selbe ist wie das eingegebene. (also dann den hash) wenn ja, schreib ich den namen in die session.
    jetzt prüf ich vor jeder aktion oder seite die man nur eingeloggt sehen darf ob die session mit einem namen aus der db gesetzt ist. was kann denn daran gefährlich werden? o.O

    grüße

  11. #11
    Avatar von Harry Boeck
    Registriert seit
    17.02.06
    Danke (erhalten)
    0
    Gefällt mir (erhalten)
    5

    Standard

    Na ja: Zum Beispiel eben das hier diskutierte Abfischen von Session-IDs.

    Das funktioniert so: PHP sendet, wenn man PHP-Sessions benutzt, ein Browser-Cookie, das eine Nummer darstellt. Dieses KANN man im Datenstrom an allen Ecken des Internet, an denen die betreffenden Datenpakete vorbeikommen, lesen. Sobald man so ein Cookie findet, kann man sich - ein bißchen Ahnung vorausgesetzt - seinen Browser so manipulieren, daß er eben dieses Cookie benutzt, wenn man eine Verbindung mit dem betreffenden Server aufbauen möchte.

    Schwups - ist man auf dem Server, wenn der genau so funktioniert, wie Du es hier beschreibst, als jener user angemeldet, aus dessen Datenstrom man das Cookie gelesen hat.

    Um dem eins draufzusetzen, bauen manche PHP-Freizeit-Bastler (wozu leider auch einige ältere viel benutzte PHP-Projekte gehören) ihre Scripte so, daß die Session-ID in der URL übertragen wird. Und dazu passend kümmern sich die Besucher jener Server einen kalten Kehricht darum, daß ihr Browser diese URLs beim Seitenwechsel immer als "Referrer" mit überträgt. Dadurch kann man als x-beliebiger Serverbetreiber ständig irgendwelche Session-IDs einsammeln.

    Der Test auf gleich bleibende IP-Adresse schränkt diese Mißbrauchs-Möglichkeit ein.

  12. #12

    Registriert seit
    30.03.07
    Danke (erhalten)
    0
    Gefällt mir (erhalten)
    35

    Cool

    Der Test auf gleich bleibende IP-Adresse schränkt diese Mißbrauchs-Möglichkeit ein.
    kleine Spritze

    @BasicAvid
    Also ich sehe den Sinn und den Zweck noch nicht ganz darinne ...
    Welcher Provider bzw. Web Hoster, oder Programmiere proggt php so das ein user meherer IP's beim Zugriff haben könnte. Verstehe deinen Grundgedanken das dieses für einen Anwender Nervig ist,a ber wenn ich das richtig verstanden habe hast du das mit Tool's welche das auch von einem Clientrechner durchführen können auch. Jetzt die Frage "Wo hört das auf und wo fängt es an??"

    @PapaJanus
    Es geht darum Möglichst viel Sicherheit in den Login zu bringen, so dass ein "Spitzbub" mehr Zeit ("relativ") verbringen müsste ungewollt Zugriff zu erhalten.
    Bzw. kein Zugriff erlangen kann!
    Problem ist mit Tools kannst du die Cookies ändern, also die nummer und die Session() wird dann Serverseitig erstellt.... ohne Session und Cookie kein Zugriff... Genauso klickst du den Browser oben rechts zu, ist die Session weg und auch der Zugang... sonst könnte man ne geraume Zeit später einfach wieder uff die Seite.... ohne Login...

    Mmhhh... löscht sich der Cookie auch... denke nicht?! Ist das schlimm? ?(
    Bleib wer Du bist !
    Es sei denn Du kannst Superman sein, dann
    sei Superman ...

  13. #13
    Member of Honour Avatar von beavisbee
    Registriert seit
    22.02.07
    Danke (erhalten)
    0
    Gefällt mir (erhalten)
    104

    Standard

    Original von ByteSurfer
    Mmhhh... löscht sich der Cookie auch... denke nicht?! Ist das schlimm? ?(
    Die Lebensdauer eines normalen Cookies wird beim Setzen des Cookies festgelegt...
    siehe http://de2.php.net/manual/de/function.setcookie.php

    bei Session-Cookies gibt es eine Einstellung in der php.ini
    http://de2.php.net/manual/de/ref.session.php

  14. #14
    Avatar von Harry Boeck
    Registriert seit
    17.02.06
    Danke (erhalten)
    0
    Gefällt mir (erhalten)
    5

    Standard

    Zu den letzten beiden Gedanken: Es gibt ja immer sowohl serverseitig als auch clientseitig die Möglichkeit, Cookie-Lebzeiten zu beenden.

    Wenn man am Browser einstellt, daß DER das Cookie vergessen soll, wenn man ihn schließt, heißt das eben noch lange nicht, daß das Cookie auf dem Server verschwunden ist. Und solange der das Ding aufhebt (standardmäßig steht da bei PHP wohl sowas wie eine Stunde, wenn ich das richtig in Erinnerung habe), kann es dort auch mißbraucht werden - WENN man seine PHP-Anwendungen nicht dagegen schützt.

    Normalerweise MÖCHTE man serverseitig eine gewisse Reserve-Lebzeit, weil es - wei hier im Hackerboard zum Beispiel recht oft - passieren kann, daß man recht lange auf einer Seite wie dem Schreiben eines Beitrags verweilt, und es einen sehr schlechten Eindruck macht, wenn man dann immer schon nach nur ner Viertelstunde schreiben und nebenbei recherchieren gleich wieder rausgeschmissen ist und dann zum Beispiel bei einer Kombination aus nicht sehr guten Browser und nicht sehr guter Weboberfläche der gesamte geschriebene Beitrag im Jenseits gelandet ist.

    Jedenfalls ist das Thema ein durchaus interessantes...

  15. #15
    Avatar von metax.
    Registriert seit
    22.01.07
    Danke (erhalten)
    0
    Gefällt mir (erhalten)
    10

    Standard

    Anzeige
    Wie ist das nun mit den rotierenden IP-Adressen bei ISPs?
    Kann mir jemand was Konkretes dazu sagen, ob es in Realität tatsächlich vorkommt, dass normale Benutzer während einer Session ihre IP ändern? Am besten mit vertrauenswürdigen Quellen!

    Ich würde nämlich auch gerne in meine Webapplikationen diesen IP-Schutz einbauen.

    Wenn das nur auftritt, wenn der Benutzer über Spezialtools surft, ist mir das egal, aber wenn AOL oder sonst jemand diese Praxis betreibt, kann man das Konzept, die Session bei unpassender IP zu verwerfen, ja nicht wirklich einbauen.

    Bitte um Aufklärung,

    mfg, metax.
    Wenn keiner zuschaut, teile ich heimlich durch Null!
    Meine Homepage: Planet Metax | meine Bilder: DeviantArt | Twitter

Ähnliche Themen

  1. Was mag das für ein Bauteil sein?
    Von AcoQ im Forum Off topic-Zone
    Antworten: 8
    Letzter Beitrag: 10.04.09, 01:37
  2. welcher TFT soll's sein?
    Von bigkahuna im Forum Kaufberatung
    Antworten: 8
    Letzter Beitrag: 24.09.08, 19:41
  3. besoffen sein
    Von Freizeithacker im Forum Off topic-Zone
    Antworten: 42
    Letzter Beitrag: 18.07.08, 00:15
  4. Omg wie blöd kann man nur sein..
    Von Eckbert im Forum Fun Section
    Antworten: 3
    Letzter Beitrag: 10.08.05, 14:35
  5. was kann das sein??
    Von Seo im Forum Linux/UNIX
    Antworten: 3
    Letzter Beitrag: 22.05.03, 17:51

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •