✔ Sicherheitslücken finden & beheben

[Cherrywine]

@ tha_specializt:
thx, hab ich grade eingebaut

@ andy:
hmm, so ganz werde ich da immer noch nicht draus schlau.

Ich hab das jetzt mal so geschrieben:

<?php 
	
$valide = array('header');

if(is_array($valide) && in_array($_GET['url'], $valide) ){
$url = $_GET['url'];
}else{
$url = 'header';
}

include($url.'.php');
	?>

- ist das nicht auch sicher?


LG
Cherrywine

 

[andy72]

Öhm, sooooo meinte ich das ja auch nicht ^^

also:
Du hast doch auf Deiner Page Links wie "Überschriften" etc in Deinen Tut's.
Dort hast Du einen Click-Counter, der Dir (scheinbar) die Seitenaufrufe zählt und dann einen Redirect macht und die Seite aufruft...
Grundsätzlich ist das ja in Ordnung, jedoch lässt sich da Unfug mit veranstalten, wenn das eine Datei ist, die includiert werden soll und nicht zur Anzeige bestimmt ist - man könnte also den Link missbrauchen und Deine - zu includierende - Seite dann aufrufen, und dort einen bösartigen Code anhängen:

http://deine-seite.de/include-datei.php?query=SELECT%20passwort%20FROM%20benutzertabelle

Somit kommt unberechtigt ein User an Deine Datenbank und kann da bösartige Abrufe machen oder Code einfügen, vorrausgesetzt, er hat Kenntnis von Deiner datenbank,deren tabellen (-Felder) oder sonstigen Abläufen.

Umgehen lässt sich das zumindest etwas sicherer auf meine oben beschriebene Art und Weise:

PHP-Seite mit Link

echo '<a href="http://deine-seite.de/page.php?url=1">Tutorials</a>';

PHP-Seite des Counters:

if( isset($_GET['url']) ) {
  $page = intval($_GET['url']);
  switch( $page ) {
    case 1: include_once('datei1.php');
                // Code Deines Counters
                break;
    case 2: include_once('datei2.php');
                // Code Deines Counters
                break;
    default: header('Location: error.php');
  }
}
else
  header("Location: error.php");

Ich hoffe, das war jetzt etwas verständlicher

 

[Cherrywine]

ah, okay, alle Klarheiten beseitigt ^^

dankeschön für die ausführliche Erklärung, jetzt funktioniert es

 

[tobias_petry]

http://deine-seite.de/include-datei.php?query=SELECT%20passwort%20FROM%20benutzertabelle

Somit kommt unberechtigt ein User an Deine Datenbank und kann da bösartige Abrufe machen oder Code einfügen, vorrausgesetzt, er hat Kenntnis von Deiner datenbank,deren tabellen (-Felder) oder sonstigen Abläufen.

sry dir wiedersprechen zu müssen aber das funktioniert kein stück
denn die Variable query wird in $_GET gespeichert, sollte er nicht wirklich sql-querys über get übergeben t das net.
sollte register-globals auf On stehen kann er den code einschleußen als $query, aber sofern der threadersteller nicht einen $query ausführt dessen variable nicht initialisiert wäre kann da gar nix passieren.
Sry, aber ist dir überhaupt bekannt wie man Script angreift?
Zudem ist das was Cherrywine geschrieben hat vollkommen ok bis auf den möglichen E_NOTICE. Sein Snippet hat den Vorteil, dass die Whitelist auch in einer DB liegen kann oder in XML-Files oder was auch immer, also deutlich wartbarer ist als dein Code.
Genauso gehört nach einem header()-Befehl ein exit() dahinter da unter Umständen nicht sofort weitergeleitet wird, und das incrementen des Counters wäre nach dem Switch-Konstrukt (oder davor) deutlich vorteilhafter, denn so hast du duplizierten Code für jede erlaubte Seite, ziemlich umständlich

 

[tha_specializt]

Ich hab jetzt nur die letzten zwei oder drei Posts gelesen, aber ich misch mich trotzdem mal ein.

sry dir wiedersprechen zu müssen aber ...

nachdem ich deine Worte unter Mühsal entschlüsseln konnte :
Natürlich geht das, hat auch absolut nix mit register_globals zu tun. Dies bezweckt lediglich, dass bestimmte DatenFelder aus HTML direkt und vollautomatisch in PHP-Variablen gespeichert werden, und auch umgekehrt geschützte Systemvariablen sehr einfach zu ändern sind .... was hat das bitte hiermit zu tun

Es gibt tatsächlich viele Websites, die anhand des $_GET-Arrays SQL-Befehle ausführen, deswegen gibt es das Wort "SQL-Inject" überhaupt. Der Sinn und Unsinn so mancher CMS-Konstruktionen beinhaltet genau das was er anspricht, und er will ihn mit einem EXTREMBEISPIEL lediglich darauf hinweisen. Natürlich wird niemand SO dumm sein, und den kompletten query-Befehl per URL auslesen, aber stellenweise findet man doch recht merkwürdige Sachen ... Er sollte (wenn es denn unbedingt $_GET sein muss) also alle eingehenden Daten tunlichst überprüfen und beschneiden, damit eventueller bösartiger Code keine Wirkung zeigt bzw. garnicht erst ankommt.

Kennste übrigens das hier:

SELECT FROM database WHERE user LIKE 'UPDATE database SET password = 'neuerpass' ON (SELECT * FROM database WHERE user LIKE '%')'

;-) Das ist ziemlich genau das, was er angesprochen hat, der mittlere Teil wurde schon in einer ähnlichen Form für Attacken auf (mittlerweile veraltete) CMS-Systeme verwendet. Das und nichts weiter wollte er aufzeigen.

 

[Gumbo]

Die häufigsten Sicherheitslücken sind auf Fehler in der Anwendung zurückzuführen, da beispielsweise Benutzereingaben nicht ausreichend validiert oder verarbeitet werden. Es sind also meist nur Logik- oder Programmierfehler.

Das System strikt zu konfigurieren, kann zwar die Schäden begrenzen und ist deshalb zu empfehlen (eine systemunabhängige Programmierung ist immer gut), doch den eigenen Programmierstil und sein Gespür für Sicherheitslücken zu sensibilisieren ist besser.

 

[tha_specializt]

rüüüschdüüsch.
Noch besser: man verbessert / sensibilisiert die eigenen Fähigkeiten UND programmiert (in diesem Fall: scripted) strikt

 

[andy72]

Danke, @specializt - genau DAS meinte ich ...ohne Kommentar