nicht angemeldet
Für ein stabil gebautes Haus nehme man ....!?
Hallöchen!
Um den Hausbau http://forum.de.selfhtml.org/?m=28836&t=5169 fortzusetzen, möchte ich meins absichern gegen Einbruch, Diebstahl und mutwillige Zerstörung. Kurz und gut also das Thema Sicherheit, zu diesem Thema ist hier schon einiges gepostet worden, aber die Sicherheit ist für mich noch ein spanisches Dorf, daher versuche ich nun alles was sich irgendwie mittlerweile bei mir so an Wissen angesammelt hat euch mitzuteilen. Vielleicht hat ja wer Lust und Laune von euch, seinen Senf dazuzugeben...
Vorweg sei erwähnt, dass das Fundament aus PHP und MySql besteht, nach meinem spärlichen Wissen in dem Bereich würde ich:
1. Ordner auf die nicht zugegriffen werden darf (soll) mit Passwort in der .htaccess schützen.
2. Die PHP-Dateien nicht im Document-Root einbinden
3. Passwörter verschlüsseln (MD5?)
4. Zugriffe in der Datenbank (falls nötig z.B. bei einer Demo) auf das nötigste Beschränken, i.e. Teile einer Tabelle, Tabelle .
5. Die Bestellung wenn vom Hoster aus erlaubt mit SSL übertragen ... und wenn es nicht möglich ist?
Ich würde mich über eure Meinung zum sicheren Hausbau für Laien freuen!
Sabine
-
Hi noch mal!
Ups, erster Fehler - wie ich gerade gesehen habe, ist Punkt 3 wohl Quatsch ... oder?
- Passwörter verschlüsseln (MD5?)
Wie sieht es denn hier mit der Funktion password aus?
Schöne Grüße
Sabine-
Hi!
ne, kein Fehler und sehr sicher, wenn Du das wie folgt machst:Benutzer eintragen:
$benutzer = "test" // Benutzername
$passwort = "hallo" // Passwort
$hash = MD5($passwort.$benutzer);
mysql_query("INSERT INTO Benutzer SET benutzername='".$benutzer."', hash='".$hash."'"); // So oder so ähnlich in die Datenbank eintragenBenutzername und Passwort überprüfen:
$benutzer = "test";
$passwort = "hallo";
$hash = MD5($passwort.$benutzer);
$result= mysql_query("SELECT benutzername, hash FROM Benutzer WHERE benutzername='".$benutzer."'");
$benutzerdaten=mysql_fetch_array($result);
if($benutzerdaten["hash"] != $hash) { // böse, böse
} else { // ok
}Grüße
Andreas-
Hi Andreas!
Dankeschön. Hat es einen bestimmten Grund in der Variable Hash das Passwort und den Benutzernamen gemeinsam zu verschlüsseln? Bedeutet das höhere Sicherheit als eine getrennte Verschlüsselung bzw. alleinige Passwort-Verschlüsselung?
Wäre es nicht sinnvoll, meine Daten, also Passwort und Benutzername für den DB-Zugriff auch mit MD5 zu verschlüsseln? Ich habe bei meinem Hoster zwar keinen Zugriff darauf - also auf die Speicherung dieser Grunddaten - daher kommt es für mich natürlich auch nicht in Frage ... aber grundsätzlich müsste das doch mehr Sicherheit bedeuten, oder? Wenn ich die Daten z.B. in einem durch .htaccess geschützten Verzeichnis ablege und die Variablen zuweise und die Variable dann mit MD5 verschlüssle. Oder schieße ich jetzt schon mit Kanonen auf Spatzen?
Schöne Grüße
Sabine-
Hi Sabine!
.htaccess Passwörter werden ja sowieso per crypt() verschlüsselt.
Die Zugangsdaten für die DB könnte man auch verschlüsselt speichern, aber da man die Zugangsdaten eh so ablegen sollte, dass kein Zugriff aus dem www möglich ist ist das nicht ganz so wichtig. Wichtig ist nur die Übertragung per SSL, dann sehe ich da kein Probhlem.
Das mit dem Buntzernamen und Passwort in einem Hash erhöht die Sicherheit nochmal, da einfach der Hash deutlich verlängert wird, mit jeder Stelle mehr ehöht sich die Potenz um 1, kannst Dir den Unterschied leicht ausrechnen! Und wenn man den Username davor speichert haben es die Cracker leichter, da dieser meist bekannt ist und man einfach von da aus weitersuchen kann, fast alle Vorteile des längeren Hashs wieder weg! Anders herum gibt es keine Ausgangsbasis! Das steht aber alles sehr viel besser erklärt im Link unten!
Ich empfehle Dir mal folgenden Thread zu lesen, den habe ich vor kurzem begonnen und sehr interessante Antworten auf diese Fragen erhalten: http://forum.de.selfhtml.org/archiv/2002/1/3267/#m19125
Grüße
Andreas-
Hi Andreas!
Merci beaucoup für die Erklärung!
Langsam bin ich soweit, dass ich beim Thema Sicherheit nicht mehr Gänsehaut bekommen, was aber nicht heißen soll, dass der Fall wieder eintritt, wenn die Umsetzung erfolgt :) ...Tschüss
Sabine-
Hi!
Dank diese Forums kann ich jetzt auch schon win wenig dazu sagen, bei Gelegenheit dann mehr dazu!Grüße
Andreas-
Hi!
Hi!
Dank diese Forums kann ich jetzt auch schon win wenig dazu sagen, bei Gelegenheit dann mehr dazu!Oki doki, danke. Ich bin echt begeistert - nicht nur vom Forum, obwohl an dieser Stelle wieder mal ein dickes Lob fällig ist für die Poster in diesem Forum, sondern auch von PHP und MySQl, auch wenn ich regelmäßig haareraufend vorm PC sitze, weil irgendwas nicht so will, wie ich es will, komme ich dann doch wieder auf einen grünen Zweig. Mit Javascript beschäftige ich mich schon länger, so in etwa ein Jahr denke ich, aber da bin ich oft (oder meist?) komplett ratlos bei Fehlern, wohingegen ich in PHP meist schon eine Ahnung habe, woher das Problem kommen kann und mit etwas Literatur oder Unterstützung oder auch doing-yourself klappts dann.
Tschüss
SabineGrüße
Andreas
-
-
-
Hi Andreas,
.htaccess Passwörter werden ja sowieso per crypt() verschlüsselt.
War UNIX als Plattform irgendwo explizit genannt worden? Falls ja, dann
ist Deine Aussage in Ordnung. (Falls nein, gibt es aber mit MD5 und SHA
ähnlich gute Verschlüsselungen.Allerdings bezieht sich Deine Aussage leider ausschließlich auf die
Speicherung des Kennwortes auf dem Server - was während der Übertragung
passiert, hängt vom AuthType ab. Und da fast alle bisher Authtype Basic
nutzen (müssen ...), wird das Passwort dabei Base64-"codiert", also so
gut wie im Klartext übertragen.Die Zugangsdaten für die DB könnte man auch verschlüsselt speichern,
aber da man die Zugangsdaten eh so ablegen sollte, dass kein Zugriff
aus dem www möglich ist ist das nicht ganz so wichtig.Da man aber letzteres nicht 110%ig garantieren kann, schadet ersteres
auch nichts, wenn man nur die Einwegfunktion der Passworte braucht.
(Wir speichern die Passworte unserer Kunden auch nur verschlüsselt -
das heißt dann aber beispielsweise, daß ein Kunde uns am Telefon nicht
fragen kann, wie denn sein Passwort hieß, daß er vergessen hat - wir
können es auch nicht lesen, nur ein neues auf seinen Wunsch setzen.
Einige sehr triviale Kennworte _können_ wir lesen - beispielsweise wenn
das Kennwort gleich dem Benutzernamen ist, meine Admin-Oberfläche macht
ein paar sophisticated guesses ... wir kennen unsere Pappenheimer ... ;-)Viele Grüße
Michael
-
-
-
-
Moin!
Vorweg sei erwähnt, dass das Fundament aus PHP und MySql besteht, nach meinem spärlichen Wissen in dem Bereich würde ich:
- Ordner auf die nicht zugegriffen werden darf (soll) mit Passwort in der .htaccess schützen.
Das betrifft nur den Zugriff per HTTP, aber dafür ist es ideal, und eigentlich unüberwindlich, solange niemand die Zugangsdaten rät oder im Netz abfängt (die werden unverschlüsselt übertragen).
- Die PHP-Dateien nicht im Document-Root einbinden
Da verstehe ich jetzt nicht so ganz, was du meinst.
Gegen PHP-Dateien irgendwo auf dem Server ist nichts einzuwenden. Wenn du auf per "include()" eingebundene Dateien abzielst: Die können in einem Include-Verzeichnis liegen und trotzdem ".php" heißen. Wenn diese Dateinen keinen Output produzieren, weil sie nur Funktionen enthalten, sind die Inhalte der Dateien so ziemlich sicher.
- Passwörter verschlüsseln (MD5?)
Genau. MD5 ist ein Einwege-Algorithmus. Man kann also das bekannte, bereits verschlüsselte Paßwort nur noch mit dem eingegebenen, ebenfalls verschlüsselten Paßwort vergleichen und bei Gleichheit den Zugriff gewähren.
Das schützt aber in erster Linie nur dagegen, daß jemand irgendwie die Datenbank oder die Paßwortdatei ausliest und nicht einen Stapel von unverschlüsselten Paßwörtern kriegen soll. Wird das Paßwort (egal ob mit .htaccess AuthType Basic oder durch Formulare mit http) unverschlüsselt übertragen, ist das ein Risiko.
- Zugriffe in der Datenbank (falls nötig z.B. bei einer Demo) auf das nötigste Beschränken, i.e. Teile einer Tabelle, Tabelle .
Richtig. Ideal wäre es zum Beispiel, wenn die Datenbank (mindestens) zwei Useraccount für PHP kennt. Einer ist nur zum Lesen, für sonst nichts (also z.B. für das öffentliche Suchformular), während der zweite Account zum Bearbeiten der Datenbank gedacht ist und beispielsweise nur von PHP-Skripten aus zugänglich ist, die per Authentifizierung zugänglich sind.
- Die Bestellung wenn vom Hoster aus erlaubt mit SSL übertragen ... und wenn es nicht möglich ist?
...dann ist das für manche Anwendungen eher schlecht (wie z.B. einem Webshop oder dem Konfigurationsmenü für den eigenen Webspace), für andere Anwendungen nicht so schlimm (wie der Abruf des persönlich konfigurierten Wetterberichts).
Ich würde mich über eure Meinung zum sicheren Hausbau für Laien freuen!
Die Grundsätze hast du ziemlich komplett erfaßt. Was noch fehlt, ist der Umgang mit Userdaten.
Userdaten sind vom Prinzip her BÖSE. Da man ohne sie nicht auskommt, sollte man alles daran setzen, daß die Eingaben in den Skripten und der Datenbank ausschließlich als ZEICHEN behandelt werden, nicht als BEFEHLE.
Typische Beispiele: Wenn man eine Textarea hat, in die man den Text einer Seite eintragen soll, dann ist es BÖSE, wenn man dort auch Javascript-Code eintragen kann und der dann beim Betrachter der editierten Seite WIRKSAM wird. In PHP sollte deshalb eigentlich immer statt echo $variableausform; der Befehl echo htmlentities($variableausform); benutzt werden. Damit werden alle HTML-Sonderzeichen in der Variable zu Entities. Aus '<script type="text/javascript">' wird '<script type="text/javascript">', und das zeigt der Browser nur an, führt es aber nicht aus.
Solche Vorgehensweise steht im Konflikt zur Möglichkeit, in der Textarea HTML-Formatierungen wie <b> oder <br> einzugeben. Da muß man eventuell dann ziemlich rumrödeln, um die erwünschten Tags vor der Umwandlung zu retten und hinterher als funktionierenden HTML-Code wieder einzubauen.
Das gleiche Spiel gilt, wenn du SQL-Statements für die Datenbank zusammensetzt. Hierbei sind Anführungszeichen in der Usereingabe besonders BÖSE. Üblicherweise werden die Daten, welche per INSERT oder UPDATE in die Datenbank kommen sollen, in Anführungszeichen gesetzt. Wenn man nun als User ein Anführungszeichen eingibt, würde das zu Konflikten führen. Auf diese Weise könnte man noch beliebige SQL-Befehle in die Eingabe mit einbauen, die die Datenbank dann ausführt - unter anderem das Löschen von einzelnen Tabellen oder der ganzen Datenbank.
Die Anführungszeichen werden bei PHP, nachdem sie vom Formular entgegengenommen wurden, meist automatisch mit Backslashes versehen (Option "magic_quotes" ist an). Ansonsten muß man mit addslashes($variable) selbst dafür sorgen, sonst meckert die Datenbank.
Wie man sowas für alle Eventualitäten programmiert, steht hier: http://www.php.net/manual/de/function.addslashes.php - Eintrag vom 20-Jun-2001 03:26.
Diese ganze Zeichen-Sicherheit ist ein ziemlicher Krampf - man muß es unverhohlen so sagen. Dagegen kann aber kein einfaches Mittel erfunden werden, denn irgendwelche Zeichen haben in irgendeinem Zusammenhang immer irgendwelche Sonderfunktionen und dürfen als normales Zeichen nicht benutzt werden. Diese Zeichen muß man also maskieren, damit sie als "das Zeichen selbst" benutzt werden, und nicht als das "Zeichen mit Sonderfunktion".
- Sven Rautenberg
-
Hi Sven!
Das betrifft nur den Zugriff per HTTP, aber dafür ist es ideal, und eigentlich unüberwindlich, solange niemand die Zugangsdaten rät oder im Netz abfängt (die werden unverschlüsselt übertragen).
Das klingt schon mal gut ... und vor allem einfach :)
Gegen PHP-Dateien irgendwo auf dem Server ist nichts einzuwenden. Wenn du auf per "include()" eingebundene Dateien abzielst: Die können in einem Include-Verzeichnis liegen und trotzdem ".php" heißen. Wenn diese Dateinen keinen Output produzieren, weil sie nur Funktionen enthalten, sind die Inhalte der Dateien so ziemlich sicher.
Irgendwie habe ich da jetzt 2 Dinge in eines gepackt ... Einerseits meinte ich die include-Dateien ... Zu deiner Erklärung bezüglich keinen Output produzieren ... Das macht mich jetzt stutzig - wenn meine Funktion einen Rückgabewert liefert, was sie ja in den meisten Fällen ja tun wird (?), dann ist die Datei nicht mehr sicher?
Wie sieht es denn hier aus, wenn ich z.B. die Verbindung zur Datenbank in ein Skript binde, dass ich über include einbinde und dieses Skript dann in ein eigenes Verzeichnis lege, sind die Zugangsdaten also Passwort und Username dann sicher?Deiner Beschreibung nach bringt es an Sicherheit also nichts wenn ich jetzt irgendeine PHP-Datei die irgendetwas an Output produziert nicht in das Stammverzeichnis sondern irgendeinen Unter-Unterordner packe, oder?
- Passwörter verschlüsseln (MD5?)
Genau. MD5 ist ein Einwege-Algorithmus. Man kann also das bekannte, bereits verschlüsselte Paßwort nur noch mit dem eingegebenen, ebenfalls verschlüsselten Paßwort vergleichen und bei Gleichheit den Zugriff gewähren.
Ach ja ... Dann bringt MD5 hier also doch was ...
Das schützt aber in erster Linie nur dagegen, daß jemand irgendwie die Datenbank oder die Paßwortdatei ausliest und nicht einen Stapel von unverschlüsselten Paßwörtern kriegen soll. Wird das Paßwort (egal ob mit .htaccess AuthType Basic oder durch Formulare mit http) unverschlüsselt übertragen, ist das ein Risiko.
:( Wo wir wahrscheinlich beim Thema SSL wären zur sicheren verschlüsselten Übertragung???
- Zugriffe in der Datenbank (falls nötig z.B. bei einer Demo) auf das nötigste Beschränken, i.e. Teile einer Tabelle, Tabelle .
Richtig. Ideal wäre es zum Beispiel, wenn die Datenbank (mindestens) zwei Useraccount für PHP kennt. Einer ist nur zum Lesen, für sonst nichts (also z.B. für das öffentliche Suchformular), während der zweite Account zum Bearbeiten der Datenbank gedacht ist und beispielsweise nur von PHP-Skripten aus zugänglich ist, die per Authentifizierung zugänglich sind.
Und die Authentifizierung sollte dann wahrscheinlich wieder über SSL abgewickelt und das Passwort mit MD5 verschlüsselt werden, oder?
- Die Bestellung wenn vom Hoster aus erlaubt mit SSL übertragen ... und wenn es nicht möglich ist?
...dann ist das für manche Anwendungen eher schlecht (wie z.B. einem Webshop oder dem Konfigurationsmenü für den eigenen Webspace), für andere Anwendungen nicht so schlimm (wie der Abruf des persönlich konfigurierten Wetterberichts).
Oje oje, ich wusste doch, irgendwann kommt die niederschmetternde Nachricht. Ich weiß noch nicht, ob ich SSL bei meinem Hoster nutzen kann. Wenn nein, gibt es eine sichere Alternative? Ich habe heute etwas von mode-ssl gelesen. Wenn nun mein Hoster mir SSL bietet, muss ich mich dann damit herumschlagen oder ist dann quasi alles fix fertig? Ich brauche dann auch einen Schlüssel oder? Kann mir hier jemand von euch einen Anbieter empfehlen? Ich habe gelesen, dass es hier teilweise auch bei Aufruf der Seite aus anderen Ländern Probleme geben kann, wenn der Anbieter dort (noch) nicht bekannt ist ... Wie sieht es hier denn mit OpenSource wie cURL aus?
Ich würde mich über eure Meinung zum sicheren Hausbau für Laien freuen!....
Das gleiche Spiel gilt, wenn du SQL-Statements für die Datenbank zusammensetzt. Hierbei sind Anführungszeichen in der Usereingabe besonders BÖSE. Üblicherweise werden die Daten, welche per INSERT oder UPDATE in die Datenbank kommen sollen, in Anführungszeichen gesetzt. Wenn man nun als User ein Anführungszeichen eingibt, würde das zu Konflikten führen. Auf diese Weise könnte man noch beliebige SQL-Befehle in die Eingabe mit einbauen, die die Datenbank dann ausführt - unter anderem das Löschen von einzelnen Tabellen oder der ganzen Datenbank.
Der Teil mit den HTML- bzw. Javascript-Eingaben ist mir klar, damit habe ich mich schon etwas beschäftigt, was nicht heißen soll, dass ich das schon alles kann, aber das mir die grundsätzliche Problematik hierbei klar ist. Auf das Problem mit den SQL-STatements habe ich ehrlich gesagt bisher nicht gedacht. Hier muss ich also aufpassen, wenn meine Besucher ein Formular absenden dessen Daten dann in die Datenbank übernommen werden, oder?
Die Anführungszeichen werden bei PHP, nachdem sie vom Formular entgegengenommen wurden, meist automatisch mit Backslashes versehen (Option "magic_quotes" ist an). Ansonsten muß man mit addslashes($variable) selbst dafür sorgen, sonst meckert die Datenbank.
Wie man sowas für alle Eventualitäten programmiert, steht hier: http://www.php.net/manual/de/function.addslashes.php - Eintrag vom 20-Jun-2001 03:26.
Dankeschön, sehe ich mir gleich an!
Danke für deine Anregungen und Tipps, nun hoffe ich, dass ich ein positives Feedback von meinem Hoster erhalte ...
Gut's Nächtle!
Sabine- Sven Rautenberg
-
Re-Moin!
Irgendwie habe ich da jetzt 2 Dinge in eines gepackt ... Einerseits meinte ich die include-Dateien ... Zu deiner Erklärung bezüglich keinen Output produzieren ... Das macht mich jetzt stutzig - wenn meine Funktion einen Rückgabewert liefert, was sie ja in den meisten Fällen ja tun wird (?), dann ist die Datei nicht mehr sicher?
Ruf deine Include-Datei (deren Lage auf dem Server, also auch deren URL du ja kennst) einfach im Browser auf. Das, was du da siehst, wird jeder andere auch sehen.
Was den Output angeht: Wenn du in der include-Datei nur Funktionen definierst, also
function eins (parameter)
{
#blahblah
}
.......dann werden diese Funktionen in der include-Datei ja niemals aufgerufen und also auch nicht ausgeführt -> kein Output. Wenn der Server aber aufgrund der Dateiendung meint, die Datei nicht durch den PHP-Parser schicken zu müssen, sondern sie im Klartext ausliefern zu müssen, dann ist das schlecht. Deshalb: Dateiendung .php geht auf Nummer Sicher. Manche Provider lassen auch .inc mit PHP parsen, weil das eine beliebte Endung von vielen PHP-Programmierern ist, aber darauf ist kein Verlaß.
Wie sieht es denn hier aus, wenn ich z.B. die Verbindung zur Datenbank in ein Skript binde, dass ich über include einbinde und dieses Skript dann in ein eigenes Verzeichnis lege, sind die Zugangsdaten also Passwort und Username dann sicher?
Wenn irgendein Skript "echo $passwort" macht, und das zum Browser gelangt, wäre es blöd. Was aber keine Ausgabe produziert, wird von PHP ja nicht an die Außenwelt geliefert. Deshalb ist es ja so wichtig, daß die Include-Dateien (meist mit sensitiven Konfigurationsdaten) nicht ungeparst an den Browser gesendet werden. Wenn PHP zum Zuge kommt, sind im Browser keine PHP-Anweisungen mehr zu sehen. :)
Deiner Beschreibung nach bringt es an Sicherheit also nichts wenn ich jetzt irgendeine PHP-Datei die irgendetwas an Output produziert nicht in das Stammverzeichnis sondern irgendeinen Unter-Unterordner packe, oder?
Richtig. Es ist völlig egal, wo die Datei sich befindet. Es ist etwas besser, wenn die Include-Datei garnicht per http erreichbar ist, aber solche Verzeichnisse gibts bei den meisten Providern nicht. Das Hauptverzeichnis, welches man per FTP sieht, ist gleichzeitig das Hauptverzeichnis des http-Servers der Domain.
Ach ja ... Dann bringt MD5 hier also doch was ...
Klar. :)
Und die Authentifizierung sollte dann wahrscheinlich wieder über SSL abgewickelt und das Passwort mit MD5 verschlüsselt werden, oder?
Im Idealfall ja, alles per SSL machen. :) Das ist sicher.
Oje oje, ich wusste doch, irgendwann kommt die niederschmetternde Nachricht. Ich weiß noch nicht, ob ich SSL bei meinem Hoster nutzen kann. Wenn nein, gibt es eine sichere Alternative? Ich habe heute etwas von mode-ssl gelesen. Wenn nun mein Hoster mir SSL bietet, muss ich mich dann damit herumschlagen oder ist dann quasi alles fix fertig? Ich brauche dann auch einen Schlüssel oder? Kann mir hier jemand von euch einen Anbieter empfehlen? Ich habe gelesen, dass es hier teilweise auch bei Aufruf der Seite aus anderen Ländern Probleme geben kann, wenn der Anbieter dort (noch) nicht bekannt ist ... Wie sieht es hier denn mit OpenSource wie cURL aus?
Wenn du SSL benutzen kannst, ist alles relativ einfach. Du hast als URL eben nicht mehr http://, sondern https://, und damit mußt du dich vermutlich nur bei einem einzigen Link auf deiner Webseite rumplagen, nämlich auf der Startseite von http://deinedomain/. Von dortaus geht der Link zur Startseite auf https://deinedomain/ (die konkrete Lösung ist etwas abhängig davon, wie dein Provider das alles gelöst hat, ob du z.B. ein eigenes Verzeichnis für den https-Server kriegst, oder ob die Seiten unter beiden Protokollen erreichbar sind (was ich für schlecht halten würde, weil User dann auch unverschlüsselt die Funktionen nutzen könnten).
Was die Schlüssel für SSL angeht: Vermutlich hat dein Provider schon einen für den Server, bzw. wird er dann einen generieren. Die Frage ist, ob du den zertifizieren lassen solltest oder nicht:
Unzertifizierte Schlüssel lassen beim Betreten im Browser ein Dialogfenster aufgehen, in dem der Benutzer zur Bestätigung aufgefordert wird, daß er wirklich mit diesem Server arbeiten möchte. Solche "Eigenzertifikate" beweisen im Prinzip garnichts, aber immerhin ist die Verbindung verschlüsselt. Der Surfer ist eben nicht 100% sicher, daß die Gegenseite wirklich _DIE_ Gegenseite ist, die er meint vor sich zu haben. Kann bei Bankgeschäften durchaus sehr interessant sein, wenn man sich (durch Tippfehler) nicht mit dem echten Bankserver verbindet.Aus diesem Grunde kann man seinen SSL-Schlüssel zertifizieren lassen. Dann signiert eine entsprechende Firma digital den Schlüssel, die Browser kennen die Signatur dieser Signier-Firmen und wissen deshalb, daß das Zertifikat zum Server und zum echten Anbieter paßt und alles in Ordnung ist - ganz ohne Usernachfrage.
Eine solche SSL-Dialogbox erscheint zum Beispiel hier: https://www.ccc.de. Da hat der Chaos Computer Club, weil er die Wichtigkeit von Verschlüsselung unterstreichen wollte, seinen Server auf SSL umgestellt (und mußte ihn danach erstmal upgraden, weil Verschlüsselung doch etwas rechenintensiver ist), und hat sich selbst einfach ein Zertifikat ausgestellt.
web.de Freemail macht es übrigens genauso: https://freemail.web.de. Spart vermutlich doch etwas Geld. Oder deren Zertifizierungsstelle ist den Browsern eben unbekannt.
- Sven Rautenberg
-
Hallo Sven!
Re-Moin!
:)
Ruf deine Include-Datei (deren Lage auf dem Server, also auch deren URL du ja kennst) einfach im Browser auf. Das, was du da siehst, wird jeder andere auch sehen.
Nix, das ist schön :)
...dann werden diese Funktionen in der include-Datei ja niemals aufgerufen und also auch nicht ausgeführt -> kein Output. Wenn der Server aber aufgrund der Dateiendung meint, die Datei nicht durch den PHP-Parser schicken zu müssen, sondern sie im Klartext ausliefern zu müssen, dann ist das schlecht. Deshalb: Dateiendung .php geht auf Nummer Sicher. Manche Provider lassen auch .inc mit PHP parsen, weil das eine beliebte Endung von vielen PHP-Programmierern ist, aber darauf ist kein Verlaß.
Ach jetzt verstehe ich, (bei den Österreichern dauerts ab und zu ein bisserl länger vor allem um die nachtschlafende Zeit ...). Dann würde mein lieber Besucher also meinen PHP-Code sehen ...
Wenn irgendein Skript "echo $passwort" macht, und das zum Browser gelangt, wäre es blöd. Was aber keine Ausgabe produziert, wird von PHP ja nicht an die Außenwelt geliefert. Deshalb ist es ja so wichtig, daß die Include-Dateien (meist mit sensitiven Konfigurationsdaten) nicht ungeparst an den Browser gesendet werden. Wenn PHP zum Zuge kommt, sind im Browser keine PHP-Anweisungen mehr zu sehen. :)
Ich denk jetzt hab ichs. Juhu - ein Erfolgserlebnis um diese Zeit, das ist schön.
Und die Authentifizierung sollte dann wahrscheinlich wieder über SSL abgewickelt und das Passwort mit MD5 verschlüsselt werden, oder?
Wenn du SSL benutzen kannst, ist alles relativ einfach. Du hast als URL eben nicht mehr http://, sondern https://, und damit mußt du dich vermutlich nur bei einem einzigen Link auf deiner Webseite rumplagen, nämlich auf der Startseite von http://deinedomain/. Von dortaus geht der Link zur Startseite auf https://deinedomain/ (die konkrete Lösung ist etwas abhängig davon, wie dein Provider das alles gelöst hat, ob du z.B. ein eigenes Verzeichnis für den https-Server kriegst, oder ob die Seiten unter beiden Protokollen erreichbar sind (was ich für schlecht halten würde, weil User dann auch unverschlüsselt die Funktionen nutzen könnten).
Ich hatte eigentlich gedacht, dass die sichere Verbindung nur genutzt werden "sollte" bei sensitiven Daten also z.B. Bestellung. Mir ist schon klar, dass ich es bei den anderen Seiten auch nutzen kann, habe aber heute bei drweb gelesen, dass die Verbindung mit SSL sehr langsam ist, ist da was dran?
» Unzertifizierte Schlüssel lassen beim Betreten im Browser ein Dialogfenster aufgehen, in dem der Benutzer zur Bestätigung aufgefordert wird, daß er wirklich mit diesem Server arbeiten möchte. Solche "Eigenzertifikate" beweisen im Prinzip garnichts, aber immerhin ist die Verbindung verschlüsselt. Der Surfer ist eben nicht 100% sicher, daß die Gegenseite wirklich _DIE_ Gegenseite ist, die er meint vor sich zu haben. Kann bei Bankgeschäften durchaus sehr interessant sein, wenn man sich (durch Tippfehler) nicht mit dem echten Bankserver verbindet.
» Eine solche SSL-Dialogbox erscheint zum Beispiel hier: https://www.ccc.de.
web.de Freemail macht es übrigens genauso:
Ich weiß nicht, irgendwie sieht das nicht gerade einladend und vertrauenserweckend aus, wenn man auf so eine Seite ohne zertifizierten Schlüssel einsteigt. Ich denke mir, dass Surfer mit wenig Erfahrung im Internet von solchen Meldungen eher abgeschreckt werden, als wenn man gar keine sichere Verbindung via SSL verwendet.
Danke nochmals für die Hilfe, jetzt ist mir einiges klarer geworden.
Tschüss
Sabine- Sven Rautenberg
-
Hi Sabine,
Ich hatte eigentlich gedacht, dass die sichere Verbindung nur genutzt
werden "sollte" bei sensitiven Daten also z.B. Bestellung. Mir ist
schon klar, dass ich es bei den anderen Seiten auch nutzen kann, habe
aber heute bei drweb gelesen, dass die Verbindung mit SSL sehr langsam
ist, ist da was dran?Ein bißchen was wird es schon kosten, die gesamte HTTP-Kommunikation in
eine Verschlüsseluns-Schale einzubetten, aber "sehr langsam" würde mich
doch überraschen. Es kostet übrigens das Verschlüsseln meistens sehr viel
mehr als das Entschlüsseln - Du wirst also eher auf dem Server etwas spüren
als der Benutzer auf seinem Client-PC (der verschlüsselt zwar auch seine
Anforderungen, da sind aber meistens sehr viel weniger Daten drin als in
Deinen Antworten).
Bedenke auch, daß Du in manchen Browsern einen Haufen Warnungen provozieren
wirst, wenn Du ständig zwischen HTTP und HTTPS wechselst. Das würde Deine
Benutzer ziemlich stören.Ich weiß nicht, irgendwie sieht das nicht gerade einladend und
vertrauenserweckend aus, wenn man auf so eine Seite ohne zertifizierten
Schlüssel einsteigt. Ich denke mir, dass Surfer mit wenig Erfahrung im
Internet von solchen Meldungen eher abgeschreckt werden, als wenn man
gar keine sichere Verbindung via SSL verwendet.Ich würde auch dazu raten, abzuklären, ob Dein Projekt nicht "richtig
seriös" werden möchte und sich dann eben ein eigenes Zertifikat kauft.Viele Grüße
Michael-
Hallo Michael!
Erstmals danke für deine Antwort.
Ein bißchen was wird es schon kosten, die gesamte HTTP-Kommunikation in
eine Verschlüsseluns-Schale einzubetten, aber "sehr langsam" würde mich
doch überraschen. Es kostet übrigens das Verschlüsseln meistens sehr viel
mehr als das Entschlüsseln - Du wirst also eher auf dem Server etwas spüren
als der Benutzer auf seinem Client-PC (der verschlüsselt zwar auch seine
Anforderungen, da sind aber meistens sehr viel weniger Daten drin als in
Deinen Antworten).
Bedenke auch, daß Du in manchen Browsern einen Haufen Warnungen provozieren
wirst, wenn Du ständig zwischen HTTP und HTTPS wechselst. Das würde Deine
Benutzer ziemlich stören.Man soll wirklich nicht glauben, was man immer so liest. Klingt einleuchtend, was du mir geschrieben hast.
Ich würde auch dazu raten, abzuklären, ob Dein Projekt nicht "richtig
seriös" werden möchte und sich dann eben ein eigenes Zertifikat kauft.Ja, das werde ich abchecken. Ich weiß zwar nicht, wie hoch die Rate der Besucher ist, die bei solchen Warnungen abbrechen, aber ich denke sie wird nicht unerheblich sein. Und was hat man vom schönsten Online-Shop und der tollen Verschlüsselung, wenn sich viele abgeschreckt fühlen und abbrechen ...
Liebe Grüße
SabineViele Grüße
Michael
-
-
-
Hi Sabine,
Um den Hausbau http://forum.de.selfhtml.org/?m=28836&t=5169
fortzusetzen, möchte ich meins absichern gegen Einbruch, Diebstahl
und mutwillige Zerstörung.Einbruch und Diebstahl sind im bisherigen Thread schon recht gut weg-
gekommen. Die mutwillige Zerstörung beinhaltet aber auch deny-of-service-
Attacken und ähnliche Sauereien ... das Netzwerk gehört in diesem Sinne
auch zu Deiner Anwendung (auch wenn es eher Dein Hoster ist, der sich
mit der Umsetzung zu befassen haben wird).
Hat Deine Anwendung definierte housekeeping-Zeiten, in denen Du den
Rolladen herunterlassen und in aller Ruhe Tagesabschluß, Datensicherung
und Ähnliches abwickeln kannst? Oder mußt Du "24/7 laufen"?- Ordner auf die nicht zugegriffen werden darf (soll) mit Passwort
in der .htaccess schützen.
Eine Datei, auf die nicht via HTTP, sondern nur via Pfadname zugegriffen
wird, kannst (und solltest) Du aus dem URL-Raum komplett entfernen.
"Geht nicht" ist sicherer als "schwer zu erraten".- Passwörter verschlüsseln (MD5?)
Soweit das ServerAuthentivation (.htaccess und Konsorten) betrifft:
Tja, wenn das mal die Browser könnten. Opera seit Version 4, M$IE seit
Version 5, aber überhaupt gar kein einziger Netscape (auch nicht 6.2.1),
Mozilla hat es gerade erst in Version 0.9.7 eingebaut.
Ich würde Dir ja gerne zu "AuthType Digest" raten, aber es ist einfach
noch zu früh dafür, wenn Du ServerAuthentication mit MD5-codierten Kenn-
worten nutzen und Netscape-Benutzer nicht ausschließen willst.- Zugriffe in der Datenbank (falls nötig z.B. bei einer Demo) auf
das nötigste Beschränken, i.e. Teile einer Tabelle, Tabelle.
Ich würde mir eher Gedanken darüber machen, wie die Installation der
Datenbank aussieht. Sind noch irgendwelche nicht geänderten Passworte
irgendwelcher Default-Benutzerkennungen drin, welche ein Besucher ggf.
aus seiner eigenen lokalen installation kennen könnte?
Die SQL-Statements würde ich eher auf Performance als auf Einbruchs-
sicherheit optimieren - wenn jemand in Deiner Datenbank gegen Deinen
Willen SQL-Statements seiner Wahl ausführen darf, ist es wahrscheinlich
eh zu spät.
Ja, es _gibt_ in SQL Rollen, GRANTSs und ähnliches, aber das würde ich
eher dazu nutzen, Funktionen modular zu kapseln, also Geheimnisprinzip
zu etablieren - Du bist ja kein Hochschulrechner, wo man die einzelnen
Studenten, die auf der Maschine selbst arbeiten, voneinander abschotten
möchte.
Da würde ich mir eher Gedanken darüber machen, auf der Maschine alle
daemons zu stoppen, die Du nicht brauchst. Wenn ein Benutzer nicht mit
Telnet bzw. SSH auf die Maschine kann, dann nützt ihm ein mySQL-Kennwort,
das er auf der Kommandozeile einsetzen könnte, gleich viel weniger.- Die Bestellung wenn vom Hoster aus erlaubt mit SSL übertragen ...
und wenn es nicht möglich ist?
Darüber nachdenken, was ein besserer Hoster kostet.
Viele Grüße
Michael - Ordner auf die nicht zugegriffen werden darf (soll) mit Passwort