Web -> Input Element (CSS FF vs IE)

Impressum | Werbung

Geizhals » Forum » Programmierung »

Web -> Input Element (CSS FF vs IE) (12 Beiträge, 205 Mal gelesen)

Top-100 | Fresh-100

Du bist nicht angemeldet. [ Login/Registrieren ]

Hi!

Firefox:

IE9

CSS:
input.text {
  width:300px;
  border:1px solid;
  padding: 0px 3px;
  margin: 3px 10px;
}

HTML:
<table>
<tr>
<td><label>Firma: </label></td>
<td><input type="text" name="firma" class="text" maxlength="<?php echo $zeichenlaenge_firma; ?>" value="<?php echo $_POST[firma]; ?>" /></td>
<td></td>
</tr>

Ich komm leider nicht drauf, wieso der Firefox Version 21 Probleme macht

Könnt ihr mir helfen

?

Danke
Frankster

gelöst

input {
  width:300px;
  border:1px solid;
  padding: 0px 3px;
  margin: 3px 10px;
}

Input.text{
 //def
}

Man muss zuerst das Hauptsegment definieren, dann das Untersegment

28.06.2013, 20:06 Uhr - Editiert von Frankster, alte Version: hier

Du beachtest nicht den Kontextwechsel. Dadurch wird die Seite unter Umständen kaputt dargestellt und ist anfällig für XSS-Attacken. Du musst Textausgaben im HTML-Kontext immer mit htmlspecialchars() maskieren.

$_POST[firma] wird eine Fehlermeldung schmeißen, da du versuchst auf eine Konstante firma zuzugreifen, die es vermutlich nicht gibt. Du möchtest wahrscheinlich auf $_POST['firma'] zugreifen. Es "funktioniert" trotzdem, da PHP so gutmütig ist und dein falsches Vorhaben korrigiert, weil es die Konstante firma nicht findet. Aber sinnvoll programmiert ist das trotzdem nicht.

29.06.2013, 08:28 Uhr - Editiert von hellbringer, alte Version: hier

Etwas was mich schon lange interessiert ...
was bringt htmlspecialchars() für die Sicherheit???

Der Befehl wandelt lediglich Symbole in html Zeichencodes um.

Dadurch wird die Seite unter Umständen kaputt dargestellt

Ok, kann sein ...

und ist anfällig für XSS-Attacken

????? How ?????

Im Gegenteil, htmlspecialchars hatte eine schwere Sicherheitslücke, welche erst vor einen Jahr oder so behoben wurde.

Außerdem sollte man die Variablen wenn dann bei der Eingabe überprüfen/umwandeln und nicht bei der Ausgabe.

Ok, die direkte Ausgabe von $_POST ist XSS anfällig ... allerdings nur, wenn über eine andere XSS anfällige Seite aufgerufen, da der Angriff nicht einfach über einen Link, gestartet werden kann.
Aus diesen Grund empfehle ich auch eine Initialisierung der Eingangs-variablen ... dabei kann man auch etwaige Warnungen abfangen, über Variablen welche man im Skript erwartet.

---
Ich gebe dir Recht, dass das Beispiel schiach programmiert ist ... aber wenn es sich nur um einen kleinen Skript handelt ist dieses auch egal.

Etwas was mich schon lange interessiert ...
was bringt htmlspecialchars() für die Sicherheit???

Der Befehl wandelt lediglich Symbole in html Zeichencodes um.

http://de.wikipedia.org/wiki/Cross-Site-Scripting

Im Gegenteil, htmlspecialchars hatte eine schwere Sicherheitslücke, welche
erst vor einen Jahr oder so behoben wurde.

Die da wäre?

Davon abgesehen hat jedes Programm und jede Programmiersprache Sicherheitslücken. Wenns nach dem geht, dürftest du nur Assembler programmieren und niemals Software dritter verwenden. Das schließt natürlich das Betriebssystem mit ein.

Außerdem sollte man die Variablen wenn dann bei der Eingabe
überprüfen/umwandeln und nicht bei der Ausgabe.

Falsch. Der Kontextwechsel findet bei der Ausgabe statt und nicht bei der Eingabe. Somit muss die Maskierung auch bei der Ausgabe stattfinden. Bei der Eingabe wäre das vollkommen fehl am Platz, weil man sich sonst zB. HTML-maskierte Zeichen in die Datenbank schreiben würde, wo sie überhaupt nichts verloren haben. In der Datenbank sollten nur die reinen Daten stehen.

Ok, die direkte Ausgabe von $_POST ist XSS anfällig ... allerdings nur, wenn
über eine andere XSS anfällige Seite aufgerufen, da der Angriff nicht einfach
über einen Link, gestartet werden kann.

Man kann ein Formular auch so darstellen, dass es aussieht wie ein Link. Und nicht jeder User schaut sich den HTML-Code der Seiten an, die er besucht.

Aus diesen Grund empfehle ich auch eine Initialisierung der Eingangs-variablen
... dabei kann man auch etwaige Warnungen abfangen, über Variablen welche man
im Skript erwartet.

Das ist die Eingangsvalidierung und wieder ein ganz anderes Thema, das nichts mit der HTML-Ausgabe zu tun hat.

Ich gebe dir Recht, dass das Beispiel schiach programmiert ist ... aber wenn
es sich nur um einen kleinen Skript handelt ist dieses auch egal.

