Ginge zum Beispiel mit dem Diffie Hellman Schlüsselaustausch.

Das hast du richtig erkannt und das war auch meine Ambition mal die meine MySql Lib zu erweitern, dass man das PHP Script mit dem Programm verknüpfen kann. So dass Queries NUR von diesem Programm akzeptiert werden.

Dieser Mechanismus ist ziemlich ausgeklügelt, aber ich habe sowas hinbekommen, muss nur mal Zeit finden es zum Abschluss zu bringen.
Ansonsten gibt es schonmal diverse kleine Mechanismen Browser usw. auszuschließen. Indem man z.B. seinen eigenen UserAgent String hat der im PHP Script ausgewertet wird, wer jedoch sein eigenes Netz Snifft bekommt somit auch die übermittelten Variblen und Header angaben heraus und kann diese nachbauen.

Diffie Hellman wird nicht viel bringen, damit kann man nur eine aktuelle Verbindung verschlüsseln, also die Daten die übermittelt werden, aber trotzdem könnte jeder mit dem Verfahren sich seinen eigenen Key generieren, da das PHP Script ja die werde aus ausgeben muss und somit kann man trotzdem Schad-Queries ausführen.

Wenn jemand Snifft, bekommt man genau die URL heraus die gerade abgefragt wird.

Sicherlich gibt es möglichkeiten, aber die sind äußerst schwer umzusetzten.

Dodo schrieb:

Diffie Hellman wird nicht viel bringen, damit kann man nur eine aktuelle Verbindung verschlüsseln, also die Daten die übermittelt werden, aber trotzdem könnte jeder mit dem Verfahren sich seinen eigenen Key generieren, da das PHP Script ja die werde aus ausgeben muss und somit kann man trotzdem Schad-Queries ausführen.

ich stell mir vor, man macht nach diffie-hellmann einen nur für diese Sitzung geltenden schlüsseltausch klar, und dann erst überträgt man (verschlüsselt!) die anmeldeDaten, also das individuelle passwort des berechtigten users.
Wennich SSL recht verstanden habe, wird dabei so vorgegangen (und ausserdem noch zertifiziert, um man in the middle - angriffe zu vereiteln).

Das hilft ihm aber nicht bei dem eigentlichen Problem.
Es wird die aktuelle Kommunikation verschlüsselt, das ist korrekt, möchte man nun aber z.B. ganze SQL Queries übermitteln, könnte sich der Angreifer auch ganz einfach einen Schlüssel generieren, das PHP Script liefert ja die Werte zum Schlüssel austausch, dann kodiert er sein Schad Query mit dem Schlüssel und schickt ihn an das Script und schon wird die gesamte DB gelöscht z.B.
Hier muss man sicherstellen, das NUR das eigene Programm auf das Script zugreifen kann und man den Mechanismus möglichst NICHT herausbekommt, so dass man ihn nachprogrammieren könnte.

@mottzi: nein zu solchem Thema wirste auch sicher nichts finden, das sit zu speziell, aber wenn man einfach mal bischel sein Kopf anstrengt, bischel rumtüftelt, kann man durchaus mechanismen finden. Ich habe ja auch einen gefunden, den ich aber nicht preisgebe, da er in meiner neuen Lib verwendet wird und wenn ich ihn sage, wäre das natürlich reichlich doof

ich sagte: wenn die aktuelle kommunikation verschlüsselt ist, dann werden die eigentlichen anmeldedaten übertragen, sonst läuft nix.
Der Angreifer kann also ebenso eine sichere Kommunikation zum Server aufbauen, aber dann kanner nix mehr machen, denn er hat keine AnmeldeDaten.

Achso meinste das, das wäre z.B. ein Mechanismus, das stimmt, siehste, das is mir noch gar nicht in Sinn gekommen, glaube das könnte ich auch noch in meine Lib einbauen, Danke =)

Zwar gehöht sich die Anzahl der Requests von 2 auf 3, das dürfte dann sich bei schnellen Abfragen schon deutlich auf die Geschwindigkeit auswirken.