[HaBo]

PCFreund · 08.05.10, 17:08

Ich hab hier 'mal ein kleines Script gebastelt, das Einträge "codiert" in die Datenbank schreibt:

Code:

function real_encode_string($string) {
    $firststring = array("a", "e", "i", "o", "u", "A", "E", "I", "O", "U");
    $secondstring = array("<:a:>", "<:e:>", "<:i:>", "<:o:>", "<:u:>", "<:A:>", "<:E:>", "<:I:>", "<:O:>", "<:U:>");
    $string = str_replace($firststring, $secondstring, $string);
    return $string;
}
function real_decode_string($string) {
    $firststring = array("a", "e", "i", "o", "u", "A", "E", "I", "O", "U");
    $secondstring = array("<:a:>", "<:e:>", "<:i:>", "<:o:>", "<:u:>", "<:A:>", "<:E:>", "<:I:>", "<:O:>", "<:U:>");
    $string = str_replace($secondstring, $firststring, $string);
    return $string;
}

Meine Frage 'nun an euch:
Ist dieses Script sicher genug?
Dass es mysql_query's in mysql_q<:u:><:e:>ry's umwandelt, müsste klar sein

Der Server müsste dann die Befehle nicht mehr erkennen, stimmt das?

L.G. PCFreund
PS: Ja ihr dürft den Script verwenden, war ja nich so schwer

beavisbee · 08.05.10, 18:52

Gegenfrage: was genau erwartest du dir von dem Script? Dass es SQL-Injections unterbindet?

In SQL-Injections wirst du kein "mysql_query" finden, sondern Code, welcher den reinen SQL-Code (also das was IN mysql_query(....) steht) manipuliert.

Dieses Script von dir ist in meinen Augen nur unnötiges Aufblähen und bringt keinen großen Gewinn.

Viel wichtiger ist, dass du sämtliche User-Eingaben mittels mysql_real_escape_string() escapest und z.B. dort, wo Zahlen erwartet werden, explizit in int castest, dort wo Fließkommazahlen erwartet werden explizit in float castest und da, wo ein ganz bestimmtes Format erwartet wird (E-Mail-Adressen, URLs), mit regulären Ausdrücken prüfst, ob die Eingaben korrekt sind.

Anzeige

- Anzeige -

Dresko · 08.05.10, 20:02

Ich sehe das genauso. Das Script wird dir nichts bringen.

Beherzige beavisbee's Sicherheitstipps und verwende zusätzlich noch Whitelists. Wenn du also irgendwo eine bestimmte ID erwartest, prüfe anhand einer Whitelist ob es die ID auch gibt, usw.

easteregg · 09.05.10, 11:44

mich würd mal der ansatz hinter deinen sript da interessieren?
gehst du davon aus, das alle schädlichen befehle mit vokalen daherkommen und du die so rauskickst?

PCFreund · 09.05.10, 11:48

Zitat:

Gegenfrage: was genau erwartest du dir von dem Script? Dass es SQL-Injections unterbindet?

In SQL-Injections wirst du kein "mysql_query" finden, sondern Code, welcher den reinen SQL-Code (also das was IN mysql_query(....) steht) manipuliert.

1. jap ich will sql-injections unterbinden
2. "INSERT INTO `test` SET `bla` = 'xD'" wird zu
"<:I:>NS<:E:>RT <:I:>NT<:O:> `t<:e:>st` S<:E:>T `bl<:a:>` = 'xD'"

gibts von außen trotzdem noch irgendwie eine möglichkeit, mich hacken zu können ?!
und achja:
mysql_real_escape_string() wird davor ausgeführt

easteregg · 09.05.10, 11:51

wenn du mysql_real_escape_strings() schon drin hast, wozu dann das noch?
und ja, es gibt IMMER möglichkeiten irgendwo was zu hacken. auch profis bauen hier und da sicherheitslücken rein, einfach weil irgendwas zu komplex wurde.
sicher is netzwerkkabel ziehen

