Login Script sicherer machen
lima-city → Forum → Programmiersprachen → PHP, MySQL & .htaccess
agent
algorithmus
browser
code
datenbank
frage
ftp
glauben
hacken
http
idee
jemand
machen
regel
safari
schnittstelle
server
session
url
zugriff
-
Also ich würde mein Login Script gern etwas sicherer machen denn ich möchte mich nicht nur auf die Session ID verlassen, also überprüfe ich die IP und schon bin ich bei meinen Recherchen auf das erste Hindernis gestoßen. Im I-Net schreiben se das manche Anbieter ihre IP bei jedem klick wechseln oder das durch Verwendung von Proxys diese nicht zur Überprüfung genutzt werden können. Also überprüfe ich nun den Browser, natürlich könnte der User auch den Browser wechseln oder mit verschiedenen PC's Online sein, aber dann muss er in meinen Augen damit Leben.
Nun aber mal zu meiner Frage^^ Was könnte man noch abfragen um die Überprüfung sicherer zu machen. Im Netz schreiben se oft das es Möglichkeiten gibt noch weitere Sachen zu überprüfen aber keiner geht darauf ein was man genau machen könnte.
Freue mich über jeden Tipp =) -
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
-
Da die Session ID sowieso vom Browser gespeichert wird, nicht an einem globalen Punkt für alle Browser, ist die Nutzung des User-Agents recht unbedenklich. Es ist eigentlich die einzige unbedenkliche Größe, die du nutzen kannst ;)
Andererseits, es ist auch sehr wahrscheinlich, dass sowohl der User Firefox 3.6.irgendwas nutzt, als auch der Angreifer...
Aber ne, ich hab keien Ideen, was man prüfen könnte... -
Schau dir mal http://www.bot-trap.de an. Damit bist du den größten Teil an Proxies und potentiellen Angreifern los.
-
nikic schrieb:
Da die Session ID sowieso vom Browser gespeichert wird, nicht an einem globalen Punkt für alle Browser, ist die Nutzung des User-Agents recht unbedenklich. Es ist eigentlich die einzige unbedenkliche Größe, die du nutzen kannst ;)
Andererseits, es ist auch sehr wahrscheinlich, dass sowohl der User Firefox 3.6.irgendwas nutzt, als auch der Angreifer...
Aber ne, ich hab keien Ideen, was man prüfen könnte...
Ich denke jetzt mal du nutzt Firefox.
Ich bin Verfechter des Safaris auf meinem Mac, es gibt für michts nicht schnellers. Seit Safari x kann man über die Menüleiste entwickler einen anderen Useragent vorschieben, wobei dieser ja Browser, Version & Betriebssystem enthält. Das heißt, ich erzähle der Only-Firefox-Seite, d.h. ich Firefox 3.5 auf Windows Vista Home Premium habe, obwohl ich in der Realität dann doch Safari 5 auf Mac OS 10.6 benutze. ;) Jetzt kommt natürlich die Frage, wieso sollte man sowas ändern.
Seit Safari 5 unterstützt dieser Erweiterungen. Eine meiner Lieblingserweiterungen, die nebenbei noch Werbung block blabla, ändert auch regelmäßig (zufällig) den Useragent. Warum man sowas macht? Nun, ich mags nicht, wenn man 'mich' protokolliert. Also erzähl ich den Protokollen gerne mal ein wenig Unsinn. ;) Die Erweiterung die ich benutze, greift eben auf eine interne Safari Funktion zu, nur eben zufällig. ;) Kostet mich nichts, der Sinn ist sicherlich fragwürdig, aber jeder wie er mag, nicht? ;) -
Nunja wenn ein User seine IP ständig ändert bzw. einen falschen Browser vortäuscht wie kann man da schon sicher sagen das es auch der User ist der sich da eingeloggt hat? Ich glaube solche User würden bei manchen WWW Seiten etwas Fluchen das man dort halt so etwas standardmäßig überprüft.
Aber wenn man nur die Session ID überprüft (die ich in meinem Fall selbst generiere und in einem Cookie schreibe) so kommt man glaub ich nicht gerade weit, selbst wenn man bei jedem neu Aufruf der Seiten eine neue Session ID geniere, würde es kaum möglich sein mit großer Wahrscheinlichkeit zu sagen, du bist auch wirklich der User der du vorgibst zu sein.
Ich danke euch für eure Meinung, scheinbar hat wirklich keiner eine Idee wie man besser machen könnte, oder es rückt nur keiner damit raus
-
@robbmaster: Ja, viele Browser lassen Änderungen des User-Agents zu. Aber normalerweise ändert sich diese nach dem Einmaligen anpassen des User-Agents nicht mehr.
Ich glaube du fühlst dich jetzt oberschlau und oberhacker, dass du so genial bist deinen User-Agent auf zufälliger Basis zu ändern. Bist du nicht!. Der User-Agent ist entscheidend bei der Erkennung von Browsern. Es gab mal ne Zeit, wo ich im Safari keine Werbung angezeigt habe, weil diese in ihm die ganze Seite verunstaltete - mit Erkennung über den User-Agent. Zeitweise habe ich auch leere User-Agents geblockt, weil wir häufig dDos Attacken mit leerem User-Agent-Header hatten (dumme Angreifer sind immer gut :D) Weiterhin leite ich auf eine iPhone-Version um, falls ich einen iPhone-User-Agent vor mir habe. Was ich damit sagen will: Der User-Agent wird nicht nur aus Spaß mitgeschickt, er wird auch wirklich benutzt.
Und, mal ganz ehrlich, mich interessiert es nicht, ob die Website nun erfährt, dass ich Firefox nutze, oder nicht. Das ist nichts, wofür man sich schämen muss ;) -
nikic schrieb:
Ich glaube du fühlst dich jetzt oberschlau und oberhacker, dass du so genial bist deinen User-Agent auf zufälliger Basis zu ändern. Bist du nicht!.
Nun mein Freund. Dann tut es mir leid dich enttäuschend zu müssen, aber du glaubst falsch. Ich hatte gehofft, dass es anders rübergekommen wäre. Wenn ich mich so fühlen würde, hätte ich wohl kaum DAS geschrieben. Der mit dem Wechsel eines Useragents, was einfach nur einen klick auf die schöne safariexz (oder whatever die Endung ist) Datei war, und auch nur der Werk einer Laune heraus, kann man kaum angeben. Entschuldige. Wenn schon Scriptkiddie und Oberhacker, dann würde ich kaum damit angeben - das wäre in dieser Situation wohl vollkommen peinlich. Sorry, aber ich finde es auch schon sehr gewagt von dir, nur aufgrund einer installierten Erweiterung eines Users, die nur erklären soll, warum er oben genannte Technik nicht benutzen würde (es gibt logischerweise auch mehr Situationen als die genannte), direkt als mutmaßliches Scriptkiddie oder, um dich zu zitieren, als selbsternannter 'Oberhacker' zu bezeichnen. Ich könnte dementsprechend jetzt glauben, dass DU dich oberschlau findest, weil du andere Leute die vielleicht keine Lust auf zu viel Protkoll haben einfach mal so mit deinen schlauen Kommentaren weg'batllest'. Bist du auch nicht!
Findest du meine Aussage jetzt gerechtfertig und in Ordnung? Nein? Dann beruht das jetzt immerhin auf Gegenseitigkeit, und man kann es dabei belassen.
-
ich sichere meine eingeloggten sessions so:
if (!isset($_SESSION['REMOTE_ADDR']) && !isset($_SESSION['HTTP_USER_AGENT']) && !isset($_SESSION['INITALIZIED'])) { session_regenerate_id(); $_SESSION['INITALIZIED'] = true; $_SESSION['REMOTE_ADDR'] = sha1($_SERVER['REMOTE_ADDR'].'INSIDE'); $_SESSION['HTTP_USER_AGENT'] = sha1($_SERVER['HTTP_USER_AGENT'].'INSIDE'); } elseif (!($_SESSION['REMOTE_ADDR'] == sha1($_SERVER['REMOTE_ADDR'].'INSIDE')) || !($_SESSION['HTTP_USER_AGENT'] == sha1($_SERVER['HTTP_USER_AGENT'].'INSIDE')) || !($_SESSION['INITALIZIED'])) { die('No Access'); }
ich weiß ich bin nurn kleiner noob, und vermutlich is des auch reiner müll was man da ließt, aber lass es mich erklären:
Session-Fixing is scheiße! soviel forne weg. Das bedeutet man errät eine Session-ID und kann dann, wenn sie richtig ist, mit der session mist machen. dazu fixier ich eben den USER_AGEND und die IP. diese sollen daran hindern, das von einem anderen computer mit der gleichen sessionID zugegriffen wird.
so, warum aber das ganze mit nem komischen .'INSIDE' drann und warum in sha1 gepackt? Session-Hijacking find ich genauso müll!
dazu kann ich mal ein szenario geben, in dem diese adds an den jeweiligen schlüsseln helfen:
wenn jemand irgendwie doch mal sein code einschmuggeln kann (das kann immer passieren, selbst den besten), und er liest aus, wie dein sessionarray zusammengebaut ist, kann er versuchen selbst so eine session zusammenzubauen. er könnte nun also eine session bauen, mit der er als initialisiert gilt, einen user_agend eingibt und seine IP adresse, und somit ja als eingeloggt gelten würde und zugriff auf alles hat. dadurch dass der sha1 von dem USER_AGENT aber nicht der ist, den ich habe, weil bei mir nochwas dran hängt, isses aber auch nen griff ins klo. er wird es auch umgehen können wenns ein profi ist, bestimmt, irgendwie, aber es hindert ne zeit und vllt ist der ein oder andere ja schon da am ende seines lateins^^
ich habe keine ahnung wie man eine session fälschen kann, oder wie session-hijacking geht, aber ich weiß dass es mobbelkotze ist! im enddefekt kannst du nicht immer alles sicher haben, aber du kannst es schwerer machen rein zu kommen. ich hab das ganze mal nach lesen eines langen tutorials über sicherheit gemacht xD dachte es hilft vllt
zu den user_agents: da hat nikic vollkommen recht je nach useragent kann man den kontent anpassen. zb für altere browser nur alten CSS code, für handys nochmal anderen, und für den IE, weil er so komisch ist, auch was eigenes. so kannst du über die useragents praktisch steuern dass immer das richtige design für den jeweiligen clienten daliegt. aber man kann es eben auch in solchen fällen für die sessionsicherung nutzen
-
@ ggamee, vielen dank für deinen Beitrag^^
Also keine Angst ich generiere meine eigene Session ID und wenn die einer nachbauen kann fresse ich nen Besen
Aba jetzt mal Spaß bei Seite^^ ich Speichere die Session ID + IP und Browser des Users in eine Mysql Datenbank und frage darüber alles ab. Die eingaben werden doppelt (an manchen stellen sogar noch öfters) überprüft, das ich da auch ja nix übersehen habe oder sich etwas einschleichen konnte.
Mir ging es eher darum einen User genau zu identifizieren.
Aba es hat sich mir noch eine Frage auf getan^^
Wie kann ich es am besten vermeiden das jemand ein Script von mir mit lauter anfragen zumüllt? (als Beispiel jetzt mal ein Registrierung Script)
Ich hab e daran gedacht jede Seite in einer Mysql Tabelle zu schreiben und den letzte Seitenaufruf, jetzt könnte man ja einstellen wie oft man welche Seite in einer gewissen zeit aufrufen darf bzw. auf unser Beispiel bezogen sich registrieren darf. Wenn man jetzt noch überprüfen würde ob die IP sich schon einmal angemeldet hat denke ich wäre es schon etwas Spam sicherer, aber für meinen Geschmack nicht wirklich sicher genug, hat jemand noch eine Idee wie man solchen Spam vermeiden kann? (Captchas lehne ich vornherein ab)
-
fabo schrieb:
Schau dir mal http://www.bot-trap.de an. Damit bist du den größten Teil an Proxies und potentiellen Angreifern los.
-
@ fabo, ich habe mir diese Seite schon beim ersten mal angesehen und finde das für mein Projekt nicht gerade als dich richtige Methode.
Mir geht es mehr darum so etwas wie eine zusätzliche Frage einzubauen die der User beantworten muss oder ähnliches.
Aber gleich ein haufen IP's und Co zu sperren für so nen kleines Projekt finde ich schon etwas übertrieben^^ -
Was du aufjedenfall machen musst.
- Alle variablen mit htmlentities() filtern.
- Den HTTP User Agent checken -
thx. Die Variabeln werden auf alles mögliche gecheckt, also da wird sich so schnell nix einschleusen. Aber das müsste ja auch Standart sein solchen Eingaben nicht 100% zu vertrauen.
Der Thread kann geschlossen werden. -
Eins möchte ich noch eben anmerken. ;)
nehgative schrieb:
Was du aufjedenfall machen musst.
- Alle variablen mit htmlentities() filtern.
- Den HTTP User Agent checken
Oder mit der wesentlich größeren Alternative htmlspecialchars() . ;) Die filtert noch einiges mehr an HTML Codes. ;) -
Also für mich liestsich das genau anders herum robbmaster.Die Funktion ist komplett identisch zu htmlspecialchars(), allerdings wandelt htmlentities() wirklich [b]alle[/b] Zeichen, die eine HTML-Code-Entsprechung haben, in diese Entsprechung um. -
He ich sag dir eins. Du kannst dein Login nicht so programmieren das es die Hacker nicht schaffen hinein zu hacken. Die Hacker hacken alles auch das eigene Netzwerk. Ich glaube daher ist die md5 verschlüßelung am besten.
-
tezt schrieb:
Also ich habe des öfteren im Web gelesen das md5 schon vor ner weile "geknackt" wurde. Zudem verwende ich diese Verschlüsselung nur wenn ich bestimmte Sachen in die Datenbank schreiben die mich im endeffekt nix angehen., also z.B. Userpasswörter
He ich sag dir eins. Du kannst dein Login nicht so programmieren das es die Hacker nicht schaffen hinein zu hacken. Die Hacker hacken alles auch das eigene Netzwerk. Ich glaube daher ist die md5 verschlüßelung am besten.
Und ich möchte es den sogenannten Hackern doch gern so schwierig wie möglich machen Ich Persönlich frage mich aber eher wie ich mögliche Bots loswerden kann, die würden mir mehr sorgen bereiten als Hacker.
-
md5 ist kein Verschlüsselungs-Algorithmus, sondern ein Checksum-Algorithmus. IdR nutzt man den, um die Passwort-Authentifizierung zu machen... aus einem MD5-Hash kann man keine Passwörter errechnen, weswegen man das ding nur Bruten kann oder Dictionary-Attack...
und solange der Hacker keinen Zugriff auf die DB hat, kommt er auch nciht an die hashes, um die über CUDA-Anwendungen Bruten zu können... (alles andere Dauert zu lange und ist prähistorisch)
und wenn der Hacker Zugriff auf die Datenbank hat, ist sowieso alles zu spät... dann kann er auch andere verschlüsselte Inhalte bruten... -
@siteplayer: Sorry, hast Recht
sebulon schrieb:
md5 ist kein Verschlüsselungs-Algorithmus, sondern ein Checksum-Algorithmus. IdR nutzt man den, um die Passwort-Authentifizierung zu machen... aus einem MD5-Hash kann man keine Passwörter errechnen, weswegen man das ding nur Bruten kann oder Dictionary-Attack...
Stimmt nicht ganz. Es handelt sich hierbei im einen offenen Algorithmus. Die größte Gefahr bei einem Hash ist, dass irgendwann jemand eine Methode entwickelt, mit der möglichst schnell eine Kollision (d.h. zwei völlig verschiedene Werte bilden den exakt selben Hashcode) gefunden werden soll. 2008 (so um den Dreh jedenfalls) gelang es ein paar Forschern mit einem Cluster aus ~100 PS3 regelmäßig und (verhältnismäßig) schnell Kollisionen zu md5 zu finden. Das Problem bei md5 ist, dass er doch schon etwas älter ist - und die Hardware immer besser wird. Klar, es waren noch PS3. Aber auch der Kollisionalgorithmus lässt sich sicherlich verbessern, und i nein paar Jahren ist die Hardware wieder deutlich besser. ;)
Wenn ich was das angeht unbedingt sicher sein will, benutzen ich lieber einen der sha-Familie. ;) -
wenn ich sicher sein will, nutze ich 2 verschiedene in kette, die künstlich die Zeichenlänge aufbläht... dann hilft dir auch ne Kollision nix, weil du nciht weißt, welcher Algorithmus in der letzten stufe verwendet wurde^^
ne relativ sichere geschichte wäre dann zum beispiel base64 -> md5 -> base64
ne relativ einfache und CPU-Zeit-sparende geschichte, aber doch recht effektiv... das erste base64 gegen eine brute-force-attacke, um die Zeichenlänge künstlich in die länge zu treiben, trotz geringerer zeichenkomplexität... dann die md5 daraus, um wie gesagt kein reverse zu ermöglichen und das letzte md5, um solche kollision geschichten zu verhindern...
und da es noch keinen alles lösenden algorithmus gibt, bleibt den leuten nur noch das altbekannte bruteforce^^
mehrere einfache Verfahren hintereinander sind komplizierter zu knacken, als ein komplexer algorithmus... die algorithmen sind bekannt, aber was du dir ausdenkst, sollte in der Regel unbekannt sein^^
um ganz sicher zu gehen, dass keiner aus versehen den ftp-server knackt und einfach in deine php-files schaut, kannst du die natürlich verschlüsselt ablegen und zur laufzeit erst entschlüsseln lassen... oder verschlüsselt in der Datenbank ablegen... dann wirds aber langsam rechenaufwendig... aber auch sicherer... und wer wirklich da rein will... da kannst du dich nciht wehren, wenn derjenige physischen Zugriff hat darauf... -
Diskutiere mit und stelle Fragen: Jetzt kostenlos anmelden!
lima-city: Gratis werbefreier Webspace für deine eigene Homepage
