nicht angemeldet
PHP Sicherheit: SQL Injection
Ich habe letztens eine Webseite optimieren lassen. Der Programmierer meinte, dass er meine Seite sicher machen will und hat auch seiner Meinung nach auch alles korrigiert, so dass ich gegen SQL Injection geschützt bin. Bevor die Seite online geht, wollte ich mir die Daten genauer anschauen und ich habe eine neue Seite bemerkt und des weiteren WinMerge benutzt und keine großen Unterschiede bemerkt. Kann mir mal einer sagen, 1. was die class.stmp macht und 2. wie ein typischer Datenstrang gegen den SQL Injection aussieht? Also ich möchte irgendwas in der PHP Datei finden, die typisch ist, was gegen SQL injection schützt.
Ist sowas gegen SQL Injection? $_GET["id"] = (int)$_GET["id"];
Hier die class.stmp. Die Email Adresse + Password + Textinhalt habe ich gelöscht/ersetzt:
<?php
class smtp {
private $sock;
private $connected = false;
private $content_type;
private $errormsg;
function \_\_construct($host, $user, $pass, $port = 25) {
$this->sock = socket\_create(AF\_INET, SOCK\_STREAM, getprotobyname("tcp"));
socket\_connect($this->sock, $host, $port);
$version = socket\_read($this->sock, 1024);
socket\_write($this->sock, "EHLO $host\r\n");
$response = socket\_read($this->sock, 1024);
if (ereg("LOGIN", $response)) {
socket\_write($this->sock, "AUTH LOGIN\r\n");
$response = socket\_read($this->sock, 1024);
if (ereg("334", $response)) {
socket\_write($this->sock, base64\_encode($user) . "\r\n");
$response = socket\_read($this->sock, 1024);
if (ereg("334", $response)) {
socket\_write($this->sock, base64\_encode($pass) . "\r\n");
$response = socket\_read($this->sock, 1024);
if (ereg("235", $response))
$this->connected = true;
}
}
}
}
function isConnected() {
return $this->connected;
}
function getError() {
if ($this->errormsg != "")
return $this->errormsg;
}
function sendMail($from, $to, $replyTo, $subject, $msg) {
socket\_write($this->sock, "mail from: ABC@yahoo.com.ar\r\n");
$response = socket\_read($this->sock, 1024);
if (ereg("250", $response)) {
socket\_write($this->sock, "rcpt to: $to\r\n");
$response = socket\_read($this->sock, 1024);
if (ereg("250", $response)) {
socket\_write($this->sock, "data\r\n");
$response = socket\_read($this->sock, 1024);
if (ereg("354", $response)) {
// en hotmail el header Date no se puede cambiar
// el encabezado llega tal cual lo mande, pero dentro del mail, se muestra con la hora real
// en yahoo se puede cambiar
// headers
$message = "";
$message .= "Content-Type: " . $this->content\_type . " charset='utf-8'\r\n";
$message .= "From: $from\r\n";
$message .= "To: $to\r\n";
$message .= "Reply-To: $replyTo\r\n";
$message .= "Subject: $subject\r\n\r\n";
$message .= $msg;
$message .= "\r\n";
$message .= ".";
$message .= "\r\n";
socket\_write($this->sock, $message . "\r\n" . "." . "\r\n");
$response = socket\_read($this->sock, 1024);
// si no se lee la ultima respuesta, no se puede volver a mandar otro mail
if (ereg("250", $response))
$this->errormsg = "";
} else {
$this->errormsg = "[DATA error]";
}
} else {
$this->errormsg = "[RCPT TO error]";
}
} else {
$this->errormsg = "[MAIL FROM error]";
}
}
function setContentType($type) {
if ($type == "text")
$this->content_type = "text/plain;";
else if ($type == "html")
$this->content_type = "text/html;";
}
}
// $smtp = new smtp("smtp.mail.yahoo.com.ar", "...", "...");
// $smtp->isConnected();
// $smtp->setContentType("text");
// $smtp->sendMail("....@yahoo.com.ar", "ABC", "...P");
?>
-
Hallöchen auch,
... Kann mir mal einer sagen, 1. was die class.stmp macht und 2. wie ein typischer Datenstrang gegen den SQL Injection aussieht? Also ich möchte irgendwas in der PHP Datei finden, die typisch ist, was gegen SQL injection schützt.
Ist sowas gegen SQL Injection? $_GET["id"] = (int)$_GET["id"];
Nein!
mysql_real_escape_string($_GET['id'])) wäre z.B. ein Schutz gegen Injection.
Hier die class.stmp. Die Email Adresse + Password + Textinhalt habe ich gelöscht/ersetzt:
<cut>
Diese Klasse ist für Email-Versand zuständig.MfG
cross-
Hi!
- wie ein typischer Datenstrang gegen den SQL Injection aussieht? Also ich möchte irgendwas in der PHP Datei finden, die typisch ist, was gegen SQL injection schützt.
Ist sowas gegen SQL Injection? $_GET["id"] = (int)$_GET["id"];
Nein!Ja! Hier wird durch den Typecast sichergestellt, dass $_GET["id"] eine Integerzahl ist. Damit kann man garantiert keine SQL-Injection betreiben.
mysql_real_escape_string($_GET['id'])) wäre z.B. ein Schutz gegen Injection.
Nicht in jedem Fall: http://wiki.selfhtml.org/wiki/Artikel:Kontextwechsel#Zahlen_im_.28My.29SQL-Statement
Lo!
-
Hallöchen auch,
Ist sowas gegen SQL Injection? $_GET["id"] = (int)$_GET["id"];
Nein!Ja! Hier wird durch den Typecast sichergestellt, dass $_GET["id"] eine Integerzahl ist. Damit kann man garantiert keine SQL-Injection betreiben.
Überredet! Ich war oberflächlich davon ausgegangen, dass $_GET['id'] nicht zwangsläufig eine Zahl ist.
mysql_real_escape_string($_GET['id'])) wäre z.B. ein Schutz gegen Injection.
Nicht in jedem Fall: http://wiki.selfhtml.org/wiki/Artikel:Kontextwechsel#Zahlen_im_.28My.29SQL-Statement
deshalb schrieb ich "z.B."
MfG
cross -
Nicht in jedem Fall: http://wiki.selfhtml.org/wiki/Artikel:Kontextwechsel#Zahlen_im_.28My.29SQL-Statement
Hey.
Der Artikel ist zwar ziemlich informativ, aber ich find das doch insgesamt relativ abstrakt. Das ist schon mehr eine Einleitung zu einem Programmierhandbuch. (naja, vermutlich ist es das auch, TL;DR)Der Teil über die Prepared Statements kommt aber eindeutig zu kurz. Wenn schon so ein langer Artikel über Sicherheit beim String-Verketten, dann sollte auch die standardisierte Profilösung entsprechend mit Beispiel untermauert werden.
G!
-
Hi!
Der Artikel ist zwar ziemlich informativ, aber ich find das doch insgesamt relativ abstrakt. Das ist schon mehr eine Einleitung zu einem Programmierhandbuch. (naja, vermutlich ist es das auch, TL;DR)
Es ist ja auch eines der wichtigsten und am häufigsten missachteten Themen.
Der Teil über die Prepared Statements kommt aber eindeutig zu kurz. Wenn schon so ein langer Artikel über Sicherheit beim String-Verketten, dann sollte auch die standardisierte Profilösung entsprechend mit Beispiel untermauert werden.
Prepared Statements sind nicht als Sicherheitsfeature konzipiert. Es ist ohne Frage sinnvoll, darüber ausführlicher zu schreiben, dann aber eher um generell in das Thema einzuführen, was einen eigenständigen Artikel rechtfertigt - in meinen Augen. Es ist ja nicht so, dass man mal eben schnell das mysql_query() durch eine Prepared-Statement-Funktion ersetzt, da braucht es schon noch etwas mehr Umbau des Scripts - deutlich mehr als das Maskieren in den bisherigen Code einzubringen.
Lo!
-
Moin!
Der Teil über die Prepared Statements kommt aber eindeutig zu kurz. Wenn schon so ein langer Artikel über Sicherheit beim String-Verketten, dann sollte auch die standardisierte Profilösung entsprechend mit Beispiel untermauert werden.
Prepared Statements sind aus meiner Sicht eher als Performance-Steigerung zu verstehen, denn als Security-Lösung. Sie sind genau dann sinnvoll, wenn man ein gleichartiges Statement mehrfach mit unterschiedlichen Daten benutzen will - egal ob lesend oder schreibend.
Das Problem ist nur: Mit PHP muss für jeden Browser-Request immer wieder alles neu initialisiert werden.
Ein Prepared Statement hat daher eigentlich nur begrenzten Performance-Wert und wird daher oft nicht eingesetzt. Und erfordert die Nutzung der MySQLi-Extension, was vielen Programmierern offenbar noch Unbehagen bereitet. Es ist daher praxisfern, diese Lösung als "Profilösung" zu propagieren - denn das ist sie in der Tat: Sie wird, wenn überhaupt, nur in Umfeldern genutzt werden, die aufgrund ihrer Anforderungen eher als extrem zu bezeichnen sind, also extreme Performanceanforderung bei extrem ungewöhnlichem Query- oder Datenaufkommen, extrem ungewöhnliches PHP-Setup (lang laufende Skripte), etc. - und sie erfordern entsprechend ausgebildetes Programmierpersonal.
- Sven Rautenberg
-
-
-
Ich muss was zufügen:
Die Class.stmp Dateien stammen nicht von mir. Das heißt, es ist nicht meine Email Adresse und meine Zugangsdaten, sondern von jemand anderes. Deshalb war ich irritiert, ob dadurch von meiner Webseite aus irgendwelche versteckten Nachrichten rausgehen. Daher habe ich gefragt, wie genau die class.stmp funktioniert.
-
Hi!
Die Class.stmp Dateien stammen nicht von mir. Das heißt, es ist nicht meine Email Adresse und meine Zugangsdaten, sondern von jemand anderes. Deshalb war ich irritiert, ob dadurch von meiner Webseite aus irgendwelche versteckten Nachrichten rausgehen. Daher habe ich gefragt, wie genau die class.stmp funktioniert.
Sie macht erst einmal nichts weiter als den Code der Klasse zu enthalten. Am Ende findest du ein auskommentiertes Anwendungsbeispiel. Du müsstest also nach new smtp suchen oder auch nach sendMail, wenn du wissen willst, wo sie angewendet wird. Wenn das passiert, sendet sie eine Mail direkt an den im Konstruktor angegebenen SMTP-Server. Wobei noch die Zeile
socket_write($this->sock, "mail from: ABC@yahoo.com.ar\r\n");
kontraproduktiv sein kann, alles andere ist ja variabel gestaltet.
Lo!
-
Hi!
Die Class.stmp Dateien stammen nicht von mir. Das heißt, es ist nicht meine Email Adresse und meine Zugangsdaten, sondern von jemand anderes. Deshalb war ich irritiert, ob dadurch von meiner Webseite aus irgendwelche versteckten Nachrichten rausgehen. Daher habe ich gefragt, wie genau die class.stmp funktioniert.
Danke! Ich habe nur die geänderten Dateien angeschaut und die anderen waren halt nur Index.php und paar andere profilsachen, also nix mit sendmail oder ne neue stmp Datei.Danke
-
Moin!
Hi!
Die Class.stmp Dateien stammen nicht von mir. Das heißt, es ist nicht meine Email Adresse und meine Zugangsdaten, sondern von jemand anderes. Deshalb war ich irritiert, ob dadurch von meiner Webseite aus irgendwelche versteckten Nachrichten rausgehen. Daher habe ich gefragt, wie genau die class.stmp funktioniert.
Danke! Ich habe nur die geänderten Dateien angeschaut und die anderen waren halt nur Index.php und paar andere profilsachen, also nix mit sendmail oder ne neue stmp Datei.Danke
Wenn dir die Datei suspekt ist:
1. Du kannst sie löschen und dann sehen, ob noch alles funktioniert.
2. Du kannst deinen Programmierer natürlich auch fragen, warum die Datei da ist und wozu sie gut ist. Kann ja auch aus Versehen mit hochgeladen worden sein.- Sven Rautenberg
-
-
-