Hi,
ich habe in meinen Scripten routine eingebaut die ganz einfach jeden
schlüssel von $_POST und $_GET nehmen und den wert mit
htmlspecialchars() bearbeitet.
Das wehrt SQLinjenctions !und! XSS angriffe ab.
Wenn ich jetzt dem User die möglichkeit geben will, seinen eintrag zu
bearbeiten und er zufällig ein & verwendet hat
(das zu & umgewandelt wurde), und er ändert dies so kommt ungefähr
das dabei raus: & (und im quelcode steht: &).
Naja, diesen fehler könnte ich ganze einfach mit
htmlspecialchars_decode() beheben... wenn da nicht noch XSS wär... und
nur jeden eintrag damit zu bearbeiten (bei ein/ausgabe) dazu bin ich
ehrlich gesagt (im nachhinein) zu faul!
Wie habt ihr das geregelt?

Gruß
Dominik

ehrldo schrieb:

> ich habe in meinen Scripten routine eingebaut die ganz einfach jeden
> schlüssel von $_POST und $_GET nehmen und den wert mit
> htmlspecialchars() bearbeitet.
> Das wehrt SQLinjenctions !und! XSS angriffe ab.

Das ist Schwachsinn. htmlspecialchars() kodiert nicht alle Zeichen, die
man kodieren muss, um einer SQL-Injektion vorzubeugen! Es werden hier
nur <, > und & kodiert.

> Wenn ich jetzt dem User die möglichkeit geben will, seinen eintrag zu
> bearbeiten und er zufällig ein & verwendet hat
> (das zu & umgewandelt wurde), und er ändert dies so kommt ungefähr
> das dabei raus: & (und im quelcode steht: &amp;).

Dann wendest du bei der Ausgabe aber nochmal htmlspecialchars() o.ö. an,
sonst würde das nicht auftreten:

<?php $a = "Test & Co"; ?>
<textarea><?php echo $a ?></textarea>

Wird der Text jetzt gespeichert, wird wieder nur & zum Server gesendet,
was dann von deinem Eingabefilter zu & umgewandelt wird.

Aber um genau diesem Gewusel vorzubeugen sollte man die Rohdaten in die
Datenbankspeichern und nicht irgendwas Umgewandeltes. Lass bei der
Ausgabe htmlspecialchars() drüber laufen und verwende bei der Eingabe
mysql_escape_string() bzw. Prepared Statements um SQL-Injections
entgegenzuwirken.

> Naja, diesen fehler könnte ich ganze einfach mit
> htmlspecialchars_decode() beheben... wenn da nicht noch XSS wär... und
> nur jeden eintrag damit zu bearbeiten (bei ein/ausgabe) dazu bin ich
> ehrlich gesagt (im nachhinein) zu faul!
> Wie habt ihr das geregelt?

Prüfe, ob das was eingegeben wurde dem entspricht was du erwartest. Also
bei einem Datum zum Beispiel das Format DD-MM-YYYY und nichts anderes.
Wenn du kein HTML in einem Texteingabefeld erwartest, dann behandelst du
die Eingabe halt wie normalen Text und wendest bei der Ausgabe wie bei
jedem anderen Text der unter Umständen "special chars" enthalten könnte
htmlspecialchars() an.

Wenn du freie HTML-Eingaben erlaubst (wie z.B. bei der
eBay-Artikelbeschreibung), dann wird es komplizierter. Du musst dann
alles rausfiltern, was potienziell Client-Code enthalten könnte. Dazu
kannst du zum Beispiel den "HTML-Purifier" verwenden:

http://htmlpurifier.org/
http://htmlpurifier.org/demo.php

ehrldo schrieb:
> Hi,
> ich habe in meinen Scripten routine eingebaut die ganz einfach jeden
> schlüssel von $_POST und $_GET nehmen und den wert mit
> htmlspecialchars() bearbeitet.
> Das wehrt SQLinjenctions !und! XSS angriffe ab.

Nein, weil htmlspecialchars() die für SQL gefährlichen Zeichen nicht
maskiert.

> Wenn ich jetzt dem User die möglichkeit geben will, seinen eintrag zu
> bearbeiten und er zufällig ein & verwendet hat
> (das zu & umgewandelt wurde), und er ändert dies so kommt ungefähr
> das dabei raus: & (und im quelcode steht: &amp;).
> Naja, diesen fehler könnte ich ganze einfach mit
> htmlspecialchars_decode() beheben... wenn da nicht noch XSS wär... und
> nur jeden eintrag damit zu bearbeiten (bei ein/ausgabe) dazu bin ich
> ehrlich gesagt (im nachhinein) zu faul!
> Wie habt ihr das geregelt?

Die Daten werden erst bei der Ausgabe mit htmlspecialchars() bearbeitet.

--
Mein Zeugs:
http://www.hadanite-marasek.de/classes.php
http://www.objektivsuche.de/
Ansonsten:
http://www.php-faq.de/q/q-newsgroup-wie-helfen.html

