SQL-Injection

Moin,

ich befasse mich grade mit dem Thema SQL-Injection, bzw Verhinderung
selbiger. Je mehr ich allerdings lese, umso verwirrter werde ich.

Soweit ich das bisher sehe, geht es im Wesentlichen um die folgenden zwei
Bereiche:
a) Alle Variablen, die ich in eine SQL-Query einbaue, sind auf erlaubten Typ
und Wertebereich zu prüfen.
b) Sonderzeichen sind zu maskieren.

Jetzt ist mir nur nicht so ganz klar, was da ausreicht.

Die PHP-FAQ sagt:
16.18. Wie kann ich bösartigen Code in SQL-Abfragen unterbinden?
http://www.php-faq.de/q/q-sql-injection.html

und stellt u.a. folgende Funktionen vor:

function sqlSafeString($param) {
return (NULL === $param ? "NULL" : '"'.mysql_escape_string ($param).'"');
}

function sqlSafeInt($param) {
return (NULL === $param ? "NULL" : intVal ($param));
}

Bin ich damit auf der sicheren Seite, wenn ich meine Queries z.B. wie folgt
aufbaue:
"SELECT foo FROM table WHERE id=" . sqlSafeInt($_POST['id'])
(Angenommen $id kommt über ein Post-Formular und muss Int sein)
oder
"SELECT vorname FROM table WHERE name=" . sqlSafeString($_POST['name'])
(Angenommen $name kommt über ein Post-Formular und muss String sein)


Oder übersehe ich was entscheidendes?

Grüße
Günther

--
Now playing:
A Perfect Circle - When the Levee Breaks
Emotive (2004)

Re: SQL-Injection

"Guenther Theilen" schrieb im Newsbeitrag
news:d2tj0u$ru1$05$1@news.t-online.com...
> Moin,
>
> ich befasse mich grade mit dem Thema SQL-Injection, bzw Verhinderung
> selbiger. Je mehr ich allerdings lese, umso verwirrter werde ich.
>
> Soweit ich das bisher sehe, geht es im Wesentlichen um die folgenden zwei
> Bereiche:
> a) Alle Variablen, die ich in eine SQL-Query einbaue, sind auf erlaubten
Typ
> und Wertebereich zu prüfen.
> b) Sonderzeichen sind zu maskieren.
>
> Jetzt ist mir nur nicht so ganz klar, was da ausreicht.
>
> Die PHP-FAQ sagt:
> 16.18. Wie kann ich bösartigen Code in SQL-Abfragen unterbinden?
> http://www.php-faq.de/q/q-sql-injection.html
>
> und stellt u.a. folgende Funktionen vor:
>
> function sqlSafeString($param) {
> return (NULL === $param ? "NULL" : '"'.mysql_escape_string
($param).'"');
> }

Schau mal nach was mysql_real_escape_string() mehr macht.

> function sqlSafeInt($param) {
> return (NULL === $param ? "NULL" : intVal ($param));
> }
>
> Bin ich damit auf der sicheren Seite, wenn ich meine Queries z.B. wie
folgt
> aufbaue:
> "SELECT foo FROM table WHERE id=" . sqlSafeInt($_POST['id'])
> (Angenommen $id kommt über ein Post-Formular und muss Int sein)
> oder
> "SELECT vorname FROM table WHERE name=" . sqlSafeString($_POST['name'])
> (Angenommen $name kommt über ein Post-Formular und muss String sein)

Lesbarer wird es wenn du

$sql = sprintf("SELECT vorname from table WHERE name=%s and id=%d",
sqlSafeString($_POST['name']),
sqlSafeInt($_POST['id'])
);

es schreibs. Wichtig ist halt das Strings in Quotes stehen und Quotes
innerhalb des Strings maskiert werden damit man das Statement nicht
umschreiben kann.

>
> Oder übersehe ich was entscheidendes?

Nein.
Zusaetzlich sollte der Anwender auf der Webseite niemals das Statement als
Teil einer Fehlerausgabe sehen. Also auch nicht die direkten Fehlerausgaben
des DB Clients.

Gruss
Joerg

--
TakeNet GmbH Mobil: 0171/60 57 963
D-97080 Wuerzburg Tel: +49 931 903-2243
Alfred-Nobel-Straße 20 Fax: +49 931 903-3025

Re: SQL-Injection

Joerg Behrens (Dienstag, 5. April 2005 11:01):

> Schau mal nach was mysql_real_escape_string() mehr macht.

Yep, das sollte da eigentlich auch stehen...

> Lesbarer wird es wenn du
>
> $sql = sprintf("SELECT vorname from table WHERE name=%s and id=%d",
> sqlSafeString($_POST['name']),
> sqlSafeInt($_POST['id'])
> );

Stimmt, sieht besser aus.

> Zusaetzlich sollte der Anwender auf der Webseite niemals das Statement als
> Teil einer Fehlerausgabe sehen. Also auch nicht die direkten
> Fehlerausgaben des DB Clients.

Ah ja, das hatte ich nicht bedacht.
Muss ich mal gucken, was AdoDB da so anbietet.
Was ist sinnvoll? Error-Logging in eine Datei?

Danke und Grüße
Günther

--
Now playing:
Death Cab for Cutie - Bend to Squares
Something About Airplanes (1999)

Re: SQL-Injection

Guenther Theilen schrieb:
> Joerg Behrens (Dienstag, 5. April 2005 11:01):

Interessant in diesem Zusammenhang:



>>Zusaetzlich sollte der Anwender auf der Webseite niemals das Statement als
>>Teil einer Fehlerausgabe sehen. Also auch nicht die direkten
>>Fehlerausgaben des DB Clients.

> Was ist sinnvoll? Error-Logging in eine Datei?

Ja, du kannst auch einen Syslog-Server nehmen, in eine Datenbank
schreiben, was auch immer. Wichtig ist, dass der Benutzer das Statement
nicht sieht*, weil ein möglicher Angreifer damit sehr schnell
feststellen kann, wie er es umbauen muss. Damit du dennoch feststellen
kannst, wo und wann in deiner Anwendung Fehler auftreten, solltest du
sie halt loggen.

* das gilt nicht nur für SQL-Statements, sondern auch für Dateipfade.

MfG,
Thomas

Re: SQL-Injection

Post removed (X-No-Archive: yes)

Re: SQL-Injection

Post removed (X-No-Archive: yes)