Sicherheit ist doch eigentlich SOOO einfach... Ich kanns kaum glauben... Langsam wird das definitiv zum Kavaliersdelikt... Furchtbar!
Ein Tutorial von mir für sichere Passwörter, die sich nicht mit Rainbow-Tables knacken lassen: http://www.cybton.com/tutorials_show,Siche...0,tut,1463.html
Wenn man sich an das Tut hält, ist man genau bei einem solchen Angriff sicher.
Eine grosse Rainbow-Table online zum Testen der eigenen PWDs ist übrigens z.B. gdataonline.
Die wichtisten Regeln:
- Passwort-Hashes generieren, die am besten gemäss einem eigenen Algorithmus verschlüsselt werden sollten (am sinnvollsten ist eine Weiterverarbeitung des MD5-Hashes)
- JEDE Variable, die vom User/Browser kommt, muss "entschärft" werden. Sogar der Browsername oder die Sprache müssen mit addslashes() für Logs mit Slashes versehen werden! Genauer:
* Datenbanken: addslashes(), falls magic_quotes off (gegen MySQL-Injections)
* URLs: urlencode() (gegen XSS)
* HTML-Text: htmlentities() (gegen XSS)
* Mail-Header-Daten: Zeilenumbrüche entfernen (gegen Spam)
* JavaScript-Alerts & Co.: addslashes() und htmlentities() (je nach Bedarf, gegen XSS)
- Single Quotes im HTML-Code vermeiden (In diesem Beispiel ist die vom User eingegebene Bildbeschreibung rot hervorgehoben: <img src='bild.jpg' alt='bild' width='1000' height='1000' onmouseover='...' />, gegen XSS) ODER bei htmlentities() als zweite Variable die Konstante ENT_QUOTES verwenden, die auch Single Quotes umwandelt.
- POST-Formulare (v.a. für E-Mail-Adressen- und Passwortänderung): In einem HIDDEN-Feld die Session-ID mitsenden, den Referer checken (kann evtl. umgangen werden) oder das Passwort in jedem Formular mitverlangen (schlecht für die Usability). Scheint auf Ayom nur teilweise geschlossen zu sein. (Notizen können von aussen geändert werden, jedoch ist das nicht weiter schlimm. Trotzdem sollte es behoben werden.) (gegen externe AutoSubmit-Formulare)
- GET-Formulare für Änderungen (UPDATE- oder INSERT-Befehle) vermeiden. Abfragen sind jedoch erlaubt. (wichtige Variablen stehen sonst in der URL und können von externen Anbietern aus dem Referer gelesen werden, oder aber es existiert dasselbe Problem wie bei POST)
Wenn man diese wenigen Regeln befolgt, hat man bereits 99% der Angriffe abgewehrt.
Ayom ist in dieser Hinsicht Vorbild (Im Vergleich zu phpBB, StudiVZ und vielen anderen wirklich VIEL genutzten Services).
Ein Tutorial von mir für sichere Passwörter, die sich nicht mit Rainbow-Tables knacken lassen: http://www.cybton.com/tutorials_show,Siche...0,tut,1463.html
Wenn man sich an das Tut hält, ist man genau bei einem solchen Angriff sicher.
Eine grosse Rainbow-Table online zum Testen der eigenen PWDs ist übrigens z.B. gdataonline.
Die wichtisten Regeln:
- Passwort-Hashes generieren, die am besten gemäss einem eigenen Algorithmus verschlüsselt werden sollten (am sinnvollsten ist eine Weiterverarbeitung des MD5-Hashes)
- JEDE Variable, die vom User/Browser kommt, muss "entschärft" werden. Sogar der Browsername oder die Sprache müssen mit addslashes() für Logs mit Slashes versehen werden! Genauer:
* Datenbanken: addslashes(), falls magic_quotes off (gegen MySQL-Injections)
* URLs: urlencode() (gegen XSS)
* HTML-Text: htmlentities() (gegen XSS)
* Mail-Header-Daten: Zeilenumbrüche entfernen (gegen Spam)
* JavaScript-Alerts & Co.: addslashes() und htmlentities() (je nach Bedarf, gegen XSS)
- Single Quotes im HTML-Code vermeiden (In diesem Beispiel ist die vom User eingegebene Bildbeschreibung rot hervorgehoben: <img src='bild.jpg' alt='bild' width='1000' height='1000' onmouseover='...' />, gegen XSS) ODER bei htmlentities() als zweite Variable die Konstante ENT_QUOTES verwenden, die auch Single Quotes umwandelt.
- POST-Formulare (v.a. für E-Mail-Adressen- und Passwortänderung): In einem HIDDEN-Feld die Session-ID mitsenden, den Referer checken (kann evtl. umgangen werden) oder das Passwort in jedem Formular mitverlangen (schlecht für die Usability). Scheint auf Ayom nur teilweise geschlossen zu sein. (Notizen können von aussen geändert werden, jedoch ist das nicht weiter schlimm. Trotzdem sollte es behoben werden.) (gegen externe AutoSubmit-Formulare)
- GET-Formulare für Änderungen (UPDATE- oder INSERT-Befehle) vermeiden. Abfragen sind jedoch erlaubt. (wichtige Variablen stehen sonst in der URL und können von externen Anbietern aus dem Referer gelesen werden, oder aber es existiert dasselbe Problem wie bei POST)
Wenn man diese wenigen Regeln befolgt, hat man bereits 99% der Angriffe abgewehrt.
Ayom ist in dieser Hinsicht Vorbild (Im Vergleich zu phpBB, StudiVZ und vielen anderen wirklich VIEL genutzten Services).