Moin, Bin sonst eher in C unterwegs und nicht in Webhochsprachen, daher hab' ich da einige Defizite... Grad guck' ich mir die Beispiele von bootstap an: https://getbootstrap.com/docs/4.5/examples/ Insbesondere das "sign-in". Hab' also einen Webserver am laugfen, die Seite erscheint in meinem Browser, ich kann tolle Sachen tippern und auf den Knopf "Sign-in" druecken. Dann passiert halt nur leider nix, ausser dass die Seite sich neu laed, was bei diesem Beispiel ja so gewollt sein wird. Nun haett' ich halt ganz gerne sowas, das nach dem "Sign-in" Knopfdruck tatsaechlich ueberprueft wird, ob da einer auch auf andere Seiten zugreifen darf, oder nicht. Am liebsten waer' mir dabei, wenn irgendwelches Javascript dann z.b. auf eine xml-Datei zugreifen koennte, in der z.b. hashes von "meinen" email/password Kombis drinnenstehen und dann entsprechend guckt, obs passt oder nicht. Dabei sollte natuerlich die xml-Datei mit den hashes nicht unbedingt ueber den Webserver auch von aussen "runterladbar" sein oder aehnliche Sicherheitskaspereien aufweisen. Wie mach' ich das, oder wo steht, wie man sowas macht? Also wie flansch' ich an diese Beispiele von bootstrap was eigenes an? Also irgendwelches Zeugs aud xml files lesen oder von mir aus auch per Websocket (wenn ich nur wuesst' was dann am Anderen Ende dieses Websockets haengen soll und lauschen und zurueckquaken) oder sonstwie? Gruss WK
JS wird nichts, denn dir Auswertung soll ja auf dem Server passieren. Dafür gibt es klassischerweise PHP. Alternativ das ASP.NET-Zeug von MS, das wird aber mWn auch wieder in PHP übersetzt an Ende.
Für irgend so eine Frameworkgedöns wirst du hier vermutlich nicht viele Antworten bekommen. Davon gibt es zig tausend Verschiedene. Da ist eher ein Forum angebracht wo genau dein Framework Supporte wird. Aber ganz allgemein solltest du dich mal damit beschäftigen war macht der Client und was läuft auf diesem und was macht der Server und welche Anteile laufen dort. Und wie sieht die Arbeitsteilung zwischen den beiden aus. Mit Javascript eine xml prüfen ohne die xml herunter zu laden schließt sich gegenseitig aus. Und allgemein ist eine Sicherheitsüberprüfung auf dem Client machen zu wollen ob der auf den Server darf sowieso eine ganz dumme Idee.
Du hast bei Webseiten immer die Serverseite und die Clientseite. JavaScript wird immer auf dem Clientrechner ausgeführt und kann entsprechend auch nur auf Serverressourcen zugreifen, die öffentlich zugänglich sind. Die Liste mit Logindaten sollte das möglichst nicht sein :D Heißt: du musst die Auswertung auf dem Server machen, zB. mit php. Php Skripte werden nur auf dem Server ausgeführt und sind von außen nicht einsehbar. Je nach dem welchen Zugriff du auf den Server hast kann man das unterschiedlich umsetzen. Prinzipiell funktioniert das ganze so (grob umrissenes Beispiel): Der Client ruft die "Loginseite" auf. Der Server startet eine Session. Der Nutzer tippt seine Login-Daten ein und drückt "absenden". In dem Moment wird die "Loginseite" erneut aufgerufen, diesmal stehen aber in der http Anfrage zusätzlich die eingegebenen Login-Daten. Dein Serverskript schaut dann also ob Logindaten mitgesendet wurden, wenn ja dann schaut er, ob diese mit hinterlegten Daten übereinstimmen*. Wenn die Daten verifiziert werden konnten wird ein Cookie gesetzt, dass den Nutzer als "angemeldet" ausweist. Das wird bei jeder Anfrage serverseitig geprüft und die Webseite, diesem Status entsprechend, zurückgegeben. * wichtig ist, dass die Datei mit den Anmeldedaten nicht öffentlich einsehbar ist. Wenn du selber einen Server betreibst, kannst du die Anmeldedaten z.B. in einer Textdatei außerhalb des document-root des Webservers ablegen. Wenn du nur Zugriff auf das document-root-Verzeichnis hast, nimmst du am besten eine Datenbank (zB. MariaDB oder MySQL sind ja in den meisten Hostingangeboten enthalten). Wenn das wirklich mal mit echten Nutzerdaten genutzt werden soll, muss man sicherstellen, dass das ganze technisch sicher ist und auch die Gesetze beachten, wie zB. keine unverschlüsselte Übertragung von sensiblen Daten, Einwilligung in dei Datenverarbeitung, Auftrags-Datenverarbeitungvertrag mit dem Hoster haben, Impressumspflicht und was es da sonst noch alles gibt.
Du kannst die login daten auch direkt in die php schreiben denn die php quelldatei ist auch nicht clientseitig lesbar sofern der Server korrekt läuft. (ich empfehle aber mindestens passwörter dennoch zu hashen, nur für den Fall) von xml oder textdateien halte ich nicht soooo viel, ist natürlich möglich aber eben nur selten sinnvoll; bei wenigen erlaubten Zugängen die Du manuell verwaltest, kannst Du ein Array aus username-passwort(HASH) Paaren in die php direkt (oder eine zweite include php) schreiben; hast Du mehrere und willst die ggf online erweiterbar halten nutzt man besser eine Datenbank. Wenn Du es klein und möglichst mit nur einer Datei halten willst, SQLite. Ansonsten hat Alexander alles gesagt denke ich 'sid
qwertzuiopü+ schrieb: > Alternativ das ASP.NET-Zeug von MS, > das wird aber mWn auch wieder in PHP übersetzt an Ende. 100% garantiert nicht :)
Moin, Ja, wenn man mal von meiner Schnapsidee im ersten Post absieht, ist mir's prinzipiell schon klar,was auf der Server und Clientseite jeweils ablaeuft. Ich kann mangels Wissen halt nicht abschaetzen, was gerade der heisse Scheiss ist. OK, scheint also PHP zu sein. Gut, hab's grad mal fuer x86_64 gebaut: umpf - 3 jeweils 12MByte grosse executables: php,php-cgi,php-fpm (wenigstens brauchts keine exotischen libraries). Der olle nginx ist ja nur 1.2MByte gross. Ging's nicht auch ne Nummer kleiner? Datenbank muss auch echt nicht sein. Es wird spaeter eher nur 1..3 User geben. Ich will eher nicht sowas wie facebook oder youtube bauen, sondern eher so was in Richtung "embedded", also keine CPU Cluster mit RAID-Arrays. Auf bootstrap bin ich auch nur gekommen, weils bei heise unlaengst einen Artikel gab mit bootstrap in der Ueberschrift. Eigentlich ist mir das Framework voellig wurscht. Ich brauch' halt ein paar bunte Knoepf' wo was passiert, wenn ich draufdrueck'. Beim Login waers schick, wenn auch bei einer http(ohne s) Verbindung nicht grad im Wireshark das user/password in clear text auftauchen wuerden. Also eher nicht sowas wie : "http://1.2.3.4/login.php?user=admin&password=admin"; So entstand auch die - zugegeben - Schnapsidee mit dem js fuers Login. Gruss WK
Irgendwie wären dann ein paar konkretere Hinweise hübsch, was denn nun eigentlich die Anforderungen sind. Ist die Größe des Interpreters wirklich ein Thema? Dann wäre Lua eine Option. Das versteht sich auch gut mit nginx, ist nicht zu exotisch, aber kein Vergleich mit PHP oder Perl. Wenn klickibunti keine Anforderung ist und nur bestimmte Seiten hinter einem Login verschwinden sollen, wäre vielleicht htaccess eine noch einfachere Lösung. Wenn es schlank sein soll, willst du eher kein Framework. Wenn du dir keine großen Gedanken machen willst, wie man eine Anmeldefunktion sicher gestaltet, willst du ein Framework. Dergute W. schrieb: > Beim Login waers schick, wenn auch bei einer http(ohne s) Verbindung > nicht grad im Wireshark das user/password in clear text auftauchen > wuerden. Das ist zwar machbar (wahrscheinlich am einfachsten: hashen mit JS), aber eine solche "Lösung" willst du bei öffentlich Zugänglichem nicht haben. Du willst TLS und spätestens seit Let's encrypt ist das auch mit sehr erträglichem Aufwand möglich.
Moin, Heiner schrieb: > Irgendwie wären dann ein paar konkretere Hinweise hübsch, was denn nun > eigentlich die Anforderungen sind. Die Anforderung ist, dass ich ein bisschen einen Plan krieg, was bei einem Webinterface derzeit hip ist und was eher nicht. Und dass ich so ein bisschen ein Gefuehl dafuer bekomme, wie weit es sinnvoll ist, auf Bloat zu setzen um irgendwas anderes (Was? irgendwelche weiteren Frameworks/Sicherheit/Entwicklungsgeschwindigkeit/...) dafuer zu bekommen. Heiner schrieb: > Das versteht sich auch gut mit nginx, ist nicht zu exotisch, > aber kein Vergleich mit PHP oder Perl. Was soll das heissen: Versteht sich gut mit nginx? Was geht mit nginx, was mit apache, lighty, sonstwem nicht geht? Was geht mit Lua nicht, was mit PHP oder Perl geht? Ich suche konkrete Beispiele. Eben sowas wie im ersten Post das bootstrap-sign-in. Das ist hurtig runtergeladen, vom Umfang her auch fuer mich ueberschaubar, ich erkenne sofort, wo ich nicht mehr weiterkomme... Und da waeren weiterfuehrende Beispiele schick, die dann ja auch gerne mit LUA,PHP, etc. zusammenarbeiten, ohne gleich voellig aus dem Ruder zu laufen. Auch gut: Moeglichst allgemein gehalten, nicht irgendwelche sudo apt-get Orgien, die nur mit Ruelpsbuntu in der Version 1.23.4.56-LTS-rubbeldiekatz und nur bei Webhostern, die mit HP Baxxter werben, funktionieren. Sondern eher sowas, wo tatsaechlich wurscht ist, mit welchem Texteditor ich in den Konfigurationen rumferkele... Gruss WK
Dergute W. schrieb: > Ich suche konkrete Beispiele. Eben sowas wie im ersten Post das > bootstrap-sign-in. Das ist hurtig runtergeladen, vom Umfang her auch > fuer mich ueberschaubar, ich erkenne sofort, wo ich nicht mehr > weiterkomme... Arbeite dich mal in PHP ein, als erster Tip https://wiki.selfhtml.org/wiki/PHP/Tutorials/Einstieg Eine Abfrage von POST-Variablen und die an eine Datenbank schicken war zumindest zu PHP4-Zeiten nicht sonderlich schwer :) > Sondern eher sowas, wo tatsaechlich wurscht ist, > mit welchem Texteditor ich in den Konfigurationen rumferkele... Du solltest weniger in den Konfigurationen rumbasteln denn in den Dokumenten/Skripten :)
> Du kannst die login daten auch direkt in die php schreiben > denn die php quelldatei ist auch nicht clientseitig lesbar Nein, bitte auf keinen Fall solche Empfehlungen geben. > sofern der Server korrekt läuft. Genau deswegen. Wenn irgendwas mit der PHP-Instanz nicht stimmt, wird das PHP-Script im Klartext übertragen, inkl. aller darin gespeicherten Kennwörter. Deswegen ist es extrem empfehlenswert, im htdocs-Ordner keine Kennwörter im Klartext zu speichern. Nicht mal die Datenbankkennwörter, die das PHP-Script zwangsweise kennen muß - die gehören in eine Datei außerhalb von htdocs (oder wenn es ein Unterordner sein muß, dann in einen mittels htaccess von der Auslieferung ausgesperrten Ordner), von wo sie mittels require_once oder so nachgeladen werden. Dann sind sie schon recht gut geschützt, auch im Falle eines Serverproblems. > (ich empfehle aber mindestens passwörter dennoch zu hashen, > nur für den Fall) Hey, er kann es ja doch richtig. :) Direkte Hashwerte im PHP sind gerade noch akzeptabel, auch wenn man damit bei einer solchen Panne viel über den Aufbau und eventuelle Salts preisgibt (vereinfacht den Angriff mit externen Programmen, z.B. Wörterbuchangriff mit den korrekten Salts). Ein sicheres Kennwort (nicht "admin" oder sowas) ist dann immer noch eine recht hohe Hürde. Zum Thema: So ein statischer Login ist eigentlich keine große Sache, die funktionielle Basis davon programmiert man in PHP binnen 5 Minuten. Etwas aufwendiger wird es für wechselnde Benutzer oder wenn man Schutzmechanismen haben will (für all das braucht man dann eine Datenbank). Also ich meine sowas wie daß nach dem 3. Fehlversuch für eine Stunde alle Kennwörter als falsch abgewiesen werden (auch das korrekte), damit kann man ziemlich wirkungsvoll ein Durchprobieren vieler Kennwörter (Wörterbuchangriff) verhindern. Oder 'ne Teergrube - Kennwort falsch, bitte warte 10 Minuten bevor du es erneut probieren darfst. HTTPS/TLS/SSL sollten heute alle Anbieter für ganz wenig Geld können. Wenn nicht, Finger weg - dann gibt es bessere Anbieter. Dann mußt Du die Benutzer nur noch deutlich darüber informieren, daß Du bei der Anmeldung Daten über sie speicherst bzw. welche Daten Du speicherst und daß sie das mit der Anmeldung/Login absegnen. Auf Wunsch mußt Du Auskunft erteilen, welche persönlichen Daten Du gespeichert hast bzw. mußt diese auf Verlangen löschen. Vernünftiges Impressum, Datenschutzerklärung, sollte für ein Hobbyprojekt reichen.
:
Bearbeitet durch User
Dergute W. schrieb: > Die Anforderung ist, dass ich ein bisschen einen Plan krieg, was bei > einem Webinterface derzeit hip ist und was eher nicht. Oben schreibst du kurz von "embedded". Das wäre eine Anforderung, wie ich sie gemeint habe: Auf welcher Hardware soll das laufen? Dergute W. schrieb: > Und dass ich so > ein bisschen ein Gefuehl dafuer bekomme, wie weit es sinnvoll ist, auf > Bloat zu setzen um irgendwas anderes (Was? irgendwelche weiteren > Frameworks/Sicherheit/Entwicklungsgeschwindigkeit/...) dafuer zu > bekommen. Es ist sinnvoll. Eine ausreichend abgehärtete Versammlung von Sicherheitsmaßnahmen schon fertig zur Verfügung zu haben, ohne sich in alle Details selbst einarbeiten zu müssen, spart Zeit und Nerven. Einen groben Abriss hat Ben B. gegeben. Das sind Dinge in die man sich nicht unbedingt knietief einarbeiten will, wenn man ein fertiges Framework benutzen kann. Dergute W. schrieb: > Was soll das heissen: Versteht sich gut mit nginx? Die Kombination ist gut erprobt, wird in realen Anwendungen regelmäßig genutzt (z.B. cloudflare) und es gibt sogar fertige Pakete (openresty). Dergute W. schrieb: > Was geht mit nginx, > was mit apache, lighty, sonstwem nicht geht? > Was geht mit Lua nicht, was mit PHP oder Perl geht? Nichts, zumindest auf dem Niveau, um das es hier geht. Das würde sogar noch dann gelten, wenn du die Aufzählung von Webservern und Sprachen erheblich verlängern würdest. Genau deshalb frage ich nach deinen Anforderungen: Was du machen willst, geht ziemlich sicher auf jedem Webserver mit jeder Skriptsprache und mit oder ohne jedes Framework. Wenn es wirklich keine weiteren technischen Anforderungen gibt: Nimm das, was dir gefällt. nginx habe ich aufgegriffen, weil du es erwähnt hast, und Lua hätte ein sogar noch kleineres executable, was du wohl (völlig wertungsfrei) interessant findest. Jede andere Kombination wird es aber auch tun. bootstrap ist übrigens für Frontends gedacht - was ich oben als klickibunti bezeichnet habe. Für die Funktionalität muss da etwas anderes dahinter arbeiten, typisch wäre Node.js, Ruby on Rails oder ASP.NET. Deshalb die Frage, ob es hübsch werden muss - sonst kann man das für den Moment einfach mal ausklammern.
Dergute W. schrieb: > Die Anforderung ist, dass ich ein bisschen einen Plan krieg, was bei > einem Webinterface derzeit hip ist Wen interessiert, was hip ist? Funktionieren muss es und sicher muss es sein. > und was eher nicht. Und dass ich so > ein bisschen ein Gefuehl dafuer bekomme, wie weit es sinnvoll ist, auf > Bloat zu setzen um irgendwas anderes (Was? irgendwelche weiteren > Frameworks/Sicherheit/Entwicklungsgeschwindigkeit/...) dafuer zu > bekommen. Bloat nimmt dir viel Arbeit ab. Das ist alles. Wenn du volle Kontrolle und eine schlanke Lösung haben willst und bereit bist, eigene Arbeit zu investieren, dann kannst du auf den Bloat verzichten. Ich persönlich benutze für kleinere Sachen lighttpd als Server, Perl als Sprache und ggf. PostgreSQL als DB. Perl übrigens deswegen, weil es den Benutzer schon vom Konzept her zwingt, über Sicherheitsfragen nachzudenken. Fortgeschrittene Kenntnisse bezüglicher regularer Ausdrücke sind allerdings strengstens empfehlenswert, denn letztlich hängt die Sicherheit der Gesamtlösung von der Korrektheit eben dieser Ausdrücke ab. Für größere Sachen nehme ich allerdings eher ASP.net, also unsagbaren Bloat. Die Zeitersparnis bei der Entwicklung überwiegt hier.
Soooo... da ich viel zu früh wach war und nicht mehr einschlafen konnte habe ich die Zeit mal mit was Sinnvollem verbracht. Das Script sollte so sicher sein, wie es ohne großen Aufwand ohne Datenbank möglich ist. Es kann ein .htaccess geschütztes Verzeichnis für reines HTML verwenden. Wenn man Bilder aus diesem Verzeichnis braucht/schützen will, muß man es um einen Content-Type-Handler dafür erweitern (könnte ich bei Bedarf noch nachreichen), der das Bild nach dem Check durchreicht. Mir ging es jetzt nur darum, aufzuzeigen, wie man so einen serverseitigen Login einigermaßen sicher hinbekommt, deswegen ohne jedes Design-Extra. Das Script ist z.B. nicht gegen session hijacking oder brute force scans geschützt und ohne SSL wird das Passwort unverschlüsselt übertragen, aber sowas sollte heutzutage sowieso nicht mehr ohne SSL laufen, dadurch ist letzteres kein Problem. Gegen ersteres kann sich jemand selbst Maßnahmen ausdenken, für die Demo war mir das jetzt unwichtig. Die Zugangsdaten für die unsichere Zeile in der Hashliste sind admin:admin, das sollte man natürlich als erstes rausschmeißen wenn man da Benutzer anlegt. Getestet hab ichs auf einem Apache 2.4, PHP7 und dem Firefox. Das .ZIP gibts wegen mehreren Dateien und damit ich das geschützte Verzeichnis nicht extra zu erklären brauche, oder welche Datei wo rein gehört. Haftung übernehme ich für das im Halbschlaf aneinandergeschmissene PHP/HTML-Gekritzel natürlich nicht. Wenn ich was übersehen habe oder ihr's kaputt bekommt, dürft ihr's gerne hier schreiben, evtl. schaue ich dann nochmal drüber wie man die Sicherheit steigern könnte. Nur für den Fall der Fälle: Ich verbitte mir eine kommerzielle Nutzung, auch wenn ich glaube, daß diese kleine Demo für diesen Zweck lange nicht ausgereift genug ist. Alles andere ist mir egal, das Prinzip ist so simpel, daß sich dafür nicht mal ein Eintrag in die Credits lohnt.
Dergute W. schrieb: > Die Anforderung ist, dass ich ein bisschen einen Plan krieg, was bei > einem Webinterface derzeit hip ist und was eher nicht. Da fragst du hier aber ab der falschen Stelle. PHP, ASP etc. was hier genannt wird ist mittlerweile "gereift" aber bestimmt nicht mehr hip. Wenn's danach geht: Node.js am Server, Angular/Vue/React am Client.
Dergute W. schrieb: > Die Anforderung ist, dass ich ein bisschen einen Plan krieg, was bei > einem Webinterface derzeit hip ist und was eher nicht. Zwar schon etwas in die Jahre gekommen, aber von der Sache noch voll aktuell, nur die Frameworks und Zwischenschichten sind mehr geworden: https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f#.mley0kodp
Dergute W. schrieb: > Bin sonst eher in C unterwegs und nicht in Webhochsprachen, daher hab' > ich da einige Defizite... Du hast ganz andere Defizite. Wenn du in C genauso planlos rumfrickelst wird das nix. Du weisst ja nicht mal was du selber willst wie sollen da andere helfen. Ist das wieder ein Stümperthread. Und alle geben fleissig Ratschläge, was eigenltlich konkret gefordert ist, keiner weiss es, nicht mal der C-Gott.
qwertzuiopü+ schrieb: > JS wird nichts, denn dir Auswertung soll ja auf dem Server passieren. > Dafür gibt es klassischerweise PHP. Alternativ das ASP.NET-Zeug von MS, > das wird aber mWn auch wieder in PHP übersetzt an Ende. dotNET != PHP es wird in CLI übersetzt. https://de.m.wikipedia.org/wiki/Common_Intermediate_Language
S. R. schrieb: > Was ist eigentlich das Problem mit der .htaccess-Variante? http://www.bot-trap.de/wiki/wikka.php?wakka=htaccessNachteile
Moin, Wo die Sicherheitsexperten ja grad' da sind: Gibts da irgendwelche Sicherheitsriesenloecher, wenn man C funktionen aus PHP aufruft, wie hier beschrieben: https://wiki.php.net/rfc/ffi Die Option "--with-ffi" wird im BLFS Buch beim Bau von PHP auch nicht verwendet oder erwaehnt - koennte das solche Gruende haben? Gruss WK
Dergute W. schrieb: > Wo die Sicherheitsexperten ja grad' da sind: > > Gibts da irgendwelche Sicherheitsriesenloecher, wenn man C funktionen > aus PHP aufruft Naja, man ruft halt Code auf, der in einer inhärent unsicheren Sprache geschrieben wurde. Dadurch kann es natürlich mit erhöhter Wahrscheinlichkeit zu Sicherheitslücken kommen. Ist der aufgerufene C-Code fehlerfrei, gibt's auch keine Sicherheitslücken. Allerdings gibt es nur recht wenig wirklich fehlerfreien C-Code in der freien Wildbahn zu entdecken. Der meiste C-Code wird halt von Idioten geschrieben, die C nur deshalb verwenden, weil es soviel Vorlagen für die C&P-Operationen gibt, die die "Programmieren" nennen...
Patrick S. schrieb: >> Was ist eigentlich das Problem mit der .htaccess-Variante? > http://www.bot-trap.de/wiki/wikka.php?wakka=htaccessNachteile Aha. Also in diesem Fall, keine Probleme.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.