addslashes(), htmlentities(), stripslashes() und je nachdem evtl auch nl2br()
Ist jetzt das, was mir persönlich dazu einfällt...

es empfiehlt sich weiterhin:
- keine unverknüpften dateiendungen wie .inc für code-includes verwenden, da man sie sonst bei direkter angabe in der url im klartext sehen kann.
- beim includen von dateien über die url prüfen, ob sie auch lokal vorhanden ist und möglichst auch auf ein festes verzeichnis festlegen, insbesondere relative pfandangaben müssen gefiltert werden.
- ... mehr fällt mir gerade nicht ein, bin auf'm sprung

register_globals wäre da noch so ein Stichwort. Was hat es damit auf sich. Nun, wir alle haben es schonmal gesehen:

domain.de/index.php?seite=start

Hierbei wird die Variable 'seite' mit dem Inhalt 'start' an die Datei index.php übergeben. Jetzt könnte man ja auf die Idee kommen und dort einfach mal etwas anderes als 'start' eintragen.

Zeit für ein Beispiel aus der Praxis. Y0Gi kennt das nachfolgende Versuchopfer bestimmt auch noch ;D

Link 1

Link 2

Nanu, was ist denn im zweiten Link passiert? :

Ich denke hier wird schnell klar wieso man vor allem Variablen, die extern manipuliert werden können, sehr sorgfältig unter die Lupe nehmen sollte bevor diese verwendet werden.

An der Stelle sei noch zu erwähnen, dass ich der Seite kein einziges Bit gekrümmt habe. Ich habe lediglich eine Seite von meinem Webspace durch das Script einbinden lassen. Das ist in etwa verlgleichbar mit Frames.

Zitat von »Shoggy«

Nanu, was ist denn im zweiten Link passiert? :

soviel zum thema "skill0rs" : ;D

das fatale ist, das es solche beispiele wie sand am meer gibt. wenn man mal die augen aufmacht und es bei seiten, die derartige technik nutzen einfach mal probiert ob sie externe seiten ebenfalls einbinden wird man erstaunt sein wie häufig man "glück" hat.

was auch noch ein thema ist mit dem man die sicherheit erhöhen kann (aber nicht nur das) ist "URL rewriting" (google ist dein freund ). Setzt aber voraus, dass mod_rewrite am webserver aktiviert ist.

Du kannst die einzelnen Ordner noch mit .htaccess und deny all schützen, dann können nur Scripts die auf dem Server liegen die Dateien ausführen.

peace
moede

Zitat von »friedensmoede«

Du kannst die einzelnen Ordner noch mit .htaccess und deny all schützen, dann können nur Scripts die auf dem Server liegen die Dateien ausführen.

peace
moede

DAS ist jetzt allerdings falschrum gedacht

http://faq.1und1.de/server/root_server/security/4.html

Das gibt einen ganz vernünftigen Überblick über gängie Angriffsmethoden inkl. verständlichen Beispielen sowie Tipps für Gegenmaßnahmen.

Zitat von »mousonmars«

Moin

@shoggy da hast jetz wohl denn nagel auf denn Kopf getroffen ,
hab das gleiche problem wie bei skill0r's :-[

Blos wie kann ich es umgehen das jemand eine seite die sich nicht auf dem Server befindet einbindet ???

thx mous

Anstatt den Dateinamen anzugeben, wie du es grade machst, musst du nur einfach nur die Variablen gegen Konstante ersetzen.

Also


Wobei du einfach nur <blubb> und <relativer oder absoluter pfad> ersetzen musst

MfG TrOuble

Wenn jamend so weit ist eigene Dateien bei dir anzulegen wird er ein PHP-Script wohl kaum noch nötig haben

shoggy:
ja, das beispiel erkenne ich neben zahlreichen anderen noch wieder
statische seiten einzubinden kann z.b. durch verleumderische äußerungen, konkurrenzwerbung oder unterschiebung irgendwelcher inhalte schon sehr böse enden. da aber auch php-code eingefügt werden kann (und nein, ich verrate das besser nicht), kann dort auch ein angreifer sehr nützliche informationen über den server bekommen und bei schlampiger administration sogar noch weitreichenderen zugriff als nur auf das eine hostung erhalten. weiterhin lassen sich so nicht verlinkte dateien finden und auch php-code mit z.b. passwörtern auslesen.

Zitat von »mousonmars«

Blos wie kann ich es umgehen das jemand eine seite die sich nicht auf dem Server befindet einbindet ???

wie ich schon sagte:

Zitat von »Y0Gi«

es empfiehlt sich weiterhin:
- beim includen von dateien über die url prüfen, ob sie auch lokal vorhanden ist und möglichst auch auf ein festes verzeichnis festlegen, insbesondere relative pfandangaben müssen gefiltert werden.
[/code]

also etwa bei http://www.example.com/?page=hallo (wobei /? die abkürzung für index.php? und andere default-indexfiles ist)
[code]
<?php
$includepath = './includes/' . $_GET['page'] '.php';
if (! file_exists($includepath)) {
// fehlerbehandlung
}
?>

zudem solltest du testen, ob der pfad illegale strings wie "../" u.ä. enthält.


irgendwann habe ich schon mal ein stück modforge-code gepostet, findet das grad jemand wieder?

ah, da haben wir es ja endlich. so prüfe ich das bei modforge:

Zitat von »Y0Gi«

ich zitiere mal aus unserem text-modul:

Quellcode

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

if (empty($_GET['text'])) trigger_error('Kein Text ausgewählt.', E_USER_ERROR); // check for illegal strings if (false !== strpos($_GET['text'], '/etc/passwd')) trigger_error('Wow, you\'re a super l33t h4x0r, eh?', E_USER_ERROR); $illegalParts = array('/', '\\'); foreach ($illegalParts as $illegalPart) { if (false !== strpos($_GET['text'], $illegalPart)) trigger_error('Nicht erlaubte Zeichen gefunden.', E_USER_ERROR); } // check file existence $textfile = realpath($_SERVER['DOCUMENT_ROOT'] . $CFG['path_texts'] . $_GET['text'] . '.inc.php'); if (! file_exists($textfile)) trigger_error('Text nicht gefunden.', E_USER_ERROR); // load file include($textfile);

man sieht auch wieder deutlich: php suxxst zualleroberst.