Naja, kommt drauf an, welche Leute darauf zugreifen können. Wenn das Script öffentlich im Internet zugänglich ist, ist das schon fast eine Katastrophe. Genau an solchen plumpem Bastelscripts lassen sich dann die ganzen Script-Kiddies aus, weil der Aufwand das zu knacken ein Witz ist. Das ist ja schon fast wie eine Einladung.

Hi!

Danke für deinen Input.
Kannst du mir bitte die Zeile als Bsp. umschreiben, damit es nicht "schiach" programmiert ist ?

Danke
Frankster

Die da wäre?Davon abgesehen hat jedes Programm und jede Programmiersprache Sicherheitslücken. Wenns nach dem geht, dürftest du nur Assembler
programmieren und niemals Software dritter verwenden. Das schließt natürlich das Betriebssystem mit ein.

Na gut ... ist schon länger her:
http://www.zerodaylab.com/vulnerabilities/CVE-2010/CVE-2010-2100.html

Falsch. Der Kontextwechsel findet bei der Ausgabe statt und nicht bei der
Eingabe. Somit muss die Maskierung auch bei der Ausgabe stattfinden. Bei der
Eingabe wäre das vollkommen fehl am Platz, weil man sich sonst zB.
HTML-maskierte Zeichen in die Datenbank schreiben würde, wo sie überhaupt
nichts verloren haben. In der Datenbank sollten nur die reinen Daten stehen.

Vor der Übergabe an die Datenbank muss man den Übergebenen Text ohnehin analysieren oder umwandeln, da man sonst eine SQL-Injektion riskiert, warum den Text also nicht gleich so abspeichern wie man Ihn nachher ausgeben will.

Es ist weit sinnvoller die Umwandlung bei der Eingabe zu machen ... weniger Code und weniger Rechenleistung von Nöten.

Dafür braucht man halt 0,1-1% mehr speicher ... bei manchen Sonderzeichen eben 3 byte statt 1 byte.

Man kann ein Formular auch so darstellen, dass es aussieht wie ein Link. Und nicht jeder User schaut sich den HTML-Code der Seiten an, die er besucht.

Voraussetzung: Method = GET!
Sobald man POST verwendet, müsste man die übergebenen Variablen erst in einen Skipt initialisieren => XSS Angriff führt sich ab-absurdum, da Skript bereits unbemerkt ausgeführt wird.
Ist aber ausführbar.

Vor der Übergabe an die Datenbank muss man den Übergebenen Text ohnehin
analysieren oder umwandeln, da man sonst eine SQL-Injektion riskiert

Analysieren, ja. Umwandeln, nein.

da man sonst eine SQL-Injektion riskiert

Wenn man Prepared Statements verwendet, sind SQL-Injections unmöglich.

warum den Text also nicht gleich so abspeichern wie man Ihn nachher ausgeben
will.

Weil es falsch ist. Die Umwandlung findet beim Kontextwechsel statt. Was machst du, wenn du die Daten einmal nicht in einer HTML-Seite, sondern zB. in einem PDF- oder Excel-Dokument ausgeben möchtest? Dann hast du den ganzen HTML-Müll in der Datenbank stehen und musst ihn dann wieder vorher rausfiltern. Außerdem verhinderst du so effektiv, dass die Datenbank richtig sortieren, filtern und indexieren kann. Es bringt nur Probleme und keine Vorteile.

Außerdem ersparst du dir die Maskierung beim Kontextwechsel sowieso nicht, da du ja nicht davon ausgehen kannst, dass alle Daten immer aus der Datenbank kommen. Schlussendlich hast du dann ein Mischmasch aus nichtmaskieren, richtig maskierten und doppelt maskierten Daten. Na herzlichen Glückwunsch.

Es ist weit sinnvoller die Umwandlung bei der Eingabe zu machen ... weniger
Code und weniger Rechenleistung von Nöten.

Der Code wird nicht mehr. Zumindest nicht, wenn man sauber nach dem DRY-Prinzip programmiert. Wenn man Copy&Paste-mäßig programmiert, dann ist der erzeugte Code natürlich Müll und schwer wartbar.

Und wenn du dir bei sowas wegen der Rechenleistung sorgen machst, darfst du gar kein PHP verwenden. Denn PHP an sich verschwendet mindestens das tausendfache der Leistung, die du damit einsparen willst. Dafür gibts übrigens auch ein Stichwort: Mikrooptimierung.

Du solltest das optimieren, was wirklich viel Rechenleistung frisst, und nicht den kleinen Fliegenschiss.

Dafür braucht man halt 0,1-1% mehr speicher ... bei manchen Sonderzeichen eben
3 byte statt 1 byte.

Zu heutigen Zeiten, wo ein Server mehrere GB RAM und hunderte/tausende GB an Festplattenspeicher hat, bedeutungslos. Das soll ja kein Programm für einen C64er werden. Und wenn doch, dann ist PHP die falsche Sprache bzw. MySQL der falsche Datenspeicher.

Voraussetzung: Method = GET!

Nein, auch POST!

Sobald man POST verwendet, müsste man die übergebenen Variablen erst in einen
Skipt initialisieren => XSS Angriff führt sich ab-absurdum, da Skript bereits
unbemerkt ausgeführt wird.
Ist aber ausführbar.

Geht das auch in Deutsch? Ich versteh nicht, worauf du hinaus willst.

01.07.2013, 23:39 Uhr - Editiert von hellbringer, alte Version: hier

Dieses Forum ist eine frei zugängliche Diskussionsplattform.
Der Betreiber übernimmt keine Verantwortung für den Inhalt der Beiträge und behält sich das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
Datenschutzerklärung