treziman: Sicherheit: MySql-Injection und Zugriff "von aussen"

Hallo,

ich muss mich nochmal schlau machen. Ein paar Infos habe ich ja schon, Dank diesem Forum, einiges verstehe ich aber noch nicht so ganz. Auch, was ich anderswo gelesen habe.

Zunächst mal mysql-injection. Was das ist weiss ich inzwischen, auch wie ein potenzieller Hacker vorgehen könnte (siehe Wikipedia). Um dies zu verhindern, habe ich in meinen scripten umfangreiche Abfragen gestaltet. So z.B. bei Passwörtern, dass diese nur aus Buchstaben und Zahlen bestehen dürfen, ebenso Nicknamen, dabei ausgenommen ist der Unterstrich. Wenn also jemand etwas per script in die DB schreiben muss, wird vorher bestimmt, welche Zeichen erlaubt sind.
Muss ich darüber hinaus noch etwas beachten?

Eine andere Sache ist immernoch die, wenn jemand einen Link über die Favoriten auf eine Seite setzt, die er ohne Login nicht erreichen darf, und irgendwann später dahin über seine Favoriten zurückkehren will. Ich kann sicher zu Beginn eines jeden scriptes Abfragen, ob z.B. $_SESSION['passwort'] gesetzt ist. Wenn nicht, eben umleiten. Nun habe ich etwas mehr über .htaccess gelesen, kann mir aber nicht so recht etwas darunter vorstellen. Es soll sich dabei um eine Datei handeln. Muss man die selber einrichten? Und wo befindet sie sich, bzw. wohin platziert man sie? Auf meinem Webspace finde ich nichts dergleichen. Wie wird sie angesteuert?

Nochmal zur Klarheit:
"document-root" bedeutet, das Verzeichnis, in dem sich die index.html befindet und welches "von aussen" erreicht werden kann?

Wenn dem so ist und sich die Dateien, die nur über ein vorheriges Login erreicht werden können, in einem anderen Verzeichnis ausserhalb des document-root befinden, dann können diese Dateien doch trotzdem über einen Favoritenlink erreicht werden, oder? Welchen Nutzen hätte dann htaccess?
Dasselbe, wenn jemand die Zieladresse direkt im Browser eintippt. Der Pfad wird ja beim Besuch im unteren Browserrand angezeigt und kann sich gemerkt werden.

