nicht angemeldet
Hi,
Da bin ich jetzt unsicher geworden.
Fein. Man sollte sich nie zu sicher fühlen. :)
ACK. Ich weiß leider nicht mehr, wer es in welcher Newsgroup sagte:
Sicherheit ist kein Ziel, sondern ein Weg.
Soll heißen: Sicherheit ist niemals ein erreichbarer Punkt, bei dem man sich entspannt zurücklehnen kann. Man muss _immer_ Sicherheitsaspekte im Hinterkopf (und idealerweise auch weiter vorne) behalten, stets die durchgeführten Prüfungen neu durchdenken.
Bei mySQL [...]
Zum Glück gibts "magic_quotes", [...]
Hm, ich dachte, MySQL beherrsche Bind-Variablen, finde aber spontan nichts darüber (auch keinen Hinweis in den PHP-Funktionen). Damit wäre dieses spezielle Problem leicht zu beheben. Kann jemand meinen Irrtum bestätigen? :-)
In der Tat sind es, wie bei PHP sehr häufig zu sehen, meist unerfahrene Programmierer, die noch nicht mal auf die Idee kommen, "Ist das auch sicher?" zu fragen.
Ja. Mit gerunzelter Stirn muss ich feststellen, dass diese Eigenschaft auch bei vielen Anwendern von Microsoft-Programmen zu finden ist.
Solange es mit den erlaubten Eingaben alles funktioniert, kann doch nichts passieren. Was ist aber, wenn man die Eingaben mal etwas über die spezifizierten Parameter hinaus dehnt, wird vernachlässigt.
Ich habe neulich in einer Schulung über Unit-Tests gelernt: Ein Bug ist ein Testfall, den man nicht beachtet hat. Man kann also sagen, dass solche Programme ziemlich buggy sind :-)
Das ist wahrscheinlich noch nicht die Ideallösung, wenngleich eigentlich nur zwei Skripte existieren, eines für den Normaluser und eines für das Editing-System.
Darf ich mal kurz das Prinzip "SetEnvIf" mit entsprechenden getenv()-Abfragen in den Raum werfen? Das an sich ist auch noch nicht sicher (insbesondere weil man entweder erst danach zum Editing-System kommt, was bisher ungeprüft wäre, oder aber gleich im Editing-System ist, welches dann deaktivierbar sein muss), könnte aber als "durchschaubarerer" Ansatz dienen.
[...] Und gerade das ist nicht einfach, weil man, um sie zu gewinnen, eigentlich professioneller Hacker sein müßte, um abstruse Ideen zu erlangen, was man alles machen könnte, was nicht vorgesehen ist.
Tja, abstruse Ideen sollte man immer mal wieder haben... :-) Ein guter Ansatz ist es aber, wenn man pro Schritt einzeln _alle_ Möglichkeiten aufzeigt (sofern es geht), und deren Implikationen streng protokolliert. Gerade bei mehrstufigen Konfigurations-Geschichten kommt man auf diese Weise durchaus zu möglichen Problemfällen - und kann oft recht leicht streng definieren, was zur Vermeidung derselben zu tun ist. Und "dann müssen sich nur noch alle dran halten".
Ich bin kein Profi-Hacker,
Einige Firmen haben in der Vergangenheit Aufsehen erregt, indem Sie einen Hacker-Contest ins Leben gerufen haben: "Hier ist unser Testsystem, versucht es zu hacken. Wer Sicherheitslecks offenlegt, kriegt eine Belohnung." Dieses Konzept erinnert ein wenig an Open Source, ist nur leider zeit- und kostenintensiver.
Cheatah