[TYPO3-german] Crossite Scripting t3lib_div::_POST('variable')

[Christian Wolff]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 01.07.2010 08:46, schrieb Chris Bernhard:
> Am 30.06.2010 23:31, schrieb Christian Wolff:
> Am 30.06.2010 22:29, schrieb Chris Bernhard:
>>>> Hi zusammen,
>>>>
>>>> wenn ich eine Variable über t3lib_div::_POST('variable') verarbeite
>>>> und damit meinetwegen eine MySQL Abfrage starte, bin ich dann
>>>> schon vor XSS Scripting sicher oder muss ich hier noch irgendwas
>>>> beachten?
>>>>
>>>> Viele Grüße und Dankeschön,
>>>>
>>>> Chris
> 
> Hallo Chris,
> die functionen:
> t3lib_div::_POST(), t3lib_div::_GET() ,t3lib_div::_GP()
> 
> kümmern sich lediglich darum das die variablen unabhängig von der server
> konfiguration ohne escaping bei dir ankommen.
> 
> wenn du sie in datenbank abfragen verwenden willst solltest du sie
> escapen.
> 
> dafür gibts in der classe t3lib_DB die function fullQuoteStr($str,$table)
> 
> also folgende verwendung:
> $myPostVar = t3lib_div::_POST();
> $myPostVar = $GLOBALS['TYPO3_DB']->fullQuoteStr($myPostVar,'pages');
> 
> die funktion setzt den string direkt in anführungzeihen. da rüber bin
> das erst mal gestolpert.
> 
> gruss chris
> 
> 
> 
> 

> Hi Chris auch :-)

> Okay, dankeschön für den Hinweis, aber reicht dann nicht schon sowas wie

> $this->myfunction(htmlspecialchars(t3lib_div::_POST('mypostvar')));

> So sieht dann die Funktion aus:

> function myfunction($test)
> {

> $clause = "p.plz LIKE '$test' LIMIT 1 ";

> $res = $GLOBALS['TYPO3_DB']->exec_SELECTquery('*','tx_blablabla_huhu p
> LEFT JOIN tx_blablabla_huhuhu a ON p.id= a.pid', $clause);

> um eine Attacke komplett auszuschließen? Möchte ja nur sichergehen, dass
> meine Extensions auch wirklich sicher sind :-)

> Vielen Dank und beste Grüße,

> Chris


Hi Bernhard wie Georg Ja ja auch schon gesagt hat ein htmlspecialchars
reicht nicht aus.

htmlspecialchars konvertier html eigene zeichen in die entinites also
<,>,& ",' werden in ihre entsprechenden entinies umgewandelt.

htmlspecialchars schützt dich nicht vor SQL injections. und das sind die
dinge um die dur dir sorgen machst wenn du sachen mit der datenbank machst.

also dein oben genanntes beisiel baut ungefähr folgendes SQL zusammen

SELECT *
FROM tx_blablabla_huhu p
LEFT JOIN tx_blablabla_huhuhu a ON p.id= a.pid
WHERE * p.plz LIKE '$test' LIMIT 1


wenn ich jetz als angreifer angreifer folgendes in $test übergebe.

"%' LIMIT 1; INSERT INTO be_users SET
username=`eviladmin`,
 'password'=`4faa70cd67f1101dc39ae6629def1aef`,
admin=1

könnte ich eventuell einen admin user anlegen der. und das will man ja
nicht. deswegen gilt es alle werte die du der datenbank übergibst durch:
$GLOBALS['TYPO3_DB']->fullQuoteStr() zu schicken. so kannst du dir
sicher sein das keiner ausbüchst.

falls du nutezerdaten (kommentare oder ähnliches) in deiner datenbank
speicherst und später wieder ausgibst solltest du dann bei der ausgabe
darauf achten das kein böser html/javascript erlaubt ist.

das kann im einfachsten falle über htmlentities() geschehen in dem du
einfach alles in "für den menschen lesbaren text konvertierst.

wenn du den leuten aber etwas html erlauben willst. und nur bei der
ausgabe sicherstellen willst das nix böse drin ist stellt typo3 dafür
eine funktion bereit:

tslib_cObj.removeBadHTML($text,$conf)

in normalen plugins hast du eine instanz von tslib_cObj schon geerbt.
und solltest sie über
$this->cObj->removeBadHTML($text,$conf) erreichen können.

damit kannst du dann für die FE ausgabe alle schön filtern.

gruss chris



- -- 
Christian Wolff // Berlin
http://www.connye.com

some projects:
http://richtermediagroup.com | http://titanic.de |
http://fairplay-homepage.de
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iEYEARECAAYFAkwsVuIACgkQIcCaXPh/JHEUGQCeONGghuBt53BicSgaPA6IC8ga
xt8AoK4G6ZohpiaYJ+gQ+BqbtNScTSiW
=cZtR
-----END PGP SIGNATURE-----