Nogga: Internationale Zeichensätze validieren mit REGEX

Hallo zusammen,

ich bin gerade an einer internationalen Applikation, die ich in PHP realisiere.

In dieser habe ich nun auch ein Namens-Feld, das in eine Datenbank geschrieben werden soll. Auch Sicherheitsgründen möchte ich natürlich zunächst mal nur sichere Eingaben haben und filtere für den Namen entsprechend alles ausser Buchstaben heraus. Mit Umlauten und Bindestrichen mag das ja auch noch entsprechend funktionieren.

Aber wie realisiere ich das am Besten für mich gänzlich unbekannte Sprachen wie Japanisch oder Chinesisch? Französisch oder Spanisch würde ich noch umsetzen können, aber bei ersteren zweien habe ich keine Lösung.

Ideen Eurerseits? Vielleicht gegen eine Range checken, aber wie am Besten?

Danke Euch vielmals!
Alex

  1. Hi,

    In dieser habe ich nun auch ein Namens-Feld, das in eine Datenbank geschrieben werden soll. Auch Sicherheitsgründen möchte ich natürlich zunächst mal nur sichere Eingaben haben und filtere für den Namen entsprechend alles ausser Buchstaben heraus.

    Welchen Gewinn an Sicherheit versprichst du dir davon?

    MfG ChrisB

    --
    „This is the author's opinion, not necessarily that of Starbucks.“
    1. Moin!

      In dieser habe ich nun auch ein Namens-Feld, das in eine Datenbank geschrieben werden soll. Auch Sicherheitsgründen möchte ich natürlich zunächst mal nur sichere Eingaben haben und filtere für den Namen entsprechend alles ausser Buchstaben heraus.

      Welchen Gewinn an Sicherheit versprichst du dir davon?

      Diese Frage möchte insbesondere erstmal für den einfach überschaubaren Normalfall "deutsche Sprache und auf deutschen Tastaturen auffindbare Sonderzeichen" beantwortet werden, sprich: Welche Zeichen würden einem spontan einfallen, "böse" zu sein, so dass man sie herausfiltern wollen würde?

      - Sven Rautenberg

      --
      "Love your nation - respect the others."
      1. Hallo,

        so gesehen habt Ihr ja eigentlich recht. Vielleicht sollte ich es umformulieren: Welche Zeichen machen Sinn? Nicht, dass plötzlich ein Name mit Buchstaben - zwar aus dem Alphabet, aber nicht wirklich sinn-ergebend - eingegeben wird.

        Aber angesichts der schier unüberschaubaren Menge an möglichen (und sinnvollen) Zeichen, insbesondere, wenn man den ausländischen Teil dazurechnet, lasse ich das lieber und beschränke mich auf die Filterung von bösen Zeichenketten (gegen XSS/SQL Injection Attacken).

        Vielen Dank
        Alex

        1. Hi Nogga!

          Aber angesichts der schier unüberschaubaren Menge an möglichen (und sinnvollen) Zeichen, insbesondere, wenn man den ausländischen Teil dazurechnet, lasse ich das lieber und beschränke mich auf die Filterung von bösen Zeichenketten (gegen XSS/SQL Injection Attacken).

          Du solltest dich lieber auf die Maskierung dieser Daten beschränken.

          MfG H☼psel

          --
          "It's amazing I won. I was running against peace, prosperity, and incumbency."
          George W. Bush speaking to Swedish Prime Minister unaware a live television camera was still rolling, June 14, 2001
          Selfcode: ie:% fl:( br:> va:) ls:& fo:) rl:? n4:& ss:| de:] js:| ch:? sh:( mo:) zu:)
        2. Hallo,

          wie hospel schon sagt: maskiere die daten kontextgerecht

          so gesehen habt Ihr ja eigentlich recht. Vielleicht sollte ich es umformulieren: Welche Zeichen machen Sinn? Nicht, dass plötzlich ein Name mit Buchstaben - zwar aus dem Alphabet, aber nicht wirklich sinn-ergebend - eingegeben wird.

          was ist, wenn jemand "岩 Franz N'xi <Z0nk" heisst? es hat überhaupt keinen sinn, irgendwelche zeichen auszufiltern, ausser du bist sicher, dass sie auszufiltern sind

          ebenso ist es sinnlos ein eingabefeld auf "ziffern" zu beschränken:
          die eingabe "Ⅷ", "VIII", "8", "acht", "आठ" oder "θ" kann richtig sein

          lasse ich das lieber und beschränke mich auf die Filterung von bösen Zeichenketten (gegen XSS/SQL Injection Attacken).

          es gibt keine bösen zeichenketten - ledlich eine falsche maskierung dieser

          die eingabe "DELETE * FROM posts;" entfernt auch noch lange nicht alle daten aus dem forum ;)

          1. Moin!

            die eingabe "DELETE * FROM posts;" entfernt auch noch lange nicht alle daten aus dem forum ;)

            Oh, da haben wir ja Glück, dass das Forum keine SQL-Datenbank benutzt... ;)

            - Sven Rautenberg

            --
            "Love your nation - respect the others."
            1. Oh, da haben wir ja Glück, dass das Forum keine SQL-Datenbank benutzt... ;)

              rein interessenhalber, was wird dann benutzt? sag jetzt nicht "domino" ;)

              1. rein interessenhalber, was wird dann benutzt? sag jetzt nicht "domino" ;)

                Eine Datei. Wusstest du nicht? Wird brav gecached und dir zum Vergnügen übermittelt.[1]

                Grüße, Matze

                [1] im Fall dass ich mich irre, nehm ich alles zurück und behaupte das Gegenteil.

                1. Eine Datei. Wusstest du nicht? Wird brav gecached und dir zum Vergnügen übermittelt.[1]

                  jaja, auch eine sql-datenbank legt die daten in einer "datei" ab :p

                  1. Hallo

                    Eine Datei. Wusstest du nicht? Wird brav gecached und dir zum Vergnügen übermittelt.[1]

                    jaja, auch eine sql-datenbank legt die daten in einer "datei" ab :p

                    Hier ist es XML. :-)

                    Tschö, Auge

                    --
                    Die deutschen Interessen werden am Liechtenstein verteidigt.
                    Veranstaltungsdatenbank Vdb 0.2
              2. Hallo,

                Oh, da haben wir ja Glück, dass das Forum keine SQL-Datenbank benutzt... ;)

                rein interessenhalber, was wird dann benutzt? sag jetzt nicht "domino" ;)

                Die Postings werden in einer Datenstruktur im RAM gehalten (im Endeffekt eine flache Liste pro Thread, bei der zusätzlich die Einrücktiefe gespeichert wird, damit man einen Baum abbilden kann) und als Backup alle paar Minuten als XML-Dateien auf die Festplatte gespeichert (dort dann allerdings als richtiger Baum). Alle archivierten Postings sind nur als XML-Dateien vorhanden und die HTML-Ausgabe des Archivs wird zusätzlich noch gecached.

                Viele Grüße,
                Christian

                1. Die Postings werden in einer Datenstruktur im RAM gehalten (im Endeffekt eine flache Liste pro Thread, bei der zusätzlich die Einrücktiefe gespeichert wird, damit man einen Baum abbilden kann) und als Backup alle paar Minuten als XML-Dateien auf die Festplatte gespeichert (dort dann allerdings als richtiger Baum). Alle archivierten Postings sind nur als XML-Dateien vorhanden und die HTML-Ausgabe des Archivs wird zusätzlich noch gecached.

                  interessant :) aber ist das nicht beim durchsuchen des archivs schwerfälliger als das durchsuchen einer relationalen datenbank?

                  1. Hallo,

                    interessant :) aber ist das nicht beim durchsuchen des archivs schwerfälliger als das durchsuchen einer relationalen datenbank?

                    Es gibt für die Suche einen separaten Index. Genauso, wie bei relationalen Datenbanken ja auch nicht ein Full Table Scan beim Suchen gemacht würde, sondern auf einen separaten Index zugegriffen würde. Nur, dass ein RDBMS diese Funktionalität bereits integriert hat und sie hier extra ist.

                    Viele Grüße,
                    Christian

                    1. Nur, dass ein RDBMS diese Funktionalität bereits integriert hat und sie hier extra ist.

                      ist mit "extra" gemeint, dass es dafür fertige "ich simuliere mit xml-files eine datebank"-schnittstellen gibt, oder ist das alles eine eingene lösung?

                      1. Hallo,

                        Nur, dass ein RDBMS diese Funktionalität bereits integriert hat und sie hier extra ist.

                        ist mit "extra" gemeint, dass es dafür fertige "ich simuliere mit xml-files eine datebank"-schnittstellen gibt, oder ist das alles eine eingene lösung?

                        Du denkst viel zu relational. ;-)

                        Stell Dir nun einmal vor, Du hast 1000 Adressdatensätze. Wenn Du die auf der Festplatte abspeicherst, dann müssen die ja irgendwie hintereinander gespeichert werden (in welchem exakten Format auch immer) - egal ob nun von einer Datenbank oder nicht. Die Idee ist nun: Wenn Sie hintereinander gespeichert werden, dann müsste man, um zum Beispiel nach einem bestimmten Nachnamen zu suchen, alle Datensätze hintereinander durchgehen - und das dauert halt seine Zeit, bis man 1000 Datensätze durchsucht hat.

                        Wenn man jetzt aber zum Beispiel *zusätzlich* zu den eigentlichen Daten noch einen Index - im einfachsten Fall zum Beispiel einen binären Baum (in der Realität werden meist etwas kompliziertere Datenstrukturen genutzt), dann könnte man sich z.B. sowas aufbauen (jetzt mal nur ein Ausschnitt):

                        +--------------+
                                          | McKinley: 25 |
                                          +--------------+
                                           /            \                   /              \        +-------------+          +----------+
                               | Kennedy: 35 |          | Taft: 27 |
                               +-------------+          +----------+
                                 /      \                 /       \         /        \               /         \ +----------+ +------------+ +-----------+ +---------------+
                        | Adams: 2 | | Licoln: 16 | | Nixon: 37 | | Washington: 1 |
                        +----------+ +------------+ +-----------+ +---------------+

                        Im binären Baum würden dann die Informationen "Nachname" und "Position in den realen Daten" gespeichert werden (das ist hier die Nummer). Wenn man dann nach einem Nachnamen sucht, dann macht man z.B. folgendes:

                        Suche Adresse von "Nixon":

                        * Vergleiche mit oberstem Knoten im Index (McKinley)
                                 -> Kommt später im Alphabet
                                 -> Ein Knoten nach Rechts
                          * Vergleiche mit aktuellem Knoten (Taft)
                                 -> Kommt früher im Alphabet
                                 -> Ein Knoten nach Links
                          * Vergleiche mit aktuellem Knoten (Nixon)
                                 -> Gefunden!
                          * Suche Datensatz nummer 37 aus den eigentlichen Daten heraus

                        Beachte, dass die Zahl nicht unbedingt eine fortlaufende Datensatznummer sein muss (wie hier in diesem einfachen Beispiel), sondern durchaus z.B. ein Offset in einer großen Datei sein kann (soundsoviel Bytes ab Begin der Datei), wo halt der Datensatz anfängt.

                        So funktionieren Indizes im Allgemeinen. Wenn man es mit Laufzeitkomplexitätsklassen ausdrücken will, brauchen Indizes bei n Datensätzen nur log(n) Vergleiche, um zum Ziel zu kommen (bei 1000 wären das z.B. 10, bei 1000000 wären es 20, bei 1000000000 wären es 30, etc.), während man ohne Index n Vergleiche durchführen muss (bei 1000 wären es also weiterhin 1000, bei 1000000 wären es 1000000, etc.).

                        Wenn Du eine relationale Datenbank hast, dann liefert die einen Indexmechanismus gleich mit, d.h. wenn Du sowas machst wie

                        CREATE INDEX name_des_indizes ON tabelle (spalte);

                        dann führt ein

                        SELECT * FROM tabelle WHERE spalte = 42;

                        automatisch zur Verwendung des Indizes, d.h. Du musst Dich um nichts mehr kümmern.

                        Wie ich oben allerdings dargelegt habe, sind Datenbanken mit Sicherheit nicht diejenigen, die Indizes erfunden haben. Sie nutzen sie nur. Man kann so einen Index (man muss ihn halt geeignet abspeichern) auch relativ problemlos selbst verwenden. Es wäre absoluter Blödsinn, für sowas eine Emulationsschicht für ein RDBMS zu verwenden, das im Hintergrund die XML-Dateien verwendet, wenn wir sowieso schon alles als XML zur Verfügung haben. Deswegen auch die ausführliche Antwort auf Deine Frage, Du scheinst nämlich nicht verstanden gehabt zu haben, dass relationale Datenbanken in der Datenhaltung nicht ein Monopol haben. Sie spielen eine wichtige Rolle, es gibt aber sehr viele Awnendungen (zum Beispiel Dein Dateisystem - ist ja auch ein Datenhaltungssystem ;-)), die keine *relationale* Datenbank im Hintergrund verwenden, die jedoch oftmals auf ähnliche Konzepte zurückgreifen.

                        So, und nachdem ich das alles erzählt habe, wie sowas im Idealfall funktioniert, darf ich Dir die Illusionen gleich mal wieder kaputt machen: Wir bei SELFHTML verwenden aktuell noch eine Suche, die in Perl geschrieben wurde, die nichts anderes macht, als eine *reisige* Textdatei (unser "Index", aber halt kein Baum wie oben, sondern ein linearer Index) zeilenweise einzulesen und jede Zeile mit dem Suchbegriffen zu vergleichen (jede Zeile ist ein Posting, dessen Text um bestimmte Sonderzeichen wie Neue-Zeile-Zeichen bereinigt wurde) und dann die entsprechenden Postings auszuspucken. Das ist natürlich bei der Menge an Postings sehr ineffiizent und deswegen verstehst Du jetzt hoffentlich auch, warum die Suche bei uns gerne mal 10 Sekunden braucht, *obwohl* wir sauschnelle und nichtausgelastete Hardware hier haben. Dass die Suche trotz des Designs immer noch so schnell ist, zeigt eigentlich, dass die Hardware sehr gut ist. ;-)

                        Allerdings kann ich Dich beruhigen: Wir hatten vor einiger Zeit uns darum bemüht, jemanden zu finden, der die Suche bei uns neu entwickelt. Es hat sich dankenswerterweise jemand gefunden (Jens Krämer), der inzwischen eine neue Suchfunktion auf Basis von Ferret/Stellr (Ruby) entwickelt hat. Ferret ist das Ruby-Äquivalent von Lucene, was ein Framework für Volltextsuchanwendungen darstellt und darauf abgestimmte Indexstrukturen bietet. Da wollten wir im Prinzip schon vor Ewigkeiten einen öffentlichen Betatest machen, dass das bisher noch nicht stattgefunden hat, liegt an mir, wie ich zugeben muss.

                        Viele Grüße,
                        Christian

                        1. Du denkst viel zu relational. ;-)

                          ja, manchmal :D

                          [...]

                          sag doch gleich, dass das so ähnlich funktioniert wie binary space partitioning - das prinzip dahinter ist mir bekannt, wusste allerdings nicht (bzw hatte es nie in betracht gezogen) dass man es auch für die ablage von daten (wie in deinem beispiel adressen) nutzen kann

                          danke jedenfalls für die ausführliche erklärung :)

                          So, und nachdem ich das alles erzählt habe, wie sowas im Idealfall funktioniert, darf ich Dir die Illusionen gleich mal wieder kaputt machen: Wir bei SELFHTML verwenden aktuell noch eine Suche, die in Perl geschrieben wurde, die nichts anderes macht, als eine *reisige* Textdatei (unser "Index", aber halt kein Baum wie oben, sondern ein linearer Index) zeilenweise einzulesen und jede Zeile mit dem Suchbegriffen zu vergleichen (jede Zeile ist ein Posting, dessen Text um bestimmte Sonderzeichen wie Neue-Zeile-Zeichen bereinigt wurde) und dann die entsprechenden Postings auszuspucken. Das ist natürlich bei der Menge an Postings sehr ineffiizent und deswegen verstehst Du jetzt hoffentlich auch, warum die Suche bei uns gerne mal 10 Sekunden braucht, *obwohl* wir sauschnelle und nichtausgelastete Hardware hier haben. Dass die Suche trotz des Designs immer noch so schnell ist, zeigt eigentlich, dass die Hardware sehr gut ist. ;-)

                          das ist eigentlich das was ich wissen wollte ;)

                          1. Hallo,

                            [...]
                            sag doch gleich, dass das so ähnlich funktioniert wie binary space partitioning

                            Diese Anwendung von binären Bäumen kannte ich dagegen nicht.

                            Viele Grüße,
                            Christian

                            1. Diese Anwendung von binären Bäumen kannte ich dagegen nicht.

                              wobei man heutzutage eher bäume zur einteilung 2- oder 3-dimensionaler räume verwendet - sprich 4 oder 8 kinder pro knoten

                              diese dinger sind echt effizent und es gibt echt coole beispiele dafür:
                              http://www-evasion.imag.fr/Membres/Sylvain.Lefebvre/pict1.png

                              soweit ich weiss nutzen viele moderne 3d-kopierer derartige datenmodelle um die struktur des zu reproduzierenden objekts zu speichern

                        2. Hallo Christian,

                          Allerdings kann ich Dich beruhigen: Wir hatten vor einiger Zeit uns darum bemüht, jemanden zu finden, der die Suche bei uns neu entwickelt.

                          Hups? Was ist denn aus Danielas Suche geworden? Die damalige nicht-öffentliche Beta funktionierte doch ganz gut.

                          Tim

                          1. Moin!

                            Allerdings kann ich Dich beruhigen: Wir hatten vor einiger Zeit uns darum bemüht, jemanden zu finden, der die Suche bei uns neu entwickelt.

                            Hups? Was ist denn aus Danielas Suche geworden? Die damalige nicht-öffentliche Beta funktionierte doch ganz gut.

                            Die Suche war nicht fertig, enthielt nach meiner Kenntnis noch bekannte Bugs, und fiel in diesem Zustand mangelnder Motivation und Desinteresse zum Opfer.

                            - Sven Rautenberg

                            --
                            "Love your nation - respect the others."
  2. Auch Sicherheitsgründen möchte ich natürlich zunächst mal nur sichere Eingaben haben und filtere für den Namen entsprechend alles ausser Buchstaben heraus.

    Und was ist mit Dr.Oetker? Dipl.Ing. und den ganzen anderen Titeln?
    So eine Prüfung ist ziemlich unsinnig und hat nichts mit Sicherheit zu tun.

    Grüße, Matze