Forum: PC-Programmierung Webgedoens/Login etc.


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Dergute W. (derguteweka)


Bewertung
0 lesenswert
nicht lesenswert
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

von qwertzuiopü+ (Gast)


Bewertung
-3 lesenswert
nicht lesenswert
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.

von Irgend W. (Firma: egal) (irgendwer)


Bewertung
3 lesenswert
nicht lesenswert
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.

von Alexander F. (gustin)


Bewertung
0 lesenswert
nicht lesenswert
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.

von sid (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von cppbert (Gast)


Bewertung
1 lesenswert
nicht lesenswert
qwertzuiopü+ schrieb:
> Alternativ das ASP.NET-Zeug von MS,
> das wird aber mWn auch wieder in PHP übersetzt an Ende.

100% garantiert nicht :)

von Dergute W. (derguteweka)


Bewertung
0 lesenswert
nicht lesenswert
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

von Heiner (Gast)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Dergute W. (derguteweka)


Bewertung
0 lesenswert
nicht lesenswert
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

von Reinhard S. (rezz)


Bewertung
1 lesenswert
nicht lesenswert
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 :)

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Bewertung
0 lesenswert
nicht lesenswert
> 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
von Heiner (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von c-hater (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

von Jan H. (j_hansen)


Bewertung
2 lesenswert
nicht lesenswert
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.

von Εrnst B. (ernst)


Bewertung
0 lesenswert
nicht lesenswert
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

von Rausprüfer (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
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.

von Dergute W. (derguteweka)


Bewertung
0 lesenswert
nicht lesenswert
Moin,

Merci fuer das PHP Login beispiel :-)

Gruss
WK

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
Was ist eigentlich das Problem mit der .htaccess-Variante?

von Patrick S. (paddyhb89)


Bewertung
0 lesenswert
nicht lesenswert
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

von Patrick S. (paddyhb89)


Bewertung
0 lesenswert
nicht lesenswert
S. R. schrieb:
> Was ist eigentlich das Problem mit der .htaccess-Variante?

http://www.bot-trap.de/wiki/wikka.php?wakka=htaccessNachteile

von Dergute W. (derguteweka)


Bewertung
0 lesenswert
nicht lesenswert
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

von c-hater (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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...

von S. R. (svenska)


Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.