Welche Funktionen für höchstmögliche Sicherheit?

[aJunkie]

Hallo,

Am Beispiel eines Formulares.

Ziemlich unsicher ist folgendes:

<?php echo $name; ?>

wegen register_globals.

Also doch lieber:

<?php $_POST['name']; ?>

Ich prüfe meist immer noch, ob es ein Array ist.
Also meine Fallentscheidungen sehen meistens so aus:

<?php if(isset($_POST['name']) && !is_array($_POST['name'])) {
// dann alles klar
} else {
// sonst nicht.
}

Wenn es ziemlich eindeutig ist wie bei einer Telefonnummer, dass eine Zahl erwartet wird, dann prüfe ich noch zusätzlich mit is_numeric, ob es sich um Zahlen handelt.

Bei der Ausgabe oder Mailversand mache ich noch folgendes:

<?php htmlspecialchars($ausgabe); ?>

Was gibt es noch für Möglichkeiten?
Was für Arten von Attacken können diese Methoden verhindern?
Was ist noch wichtig zu prüfen?

 

[mustang]

hier im forum hat mir jemand einen guten code gegeben.

<tr id='tr_email_address'>
      <th><label for='email_address'>Dieses Feld muss leer bleiben:</label></th>
      <td><input type='text' id='email_address' name='email_address' value='' class='eingabe' /></td>
    </tr>

und per css einfach tr_email_address auf display:none stellen.
später einfach überprüfen, ob das feld wirklich leer ist.
hintergrund:
ein spambot wird versuchen alle felder mit sinnvollen inhalten zu füllen. ein richtiger user sieht dieses feld aber nicht und wird daher keinen wert eingeben.
dadurch kannst du dir auch noch ein paar bots vom hals halten.

 

[struppi]

Was für Arten von Attacken können diese Methoden verhindern?
Was ist noch wichtig zu prüfen?

Gar keine oder besser gesagt, es kommt drauf an. Du musst sowas immer im Kontext betrachten. Es gibt keine allgemeingültige Variante.

Wenn es um den Mailversand geht, sind einzig und allein die header Daten betroffen. Da PHP das etwas verschleiert, merkst du es nicht so schnell. Hier geht es um die Parameter $to, $subject und dem letzten optionalen Parameter: http://php.net/manual/de/function.mail.php hier darfst du von aussen kein Newline zulassen, alles andere ist egal. Beim Text ist auch das Newlinezeichen ungefährlich.

 

[aJunkie]

Und bei Scripten allgemein?
POST Elemente verarbeite ich auch mit $_POST['varibale'] weiter.
Aber ich denke, da kann man mehr prüfen als nur, ob es eine Array ist.
Zum Beispiel SQL Injections?
mysql_real_escape nimmt man ja, wenn man was in die Datenbank schreibt.
Aber man kann doch sicherlich Schadcodes mit in ein Feld einbinden, welches andere Aufgaben erfüllt, als in eine Datenbank zu schreiben.
Zum Beispiel bei Logins?

<?php if($_POST[username] == "MeinName") {
// eingeloggt
} ?>

ist ja eher spartanisch?

 

[struppi]

Wie gesagt, es kommt immer auf den Kontext an, also was du mit den Werten vor hast. Die Prüfung auf ein Array ist aber überflüssig, zumindest kann ich mir nicht vorstellen, was da passieren sollte.

 

[Mad Dog]

naja wenn es darum geht zu schauen, was der user eigegeben hat (vlt schadcode) kannst du das ganze auch mittles preg_match ueberpruefen und dem user vorgeben was ueberhaupt eingegeben werden darf.

vor sql injection kann man sich mittels prepared statement teilweise schuetzen.

 

[aJunkie]

Danke, aber wieso behauptet der Dozent einer Lern-DVD, dass man es immer prüfen sollte, um Angriffe zu verhindern?

Hat jemand eine Idee?

 

[struppi]

Keine Ahnung warum das so sein sollte. Es gibt keinen Schadcode den du eingeben kannst. Erst die Verwendung kann zu Schaden führen, dafür bist du als Programmierer verantworlich. Aber ein Array an sich kann keinen Schaden verursachen und hat auch ncihts mit SQL Injections zu tun.

Die Frage ist, was du unter Schaden verstehst? Eine Fehlfunktion? Dann musst du die Eingabe entsprechend filtern und/oder maskieren. Oder einen Angriff? Dann musst du die entsprechenden Funktionen so einschränken, dass kein Angriff erfolgen kann. Das ist das was ich schon mehrfach gesagt habe, es kommt auf den Kontext an

 

[Mad Dog]

meint der dozent das pruefen ob es ein array ist oder meint der dozent die eingabe des users zu pruefen?

 

[T-sneak]

Sicherer wie ein Captcha wird wohl nichts sein das mit den unsichtbaren Felder können moderene Bots mittlerweile auch hab das nämlich früher auch mal gemacht, hält zwar schon viel ab aber einige kommen trotzdem durch..
was auch noch relativ viel bringt ist die User Agents auszuwerten und diese auszuschließen.. Aber aufpassen wenn man alles bannt was Bot im UserAgent hat sperrt damit auch den Zugriff für Suchmaschinen.. Kannst ja mal in Google nach den schädlichsten UserAgents suchen da gibts Listen ;-)

 

[struppi]

In dem Fall geht es aber weniger um Sicherheit, sondern um verhinderung von Spam. Aber captchas sind Mist, damit nervt man nur die Besucher. Es gibt andere Wege WebAIM: Blog - Spam-free accessible forms

 

[freak131]

U

<?php if($_POST[username] == "MeinName") {
// eingeloggt
} ?>

$_POST[username]
ist dir bewusst, dass jedesmal nach einer konstanten username gesucht wird, php diese nicht fndet, extrem aufwendig in die serverlogs schreibt, daraufhin versucht username in einen string zu casten?

"MeinName"
ist dir bewusst, dass PHP den String intern nach variablen durchsuchen muss? Nutze besser 'MeinName', dies ist um ein vielfaches schneller.


du kannst ein wenig mit XSS angrffen rumspielen, schau dir mal das an:
XSS (Cross Site Scripting) Cheat Sheet

SQL Injectionen sind was völlig anderes, schau dir dazu mal
"pdo bind", real_escape_string an.

 

[aJunkie]

'' ist schneller als ""?
Echt? Generell so?

 

[struppi]

Wie freak131 schon sagte, in den doppelten Anführungszeichen werden Variabeln geparst in den einfachen nicht, jetzt kannst du dir überlegen was wohl generell schneller ist.

 

[crash]

Interpolation nennt man das. In PHP benutzt man " nur wenn man Steuerzeichen ausgeben will, oder ab-und-zu mal eine Variable innerhalb einen Strings. Bei mehreren "Ersetzungen" bietet sich printf() bzw. sprintf() an.