Alex: FireBug, das perfekte Manipulations-Tool bei HTML & JavaScript ?

Hallo, ich arbeite gerade an einem Online-Shop für einen Mandanten.
Dabei ist mir aufgefallen das man die JS-Validierung (oder was auch immer) ganz einfach außer Kraft setzten kann.

Beispiel:

html<form action="xyz" method="post" ... onSumbit="return validateTheForm(this)">

im FireBug kann man den "onSubmit-Befehl" außer kraft setzten, und der Validierung entgehen. Das gleiche lässt sich (leider) auch bei Kreditkarten-Validierung einsetzen (JavaScript-Validierung).

Ist es eine große Lücke im FireBug oder wie soll ich das ganze verstehen?

  1. Merhaba!

    html<form action="xyz" method="post" ... onSumbit="return validateTheForm(this)">

    im FireBug kann man den "onSubmit-Befehl" außer kraft setzten, und der Validierung entgehen. Das gleiche lässt sich (leider) auch bei Kreditkarten-Validierung einsetzen (JavaScript-Validierung).

    Ist es eine große Lücke im FireBug oder wie soll ich das ganze verstehen?

    Nein, Firebug macht es nur bequemer. Leute ohne Firebug können die Seite abespeichern, die betreffende Änderung mit dem Texteditor vornehmen und das Formular dann aus der veränderten Version abschicken.
    Und dann gibt es noch Leute, die NoScript benutzen (ich möchte nie mehr ohne surfen) oder Javascript einfach so ausschalten.

    Du bist auf einem Umweg auf die Tatsache gestoßen, daß ausschließlich clientseitige Validierung generell keine gute Idee ist. ;-)

    Viele Grüße vom Længlich

    --
    Mein aktueller Gruß ist:
    Türkisch
    1. Nein, Firebug macht es nur bequemer. Leute ohne Firebug können die Seite abespeichern, die betreffende Änderung mit dem Texteditor vornehmen und das Formular dann aus der veränderten Version abschicken.

      Nein!
      Das Perl-Dokument das die Daten empfängt prüft auf Referer, stimmt der nicht, wird der Zugang verweigert.

      Und dann gibt es noch Leute, die NoScript benutzen (ich möchte nie mehr ohne surfen) oder Javascript einfach so ausschalten.

      Mit ausgeschaltetem JS funktioniert der Shop nicht. Daher kommt man erst garnicht in den Bereich wo die Validierung stattfindet (Warenkorb).

      Du bist auf einem Umweg auf die Tatsache gestoßen, daß ausschließlich clientseitige Validierung generell keine gute Idee ist. ;-)

      Ja, danke :)

      1. Hello,

        Das Perl-Dokument das die Daten empfängt prüft auf Referer, stimmt der nicht, wird der Zugang verweigert.

        cool, unbenutzbare Anwendung für mein privates und mein Firmennetzwerk, hier wird der Referer aus dem Request gelöscht.

        MfG
        Rouven

        --
        -------------------
        sh:| fo:} ch:? rl:( br:& n4:{ ie:| mo:} va:) js:| de:] zu:| fl:( ss:) ls:& (SelfCode)
        Computer programming is tremendous fun. Like music, it is a skill that derives from an unknown blend of innate talent and constant practice. Like drawing, it can be shaped to a variety of ends: commercial, artistic, and pure entertainment. Programmers have a well-deserved reputation for working long hours but are rarely credited with being driven by creative fevers. Programmers talk about software development on weekends, vacations, and over meals not because they lack imagination, but because their imagination reveals worlds that others cannot see. -- Larry OBrien and Bruce Eckel in Thinking in C#
      2. Nein, Firebug macht es nur bequemer. Leute ohne Firebug können die Seite abespeichern, die betreffende Änderung mit dem Texteditor vornehmen und das Formular dann aus der veränderten Version abschicken.
        Nein!

        Doch!

        Das Perl-Dokument das die Daten empfängt prüft auf Referer, stimmt der nicht, wird der Zugang verweigert.

        Formulardaten, Referrer usw. lassen sich beliebig fälschen. Wenn ich Unsinn an deinen Shop senden will und z.B. tausende Bestellungen erzeugen will, dann ist das auch möglich, weder JavaScript noch Referrer-Prüfungen hindern mich daran, sie erschweres es nur minimal.

        Solche Pseudo-Sichherheitsüberprüfungen gehen nur nach hinten los, denn zuverlässig sind sie nicht.

        Mathias

        1. Doch!

          Nein!

          Formulardaten, Referrer usw. lassen sich beliebig fälschen. Wenn ich Unsinn an deinen Shop senden will und z.B. tausende Bestellungen erzeugen will, dann ist das auch möglich, weder JavaScript noch Referrer-Prüfungen hindern mich daran, sie erschweres es nur minimal.

          Du verstehst mich nicht.
          Wenn du eine Anfrage an die Perl sendest, was auch immer (...) dann wird dir die Perl den Zugang verweigern wenn du nicht von der (den) Domain kommst, von der das Script die Daten empfangen DARF!
          Sprich wenn der Shop auf www.xyz.de liegt, dann kannst du keine Anfragen von www.xyzz.de oder www.zxy.de oder localhost zusenden. ZUGANG WIRD VERWEIGERT!
          Und ohne die die Zugangsdaten zu dem Server, kannst du auch keine veränderungen am Perl vornehmen, ja né ist klar :)

          1. Mahlzeit

            Du verstehst mich nicht.

            Du verstehst Matthias nicht. Ursache: Dir mangelt es an grundlegendem Wissen.

            Sprich wenn der Shop auf www.xyz.de liegt, dann kannst du keine Anfragen von www.xyzz.de oder www.zxy.de oder localhost zusenden. ZUGANG WIRD VERWEIGERT!
            Und ohne die die Zugangsdaten zu dem Server, kannst du auch keine veränderungen am Perl vornehmen, ja né ist klar :)

            Irrelevant. Die Information "Anfragen von www.xyzz.de oder www.zxy.de" sendet der Client und ist beliebig manipulierbar.

            Grüße

            1. Du verstehst mich nicht.
              Du verstehst Matthias nicht. Ursache: Dir mangelt es an grundlegendem Wissen.

              Mag sein, bin noch jung und habe alles noch vor mir ;)

              Und ohne die die Zugangsdaten zu dem Server, kannst du auch keine veränderungen am Perl vornehmen, ja né ist klar :)
              Irrelevant. Die Information "Anfragen von www.xyzz.de oder www.zxy.de" sendet der Client und ist beliebig manipulierbar.

              NEIN! Eben nicht! Kann sein dass ich mich hier falsch Ausgedrückt habe.
              Es ist nicht möglich, habe ich bereits selber probiert.
              Wenn die Anfrage nicht von der Damain kommt, die auf der Liste steht, wird NIX gemacht. Basta!

              1. Yerf!

                Wenn die Anfrage nicht von der Damain kommt, die auf der Liste steht, wird NIX gemacht. Basta!

                Das heißt, bevor ich bei euch etwas bestellen kann muss ich mir erst eine Domain registrieren die auf deiner Liste steht und dann auf dem Server dem diese Domain zugeordnet ist den Browser starten, damit die Anfrage *von dieser Domain* kommt?

                ...und wenn dir diese Aussage lächerlich und blöd vorkommt, das beruht auf Gegenseitigkeit.

                Dir ist scheinbar nicht klar, was man alles an Requests manipulieren kann. Um es einfach zu sagen: es gibt nichts, das man nicht manipulieren kann. Hol dir mal den Fiddler2 (Proxy), damit kannst du Requests mitprotokolieren, analysieren und modifizieren... viel Spaß ;-)

                Gruß,

                Harlequin

                --
                <!--[if IE]>This page is best viewed with a webbrowser. Get one today!<![endif]-->
                1. Das heißt, bevor ich bei euch etwas bestellen kann muss ich mir erst eine Domain registrieren die auf deiner Liste steht und dann auf dem Server dem diese Domain zugeordnet ist den Browser starten, damit die Anfrage *von dieser Domain* kommt?

                  ...und wenn dir diese Aussage lächerlich und blöd vorkommt, das beruht auf Gegenseitigkeit.

                  Ja das tut sie :)
                  Ich habe bereits eingesehen das ich unrecht hatte. Ich hatte keine Ahnung was alles dahinter steckt und welche Möglichkeiten man heut zutage hat.

                  Dir ist scheinbar nicht klar, was man alles an Requests manipulieren kann. Um es einfach zu sagen: es gibt nichts, das man nicht manipulieren kann. Hol dir mal den Fiddler2 (Proxy), damit kannst du Requests mitprotokolieren, analysieren und modifizieren... viel Spaß ;-)

                  Danke für den Tipp, werde mir mal das näher ansehen.

              2. Es ist nicht möglich, habe ich bereits selber probiert.

                LOL

                Grüße

              3. NEIN! Basta!

                Es ist eine Sache, wenn man als Profi Dinge nicht kennt oder nicht beachtet. Man lernt nicht aus, muss aber auch bereit sein, den Hinweisen von anderen Fachleuten auf den Grund zu gehen. Es ist eine andere Sache, wenn man an einem großen Projekt arbeitet, es einem eklatant an Grundlagenwissen fehlt UND man sich stur und lernresistent stellt, wenn andere einem wertvolle Tipps geben. Das ist, sorry, einfach Pfusch am Bau. Ich kann nur hoffen, dass niemand die Sicherheitsmängel und Missbrauchsmöglichkeiten ausnutzt.

                Mathias

                1. [latex]Mae  govannen![/latex]

                  Es ist eine andere Sache, wenn man an einem großen Projekt arbeitet, es einem eklatant an Grundlagenwissen fehlt UND man sich stur und lernresistent stellt, wenn andere einem wertvolle Tipps geben. Das ist, sorry, einfach Pfusch am Bau. Ich kann nur hoffen, dass niemand die Sicherheitsmängel und Missbrauchsmöglichkeiten ausnutzt.

                  Ich weiß, ich bin wieder gemein, aber ich hoffe fast schon, *daß* jemand das ausnutzt und einen gewissen, aber nicht zu eklatanten Schaden anrichtet. Die Erfahrung zeigt, daß die kewlen "Das ist sicher, hab ich selber probiert.Basta"-Progger es nur auf diese Weise (-> auf die Schnauze fallen) lernen. Zumal ein Shop auf Javascript ohnehin ein Witz ist, wenn dieses nicht nur als Komfort-Funktionalität vor dem Server genutzt wird.

                  Cü,

                  Kai

                  --
                  Ash nazg durbatulûk, ash nazg gimbatul,ash nazg thrakatulûk, agh burzum-ishi krimpatul
                  selfcode sh:( fo:| ch:? rl:( br:< n4:# ie:{ mo:| va:) js:) de:> zu:) fl:( ss:| ls:?
                  Mein Selfhtml-Kram
                  1. Hey, zuspät.
                    Das System wird täglich ausgenutzt, ca. 10.000 EUR Schaden / Tag. Aber den Mandanten interessiert das nicht, da der Gewinn der erzielt wird, den Schaden in den Schatten stellt :) ... ist auch nicht mein Problem, ich mache das, was zu machen ist, nicht das was ich gerne machen würde (eine ordentliche validierung, und vorallem serverseitige-kommunikation).

                    Ja es ist ein Wizt, aber dieser Witz ist jeder 2te eShop in Internet.
                    Ich kann dir min. 10 Shops aufzählen, die Millionengewinne verzeichnen, und zu 70-80% auf JavaScript basieren. Witz? Ehr traurige realität.

                    1. Hallo,

                      Ich kann dir min. 10 Shops aufzählen, die Millionengewinne verzeichnen, und zu 70-80% auf JavaScript basieren.

                      bist du sicher, dass wir das gleiche meinen? - Ich nämlich nicht.

                      Ein Shopsystem, das ohne JS nicht bedienbar ist, würde ich zwar auch schon als Negativbeispiel sehen, aber das gibt es leider häufig. Die Frage ist aber: Werden "geschäftswichtige" Daten und Bedingungen ausschließlich clientseitig überprüft?
                      Viele Shops sind so aufgebaut, dass Javascript beim Client für eine reibungslose Bedienung des Frontends erforderlich ist, aber die wichtigen Vorgänge (Validitäts- und Plausibilitätschecks) finden serverseitig statt - eventuell nach einer clientseitigen Vorab-Prüfung, damit nicht unnötig Traffic generiert wird.

                      Bei deinem Beispiel habe ich aber den Eindruck, dass das Shopsystem Daten vom Client ohne serverseitige Überprüfung annimmt (bzw. es scheint nur Informationen zu prüfen, die per definitionem unzuverlässig sind) - auch wenn man dazu die Requests manipulieren müsste. Wenn das wirklich der Fall ist, unterscheidet sich "dein" Shop signifikant von den meisten eingesetzten Lösungen.

                      So long,
                       Martin

                      --
                      Man gewöhnt sich an allem, sogar am Dativ.
                      1. bist du sicher, dass wir das gleiche meinen? - Ich nämlich nicht.

                        Ich jetzt auch nicht mehr :)

                        Ein Shopsystem, das ohne JS nicht bedienbar ist, würde ich zwar auch schon als Negativbeispiel sehen, aber das gibt es leider häufig. Die Frage ist aber: Werden "geschäftswichtige" Daten und Bedingungen ausschließlich clientseitig überprüft?

                        Nicht nur!
                        JS wird bei uns (wie du schon erwähnt hast) im Frontends benutzt, aber auch bei der Übermittlung der relevanten Daten des Warenkorbes.
                        Den Abgleich mit der DB übermimmt eine exe (c++), da diese Methode am sichersten ist. Am sonsten läuft alles in Perl.

                        Viele Shops sind so aufgebaut, dass Javascript beim Client für eine reibungslose Bedienung des Frontends erforderlich ist, aber die wichtigen Vorgänge (Validitäts- und Plausibilitätschecks) finden serverseitig statt - eventuell nach einer clientseitigen Vorab-Prüfung, damit nicht unnötig Traffic generiert wird.

                        Genau das!

                        Bei deinem Beispiel habe ich aber den Eindruck, dass das Shopsystem Daten vom Client ohne serverseitige Überprüfung annimmt (bzw. es scheint nur Informationen zu prüfen, die per definitionem unzuverlässig sind) - auch wenn man dazu die Requests manipulieren müsste. Wenn das wirklich der Fall ist, unterscheidet sich "dein" Shop signifikant von den meisten eingesetzten Lösungen.

                        Jein!
                        Ich habe heute festgestellt das man Sachen bestellen kann, ohne die Adresse angeben zu müssen (eigentlich validiert das JS, die man aber mit FireBug austrixen kann), oder die Kreditkartendaten (spätestens beim Abbuchen, wird der Fehler entdeckt, und die Lieferung storniert).

                2. Danke!
                  Ihr hattet Recht, sicher ist es so nicht. Aber wie schon gesagt, ich habe keine Möglichkeiten den Shop sicherer zu machen. Die Auslastung der Mitarbeiter wäre zu gross, außerdem zu kostspielig.

                  PS: Das System wird ausgenutzt, ca. 10.000 EUR Schaden / Tag.
                  Ist aber ein Witz gegen den täglichen Gewinn des Mandanten, den es auch nicht weiterhin Interessiert, obwohl er es weiß.

              4. Hallo,

                Du verstehst mich nicht.
                Du verstehst Matthias nicht. Ursache: Dir mangelt es an grundlegendem Wissen.
                Mag sein, bin noch jung und habe alles noch vor mir ;)

                gut, dass du es wenigstens so siehst.

                Irrelevant. Die Information "Anfragen von www.xyzz.de oder www.zxy.de" sendet der Client und ist beliebig manipulierbar.
                NEIN! Eben nicht! Kann sein dass ich mich hier falsch Ausgedrückt habe.
                Es ist nicht möglich, habe ich bereits selber probiert.

                Das heißt nur, dass du es -vermutlich mangels Kenntnis der technischen Grundlagen von HTTP- nicht geschafft hast.

                Wenn die Anfrage nicht von der Damain kommt, die auf der Liste steht, wird NIX gemacht. Basta!

                Nochmal: Es gibt im HTTP-Kontext kein "von". Auf deinem Server trifft ein Request ein, der eine bestimmte Ressource anfordert (und der kommt *von* einem dir völlig unbekannten Client). Im Request-Header *kann* ein Feld namens "Referer" sein. Muss aber nicht. Und wenn es da ist, *kann* es die URL des Dokuments enthalten, das den Browser zu diesem Request veranlasst hat. Muss aber nicht.

                Und da alle diese Informationen vom Client kommen, von dem du weder die technischen Möglichkeiten kennen kannst, noch das Fachwissen oder gar die kriminelle Energie des Anwenders, sind diese Informationen prinzipiell nicht vertrauenswürdig. Nicht einmal die IP-Adresse des Clients lässt sichere Rückschlüsse zu - sie kann nach dem Weg über -zig Proxies mehrmals verschleiert worden sein.
                Jemand könnte deinem Server einen Request zustellen, bei dem du felsenfest überzeugt wärst, es ist der Bot von Google. Ebenso könnte man den HTTP-Request, den dein Shopsystem als "korrekt" annimmt, auch komplett mit einem x-beliebigen Programm erzeugen. Du würdest den Unterschied nicht bemerken.

                Fazit: Wenn sich jemand Mühe gibt, der sich mit der Materie wirklich auskennt, dann kann er deinen Shop gnadenlos manipulieren.

                So long,
                 Martin

                --
                Programmierer (m), seltener auch ~in (w):
                Irdische, i.a. humanoide Lebensform, die in einem komplizierten biochemischen Prozess Kaffee, Cola und Pizza in maschinenlesbaren Programmcode umwandelt.
                P~ bilden gelegentlich mit ihresgleichen kleine Gruppen, sogenannte Communities, sind aber ansonsten meist scheue Einzelgänger.
                P~ sind vorwiegend nachtaktiv und ohne technische Hilfsmittel nur eingeschränkt lebensfähig.
                1. Danke, hattest Recht.
                  Bei der nächsten Frage werde ich genauer hinsehen, und mich auch gründlicher Informieren! Danke!

          2. Yerf!

            Wenn du eine Anfrage an die Perl sendest, was auch immer (...) dann wird dir die Perl den Zugang verweigern wenn du nicht von der (den) Domain kommst, von der das Script die Daten empfangen DARF!

            Es gibt bei HTTP kein *von* sondern nur einzelne völlig voneinander unabhängige Zugriffe auf Ressourcen.

            Der Refferer ist eine freiwillige Angabe des Clients und etwa so glaubwürdig, wie wenn ich dir jetzt sage, dass ich vom Mars komme...

            Gruß,

            Harlequin

            --
            <!--[if IE]>This page is best viewed with a webbrowser. Get one today!<![endif]-->
  2. Hallo Alex,

    das kann man auch ohne Firebug, indem man Javascript einfach ausschaltet. Javascriptvalidierung ist nur zu gebrauchen, um dem User ein direktes Feedback zu geben, in jedem Fall muessen alle Daten serverseitig nocheinmal kontrolliert werden.

    Gruss

    Dieter

    1. das kann man auch ohne Firebug, indem man Javascript einfach ausschaltet.

      Wenn man JS ausschaltet, gelangt man erst garnicht zur der Seite.
      <noscript></noscript> ;)

      Javascriptvalidierung ist nur zu gebrauchen, um dem User ein direktes
      Feedback zu geben, in jedem Fall muessen alle Daten serverseitig nocheinmal
      kontrolliert werden.

      Leiter tuts nicht.
      Es wäre viel zu umständlich das jetzt einzubauen, der der Shop sehr komplex ist.

      1. Hi Alex!

        Wenn man JS ausschaltet, gelangt man erst garnicht zur der Seite.

        Ich kann doch auch erst auf die Seite und dann Javascript ausschalten.
        Oder ich nehme Firebug. Auf deine Validierung pfeiff ich, so wie ich gerade Lust habe. Du DARFST clientseitiges Javascript NICHT AUSSCHLIESSLICH zur Validierung von Nutzereingaben verwenden! Da gibt´s keine Diskussion und keinen Workarround!

        Es wäre viel zu umständlich das jetzt einzubauen, der der Shop sehr komplex ist.

        Dann wunder dich nicht, wenn du arge Probleme bekommst.

        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:)
        1. Ich kann doch auch erst auf die Seite und dann Javascript ausschalten.
          Oder ich nehme Firebug. Auf deine Validierung pfeiff ich, so wie ich gerade Lust habe. Du DARFST clientseitiges Javascript NICHT AUSSCHLIESSLICH zur Validierung von Nutzereingaben verwenden! Da gibt´s keine Diskussion und keinen Workarround!

          Du, ich überarbeite den Shop nur.
          Eine Umstellung auf Serverseitige-Validierung würde den Rahmen sprengen.
          Der Shop läuft in mehr als 15 Ländern.
          Leider habe ich den Shop nicht erstellt, sonst würde ich auch auf Serverseitige Validierung setzen!

          Es wäre viel zu umständlich das jetzt einzubauen, der der Shop sehr komplex ist.

          Ich nicht! Das Unternehmen ;)

          1. Moin!

            Ich kann doch auch erst auf die Seite und dann Javascript ausschalten.
            Oder ich nehme Firebug. Auf deine Validierung pfeiff ich, so wie ich gerade Lust habe. Du DARFST clientseitiges Javascript NICHT AUSSCHLIESSLICH zur Validierung von Nutzereingaben verwenden! Da gibt´s keine Diskussion und keinen Workarround!
            Du, ich überarbeite den Shop nur.
            Eine Umstellung auf Serverseitige-Validierung würde den Rahmen sprengen.

            Ein Verzicht darauf würde eventuell den Shop sprengen!

            Der Shop läuft in mehr als 15 Ländern.

            Dann sollte genug Gewinn abgeworfen werden, um eine vernünftige Lösung einbauen zu lassen.

            Leider habe ich den Shop nicht erstellt, sonst würde ich auch auf Serverseitige Validierung setzen!

            Es wäre viel zu umständlich das jetzt einzubauen, der der Shop sehr komplex ist.

            "Es wäre DIR viel zu umständlich, es einzubauen, da es DIR zu komplex ist."

            Verstehe nicht, wo das Problem liegt? Die sinnlosen Barrieren mit Referrerprüfung konnten doch auch eingebaut werden.

            - Sven Rautenberg

            --
            "Love your nation - respect the others."
            1. Dann sollte genug Gewinn abgeworfen werden, um eine vernünftige Lösung einbauen zu lassen.

              Amen! Das denke ich auch, aber ich bin ja nicht der Chef hier.

              "Es wäre DIR viel zu umständlich, es einzubauen, da es DIR zu komplex ist."

              Nein! Ich habe keine Erlaubnis, kein "Go" für diese gravierende Veränderung.
              Ich müsste zig tausend Zeilen am Quellcode ändern/anpassen um das Umzusetzten, dann würde man wieder zig hunderte Tests durchjagen, eine Firma beauftragen die Seite auf Manipulationsmöglichkeiten zu prüfen, was viele, viele Tausend EUR kostet wird. Wäre ich von anfangan am Shopaufbau beteiligt, wäre das was anderes, aber der Shop ist bereits seit 4 oder 5 Jahren online.

              1. Yerf!

                eine Firma beauftragen die Seite auf Manipulationsmöglichkeiten zu prüfen

                Hätte man das schon beim ersten mal gemacht wäre es nicht soweit gekommen...

                Falls doch eine Firma beauftragt wurde solltet ihr Prüfen ob ihr diese Verklagen könnt!

                Gruß,

                Harlequin

                --
                <!--[if IE]>This page is best viewed with a webbrowser. Get one today!<![endif]-->
                1. Falls doch eine Firma beauftragt wurde solltet ihr Prüfen ob ihr diese Verklagen könnt!

                  Wurde beaftragt!
                  Alles in Ordung.
                  Mag sein das es möglich ist, ohne Seinen Adresse anzugeben, Sache im Shop zu bestellen, aber MANIPULATION von Preisen, DB o.ä. ist NICHT MÖGLICH!
                  Alle relevanten Sachen wie Preise, IDs, PWs, Loginnamen usw. können NICHT manipuliert werden. Lediglich die Validierung der Rechnungsanschrift und Lieferanschrift sind manipulationsanfällig.

                  1. Hallo Alex,

                    Mag sein das es möglich ist, ohne Seinen Adresse anzugeben, Sache im Shop zu bestellen, aber MANIPULATION von Preisen, DB o.ä. ist NICHT MÖGLICH!
                    Alle relevanten Sachen wie Preise, IDs, PWs, Loginnamen usw. können NICHT manipuliert werden. Lediglich die Validierung der Rechnungsanschrift und Lieferanschrift sind manipulationsanfällig.

                    und die von Kreditkarten?
                    Du gibst wirklich kein gutes Bild ab.

                    Wo siehst Du eigentlich den Bezug zwischen FireBug und Barrierefreiheit?

                    Beratende Grüße

                    Vinzenz

                    1. und die von Kreditkarten?

                      Die Kreditkarten werden auf Anfangswerte, Nummerlänge, Zugehörigkeit und auf Prüfziffer überprüft. Das abbuchen sowie das verefizieren übernimmt ein Fachunternehmen "Bibit.com". Sollte es trotzdem gelingen mit falschen Daten durch die Kasse zu gelangen, wird spätestens beim Abbuchen des Betrages die Bestellung storniert bzw. der Kunde wird um Info gebeten.

                      Du gibst wirklich kein gutes Bild ab.

                      Wie meinst du das den?

                      Wo siehst Du eigentlich den Bezug zwischen FireBug und Barrierefreiheit?

                      Keine Ahnung, aber das Thema "Manipulation" stand ja nicht zur Auswahl.

                      1. Wo siehst Du eigentlich den Bezug zwischen FireBug und Barrierefreiheit?
                        Keine Ahnung, aber das Thema "Manipulation" stand ja nicht zur Auswahl.

                        Es gibt aber ein Feld "Sonstiges", wenn man wirklich nichts findet ("Browser" wäre eventuell noch gegangen, Firebug ist immerhin ein Browser-Plugin).

                        --
                        Reden ist Silber, Schweigen ist Gold, meine Ausführungen sind Platin.
                        Self-Code: sh:( ch:? rl:( br:> n4:( ie:{ mo:) va:) de:> zu:} fl:| ss:| ls:~ js:|
  3. Hallo,

    Hallo, ich arbeite gerade an einem Online-Shop für einen Mandanten.
    Dabei ist mir aufgefallen das man die JS-Validierung (oder was auch immer) ganz einfach außer Kraft setzten kann.

    jegliches Javascript zur Validierung ist nett und benutzerfreundlich, aber immer nur die Kür zusätzlich zur Pflicht der serverseitigen Prüfung.

    Beispiel:

    html<form action="xyz" method="post" ... onSumbit="return validateTheForm(this)">

    im FireBug kann man den "onSubmit-Befehl" außer kraft setzten, und der Validierung entgehen. Das gleiche lässt sich (leider) auch bei Kreditkarten-Validierung einsetzen (JavaScript-Validierung).

    Ist es eine große Lücke im FireBug oder wie soll ich das ganze verstehen?

    Nein, natürlich nicht. Wenn sich eine Anwendung in Sachen Sicherheit ausschließlich auf Javascript verläßt, dann ist die Anwendung grob fehlerhaft und den Entwicklern darf Stümperei bescheinigt werden.

    Alles was vom Client (Browser) kommt, sind Daten, die fehlerhaft und manipuliert sein können und serverseitig validiert werden müssen. Oft zitiert:

    "All input is evil."

    Freundliche Grüße

    Vinzenz