Danke schonmal.
Gruss
Thorsten

  1. Hi,

    Zunächst mal mysql-injection. Was das ist weiss ich inzwischen, auch wie ein potenzieller Hacker vorgehen könnte (siehe Wikipedia). Um dies zu verhindern, habe ich in meinen scripten umfangreiche Abfragen gestaltet.

    komisch, um diesem Problem Herr zu werden, mache ich gewöhnlich gar keine Abfragen, sondern kodiere die Werte dem Kontext entsprechend. Okay, manchmal prüfe ich auf einen korrekten Datentyp.

    So z.B. bei Passwörtern, dass diese nur aus Buchstaben und Zahlen bestehen dürfen,

    Aua, bitte nicht. Passwörter werden ohnehin *nie* im Klartext gespeichert, sondern beispielsweise mittels PASSWORD() verschlüsselt; und gerade Sonderzeichen zu verbieten ist das Übelste, was man bei Passwörtern machen kann.

    Muss ich darüber hinaus noch etwas beachten?

    Kodiere einfach die Werte. Fertig.

    Eine andere Sache ist immernoch die, wenn jemand einen Link über die Favoriten auf eine Seite setzt, die er ohne Login nicht erreichen darf, und irgendwann später dahin über seine Favoriten zurückkehren will. Ich kann sicher zu Beginn eines jeden scriptes Abfragen, ob z.B. $_SESSION['passwort'] gesetzt ist. Wenn nicht, eben umleiten.

    Warum umleiten, wenn Du einfach den Login-Prozess starten und wieder an der Stelle landen kannst, wo der Nutzer hin wollte?

    Nun habe ich etwas mehr über .htaccess gelesen, kann mir aber nicht so recht etwas darunter vorstellen.

    .htaccess ist eine Datei, über die der Apache-Server verzeichnislokal konfiguriert werden kann. Auch wenn ein winziges, winziges Set der möglichen Konfigurationsdirektiven mit Authentifizierungen zu tun hat, will ich nicht verstehen, warum diese Konfigurationsdatei so häufig mit Login-Vorgängen verknüpft wird.

    Es soll sich dabei um eine Datei handeln. Muss man die selber einrichten?

    Ja, das nennt sich allerdings "abspeichern".

    Und wo befindet sie sich, bzw. wohin platziert man sie?

    In das Verzeichnis, für das sie gelten soll.

    Auf meinem Webspace finde ich nichts dergleichen.

    Es ist möglich, dass der Server so konfiguriert ist, sie nicht zu beachten. Oder er kein Apache ist.

    Wie wird sie angesteuert?

    Automatisch vom Server.

    Nochmal zur Klarheit:
    "document-root" bedeutet, das Verzeichnis, in dem sich die index.html befindet und welches "von aussen" erreicht werden kann?

    Im Prinzip richtig, nur dass keine index.html erforderlich sein muss.

    Wenn dem so ist und sich die Dateien, die nur über ein vorheriges Login erreicht werden können, in einem anderen Verzeichnis ausserhalb des document-root befinden, dann können diese Dateien doch trotzdem über einen Favoritenlink erreicht werden, oder?

    DocumentRoot bezeichnet das Verzeichnis, innerhalb dessen sich direkt per HTTP erreichbare Dateien befinden. Aus dem Dateipfad wird ein URL-Pfad, aus den Dateien werden Ressourcen. Befinden sich Dateien außerhalb dieses Verzeichnisses, sind sie nicht über diesen simplen Standard-Mechanismus verfügbar, was jedoch nichts darüber aussagt, ob und wie sie verfügbar sind. Bookmarks und Favoriten haben damit nichts zu tun.

    Welchen Nutzen hätte dann htaccess?

    Man kann darüber Konfigurationsdirektiven angeben, die für den Verzeichnisbaum gelten, in dem sie liegen. Also beispielsweise Dateien mit der Endung .exe per URLs mit der Endung .html erreichbar zu machen und als PHP ausführen zu lassen, welches eine Ressource des Typs image/gif erzeugt.

    Dasselbe, wenn jemand die Zieladresse direkt im Browser eintippt.

    Ja, das selbe, in der Tat. Zwischen einer solchen Eingabe und der Verwendung eines Bookmarks oder Favoriten gibt es keinerlei Unterschied.

    Der Pfad wird ja beim Besuch im unteren Browserrand angezeigt und kann sich gemerkt werden.

    Ja.

    Cheatah

    --
    X-Self-Code: sh:( fo:} ch:~ rl:| br:> n4:& ie:% mo:) va:) de:] zu:) fl:{ ss:) ls:~ js:|
    X-Self-Code-Url: http://emmanuel.dammerer.at/selfcode.html
    X-Will-Answer-Email: No
    X-Please-Search-Archive-First: Absolutely Yes
    1. Hallo,

      [.htaccess]
      Auf meinem Webspace finde ich nichts dergleichen.
      Es ist möglich, dass der Server so konfiguriert ist, sie nicht zu beachten. Oder er kein Apache ist.

      oder dass in seinem Webspace einfach keine .htaccess existiert, weil es der OP noch nicht für erforderlich hielt, vom Provider-Default abweichende Konfigurationen vorzunehmen.

      Der Pfad wird ja beim Besuch im unteren Browserrand angezeigt und kann sich gemerkt werden.

      Hää?

      So long,
       Martin

      --
      Der geistige Horizont ist der Abstand zwischen Brett und Hirn.
      Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
      1. Hi,

        Der Pfad wird ja beim Besuch im unteren Browserrand angezeigt und kann sich gemerkt werden.
        Hää?

        er meint die Statuszeile, in der die Ziel-URL von Links steht, wenn man zu diesen mit der Tastatur oder der Maus steuert.

        Cheatah

        --
        X-Self-Code: sh:( fo:} ch:~ rl:| br:> n4:& ie:% mo:) va:) de:] zu:) fl:{ ss:) ls:~ js:|
        X-Self-Code-Url: http://emmanuel.dammerer.at/selfcode.html
        X-Will-Answer-Email: No
        X-Please-Search-Archive-First: Absolutely Yes
        1. Om nah hoo pez nyeetz, Cheatah!

          er meint die Statuszeile, in der die Ziel-URL von Links steht, wenn man zu diesen mit der Tastatur oder der Maus steuert.

          noch., auch in der 4.0 beta 11 gibts noch keine Statusleiste.

          Matthias

          --
          Wer ein Problem beschreiben kann, hat es schon halb gelöst.                                             (Julian Huxley) http://www.billiger-im-urlaub.de/kreis_sw.gif
    2. Hallo,

      Aua, bitte nicht. Passwörter werden ohnehin *nie* im Klartext gespeichert, sondern beispielsweise mittels PASSWORD() verschlüsselt; und gerade Sonderzeichen zu verbieten ist das Übelste, was man bei Passwörtern machen kann.

      Muss ich darüber hinaus noch etwas beachten?

      Kodiere einfach die Werte. Fertig.

      Zum Kodieren benutze ich md5(). Okay?
      Natürlich werden Passwörter nicht im Klartext gespeichert, was mich aber nicht daran hindert, sie vor einer Abfrage in der DB auf gültige Formate zu prüfen. Sonst werden unnötigerweise Abfragen an die DB gestellt. Ausserdem sollen, so mein Infostand, keine Steuerzeichen in die gespeicherten Daten, wie ";" und "" usw.
      Es gibt leider viele Spinner im Web, die sich einen Spass daraus machen, Rigistrierungsformulare mit Unsinn zu füllen und abzusenden. Einen solchen hatten wir mal. Er nannte sich "Der Zerstörer" und füllte das Kontaktformular mit Müll (alle möglichen Zeichen) und sandte es ab. Erst als ich zusätzlich einen Spamschutz eingebaut habe, in dem man eine simple Rechenaufgabe lösen musste, hörte das auf. Da musste er wohl seine Birne anstrengen und hatte dann keinen Bock mehr. Nur mal so am Rande.

      Warum umleiten, wenn Du einfach den Login-Prozess starten und wieder an der Stelle landen kannst, wo der Nutzer hin wollte?

      Das ist strukturbedingt. Es gibt keinen Link "zum Login". Das Loginformular ist ständig sichtbar in einem div-Bereich - bis man sich eben eingeloggt hat.

      Es soll sich dabei um eine Datei handeln. Muss man die selber einrichten?

      Ja, das nennt sich allerdings "abspeichern".

      Nun, ich beschäftige mich erst seit kurzem mit htaccess. Aber auch als blutiger Amateur leuchtet mir ein, dass das Abspeichern einer leeren Datei wohl nicht viel bringt......oder?

      Ja, das selbe, in der Tat. Zwischen einer solchen Eingabe und der Verwendung eines Bookmarks oder Favoriten gibt es keinerlei Unterschied.

      Heisst, Dateien ausserhalb des DocumentRoot können NICHT erreicht werden?

      Der Pfad wird ja beim Besuch im unteren Browserrand angezeigt und kann sich gemerkt werden.

      @Der Martin
      Ja, ich meine die Statuszeile: Mauszeiger über Link - Link wird in Statuszeile angezeigt - Link kann notiert werden - Link kann später vom User im Browser eingetippt werden. Deutlicher?

      Danke für eure Antworten.

      Gruss
      Thorsten

      1. Hi,

        Kodiere einfach die Werte. Fertig.
        Zum Kodieren benutze ich md5(). Okay?

        nein, das hat Cheatah an dieser Stelle garantiert nicht gemeint. Das Codieren (hier: Verschlüsseln oder Hashen) eines Passworts ist eine Sache, dafür ist md5() auch geeignet. Viel wichtiger ist aber das Codieren nach den Vorgaben des verwendeten DBMS, wenn man die Daten dorthin übergibt. Bei der Übergabe von Stringwerten mit PHP an eine mySQL-DB wäre das typischerweise mysql_real_escape_string().

        Ausserdem sollen, so mein Infostand, keine Steuerzeichen in die gespeicherten Daten, wie ";" und "" usw.

        Wenn du die Codierungs- und Maskierungsregeln des jeweiligen Kontexts einhältst, ist das kein Problem.

        Warum umleiten, wenn Du einfach den Login-Prozess starten und wieder an der Stelle landen kannst, wo der Nutzer hin wollte?
        Das ist strukturbedingt. Es gibt keinen Link "zum Login". Das Loginformular ist ständig sichtbar in einem div-Bereich - bis man sich eben eingeloggt hat.

        Dann erst recht: Nach erfolgreichem Login nicht wieder irgendwohin umleiten, sondern direkt unter derselben Adresse das Dokument ausliefern.

        Es soll sich dabei um eine Datei handeln. Muss man die selber einrichten?
        Ja, das nennt sich allerdings "abspeichern".
        Nun, ich beschäftige mich erst seit kurzem mit htaccess. Aber auch als blutiger Amateur leuchtet mir ein, dass das Abspeichern einer leeren Datei wohl nicht viel bringt......oder?

        Natürlich. Aber es bringt nichts, wenn wir dir hier die Feinheiten der Apache-Konfiguration aufzählen. Es ging in deinem Posting, so wie ich es verstanden habe, erstmal um die Frage, "Was ist .htaccess?". Und das hat Cheatah erklärt: Es ist eine lokale Konfigurationsdatei für den Apache-Webserver.

        Heisst, Dateien ausserhalb des DocumentRoot können NICHT erreicht werden?

        Nicht direkt über HTTP. Ein PHP-Script, das seinerseits erreichbar ist, kann natürlich darauf zugreifen und sie dennoch ausliefrn. PHP (oder eine andere serverseitige Scriptsprache) unterliegt ja nicht den Zugriffsbeschränkungen von HTTP.

        Der Pfad wird ja beim Besuch im unteren Browserrand angezeigt und kann sich gemerkt werden.
        @Der Martin
        Ja, ich meine die Statuszeile: Mauszeiger über Link - Link wird in Statuszeile angezeigt - Link kann notiert werden - Link kann später vom User im Browser eingetippt werden. Deutlicher?

        Ja. Ich dachte, du redest von der Browser-Adresszeile und habe mich gefragt, in welcher ungewöhnlichen Browserkonfiguration die wohl *unten* ist.

        Ciao,
         Martin

        --
        Es existiert kein Weg, "für" etwas zu optimieren, sondern nur gegen alles andere.
          (Cheatah)
        Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
        1. mysql_real_escape_string() studiere ich gerade. Mein momentaner Infostand: bei Benutzung von mysql_real_escape_string() ist eine mysql-injection praktisch ausgeschlossen?

          Dann erst recht: Nach erfolgreichem Login nicht wieder irgendwohin umleiten, sondern direkt unter derselben Adresse das Dokument ausliefern.

          Missverständnis. Es wird nicht NACH einem Login umgeleitet, sondern nur dann, wenn man versucht über z.B. Bookmarks auf nicht-öffentliche Seiten zu gelangen. Ich möchte dies deutlicher beschreiben:
          Ein Mitglied loggt sicht ein und surft nun im Mitgliederbereich, meinetwegen auf der Unterseite "angebote.php", auf welcher eben Angebote und Einkaufspreise angezeigt werden. Die Einkaufspreise dürfen aber nur registrierte User sehen, die sich eben vorher eingeloggt haben. Dieses Mitglied setzt nun ein Bookmark, also einen Link unter Favoriten auf genau diese Seite und loggt sich aus. Einen Tag später will es über diesen Bookmark auf diese Seite zugreifen (ohne eingeloggt zu sein). Und JETZT soll eine Umleitung auf die index.php (Startseite) stattfinden, wo sich das Loginmodul befindet.
          Wenn ich das mit htaccess realisieren kann, wäre super und spart ne Menge Programmieraufwand.

          Nicht direkt über HTTP. Ein PHP-Script, das seinerseits erreichbar ist, kann natürlich darauf zugreifen und sie dennoch ausliefrn.

          So habe ich es mir auch vorgestellt. Sähe also so aus: z.B.
          Ordner "domain" = DocumentRoot; Inhalt: index.html
          Ordner "mitglieder" = kein Zugang über HTTP; Inhalt: angebot.php

          Im Ordner "mitglieder" befindet sich eine htaccess-Datei, die also den Zugriff auf Dateien im gleichen Ordner verbietet und auf index.html umleitet, auch wenn darauf ein Bookmark gesetzt ist. Ist das im Prinzip so richtig?

          Dank und Gruss
          Thorsten

          1. Und JETZT soll eine Umleitung auf die index.php (Startseite) stattfinden, wo sich das Loginmodul befindet.
            Wenn ich das mit htaccess realisieren kann, wäre super und spart ne Menge Programmieraufwand.

            Den Aufwand solltest du dir leisten.
            Es obliegt jedem Modul (Das heisst genauer, jedem Inhalt) zu prüfen, ob und für welche Benutzergruppe er ausgeliefert werden darf.
            So handhabe ich das in meinem CMS. Deshalb kann ich auch Gäste mitten in den Adminbereich führen, ohne etwas zu riskieren.

            Es ist keine gute Idee, dafür auf .htaccess zu setzen (auch wenn es irgendwie möglich wäre), denn .htaccess kann aus irgend einem Grund ausser Kraft gesetzt werden.

            Ich verwende .htaccess aber für eine Cookieabfrage (aber nicht validierung) um zu entscheiden, ob eine gecachte Seite ausgeliefert werden darf, statt den Interpreter anzuschmeissen. Hierbei frage ich, ob jemand eingelogged ist (erkenntlich am Cookie Userstatuswert). Falls nicht, ist er Kandidat für statisch gecachte Seiten.

            mfg Beat

            --
            ><o(((°>           ><o(((°>
               <°)))o><                     ><o(((°>o
            Der Valigator leibt diese Fische
            1. Hallo,

              Dank Euch wiedermal für Eure Antworten. Das Bild wird schon klarer. Ich muss auch um Verständnis bitten, wenn ich immer genau nachfrage. Mit MySql hab ich gerade erst angefangen und htaccess ist total neu. Auch sind mir nicht alle Begriffe geläufig, wie "Statuszeile" oder - @Der Martin - JAVA und Javascript. Deshalb lese und frage ich mir alles zusammen.

              Nochmal kurz zur Struktur (hab ich in einem anderen Thread schonmal beschrieben, da ging es um frames und divs):
              Ich habe 6 Bereiche auf der Seite, 4 divs und 2 iframes, 2 oben, 3 Mitte und 1 unten. Die iframes müssen sein, da man diese mit Namen (target='...') ansteuern kann. Diese Aufteilung ist beständig, nur die Inhalte variieren, je nach dem was man anklickt und ob man eingeloggt ist oder nicht. Mitte rechts wird die status.php angezeigt. Darin enthalten ist das Loginmodul, welches solange angezeigt wird, bis man sich einloggt. Ist man eingeloggt, erscheint dort der Logout-button. So gesehen ist das Loginmodul schon auf jeder Seite.

              Meine jetzige Lösung, die ich nach diesen Beiträgen wohl auch beibehalten werde, ist, zu Beginn eines jeden login-pflichtigen Bereichs eben eine Rechteabfrage mittels include einzubauen. Dazu bieten sich ja session-Variablen an. Ich habe nur angenommen, das ganze ging über htaccess mit weniger Aufwand. So in etwa: alle Dateien in diesem Ordner sind gesperrt, können nicht über Bookmarks (wohl aber über scripts) erreicht werden - Umleitung.

              Hilfreich wäre vielleicht noch, wenn es diese Möglichkeit gibt, feststellen zu können, woher ein user kommt. Das geht insofern, indem ich von script zu script eine Kontrollvariable weitergeben würde, anhand derer jedes script feststellen könnte, ob der user von einem anderen projekteigenen script kommt. Da eine solche Variable aber z.T. mit <a href="datei.php?variable=<?php echo $kontrolle ?>"> übergeben werden müsste, nützt mir das nichts, weil dies bei einem Bookmark mit gespeichert wird.
              Ich müsste nicht wissen, ob der user von google oder selfhtml kommt, nur, ob z.B. von einem anderen server oder soetwas. Kann man das irgendwie abfragen?

              Gruss
              Thorsten

              1. Hilfreich wäre vielleicht noch, wenn es diese Möglichkeit gibt, feststellen zu können, woher ein user kommt. Das geht insofern, indem ich von script zu script eine Kontrollvariable weitergeben würde, anhand derer jedes script feststellen könnte, ob der user von einem anderen projekteigenen script kommt. Da eine solche Variable aber z.T. mit <a href="datei.php?variable=<?php echo $kontrolle ?>"> übergeben werden müsste, nützt mir das nichts, weil dies bei einem Bookmark mit gespeichert wird.
                Ich müsste nicht wissen, ob der user von google oder selfhtml kommt, nur, ob z.B. von einem anderen server oder soetwas. Kann man das irgendwie abfragen?

                Ich hab gerade bei php.net etwas gefunden: $_SERVER['HTTPS']
                Ich habe leider nicht das Insiderwissen um exakt zu bestimmen, was in dieser Variablen genau enthalten ist. Nach der Erklärung dazu müsste es das sein, was ich suche?

                Gruss
                Thorsten

              2. Hi,

                Hilfreich wäre vielleicht noch, wenn es diese Möglichkeit gibt, feststellen zu können, woher ein user kommt.

                nein, das wäre gar nicht hilfreich, denn HTTP kennt kein "von" in diesem Sinn. Ein Zugriff kommt immer "vom" PC des Besuchers und kann daher vom Benutzer beliebig manipuliert werden.

                Du kannst zwar mit etwas Glück in $_SERVER['HTTP_REFERER'] die Adresse der Seite finden, die den Besucher zum aktuellen Zugriff bewegt hat, einfach ausgedrückt also, die zuvor besuchte Seite. Das ist aber ebenso unzuverlässig wie alle anderen clientseitigen Informationen; beim Referer kommt dazu, dass man ihn in manchen Browsern ganz abstellen kann; manche Proxies, Firewalls oder Privacy-Tools tun das teils sogar ohne Wissen des Anwenders - oder sie übermitteln irgendeinen Blödsinn als Referer. Die Information ist also bestenfalls noch für statistische Erhebungen brauchbar, wenn man eine gewisse Fehlerquote sowieso erwartet, aber nicht für sicherheitsrelevante Fragen.

                Ich müsste nicht wissen, ob der user von google oder selfhtml kommt, nur, ob z.B. von einem anderen server oder soetwas. Kann man das irgendwie abfragen?

                Nein. Du kannst nur abfragen, ob in der Session ein "angemeldet"-Status hinterlegt ist, und wenn nicht, den Besucher sofort zum Anmelden auffordern bzw. ihm in dem Moment sensible Daten vorenthalten.

                Ach so, ähm, aus $_SERVER['HTTPS'] erkennst du nur, ob der Besucher die aktuelle Ressource über eine gesicherte Verbindung (SSL, TLS) abruft. Bringt dir also nur eine Information, wenn du überhaupt SSL anbietest.

                So long,
                 Martin

                --
                Der Gast geht solange zum Tresen, bis er bricht.
                Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
          2. Hallo,

            Mein momentaner Infostand: bei Benutzung von mysql_real_escape_string() ist eine mysql-injection praktisch ausgeschlossen?

            wenn man es richtig[tm] und kosequent anwendet - vermutlich ja.

            Dann erst recht: Nach erfolgreichem Login nicht wieder irgendwohin umleiten, sondern direkt unter derselben Adresse das Dokument ausliefern.
            Missverständnis. Es wird nicht NACH einem Login umgeleitet, sondern nur dann, wenn man versucht über z.B. Bookmarks auf nicht-öffentliche Seiten zu gelangen.

            Auch dann ist keine Umleitung erforderlich.

            Ein Mitglied loggt sicht ein und surft nun im Mitgliederbereich, meinetwegen auf der Unterseite "angebote.php", auf welcher eben Angebote und Einkaufspreise angezeigt werden. Die Einkaufspreise dürfen aber nur registrierte User sehen, die sich eben vorher eingeloggt haben. Dieses Mitglied setzt nun ein Bookmark, also einen Link unter Favoriten auf genau diese Seite und loggt sich aus. Einen Tag später will es über diesen Bookmark auf diese Seite zugreifen (ohne eingeloggt zu sein). Und JETZT soll eine Umleitung auf die index.php (Startseite) stattfinden, wo sich das Loginmodul befindet.

            Und das ist ungünstig: Du hast eben irgendwo erwähnt, dass das Login-Formular auf jeder Seite sichtbar ist. Also zeige doch an der Stelle, wo die für nicht angemeldete Besucher "verbotene" Information stehen soll, einfach einen entsprechenden Hinweis an: "Um diese Information sehen zu können, müssen Sie sich anmelden."
            Dann kann der registrierte Besucher das auf *genau dieser* Seite tun und ist nach dem Login auch genau wieder an der Stelle, wo er eigentlich hin wollte.

            Nicht direkt über HTTP. Ein PHP-Script, das seinerseits erreichbar ist, kann natürlich darauf zugreifen und sie dennoch ausliefrn.
            So habe ich es mir auch vorgestellt. Sähe also so aus: z.B.
            Ordner "domain" = DocumentRoot; Inhalt: index.html
            Ordner "mitglieder" = kein Zugang über HTTP; Inhalt: angebot.php

            Das ergäbe IMHO keinen Sinn und widerspricht auch deiner restlichen Beschreibung.

            Im Ordner "mitglieder" befindet sich eine htaccess-Datei, die also den Zugriff auf Dateien im gleichen Ordner verbietet und auf index.html umleitet, auch wenn darauf ein Bookmark gesetzt ist.

            Und dann? Wie willst du angebot.php je erreichen?

            Nein, "über HTTP nicht erreichbar" heißt genau das: Nicht erreichbar.
            Nehmen wir als Beispiel an, dein Webhoster würde die Web-Verzeichnisse seiner Kunden in /var/www/kundennummer/htdocs organisieren. .../htdocs entspräche dann dem Document Root http://example.org/, aber als Kunde hast du (z.B. per FTP) auch schon den Zugang zu .../kundennummer. In diesem übergeordneten Verzeichnis, das per HTTP nicht erreichbar ist (!), kannst du beispielsweise Passwortdateien oder Konfigurationsdaten für PHP-Projekte hinterlegen, die auf keinen Fall ein Besucher -ob angemeldet oder nicht- in die Finger kriegen soll.

            Was du hier ansprichst, ist ja schon eine Ebene weiter: In dem Moment, wo du in der Lage bist, dem Besucher ein Login-Formular zu präsentieren oder ihm ein "Du kommst hier net rein" an den Kopf zu werfen, ist der HTTP-Zugriff aus technischer Sicht ja schon erfolgreich abgeschlossen.

            So long,
             Martin

            --
            I do take my work seriously and the way to do that is not to take yourself too seriously.
              (Alan Rickman, britischer Schauspieler)
            Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
            1. Hallo Martin,

              Mein momentaner Infostand: bei Benutzung von mysql_real_escape_string() ist eine mysql-injection praktisch ausgeschlossen?

              wenn man es richtig[tm] und kosequent anwendet - vermutlich ja.

              Heisst also: immer(!) beim Schreiben in die DB und(!) beim Lesen aus der DB?
              Hast Du, oder sonst noch jemand, noch irgend einen Tip dazu?

              Was alles andere betrifft, herrscht erstmal Klarheit, sodass ich jetzt weitermachen kann.

              Dank und Gruss
              Thorsten

              1. Hi Thorsten,

                Mein momentaner Infostand: bei Benutzung von mysql_real_escape_string() ist eine mysql-injection praktisch ausgeschlossen?
                wenn man es richtig[tm] und kosequent anwendet - vermutlich ja.
                Heisst also: immer(!) beim Schreiben in die DB

                nein, nur bei Stringwerten. Bei numerischen Werten schadet's zwar auch nicht, ist aber unnötig.

                und(!) beim Lesen aus der DB?

                Nein, warum das? Beim Lesen aus der DB solltest du den reingeschriebenen Wert ohne weitere Maßnahmen im Klartext wieder rausbekommen.
                Erst beim Ausgeben als HTML ist wieder Vorsicht angesagt: Damit im Text vorkommende HTML-Sonderzeichen (<, >, &) nicht die Ausgabe versauen, müssen sie HTML-gerecht codiert werden. Hier ist htmlspecialchars() das Mittel der Wahl.

                Hast Du, oder sonst noch jemand, noch irgend einen Tip dazu?

                Der Wiki-Artikel über Kontextwechsel behandelt das Thema noch recht ausführlich.

                Ciao,
                 Martin

                --
                Die letzten Worte des Hardware-Bastlers:
                Das Netzkabel lass ich wegen der Erdung lieber dran.
                Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
              2. Hallo,

                auch auf die Gefahr hin, dass ich nerve....

                Habe gerade bei php.net folgendes Beispiel gefunden:
                "Beispiel #2 Ein beispielhafter SQL Injection Angriff"

                <?php
                // Datenbankabfrage zur Ueberpruefung der Logindaten
                $query = "SELECT * FROM users WHERE user='{$_POST['username']}' AND password='{$_POST['password']}'";
                mysql_query($query);

                // Wir haben $_POST['password'] nicht geprueft, es koennte also alles darin
                // stehen, was der User will. Zum Beispiel:
                $_POST['username'] = 'aidan';
                $_POST['password'] = "' OR ''='";

                // Das bedeutet, der an MySQL gesendete Query wuerde sein:
                echo $query;
                ?>

                So, entscheidend ist die Kommentarzeile:
                // Wir haben $_POST['password'] nicht geprueft, es koennte also alles darin
                // stehen, was der User will.

                und code:
                $_POST['password'] = "' OR ''='";

                Solche Eingaben erlaube ich ja schon per php-script nicht. Das eingegebene Passwort durchläuft zuerst "ctype_alnum", bei der Registrierung als auch beim Einloggen. Alles, was nicht Buchstabe und Zahl ist, führt zu einer Fehlermeldung. Und Zeichen wie Semikolon, Komma, Leerstellen usw. haben weder in einem Passwort noch in einem Nicknamen was zu suchen. Meine Meinung. Im Nicknamen ist lediglich der Unterstrich erlaubt, in Emails darüber hinaus das Minuszeichen (Bindestrich), Punkt und Klammeraffe. Ich habe noch nie eine Email gesehen die da lautet: vorname,nachname@gmx.de

                Jetzt frage ich mich, wozu also zusätzlich mysql_real_escape_string() ? In einer Textarea, welche ein User selbst eingeben kann und Sonderzeichen erlaubt sind, erscheint mir das logisch, aber bietet eine solche einen Ansatz für eine injection?

                Gruss
                Thorsten

                1. Yerf!

                  Und Zeichen wie Semikolon, Komma, Leerstellen usw. haben weder in einem Passwort noch in einem Nicknamen was zu suchen.

                  Du hattest scheinbar noch nie Kontakt mit einem Firmennetzwerk. Dort sind Sonderzeichen in Passwörtern häufig vorgeschrieben.

                  Jetzt frage ich mich, wozu also zusätzlich mysql_real_escape_string() ?

                  Damit du die nutzbaren Zeichen nicht künstlich einschränken musst. Denn damit passiert auch mit ' OR ''=' als Paswort nichts.

                  Gruß,

                  Harlequin

                  --
                  RIP --- XHTML 2
                  nur die Besten sterben jung
                  1. Hallo Harlequin,

                    bitte richtig zitieren!

                    Und Zeichen wie Semikolon, Komma, Leerstellen usw. haben weder in einem Passwort noch in einem Nicknamen was zu suchen.

                    Du hattest scheinbar noch nie Kontakt mit einem Firmennetzwerk. Dort sind Sonderzeichen in Passwörtern häufig vorgeschrieben.

                    Hinter "...was zu suchen." kommt noch "Meine Meinung" ! Das ist meine Meinung, kein globaler Regelverstoss. Ich kann mir schon vorstellen, dass anderswo Sonderzeichen erlaubt sind, nicht jedoch bei mir. Erfahrungsgemäss neigen Passwörter, die da lauten dürfen: "ich!;lliw><-rein" eher dazu vergessen zu werden, als welche die nur aus Buchstaben und Zahlen bestehen. Aber eigentlich sollte dies jeder Autor halten wie er will.

                    Gruss
                    Thorsten

                    1. Yerf!

                      Gut, dann ist das deine Meinung. Dann kommt hier aber noch meine: ich hab ein sehr gutes System für Passwörter mit Sonderzeichen die ich mir gut merken kann und ich ärgere mich jedesmal, wenn mir eine Seite vorschreibt, dass ich die nicht benutzen darf...

                      Ob man die Sonderzeichen unbedingt erzwingen will, darüber kann man streiten. Aber sie zu verbieten ist einfach Schrott. Vor allem da bei "richtiger" Programmierung keine Gefahr davon ausgeht und man sich keine Gedanken machen muss, ob die Whitelist nicht doch noch Lücken hat.

                      Gruß,

                      Harlequin

                      --
                      RIP --- XHTML 2
                      nur die Besten sterben jung
                      1. Hallo,

                        melde mich nochmal etwas verspätet, da mir solche Sachen, wie jetzt mit den Passwörtern, keine Ruhe lassen.

                        Aber zuerst @Harlequin:

                        Gut, dann ist das deine Meinung. Dann kommt hier aber noch meine: ich hab ein sehr gutes System für Passwörter mit Sonderzeichen die ich mir gut merken kann und ich ärgere mich jedesmal, wenn mir eine Seite vorschreibt, dass ich die nicht benutzen darf...

                        Damit scheine ich aber nicht der einzigste zu sein, der Sonderzeichen in Passwörtern verbietet...
                        Die Frage ist aber nicht, ob Sonderzeichen erlaubt sind oder nicht, sondern ob Du Dich trotzdem dort registrierst (registriert hast)?

                        So unsinnig (oder Schrott) ist das mit dem Verbieten gar nicht. Denn ich habe folgendes gemacht. Nachdem wir über diesen Streitpunkt diskutiert haben, habe ich ein paar Bekannte angerufen und sie gebeten, sich Passwörter und Nicknamen zu wählen, die es bei ihnen noch nicht gibt. Ohne Einschränkungen, ganz neutral. Die Art der Website sollte egal sein. Also Chat, Kontaktplattform, Zalando, ebay oder was auch immer. Es sollten 8 Bekannte sein, habe aber nur 5 erreicht. Mit dem letzten habe ich vorhin erst wieder telefonieren können. Also 3 Damen und 2 Herren, 1 Dame und 1 Herr sind ein Paar.

                        Heraus kam, man staune:

                        1.Dame, Nick: "Tinkataube", PW: "xxxxxyyyyy" (die Vornamen ihrer Kinder)

                        2.Dame, Nick: "RoteZora", PW: "mechteltechtel"

                        3.Dame, Nick: "Jetterin36" PW: "(würde spontan gewählt; nur Zahlen als Kombination)"

                        1.Herr, Nick: "ferrari-39" PW: "ferrari-lamborghini"

                        2.Herr, Nick: "alterFritz" PW: "dashausdasautodasboot"

                        So, das wars. Ich muss noch anmerken, dass alle reine USER sind und nichts mit programmieren zu tun haben. Eben anders als hier im Forum.
                        Demnach beutzen 40% überhaupt Zahlen und 20% ein Sonderzeichen, den Bindestrich. Auf meine Frage, was denn wäre, wenn dieser Bindestrich nicht erlaubt wäre kam die Antwort: "Dann drücke ich shift und nehme diesen anderen Strich da unten oder lass ihn weg."
                        Ich selbst gestalte meine Passwörter übrigens ähnlich einer session-ID. Auch ohne Sonderzeichen.
                        Aber, soll jeder halten wie er will.

                        Gruss
                        Thorsten

                        1. Hi!

                          Damit scheine ich aber nicht der einzigste zu sein, der Sonderzeichen in Passwörtern verbietet...

                          Einzig ist schon wenig genug. Das Wort zu steigern ist nicht sinnvoll.

                          Die Frage ist aber nicht, ob Sonderzeichen erlaubt sind oder nicht, sondern ob Du Dich trotzdem dort registrierst (registriert hast)?

                          Warum willst du etwas einschränken, was technisch nicht notwendig ist? Das Argument mit der (angeblich) steigenden Vergessensrate zieht nicht, weil du ja nicht zur Bedingung machst, Sonderzeichen zu verwenden. Somit ist ein vergesslicher bei einer solchen Wahl selbst schuld.

                          Das einzige Problem wäre, dass zwei Zeichen nicht auf Anhieb optisch voneinander zu unterscheiden sind, wie beispielsweise р und p oder in bestimmten Schriftarten l und I (da hilft dir auch kein Einschränken auf lateinische Buchstaben). Wenn damit jemand Anmeldenamen fälscht um unter einer fremden Identität Unfug anzustellen, hilft nur ein weiteres vom System vergebenes eindeutiges Merkmal mit aufzuführen, beispielsweise die ID.

                          Benutzer Sowieso (ID 0815) hat geschreiben: blafasel blubb.
                            Benutzer Sоwieso (ID 4711) hat geschreiben: blafasel blubb.

                          Um die Unterschiede zu sehen bitte von diesem Posting die Quelltextansicht anschauen, darin den Nachrichtentext suchen und dann die Kodierung händisch auf ISO-8859-1 stellen (geht auf alle Fälle im Firefox). Man sieht dann, dass das erste р kein p ist und das о sowieso kein o ist.

                          Lo!

                          1. Das einzige Problem wäre, dass zwei Zeichen nicht auf Anhieb optisch voneinander zu unterscheiden sind, wie beispielsweise р und p

                            Dadurch spielst du auf Non-ASCII Chars hin. Da Betriebssicherheit höher werte als maximale Zeichensatz (siehe den Fall der möglichen Umstellung des Zeichenencodings) lehne ich Non-ASCII-Chars in allen Identitätsfeldtypen ab.

                            Du musst garantieren können, dass die Bytefolge, die ein Passwort definiert, jederzeit transportiert werden kann. Anderseits spielst du mit Feuer.

                            mfg Beat

                            --
                            ><o(((°>           ><o(((°>
                               <°)))o><                     ><o(((°>o
                            Der Valigator leibt diese Fische
                            1. Hi!

                              Das einzige Problem wäre, dass zwei Zeichen nicht auf Anhieb optisch voneinander zu unterscheiden sind, wie beispielsweise р und p
                              Dadurch spielst du auf Non-ASCII Chars hin. Da Betriebssicherheit höher werte als maximale Zeichensatz (siehe den Fall der möglichen Umstellung des Zeichenencodings) lehne ich Non-ASCII-Chars in allen Identitätsfeldtypen ab.

                              Nicht alle sind glücklich, wenn ihre Identität auf ASCII beschnitten wird. Was hat es mit dem Fall der Umstellung der Zeichenkodierung auf sich? Meinst du einen konkreten oder einen möglichen Fall?

                              Du musst garantieren können, dass die Bytefolge, die ein Passwort definiert, jederzeit transportiert werden kann. Anderseits spielst du mit Feuer.

                              Wieso muss ich garantieren können, dass die Benutzer das von ihnen selbst gewählte Passwort unter allen Umständen eingeben können? Fremde Tastaturen sind ein Anwender-Problem. Wer die aufgrund seiner Reise-/Arbeitstätigkeit ständig vorfindet, muss sich eben sein Passwort mit Bedacht wählen. Was den Transport angeht, Browser sind UTF-8-fähig. Wenn andere Clients zum Einsatz kommen, die das nicht können, ist das deren Problem, solange sie nicht von mir bereitgestellt werden.

                              Lo!

                              1. Nicht alle sind glücklich, wenn ihre Identität auf ASCII beschnitten wird.

                                Nicht alle sind glücklich, wenn deren Identität auf Unicode beschnitten wird.
                                Ein Identifizierungsfeld ist kein Feld persönlicher Ausstaffierung, sondern ein rein technisches Token.
                                Zur Ausstaffierung gibt es dann die Account-Einstellungen.

                                Was hat es mit dem Fall der Umstellung der Zeichenkodierung auf sich? Meinst du einen konkreten oder einen möglichen Fall?

                                Wieso muss ich garantieren können, dass die Benutzer das von ihnen selbst gewählte Passwort unter allen Umständen eingeben können?

                                Naja, deren Problem kann dein Problem werden wenn es sich um das Passwort deines Chefs handelt.

                                mfg Beat

                                --
                                ><o(((°>           ><o(((°>
                                   <°)))o><                     ><o(((°>o
                                Der Valigator leibt diese Fische
                                1. Hallo,

                                  ja richtig, die Sicherheit geht vor! Als ich hier in diesem Forum zum ersten Mal etwas von "mysql-injection" las, war mysql generell Neuland für mich. Inzwischen hab ich mich da aber reingearbeitet. Und weil ich in mysql noch nicht so weit war, habe ich eben die Sicherheitsabfragen in PHP gestaltet. Die Skripte sind fertig und funktionieren. Kurz gesagt halte ich nicht krampfhaft daran fest, Sonderzeichen in Passwörtern zu verbieten. Aber um JETZT nochmal umzustellen - ich habe inzwischen mehrere Male die Struktur geändert (siehe meine anderen Threads) - müsste ich wieder vieles ändern. Und das möchte ich nicht, weil nicht zwingend notwendig. Ausserdem habe ich diesen Bereich des Projektes, Login und Registrieren, eben abgeschlossen und bin weiter fortgeschritten.
                                  Ich sage nicht, dass hier jemand Unrecht hat! Und ich bin dankbar für die Tips und Anregungen, die ich hier bekomme! Aber auf Grund der Tatsache, wie User ihre Passwörter auswählen, habe ich jetzt einfach keine Lust auf Änderungen. Sollten sich später Beschwerden bezüglich der Passwortmöglichkeiten häufen, werde ich sicher reagieren. Oder vielleicht auch vorher schon. Aber jetzt arbeite ich erstmal weiter.

                                  Gruss und nochmals Danke
                                  Thorsten

                                  1. Hallo,

                                    bin gerade an einem Punkt, wo ein bereits registrierter User seine Daten (Passwort, Email usw.) ändern kann. Dort schreibe ich in die DB schon mit "mysql_real_escape_string".

                                    Skriptausschnitt:

                                    ...
                                    $passwort = "' OR '%><";
                                    $aendern = mysql_query ("update test set passwort = '" . mysql_real_escape_string($passwort) . "' where nick ='Thorsten'");
                                    ...

                                    In der DB steht: ' OR '%><
                                    Ist das richtig so? Da soll doch etwas maskiert werden?

                                    Gruss
                                    Thorsten

                                    1. Hi!

                                      Ist das richtig so? Da soll doch etwas maskiert werden?

                                      Bitte mach dich mit den Grundlagen vertraut. Wenn du das Prinzip nicht verstehst, kannst du die Sicherung gegen Injection genauso gut vergessen. Das Prinzip hab ich im Kontextwechsel-Artikel zu erklären versucht. Bitte lies ihn erst einmal, zumindest den Anfang/die erste Seite.

                                      Die Maskierung erfolgt nicht für die Datenbank, sondern weil du ein SQL-Statement hast, in dem Befehl und Daten gemeinsam notiert und eindeutig voneinander unterschieden werden müssen.

                                      Lo!

                                    2. Mahlzeit treziman,

                                      $passwort = "' OR '%><";
                                      $aendern = mysql_query ("update test set passwort = '" . mysql_real_escape_string($passwort) . "' where nick ='Thorsten'");
                                      ...

                                      In der DB steht: ' OR '%><
                                      Ist das richtig so?

                                      Ja.

                                      Da soll doch etwas maskiert werden?

                                      Wurde ja auch - deshalb steht ja auch *GENAU DAS*, was in der Variable enthalten war, in der Datenbank.

                                      Du solltest Dich *nochmals* intensiv mit der Funktionsweise von mysql_real_escape_string() im Besonderen und der Bedeutung des Begriffs "Kontextwechsels" im Allgemeinen beschäftigen.

                                      MfG,
                                      EKKi

                                      --
                                      sh:( fo:| ch:? rl:( br:> n4:~ ie:% mo:} va:) de:] zu:) fl:{ ss:) ls:& js:|
                                      1. Guten Morgen die Herren,

                                        habe nochmals den Artikel zum Kontextwechsel gelesen, aber da steht auch nirgends, ob ' OR '&<> richtig ist, bzw. warum die Backslashes nicht mit gespeichert werden. Darauf zielte eigentlich meine Frage, die sich aus dem Link von EKKI unter:

                                        mysql_real_escape_string() ruft die Funktion mysql_real_escape_string der MySQL-Bibliothek auf, die folgende Zeichen mit einem Backslash ('') versieht: \x00, \n, \r, , ', " und \x1a.

                                        ergeben hat, was ich schon ein paarmal gelesen habe. Es steht nirgends "Die Backslashes werden nicht mit gespeichert" o.ä., oder ich habs übersehen.

                                        Danke EKKI für das klare "Ja." !

                                        Gruss
                                        Thorsten

                                        1. Hi!

                                          habe nochmals den Artikel zum Kontextwechsel gelesen, aber da steht auch nirgends, ob ' OR '&<> richtig ist, bzw. warum die Backslashes nicht mit gespeichert werden.

                                          Das steht sinngemäß gleich zu Anfang im Absatz Programmcode und Daten. Die Daten müssen nur für das SQL-Statement aufbereitet werden. Im DBMS stehen (genauso wie im Speicher eines Programms) nur die reinen Daten, weil der Kontext "SQL-Statement" (beziehungsweise "Code in der Programmiersprache XY") zu dem Zeitpunkt schon wieder Geschichte ist.

                                          Du hast immer noch nicht das Prinzip dahinter verstanden, dass es nur darum geht, bei einem Mischen von Code mit Daten zu Transportzwecken, die Daten eindeutig zu kennzeichnen/erkennen. Zur weiteren internen Verarbeitung und Speicherung sind die Rohdaten erforderlich. Erst beim nächsten Transport, wenn die Daten wieder in einen Code-Kontext eingebunden werden sollen, müssen die nächsten Maskierungen eingefügt werden. Auch der Empfänger dieser Mischung wird daraus wieder die Rohdaten extrahieren.

                                          Lo!

                                          1. Hallo dedlfix,

                                            .., dass es nur darum geht, bei einem Mischen von Code mit Daten zu Transportzwecken, die Daten eindeutig zu kennzeichnen/erkennen.

                                            Bei allem Respekt, das wird so (verständlich für einen Anfänger) nirgends erklärt. Dieser Satz von Dir klärt dagegen alles, eben in einem Satz!
                                            Das habe ich verstanden. Nämlich, dass die Daten für mysql_query() maskiert werden, um die Ausführung von eventuellem Code zu verhindern. Das leuchtet ein.
                                            Wenn ich einer Variablen einen Wert zuweise wie
                                            $variable = "Hallo \n hier bin ich";
                                            ist der Backslash sichtbar. Bei
                                            echo $variable;
                                            dagegen nicht. Warum ist klar. Als Anfänger wende ich dieses Prinzip aber auch auf mysql an, weils logisch erscheint. Demnach erwarte ich, dass in der DB - sichtbar - die Backslashes stehen, also "Hallo \n hier bin ich". In der Erklärung zu mysql_real_escape_string steht es genau so: ...wird mit einem Backslash versehen. Das die Backslashes nicht mit gespeichert werden, hat nichts mit Kontextwechsel zu tun, sondern mit der Funktionsweise von mysql, bzw. mysql_real_escape_string.

                                            Ich habe es schonmal geschrieben, bevor ich hier poste, suche ich die Antwort im Web, meist über google oder über einen meiner unzähligen Bookmarks auf php.net, PHP für Dich, usw. Wenn ich da aber nix finde, DANN poste ich hier...und erwarte Hilfe, die ich meist auch bekomme und wofür dieses Forum wohl auch gedacht ist. Ein "Lies dir nochmal..." oder "Lies zuerst mal..." hilft mir eigentlich nie, weil ich dort sicher schon gewesen bin, aber nichts fand oder es nicht verstanden habe.

                                            Gruss und abermals Dank
                                            Thorsten

                                            1. Yerf!

                                              Wenn ich einer Variablen einen Wert zuweise wie
                                              $variable = "Hallo \n hier bin ich";
                                              ist der Backslash sichtbar. Bei
                                              echo $variable;
                                              dagegen nicht. Warum ist klar. Als Anfänger wende ich dieses Prinzip aber auch auf mysql an, weils logisch erscheint. Demnach erwarte ich, dass in der DB - sichtbar - die Backslashes stehen, also "Hallo \n hier bin ich". In der Erklärung zu mysql_real_escape_string steht es genau so: ...wird mit einem Backslash versehen.

                                              Der "Fehler" dabei ist nur die Zuordnung zwischen den 2 Beispielen. Das was mysql_real_escape_string ausgibt enthält die Backslashes, man sieht sie wenn man sichd as Statement das zusammengebaut wird vor der Ausführung per echo anzeigen lässt. Dies ist das vergleichbare Gegenstück zu deiner Codezeile mit \n.

                                              Das was in der Datenbank steht ist vergleichbar mit der Ausgabe von Echo, dort ist der Backslash nicht mehr sichtbar.

                                              Gruß,

                                              Harlequin

                                              --
                                              RIP --- XHTML 2
                                              nur die Besten sterben jung
                                            2. Hi!

                                              .., dass es nur darum geht, bei einem Mischen von Code mit Daten zu Transportzwecken, die Daten eindeutig zu kennzeichnen/erkennen.
                                              Bei allem Respekt, das wird so (verständlich für einen Anfänger) nirgends erklärt.

                                              Die Frage ist auch, wie man Verständlichkeit definiert. Da gibt es leider kein Patentrezept. Was der eine auf Anhieb versteht, ist für den anderen nach dem x-ten Lesen immer noch böhmisches Dorf.

                                              Wenn ich einer Variablen einen Wert zuweise wie
                                              $variable = "Hallo \n hier bin ich";
                                              ist der Backslash sichtbar. Bei
                                              echo $variable;
                                              dagegen nicht. Warum ist klar.

                                              Weil er beim Lesen des obigen Codes weginterpretiert wurde. Er wird nämlich nur für die Code-Notation benötigt.

                                              Als Anfänger wende ich dieses Prinzip aber auch auf mysql an, weils logisch erscheint. Demnach erwarte ich, dass in der DB - sichtbar - die Backslashes stehen, also "Hallo \n hier bin ich".

                                              Da verhält sich das DBMS aber im Prinzip wie die Variable: Die Backslashes wurden vor dem Speichern weginterpretiert.

                                              In der Erklärung zu mysql_real_escape_string steht es genau so: ...wird mit einem Backslash versehen. Das die Backslashes nicht mit gespeichert werden, hat nichts mit Kontextwechsel zu tun, sondern mit der Funktionsweise von mysql, bzw. mysql_real_escape_string.

                                              Für wen arbeitet denn mysql_real_escape_string()? Nicht für das DBMS, sondern für das Statement, denn sein Ergebnis wird in den Statement-String eingetragen. Das sieht man, wenn man sich den ausgeben lässt. Also ist es einen unzulässigen Schritt zu weit gedacht, wenn man annimmt, dass das mysql_real_escape_string()-Ergebnis im DBMS landet, denn es landet ja nur im SQL-Statement. Erst mysql_query() kommuniziert mit dem DBMS und was bei diesem Vorgang passiert, beeinflusst dann das was gespeichert wird.

                                              Ich habe es schonmal geschrieben, bevor ich hier poste, suche ich die Antwort im Web, [...] Ein "Lies dir nochmal..." oder "Lies zuerst mal..." hilft mir eigentlich nie, weil ich dort sicher schon gewesen bin, aber nichts fand oder es nicht verstanden habe.

                                              Das wissen wir ja nicht, wenn du nicht aufzählst, was du schon gelesen hast und was du daran eventuell nicht verstanden hast. Es ist aus "unserer" Sicht nur verständlich, wenn wir auf bereits Geschriebenes verweisen und nicht jedes Mal alles von vorn erzählen wollen, wenn wir den Eindruck haben, dass dir Grundlagenwissen fehlt, das dir eigentlich durch den beworbenen Text vermittelt werden soll.

                                              Lo!

                                              1. Hallo,

                                                Die Frage ist auch, wie man Verständlichkeit definiert. Da gibt es leider kein Patentrezept. Was der eine auf Anhieb versteht, ist für den anderen nach dem x-ten Lesen immer noch böhmisches Dorf.

                                                Dann ist ein Nachfragen ja auch okay. Allerdings erwartet der Fragende dann eine klärende Antwort und nicht einen Verweis auf den Text, den er soeben gelesen aber nicht verstanden hat. Und wenn ausserdem die Antwort nicht in diesem gelesenen Text enthalten ist? Gut, der Fragende hätte natürlich noch darauf hinweisen können, dass er da und dort schon gelesen hat. Muss er aber eigentlich nicht, wenn er eine klare Frage stellt.

                                                Ich habe soetwas ähnliches kürzlich in praktisch allen Foren gesehen, als ich auf der Suche nach Alternativen zu frames war (siehe hier im Archiv: frames, iframes und divs - kann man glaub ich nicht mehr drauf antworten). Auf Fragen wie "Kann ich mit einem Frame dies und das?" wurde dem Fragenden oft mit der Gegenfrage "Musst du denn frames benutzen? Die sind suchmaschinenfeindlich..." und und und. Danach hatte er gar nicht gefragt!
                                                Es hat mich schon genervt, wenn ich bei google Suchbegriffe eingegeben und zig Ergebnisse aus zig Foren erhalten habe. Und praktisch überall liefen die Threads auf die Frage hinaus "frames, ja oder nein", statt die eigentliche Frage zu beantworten.

                                                Sollte ich eines Tages mal über soviel Fachwissen verfügen, dass ich kompetent Fragen beantworten kann, dann werde ich es so halten, wie EKKI es gemacht hat:
                                                Beispiel + Frage des Fragenden
                                                "Ja." = Antwort

                                                Ob danach noch was kommt, spielt keine Rolle - denn die Frage ist beantwortet.

                                                Bei Fragen allerdings, die etwa so aussehen wie:
                                                ...
                                                if (dies = das) $a = $b; $c = $d;
                                                ...
                                                "Meine Abfrage funktioniert nicht. Warum?"

                                                würde ich den Fragenden allerdings auch ans PHP-Manual verweisen. HIER fehlen ganz klar Grundkenntnisse.

                                                Nichts für ungut.
                                                Gruss
                                                Thorsten

                                                1. Hi!

                                                  Dann ist ein Nachfragen ja auch okay. Allerdings erwartet der Fragende dann eine klärende Antwort und nicht einen Verweis auf den Text, den er soeben gelesen aber nicht verstanden hat. Und wenn ausserdem die Antwort nicht in diesem gelesenen Text enthalten ist? Gut, der Fragende hätte natürlich noch darauf hinweisen können, dass er da und dort schon gelesen hat. Muss er aber eigentlich nicht, wenn er eine klare Frage stellt.

                                                  Nicht jede "klare" Frage lässt sich kurz beantworten. Und aus welchem Grund erwartet der Leser denn immer eine Individualbehandlung, wenn das Thema eigentlich erschöpfend anderwo behandelt wurde? Natürlich erwarten das nicht alle Leser. Manche sind mit einem Hinweis auf einen Text zum Selberlesen zufrieden. Als Antwortender weiß man nicht vorher, was den Leser glücklich macht.

                                                  Auf Fragen wie "Kann ich mit einem Frame dies und das?" wurde dem Fragenden oft mit der Gegenfrage "Musst du denn frames benutzen? Die sind suchmaschinenfeindlich..." und und und. Danach hatte er gar nicht gefragt!

                                                  Diese Diskussion ist auch schon mehrfach geführt worden. Niemand weiß vorher, ob der Fragende dankbar ist, dass seine Frage nicht nur innerhalb des Tellerrandes beantwortet wird. Oftmals ist das eigentliche Problem ein ganz anderes als die gestellte Frage, und es ist meist sinnvoller es richtig anzugehen, statt einfach nur den kleinen Stein auf dem Weg in die noch nicht erkannte Sackgasse wegzuräumen.

                                                  Es hat mich schon genervt, wenn ich bei google Suchbegriffe eingegeben und zig Ergebnisse aus zig Foren erhalten habe. Und praktisch überall liefen die Threads auf die Frage hinaus "frames, ja oder nein", statt die eigentliche Frage zu beantworten.

                                                  Kann auch an der zu unspezifischen Suchwortwahl liegen. Aber ja, das Internet ist schon lange kein elitärer Haufen mehr, in dem nur "wertvolles" Wissen zu finden ist.

                                                  Sollte ich eines Tages mal über soviel Fachwissen verfügen, dass ich kompetent Fragen beantworten kann, dann werde ich es so halten, wie EKKI es gemacht hat:
                                                  Beispiel + Frage des Fragenden
                                                  "Ja." = Antwort
                                                  Ob danach noch was kommt, spielt keine Rolle - denn die Frage ist beantwortet.

                                                  Von oben sieht die Welt ganz anders aus als von unten. Ist die Ampel grün? Ja. (Aber auf der Querstraße kommt einer angerast, der es nicht mehr schaffen wird, vor der Kreuzung zum Stillstand zu kommen.)

                                                  Lo!

                        2. Yerf!

                          Die Frage ist aber nicht, ob Sonderzeichen erlaubt sind oder nicht, sondern ob Du Dich trotzdem dort registrierst (registriert hast)?

                          Teilweise ja. Je nach (Un)-wichtigkeit lasse ich es aber auch, da ich entweder dazu neige diese Passwörter zu vergessen oder mir die Sicherheit zu niederig ist.

                          So unsinnig (oder Schrott) ist das mit dem Verbieten gar nicht.

                          Wie dedlfix schon anmerkte: wieso etwas verbieten, was technisch nicht notwendig ist?

                          Heraus kam, man staune:

                          ...zu 100% unsichere Passwörter. Klar machen sich die meisten Leute da keine Gedanken darüber, aber sollte man es deswegen zum Standard erheben?

                          Gruß,

                          Harlequin

                          --
                          RIP --- XHTML 2
                          nur die Besten sterben jung
                2. Hi,

                  // Wir haben $_POST['password'] nicht geprueft, es koennte also alles darin
                  // stehen, was der User will.

                  und code:
                  $_POST['password'] = "' OR ''='";

                  Solche Eingaben erlaube ich ja schon per php-script nicht. Das eingegebene Passwort durchläuft zuerst "ctype_alnum", bei der Registrierung als auch beim Einloggen. Alles, was nicht Buchstabe und Zahl ist, führt zu einer Fehlermeldung. Und Zeichen wie Semikolon, Komma, Leerstellen usw. haben weder in einem Passwort noch in einem Nicknamen was zu suchen.

                  autsch, böses Foul. Ganz im Gegenteil, es wird häufig *wärmstens empfohlen*, nicht nur Buchstaben und Ziffern[1] im Passwort zu verwenden, sondern eben auch Sonderzeichen, die noch schwerer zu erraten sind.

                  Im Nicknamen ist lediglich der Unterstrich erlaubt

                  Auch das ist eine Einschränkung, die ich nicht akzeptieren mag. Damit schließt du Nicks wie "Dr. No" oder "Daddy's Darling" aus, ebenso wie "Hans-Peter". Und das waren jetzt noch nicht mal besonders ausgefallene Beispiele.

                  in Emails darüber hinaus das Minuszeichen (Bindestrich), Punkt und Klammeraffe. Ich habe noch nie eine Email gesehen die da lautet: vorname,nachname@gmx.de

                  Das mag selten sein, aber in Mailadressen sind sehr viele Zeichen erlaubt, die du als ungültig abweisen würdest - zumindest im Local-Part. Im Hostnamen ... naja, kommt drauf an, ob man Mailadressen unter IDN-Domains in menschenlesbarer Form notieren möchte, oder Punycode erzwingt.

                  Jetzt frage ich mich, wozu also zusätzlich mysql_real_escape_string() ?

                  Um sich diesen Sicherheitsaspekt *anzugewöhnen*, damit man das bei anderer Gelegenheit, wo es eher nötig ist, schon reflexartig einsetzt. Und um Hintertürchen zuzumachen, die man vielleicht trotz aller Prüferei übersehen hat.

                  Ciao,
                   Martin

                  --
                  Man ist so alt, wie man sich fühlt.
                  Aber niemals so wichtig.
                  Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
                  1. Hallo Martin,

                    ich muss mich zunächst selbst bezüglich der Emails korrigieren! Habe nochmal im Skript nachgeschaut und da wird das Emailformat lediglich auf "@" und ".", also gültiges Format, geprüft. Was vor dem "@" kommt, bleibt jedem selbst überlassen. Sonderzeichen dort zu verbieten, war meine ursprüngliche Idee, von der ich aber abgewichen bin, da die Email eh nie in einer Abfrage a la "...where email =...." auftaucht.

                    Sorry.

                    An den anderen Formaten halte ich aber fest. Nicknamen wie "Dr. No" lassen sich auch mit "Dr_No" realisieren.

                    Nochmals dankeschön an alle!
                    Gruss
                    Thorsten

                    1. Mahlzeit treziman,

                      Sonderzeichen dort zu verbieten, war meine ursprüngliche Idee, von der ich aber abgewichen bin, da die Email eh nie in einer Abfrage a la "...where email =...." auftaucht.

                      Was aber beim Beachten des Kontextwechsels kein Problem wäre.

                      An den anderen Formaten halte ich aber fest. Nicknamen wie "Dr. No" lassen sich auch mit "Dr_No" realisieren.

                      Aber warum sollte man das erzwingen? Warum hältst Du so zwanghaft an Deiner künstlichen und überzogenen Einschränkung der Eingabemöglichkeiten für Deine Benutzer fest?

                      Wenn ich Dich richtig verstanden habe, geht es Dir darum, Dein System "sicher" zu halten und "keine SQL-Injections zu riskieren"? Richtig?

                      Dazu ist *NICHTS* weiter nötig, als *ALLE* Kontextwechsel sauber zu beachten. Es ist *KEINESWEGS* erforderlich, Nutzdaten zu manipulieren oder Benutzer zu zwingen, sich einer falschen "Sicherheitsphilosophie" zu unterwerfen.

                      MfG,
                      EKKi

                      --
                      sh:( fo:| ch:? rl:( br:> n4:~ ie:% mo:} va:) de:] zu:) fl:{ ss:) ls:& js:|
                3. Hi,

                  Alles, was nicht Buchstabe und Zahl ist, führt zu einer Fehlermeldung.

                  ist á für Dich ein Buchstabe? Oder Б oder Ø oder Γ oder ﺺ oder ... (Kyrillisch, dänisch, griechisch, arabisch, ...)

                  Und Zeichen wie Semikolon, Komma, Leerstellen usw. haben weder in einem Passwort noch in einem Nicknamen was zu suchen. Meine Meinung. Im Nicknamen ist lediglich der Unterstrich erlaubt,

                  D.h., daß normale Namen bei Dir als Nicknames nicht zugelassen sind - z.B. sowas wie O'Sullivan ...

                  Und das nur, weil Du nicht bereit bist oder Dich nicht in der Lage siehst, mit Kontext-Wechseln vernünftig umzugehen?

                  cu,
                  Andreas

                  --
                  Warum nennt sich Andreas hier MudGuard?
                  O o ostern ...
                  Fachfragen per Mail sind frech, werden ignoriert. Das Forum existiert.
          3. Hi,

            Ein Mitglied loggt sicht ein und surft nun im Mitgliederbereich, meinetwegen auf der Unterseite "angebote.php", auf welcher eben Angebote und Einkaufspreise angezeigt werden.

            Das Mitglied erwartet also den selben Inhalt, wenn er erneut diese gebookmarkte Seite aufruft.

            Einen Tag später will es über diesen Bookmark auf diese Seite zugreifen (ohne eingeloggt zu sein). Und JETZT soll eine Umleitung auf die index.php (Startseite) stattfinden,

            Das wird dann wohl genau der Zeitpunkt sein, in dem sich der Kunde überlegt, ob es nicht vergleichbare Angebote gibt, bei denen er seine Bookmarks auch tatsächlich nutzen kann.

            wo sich das Loginmodul befindet.

            Ich dachte, das gäbe es auf jeder Seite?!

            Wenn ich das mit htaccess realisieren kann, wäre super und spart ne Menge Programmieraufwand.

            »»
            Wie schon von anderen gesagt: Das willst du nicht (bzw. solltest du nicht wollen)

            So habe ich es mir auch vorgestellt. Sähe also so aus: z.B.
            Ordner "domain" = DocumentRoot; Inhalt: index.html
            Ordner "mitglieder" = kein Zugang über HTTP; Inhalt: angebot.php

            Dass es so nicht finktioniert, wurde ja schon gesagt. Aber nochmal etwas anderes zu deiner Ordner/Datei-Struktur.

            Ordner kannst du machen, wie du das für richtig hälst. Über htaccess, was du ja unbedingt nutzen magst ;), kannst du auch so tun als hättest du Ordner bzw. du kannst so tun als hättest du keine. (Damit meine ich, du kann ModRewrite nutzen und die URLs umschreiben lassen. Wenn der User www.example.com/Angebote aufruft, wird er z.B. im Hintergrund auf das Skript im Ordner /Mitgliederbereich/Angebote/übersicht.php geleitet)

            Egal wie du es machst: Du brauchst in jedem Skript, welches über HTTP angesteuert werden kann eine Rechteüberprüfung. Das sind wenige Zeilen Code, die viel nützen.

            Ich habe z.B. eine Funktion check_rechte($min_rechte), die ich immer dann aufrufe, wenn der User ein bestimmtes Rechtelevel braucht. Da trage ich dann ein, dass er das Level 2 z.B. braucht um den Inhalt zu sehen. Dieser Inhalt steht dann da wenn check_rechte(2) true ist. Wenn es false ist, steht entweder nur der Hinweis, dass der User sich einloggen soll (das Loginformular ist dann immer links auf der Seite und führt auch wieder genau auf diese Seite) oder er sieht eben einen anderen Inhalt, den dann jeder sehen darf. (z.B. in einem Forum, wenn check_rechte(1) true ist, sieht der User einen Antworten-Button - ansonsten sieht er nur einen Hinweis, dass er sich registrieren muss, um antworten zu können...)

            Gruß
            Alex

    3. und gerade Sonderzeichen zu verbieten ist das Übelste, was man bei Passwörtern machen kann.

      Einiges Überlegen bringt mich auf die Tatsache, dass Interoperabilität und Zeichenencoding-Wechsel nur bei Identitätsfeldern gewährleistet ist, die Ihre Zeichenklasse nahe auf die Base_64 Zeichenklasse beschränken.

      Man kann natürlich mehr erlauben, mit so überraschenden Nebenwirkungen wie dem permanenten oder gelegentlichen Herauswurf von ganzen Benutzergruppen.

      Es ist zwar legitim, bei Passworten beliebige Bytefolgen zu erwarten. Die Legitimität wird aber in Frage gestellt, weil die Methoden zur Eingabe dieser Bytefolgen nicht garantiert sein können.

      Für Passworte gibt es nur eine Sicherheit: Lange Passworte und entsprechend verschlüsselte Übertragungswege.

      mfg Beat

      --
      ><o(((°>           ><o(((°>
         <°)))o><                     ><o(((°>o
      Der Valigator leibt diese Fische
      1. Hallo,

        und gerade Sonderzeichen zu verbieten ist das Übelste, was man bei Passwörtern machen kann.
        Einiges Überlegen bringt mich auf die Tatsache, dass Interoperabilität und Zeichenencoding-Wechsel nur bei Identitätsfeldern gewährleistet ist, die Ihre Zeichenklasse nahe auf die Base_64 Zeichenklasse beschränken.

        ja, wir sollten klären, was wir in diesem Kontext unter "Sonderzeichen" verstehen. Vermutlich hat Cheatah den Begriff hier sehr eng gefasst und zählt auch Interpunktionszeichen und ähnliches schon zu den Sonderzeichen.
        Bei der Festlegung und Eingabe von Passwörtern erwarte ich, dass zumindest mal der vollständige Bereich der druckbaren ASCII-Zeichen (0x20 .. 0x7E) zulässig ist. Diese Zeichen sollten auch auf allen Systemen mehr oder weniger einfach einzugeben sein.

        Über ASCII hinausgehende Zeichen sind tatsächlich potentiell problematisch. Das fängt bei der Eingabe an, die nicht immer trivial ist (wie gebe ich ein ö auf einer US-Tastatur ein?) und zieht sich bis hin zu Übermittlungsfehlern durch Fehler bei der Zeichencodierung.

        So long,
         Martin

        --
        Ja, ja ... E.T. wusste schon, warum er wieder nach Hause wollte.
        Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(