SQL-Injection

[Gumbo]

Ich muß hier überhaupt nix beweisen!
Und ja du hast es nicht verstanden und das ist auch so gut.Den Leute wie du sind die ersten die versuchen dies dann auszunutzen (script Kids).

Da du hier eine recht provokative aber für mich erst mal nicht plausible Behauptung aufgestellt hast, wäre es schon sinnvoll, diese durch Beweise zu stützen.

Das Argument, dass dies aus Sicherheitsgründen nicht möglich sei, lasse ebenfalls ich nicht gelten. Der Angriffsvektor Code Injection ist ja keine SQL-spezifische Schwachstelle sondern ein allgemeines Problem, das auch auf andere Sprachen zutrifft.

 

[GelbesKüken]

1. Danke für die Beleidigung.

2. Das ist immer gut, wenn man 2 Begriffe durcheinander haut und dann meint, man habe den anderen gemeint.

3.Es ist natürlich immer einfach etwas zu behaupten, wenn man seine Aussagen nicht belegen muss, weil man es nicht kann.

4.Gibst du Quellen an, die du dann selbst als unzulänglich deklarierst, nachdem dir jemand sagt was drin steht.

Naja ist ok, möchte diese Debatte auch nicht weiter führen, da sie mir in dieser Wortwahl und mit dieser Argumentation keinen Spaß macht.

@Sasser :
Also du hast jetzt keine Antwort bekommen auf deine Frage. Also ich würde mal Prüfen ob die Funktion nicht abgeschaltet wurde bei dir, weiß ja nicht wer deinen Server konfiguriert hat. Bzw. musste ja auch noch gucke ob magic_quotes an oder aus sind.
Oder du machst es so wie es splasch gesagt hat.

 

[splasch]

@Gumbo

Dir würd ich die Unterlagen schicken da ich denke das du damit Verantwortungs bewußt umgehst und es nicht einfach ausnutzt.

Die Information stehen kurz zusammen gefasst in einer Powerpoint Presentation Datei.
Mit dem verschiedensten Angriff verfahren. ca 49 Seiten. In dem nur mögliche Angriff Methoden dar gestellt werden und da gibst sicher auch noch mehrere Möglichkeiten keiner wird wohl alle kennen.
(Hab dir so eben eine Private Nachricht geschickt mit den Information gehe sorgfälltig damit um !)

@GelbesKüken

Es hat dich hier niemand Beleidig das sind erfahrungswerte die den Tatsachen entsprechen.

Schade das man immer wieder sachen beweisen muß was doch schon oft bassiert ist.
IT Welt einfach mal Nachrichten lesen da stehen immer mal wieder Berichte drin.


Mfg Splasch

ps.
(kein System ist 100% sicher .Warum also dann auf mehr Schutz verzichten wenn schon dazu die Möglichkeit geboten wird?)

 

[Gumbo]

Deine Vorsicht in allen Ehren, splasch. Aber ich sehe trotz deines Hinweises auf die Präsentation keinen Grund dafür, nicht weiterhin die Nutzung der mysql_real_escape_string()-Funktion zu empfehlen.
Auch halte ich die Inhalte der Präsentation nicht für dermaßen brisant, dass ihre Veröffentlichung ein Sicherheitsrisiko wäre. Der Verfasser sieht das übrigens ebenfalls so, da er sie sonst nicht veröffentlicht hätte.

 

[splasch]

Tatsache ist das eine Sql Injection damit möglich ist. Auch in einen mysql_real_escape_string geschützen Bereich. Wie brisant man das hält ist geschmack sache eines jeden.

Aber ich sehe trotz deines Hinweises auf die Präsentation keinen Grund dafür, nicht weiterhin die Nutzung der mysql_real_escape_string()-Funktion zu empfehlen

Ich hab nie gesagt das man Schutz massnahmen nicht weiter empfehlen soll. Aber es spricht auch nix dagend warum man nicht bessere Schutz massnahmen nennen soll.

Gerade wenn jemand nach den Thema frag wie kann ich mich am besten Schützen dann sollte man auch die besten bekannten Methoden auch nennen.
(Und schon garnicht das eine mit dem anderen Gleich stellen.Die php Entwickler haben sich nicht grundlos dazu gedanken gemacht und besser Methoden dagen bereit gestellt.)

Was anderes ist wenn jemand frag wie kann ich mich ein wenig Schützen vor Sql Injection.

Mfg Splasch

 

[GelbesKüken]

Also einmal hast du scheinbar gar nicht gelesen was der gute Mensch da oben eig. wissen wollte.
Er wollte wissen wieso es nicht geht und nicht angeschnauzt werden mit den Worten

Falsch machst du das die alten sachen immer noch verwendest

Außerdem gibt es nicht "ein wenig Sicherheit" wenn die Funktion einfach überlistet werden kann, dann ist sie unnütz. Weil dann jeder dieses umgehen würde und dann würde diese Funktion nicht immer noch "angepriesen" werden.
Ich sehe den Unterschied im Stil und nicht in der Sicherheit.
Das Recht, Recht zu haben, ist ein Recht für denjenigen der Recht hat und nicht für jemanden Recht haben will.
Ich beschäftige mich seit Jahren mit PHP und es gibt immer noch viel was ich lernen kann / muss. Deshalb lese ich alles was mir in Sachen Server- und Programmsicherheit in die Hände fällt.
Ich lasse mich von Tatsachen überzeugen, aber nicht von Geschwätz das keine Argumente hervorbringt, außer

Den Leute wie du sind die ersten die versuchen dies dann auszunutzen (script Kids).

1. Danke für die Beleidigung.

Es hat dich hier niemand Beleidig das sind erfahrungswerte die den Tatsachen entsprechen.

Naja, scio nescio

 