On 10 Nov., 01:08, Hadanite Marasek <mara... [at] telton.de> wrote:
> Nein, weil htmlspecialchars() die für SQL gefährlichen Zeichen nicht
> maskiert.
oO klar.. wenn ich jetzt drüber nachdenk, ist da ein gewaltiger
denkfehler drin...
Welche funktion maskiert den sql gefährlich Zeichen?
Aber wenn ich es nur bei der ausgabe mit htmlspecialchars bearbeite,
kommt bei der bearbeitung trozdem das "falsche" raus...
Wie hast du das den geregelt?

Gruß Dominik

ehrldo schrieb:

> Welche funktion maskiert den sql gefährlich Zeichen?

Wie Thomas bereits sagte: mysql_real_escape_string()

> Aber wenn ich es nur bei der ausgabe mit htmlspecialchars bearbeite,
> kommt bei der bearbeitung trozdem das "falsche" raus... Wie hast du
> das den geregelt?

Nein, tut's nicht.

$string = "mühe";
echo '<textarea name="field">', htmlspecialchars($string), '</textarea>'

Liefert nach dem absenden:

echo $_REQUEST['field'];
// gibts "mühe" aus

Aber auch das hat Thomas schonmal erklärt. Also lies doch in Zukunft
alle Antworten auf dein Posting. Außerdem ist deine Zitatseinleitung
etwas lang geraten. Vielleicht solltest du die noch etwas verkürzen,
denn das Datum des vorhergehenden Postings kann ich (falls es mich denn
wirklich interessiert) auch direkt ablesen. Danke! :)

Gruß
David

David schrieb:
> Aber auch das hat Thomas schonmal erklärt. Also lies doch in Zukunft
> alle Antworten auf dein Posting. Außerdem ist deine Zitatseinleitung
> etwas lang geraten. Vielleicht solltest du die noch etwas verkürzen,
> denn das Datum des vorhergehenden Postings kann ich (falls es mich denn
> wirklich interessiert) auch direkt ablesen. Danke! :)
..=2E. Sorry, ich hab den ersten Beitrag komplett übersehn. (und das mit
der Zitateinleitung, hab ich nicht gemacht, das kam automatisch.. ich
hab das nur nicht weggemacht...)

[at] Thomas
Sry, hab dein Beitrag viel zu spät gesehn...
Danke, für den Tipp. Das wusste ich nicht das wenn ich mit php "&"
ausgeb, das bei mir wieder ein "&" ankommt... Dann muss ich das
wirklich öfters aufgerufen (bearbeitet) haben...
Und das mit den SQLinjections... da hat ich einen denkfehler... ist
natürlich absoluter Schwachsinn... werds natürlich mit
mysql_escape_string() bearbeiten!

Danke für die Tipps!
Gruß Dominik

> Und das mit den SQLinjections... da hat ich einen denkfehler... ist
> natürlich absoluter Schwachsinn... werds natürlich mit
> mysql_escape_string() bearbeiten!

Und bei der Gelegenheit kannst Du gleich deine ganze Praktik überdenken.
Maskieren sollte man nciht alles, sobald es einem unterkommt (sonst
könnte die Sprache das ja fast gleich selbst erledigen), sondern erst
da, wo man es braucht, mit den Mitteln, die dafür gedacht sind:
mysql_real_escape_string(), bevor man es in die mysql_-Funktionen haut,
$db->quote(), bevor man es in PDO haut (oder gleich prepared queries),
htmlspecialchars, bevor man es ausgibt usw.
Mit Deiner Methode hättest Du ja auch HTML-Maskierungen in der Datenbank
stehen. Aber was sollen sie da? Vielleicht willst Du die Texte ja mal
als PDF ausgeben. Oder in einer anderen, nicht-XML basierten
Markupsprache. Was dann?

Aber wenn Du etwas am Anfang des Scriptes machen willst: Überprüf auf
magic_quotes_gpc und entferne sie, falls sie gesetzt sind. Sie sind
nciht das geeignete Mittel, um SQL-Queries richtig zu schützen, machen
aber mysql_real_escape_string() kaputt. Ich habe dafür folgenden Code in
meinen Scripts, um einen definierten Zustand zu erhalten:

//Deaktiviere magic_quotes_runtime
set_magic_quotes_runtime(0);
//Falls Magic Quotes GPC gesetzt, ...
if(1 == get_magic_quotes_gpc())
{
//... definiere Funktion zum Strippen von Arrays und ...
function stripslashes_array($array) {
return is_array($array)
? array_map('stripslashes_array', $array) :
stripslashes($array);
}
//... entferne die Slashes aus den GPC-Arrays
$_COOKIE = stripslashes_array($_COOKIE);
$_FILES = stripslashes_array($_FILES);
$_GET = stripslashes_array($_GET);
$_POST = stripslashes_array($_POST);
$_REQUEST = stripslashes_array($_REQUEST);
}