Inliferty · 09.05.10, 12:25

Würde eher auf mysql_real_escape_string setzen.
Oder meiner Meinung nach noch besser ist PDO [1].
Bei solchen selbstgebastelten Sachen hat man dann immer das Problem mit normalen Usereingaben :/

MfG Inliferty

[1] http://php.net/manual/de/book.pdo.php

Dresko · 09.05.10, 15:24

Zitat:

Zitat von PCFreund

1. jap ich will sql-injections unterbinden
2. "INSERT INTO `test` SET `bla` = 'xD'" wird zu
"<:I:>NS<:E:>RT <:I:>NT<:O:> `t<:e:>st` S<:E:>T `bl<:a:>` = 'xD'"

gibts von außen trotzdem noch irgendwie eine möglichkeit, mich hacken zu können ?!

Ja.

Es gibt auch SQL-Injections, die ohne Vokale auskommen.
Das allseits Bekannte

Code:

' or 1=1/*

zum Beispiel.
Zudem könnte man das ein oder andere auch Hexadezimal schreiben.

Daher ist deine Idee im Prinzip überflüssig. Um SQL-Injections effektiv zu verhindern, musst du woanders ansetzen, z.B. wie es mysql_real_escape_string() tut. Allerdings ist das allein auch nicht 100%-ig sicher.

**CDW** · 09.05.10, 16:38

Was spricht eigentlich gegen Prepared_Statement oder PHP prepared-statements als Anti-SQL-Injection? Oder wäre das zu einfach

?

beavisbee · 09.05.10, 16:53

und was auch ganz nützlich ist: Dinge, gegen die man ein System absichern will, selbst probieren...

Also selbst mit dem Thema SQL-Injections beschäftigen, um zu verstehen, was da im Hintergrund passiert. Nur so kann man abschätzen, welche Maßnahmen sinnvoll sind und welche ehr weniger...

Inliferty · 09.05.10, 18:13

Zitat:

Zitat von CDW

Was spricht eigentlich gegen Prepared_Statement oder PHP prepared-statements als Anti-SQL-Injection? Oder wäre das zu einfach

?

Das hab ich mit PDO gemeint. Mir fiel nur der Begriff nichtmehr ein.
Danke CDW

Zitat:

Zitat von Dresko

' or 1=1/*

"or" hat meiner Meinung nach auch einen Vokal

Wenn du deinen Server wirklich sichern willst würde ich zuerstmal den Server richtig konfigurieren.
* mysql Port nur auf localhost binden
* Sonst nur die nötigen Ports nach außen forwarden (80, 25, 110, ...)
* SSH/phpMyAdmin nur mit Ip aus dem LAN -> Für den Zugriff von außen einen VPN-Server aufsetzen
* Apache Konfiguration (Logs, Information Disclosure, ...)
* Linux System -> chroot
* User-Rechte mit denen der Web-Service läuft
...

MfG
Inliferty

Dresko · 09.05.10, 18:16

Zitat:

Zitat von Inliferty

"or" hat meiner Meinung nach auch einen Vokal

Da hast du natürlich Recht.
Schande über mein Haupt, dass mir das net selber aufgefallen ist.

PCFreund · 12.05.10, 19:33

danke an euch, werde es demnächst noch sicher überarbeiten

L.G. PCFreund

Anzeige

- Anzeige -

08.05.10, 20:02	#3 (permalink)
Dresko Registriert seit: 30.01.10 Likes: 1	Ich sehe das genauso. Das Script wird dir nichts bringen. Beherzige beavisbee's Sicherheitstipps und verwende zusätzlich noch Whitelists. Wenn du also irgendwo eine bestimmte ID erwartest, prüfe anhand einer Whitelist ob es die ID auch gibt, usw. __________________ Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning. - Rick Cook -