[zeroize]

Hallo liebe Board-Trolle!
Ich wünsche schöne Weihnachten und wie immer hat keiner Recht

Natürlich gibt es Sicherheitslücken in PHP und natürlich sollte man neue Funktionen nutzen.
Aber natürlich sind alte Funktionen deshalb nicht schlechter zu bewerten.
Natürlich kann man nicht jede Securitymeldung über PHP lesen - das können ja noch nicht einmal die Programmierer von PHP selbst
Natürlich muss man mit Beweisen (bestenfalls Links - Privatmails nützen nur EINER Person, nicht ALLEN - Forumsgedanke, etc.) argumentieren, sonst könnte ich ja auch behaupt Windows 7 könnte auch auf Waschmaschinen laufen.

Ich frage mich allerdings, warum ihr euch hier so fertig macht? Ist das alles gut, oder? Endweder man nutzt die alte Funktion oder die OOP-Varianten.

Schöne Weihnachten

 

[Gumbo]

Tatsache ist das eine Sql Injection damit möglich ist. Auch in einen mysql_real_escape_string geschützen Bereich.

Eben dies hast du aber nicht bewiesen. Du hast noch nicht bewiesen, dass trotz korrekten Einsatzes von mysql_real_escape_string() das Einschleusen von Schadcode möglich ist.

Ich geb zu, Prepared Statements sind bequemer. Schutz bieten sie jedoch meines Wissens gleichermaßen.

 

[Dennis Wronka]

Okay, here we go...

Das geht jetzt hauptsaechlich in Richtung splasch, aber es darf ruhig von jedem gelesen werden...

Also: mysql_real_escape_string() mag nicht den ultimativen Schutz darstellen, aber wie Du schon selbst sagst gibt es keine absolute Sicherheit.
Die Sicherheit eines Systems (ob dies nun ein Betriebssystem, eine Website oder meinetwegen ein Toaster ist) ist immer nur so gut wie

• die Erfahrung des "Herstellers" (damit's auch beim Toaster passt ) es zulaesst
• und es in dem "Hersteller" moeglich ist diese Erfahrung umzusetzen (wobei sowohl technische als auch zeitliche Faktoren eine Rolle spielen)

Auf irgendeiner Seite (es koennte LinuxSecurity.com gewesen sein) hab ich mal einen Bericht gelesen wo ueber einen bestimmten Zeitraum (ich glaub es war ein Jahr) Webseiten, darunter grosse, viel besuchte Seiten, auf Sicherheitsluecken geprueft wurden und die Resultate auch den Betreibern bekannt gemacht wurden.
Rate mal wie viel sich nach Ablauf der Zeit getan hat?

Prepared Statements sind auch nur solange sicher bis jemand eine Luecke in den genutzten Statements entdeckt, was frueher oder spaeter sowieso der Fall ist.
Dadurch dass Sicherheitsluecken in der Regel der Oeffentlichkeit bekannt gemacht werden (z.B. durch Seiten wie SecurityFocus) finden Interessierte die Informationen oft zeitnah und koennen diese Informationen umsetzen.

Das Problem ist nur dass eben nicht viel getan wird. Selbst wenn derjenige schon mit der Nase in die Pisse gedrueckt wird passiert nicht viel, oder sogar nichts...

Sicherheit ist kein Zustand, es ist ein Prozess. Ein System das heute sicher ist kann morgen gravierende Sicherheitsluecken aufweisen. Die Luecken waren bereits vorher da, nur hat sie halt noch keiner gefunden.

Dies stellt einen Website-Ersteller vor folgendes Problem:

Wird eine Schwachstelle entdeckt sollte diese natuerlich geschlossen werden.
Nicht jeder hat Lust staendig seine Website zu ueberarbeiten um kleine Probleme auszumerzen. Bei grossen Projekten kann dies auch mal durchaus in Arbeit ausarten.
In kommerziellen Umfeld stellt sich das noch ganz anders dar: Wenn jemand seine Website extern hat anfertigen lassen hat der Besitzer der Seite meist garkeine Ahnung was er machen koennte, wenn er denn ueberhaupt irgendwie davon erfaehrt dass seine Seite Sicherheitsluecken hat.
Entsprechend muss hier nochmal in die Tasche gegriffen werden um das Problem beseitigen zu lassen. Egal ob dies nun intern oder extern geschieht, es ist ein Kostenfaktor.

Security ist ein grosses Thema, und es erfordert viel Lektuere um einigermassen mitreden zu koennen.
In vielen Unternehmen hat man als IT-Angestellter schlichtweg nicht die Zeit um sich diesem Thema in dem Masse zu widmen in dem es noetig waere.
Security ist somit entweder ein Thema welches nicht oder zuwenig beachtet wird, oder ein klarer Fall fuer's Outsourcing.

So, ich koennte noch einiges zu diesem Thema loswerden, aber ich denke ich widme mich nun wieder meinem Bier und schau weiter dem Brotbackautomaten zu...

 

[Sasser]

OK vielen Dank für die vielen Antworten!

Also werde ich gleich die neuen Funktionen nutzen. Allerdings frage ich mich, wie ich diese korrekt z.B. hier einbaue?

function connect_db() {
	$dbhost = "localhost";
	$dbuser = "";
	$dbpwd = "";
	$dbname = "";
	$db = @mysql_connect ( $dbhost, $dbuser, $dbpwd );
	@mysql_select_db ( $dbname, $db ) or die ( "Aufgrund hoher Nachfrage ist die Datenbank zur Zeit überlastet!" );
	return $db;
}

$db = connect_db ();
        $row = mysql_fetch_assoc ( mysql_query ( "SELECT * FROM user WHERE `sessionID` = '$sessionID'", $db ) );
        mysql_close ( $db );