09.05.10, 11:44	#4 (permalink)
easteregg Member of Honour Registriert seit: 14.09.07 Likes: 62	mich würd mal der ansatz hinter deinen sript da interessieren? gehst du davon aus, das alle schädlichen befehle mit vokalen daherkommen und du die so rauskickst? __________________ » Flattr mich! - Wenn dir mein Beitrag geholfen hat! « <\| 2 AMD Opterons 2384@ 8x3,2ghz \| Tyan S2915 \| 10GB \| 2x 8800GT \| 8400GS \| Dell 3008WFP + 2x2007FP \|>

09.05.10, 11:51	#6 (permalink)
easteregg Member of Honour Registriert seit: 14.09.07 Likes: 62	wenn du mysql_real_escape_strings() schon drin hast, wozu dann das noch? und ja, es gibt IMMER möglichkeiten irgendwo was zu hacken. auch profis bauen hier und da sicherheitslücken rein, einfach weil irgendwas zu komplex wurde. sicher is netzwerkkabel ziehen __________________ » Flattr mich! - Wenn dir mein Beitrag geholfen hat! « <\| 2 AMD Opterons 2384@ 8x3,2ghz \| Tyan S2915 \| 10GB \| 2x 8800GT \| 8400GS \| Dell 3008WFP + 2x2007FP \|>

09.05.10, 16:38	#9 (permalink)
CDW Moderator Registriert seit: 20.07.05 Likes: 202	Was spricht eigentlich gegen Prepared_Statement oder PHP prepared-statements als Anti-SQL-Injection? Oder wäre das zu einfach ? __________________ Noch mal, für alle Pseudo-Geeks: 1+1=0. -> 10 wäre Überlauf! Selig, wer nichts zu sagen hat und trotzdem schweigt.

Themen-Optionen
Druckbare Version zeigen Jemanden per E-Mail auf dieses Thema hinweisen
Ansicht
Linear-Darstellung Zur Hybrid-Darstellung wechseln Zur Baum-Darstellung wechseln

08.05.10, 18:52	#2 (permalink)
beavisbee Member of Honour Registriert seit: 22.02.07 Likes: 77	Gegenfrage: was genau erwartest du dir von dem Script? Dass es SQL-Injections unterbindet? In SQL-Injections wirst du kein "mysql_query" finden, sondern Code, welcher den reinen SQL-Code (also das was IN mysql_query(....) steht) manipuliert. Dieses Script von dir ist in meinen Augen nur unnötiges Aufblähen und bringt keinen großen Gewinn. Viel wichtiger ist, dass du sämtliche User-Eingaben mittels mysql_real_escape_string() escapest und z.B. dort, wo Zahlen erwartet werden, explizit in int castest, dort wo Fließkommazahlen erwartet werden explizit in float castest und da, wo ein ganz bestimmtes Format erwartet wird (E-Mail-Adressen, URLs), mit regulären Ausdrücken prüfst, ob die Eingaben korrekt sind.

09.05.10, 12:25	#7 (permalink)
Inliferty Registriert seit: 05.10.05 Likes: 5	Würde eher auf mysql_real_escape_string setzen. Oder meiner Meinung nach noch besser ist PDO [1]. Bei solchen selbstgebastelten Sachen hat man dann immer das Problem mit normalen Usereingaben :/ MfG Inliferty [1] http://php.net/manual/de/book.pdo.php

09.05.10, 16:53	#10 (permalink)
beavisbee Member of Honour Registriert seit: 22.02.07 Likes: 77	und was auch ganz nützlich ist: Dinge, gegen die man ein System absichern will, selbst probieren... Also selbst mit dem Thema SQL-Injections beschäftigen, um zu verstehen, was da im Hintergrund passiert. Nur so kann man abschätzen, welche Maßnahmen sinnvoll sind und welche ehr weniger...

12.05.10, 19:33	#13 (permalink)
PCFreund Themenstarter Registriert seit: 08.05.10 Likes: 0	danke an euch, werde es demnächst noch sicher überarbeiten L.G. PCFreund

[HaBo]

Datenbank-Einträge vor dem einfügen "codieren"