PHP HTML, textarea in textarea, web-editor

[Domi_bas]

Hallo,

versuche gerade für eine kleine Seite eine Art online-backend-web&file-editor zu bauen. Auf dieser Homepage möchte ich aus dem Backend Dateien öffnen, den html/php/js-code darin bearbeiten und sie dann wieder speichern.

Das öffnen und speichern klappt soweit ganz gut. Lese die Datei mittels file_get_contents() aus und schreibe das in eine textarea. Das klappt auch soweit ganz gut, kann editieren und speichern mit fwrite.

Wenn jedoch in der zu bearbeitenden Datei selbst eine textarea ist, wird nur der Quellcode bis zum schlusstag </textarea> angezeigt, ab da fehlts dann.

Hab gedacht, dass der Browser das HTML so deutet, als ob beim ersten schlusstag die textarea zuende ist, OK, aber wo ist dann der Rest? Nach der textarea kommt nichts mehr...
Hoffe ihr versteht mich, Google tut es nicht.

Möchte einfach nur den Inhalt der Datei bearbeiten und speichern, aber immer wenn das HTML Tag textarea endet wird der nachfolgende Code abgeschnitten.

Verwende php7 und bootstrap.

Danke!

 

[Jokeboy]

Liegt daran das man eine <textarea> nicht verschachteln kann (außer mit Umwegen).

Ich würde das eher mit div und contenteditable machen.

 

[benneq]

Dein Problem ist, dass der generierte HTML Code so aussieht:

<textarea>
foo
<textarea>
bar
</textarea>
baz
</textarea>

Du müsstest also die Sonderzeichen escapen. PHP bietet dafür verschiedene Funktionen. Ich weiß leider nicht, welche "state of the art" ist. Aber eine davon wäre z.B. "htmlspecialchars"

Und dann beim Einlesen (bzw. Datei schreiben) diesen Vorgang wieder rückgängig machen.

 

[Konto gelöscht]

Genau, was die schon sagen. Und die Datei kannst du übrigens auch mit file_put_contents() wieder speichern, wenn du schon die Lesefunktion davon verwendest ☺️

 

[Sgt_H4rtman]

Hallo Domi_bas,

die technisch/sachlich richtigen Hinweise hast du schon bekommen. Ich möchte dich aber eingehend bitten dein Vorhaben noch einmal genau zu überdenken. Aus deiner Fragestellung geht hervor, dass du wenig Erfahrung in diesem Bereich hast. Was du da baust ist faktisch ein direkter Zugriff auf den Webserver mit welchem jedes halbwegs fähige Scriptkiddie eine Rootshell installieren und den Server kapern/mißbrauchen kann. Aus deiner mangelnden Erfahrung kannst du das nicht vernünftig absichern. Selbst jahrelange, erfahrene Entwickler bauen in solchen Komponenten schwerwiegende Sicherheitslücken ein. Investiere die Zeit lieber darin ein echtes CMS zu erlernen und installiere/verwende dieses. Das ist zwar auch kein hundertprozentiger Schutz, aber die häufigsten Fehler sind da schon mal nicht mehr dabei.

Bitte hör auf mich, die Welt braucht nicht noch mehr DDoS Zombies und Virenschleudern.

 

[Domi_bas]

Hallo an alle und Danke für die hilfreichen Hinweise! werde das mit dem div mal probieren.


Danke auch an S.Giny für deine tolle Einschätzung, wo du nur die ganzen Infos her hast... welcher Server, woher weißt du ob und wie diese Seite / Editor öffentlich erreichbar ist und gefunden wird...?
Sicherlich bin ich kein Profi wie du, aber htaccess kann ich noch bedienen, brauch ich aber nicht, Seite läuft lokal.

 

[Sgt_H4rtman]

Sicherlich bin ich kein Profi wie du, aber htaccess kann ich noch bedienen, brauch ich aber nicht, Seite läuft lokal

Ja merkt man, der wäre nämlich dankbar und würde den Ratschlag beherzigen. Wenn du ernsthaft glaubst mit htaccess etwas absichern zu können, dann kann man dir eh nicht wirklich helfen. Aber mal interessehalber so unter uns Profis. Wenn das alles lokal läuft, wieso dann überhaupt der Aufwand? Dann bist du mit einem Editor wie Sublime oder VS Code doch wesentlich besser beraten.

 

[Domi_bas]

Für die Hilfe bin ich dankbar...

Die Seite ist lokal bis sie fertig is, wenn sie Mal fertig wird, ist nur just for fun.

Du machst mich aber auch neugierig, warum ist htaccess, wenn es ordentlich genutzt wird und die Rechte sicher sind, denn so falsch für mein Vorhaben? Es geht na nur darum das Backend vor unbefugten zu schützen.

Sicherlich ist ein schicker Login per php und MySQL moderner, aber für mich Overkill.

 

[ayngush]

"HTTP-Basic-Auth" ist sicher genug unter folgenden Bedingungen:
* TLS Verschlüsselung.
* Die Datei mit den Logon Credentials (in der Regel die .htpasswd) ist nicht auf irgend eine Art und Weise über das Web abrufbar.

Dann gibt es nur noch drei mögliche Szenarien, wie der Schutz ausgehebelt werden kann:
1. Man-In-The-Middle Angriff, um bei einem Anmeldevorgang die Credentials abzufangen (da kann man als legitimer User mit Fachkenntnissen auch selber drauf achten, dass das Zertifikat das Richtige ist, bevor man die Anmeldedaten übermittelt). Das Würde aber auch andere Schutzmaßnahmen, die nicht einen zweiten Faktor beinhalten, aushebeln.

2. Brute-Force Angriff auf das Logon-System. Dagegen helfen bei "HTTP-Basic-Auth" unter anderem Tools wie Fail2Ban. Bei anderen Anmeldesystemen muss man sich um den Brute-Force-Schutz selbst kümmern, insofern ist "HTTP-Basic-Auth" da sogar im Vorteil, weil man mit recht wenig Aufwand ein hohes Schutzniveau dagegen errichten kann.

3. Keylogger bzw. ein beliebiger Angriff auf den Client. Aber auch hier gilt: Das Würde aber auch andere Schutzmaßnahmen, die nicht einen zweiten Faktor beinhalten, aushebeln.

.htaccess an sich ist übrigens zunächst überhaupt gar keine Schutzeinrichtung, was die Profis über mir wohl etwas übersehen, da es erstmal nur eine Datei ist, um Konfigurationsparameter an den zugrunde liegenden Webservice zu übertragen.
Man kann damit auch noch ganz andere Anmeldesysteme, neben "HTTP-Basic-Auth", konfigurieren, zum Beispiel eine Anmeldung über LDAP / Kerberos. Manchmal sogar noch über NTLM... Das sollte man langsam mal sein lassen und stattdessen lieber auf Kerberos setzen.

Was also soll an ".htaccess" jetzt genau unsicher sein, wie es ja suggeriert wird?

 

[Domi_bas]

Danke ayngush für die ausführliche Erklärung!

Wie du es mit der htpasswd Datei erklärt hast war das was ich mit den (Datei-)Rechten meinte... Bin natürlich nur blutiger Amateur, aber das glaube ich zu schaffen. Seit let's encrypt ist SSL sowieso einfacher denn je für jedermann nutzbar. Die anderen Szenarien sind dann schon eher weiter her geholt, wenn man nicht ein lohnendes Ziel wie der Bundestag oder so ist...

Was mich an dem "lass du Mal die Finger vom web, da müssen Profis ran, kleiner" Gedöns nervt ist, dass es grundsätzlich falsch ist einfachste Standards zu nutzen, während komplexe CMS so toll sind... Wenn ich mir anschaue wie viele joomla oder Wordpress Installation gehackt sind und die Betreiber das teilweise nicht Mal merken, dann glaube ich nicht, dass die Komplexität besser ist, im Gegenteil. Kann mich da gut an meine anfänglichen joomla Zeiten erinnern. Mit versionen 1.x, da waren Scheunentore offen und Updates eher langsam bzw. wurde der Betreiber nicht schnell darauf aufmerksam.

Nichts gegen die ganzen CMS, sind echt super und können viel, aber der Code ist bekannt und jeder kann Schwachstellen finden. Manche helfen diese dann zu schließen, andere nutzen sie.
Meine einfache kleine Homepage macht was sie soll, mit ordentlichen Dateirechten, einem hosting von Profis und nach bestem Wissen und Gewissen programmiert, ist da sicherer. Niemand weiß wo er ansetzen soll, wie die Datenbank aussieht, ob es eine gibt, wie heißt die config File, gibt es eine? Ist der Pfad echt oder per htaccess...

Es wie bei Autos, je mehr die können, desto mehr geht kaputt. (Mein Auto ist nicht selbst gebaut :-) kann es aber mit ein paar Schraubenschlüssel und hammer reparieren)

 

[benneq]

kann es aber mit ein paar Schraubenschlüssel und hammer reparieren)

Klingt nach einem VW Golf 1 oder 2

Ansonsten hast du aber nur teilweise Recht. Also klar tauchen für die großen CMS immer mal wieder Sicherheitslücken auf und natürlich sind dann gleich tausende Webseiten betroffen. Allerdings sitzen dann Leute daran, die diese Lücken schnellstmöglich und bestmöglich beheben.

Wenn sowas bei einem selbstprogrammierten System auftritt und du nicht wirklich weißt was los ist, dann kann es Monate dauern, bis du überhaupt weißt wo genau die Lücke ist und wie man sie behebt.

Dazu kommen dann noch die ganzen "Standard Probleme", die so ein CMS für dich löst: Von einfacher SQL Injection bis hin zu CSRF und Passwörtern mit Hasch und Salz.

Also komplett auf ein Framework verzichten würde ich niemals. Es muss ja kein komplettes CMS sein. Aber zumindest irgendeine Plattform, auf der man aufbauen kann, die einem vieles erleichtert und den Großteil der Probleme abfängt. Z.B. Laravel, Symphony, Ruby on Rails oder Spring Boot.
Alles selbst schreiben kostet viel zu viel Zeit und ist definitiv tausend mal fehleranfälliger als so ein Framework, das jeden Tag von Millionen Leuten genutzt wird.

Und zu guter Letzt: Der Code für deine Web Applikation ist natürlich nur die halbe Miete. Es können ja auch Sicherheitslücken im Webserver (z.B. Nginx oder Apache) auftreten. Oder in PHP selbst. Oder im Netzwerk Stack des Linux Kernels. Oder eben auch direkt Lücken in der CPU. Oder oder oder... Und dann musst du dich darauf verlassen, dass die Lücken schnell gefunden/geschlossen werden und dass dein Hoster die Patches einspielt.

Oder vor ein paar Tagen, als in irgendeinem sehr beliebten JavaScript Modul, das über npm verteilt wird, Schadcode gefunden wurde. Weil der ursprüngliche Entwickler gesagt hat: "Keinen Bock mehr. Ich geb das Projekt an irgendeinen Freiwilligen ab." Da waren dann auch Millionen Leute betroffen.

Einfallstore gibt's auf jeden Fall genügend. Und viele sind wahrscheinlich noch gar nicht bekannt und/oder es wurde noch keine gute Möglichkeit gefunden, um sie auszunutzen.

 

[ayngush]

Es ist aus Sicherheitsaspekten schon absolut richtig die Codekomplexität auf ein Minimum zu reduzieren.
Natürlich immer im Kontext des dazu zu betreibenden Aufwandes. Was mit Drittanbieter-Software passiert wurde ja oben geschildert, da hat der Maintainer kein Bock mehr und jemand anderes baut da eben mal ein Miningclient in eine Millionenfach genutzte Bibliothek ein. So etwas prüft auch kaum jemand, weil das irsinnig aufwendig ist, man verlässt sich da einfach drauf.
Wenn es ausreichend ist statisches HTML mit einen einfachen, selbst gebauten Tool zu schreiben und das ganze als Webseite anzubieten ist das aus Sicherheits- und auch aus Performancegründen sehr viel besser als Wordpress oder Typo3 zu verwenden.

Gerade die "Drei großen" Wordpress, Drupal und Typo3 sind imho der allerletzte Mist für Webseiten. Unperformant, ständig unsicher, hoher Wartungsaufwand, hohe Codekomplexität... Da spart man unterm Strich nicht wirklich Ressourcen im Vergleich zu HTML + CSS + eine kleine, einfache Template-Engine. Das KISS Paradigma gilt auch im Web.

Warum so viele "angebliche Profis" auf Wordpress und Co setzen, anstatt "HTML5 und CSS3" selbst zu schreiben ist auch ganz einfach (und wir erleben es bei unserer Firmenwebseite gerade am eigenen Laib...): Sie können letzteres schlichtweg nicht. Die Webdesigner sind keine Webentwickler und die haben keine Lust sich mit HTML, Javascript und Co in seinem Ursprung auseinander zu setzen. Die Medienmenschen können nur diese "Webbaukästen" bedienen und alles, was darüber hinaus geht müssen dann eher Webentwickler erledigen, die bauen aber in der Regel keine Webseiten für 3.000 EUR zusammen... Sondern Webanwendungen. Das ist halt ein Unterschied.

Fazit: Millionen von Fliegen irren nicht: Fresst Scheiße!

 

[Domi_bas]

Sorry, dass ich nach 1,5 Jahren hier noch was rein haue...

Aber der letzte Beitrag ist mir gerade wieder besonders in Erinnerung geraten! Nach den vielen Jahren Basteln, lernen und "es selbst machen", habe ich nun schon mein zweites Projekt aus genau diesen Gründen.

Eine Datenbank für den ausschließlich internen Gebrauch einer Firma. Es soll ein komplexer Prozess mit viel Dokumentation und Pass/Fail/NA Abfragen möglichst einfach dokumentiert und als "sauberes" Protokoll ausgegeben werden. Damit keine spezielle Software benötigt wird (geschweige denn Access und Co.), sowie die Bedienbarkeit auch am Handy und Tablet klappt, wird es Browser-gestützt laufen. Das ganze setze ich mit php, mysql, jquery und für die Optik bootstrap um.
Die Angebote der Firmen (richtige Webentwickler, mit ihren agilen Entwicklungsmethoden) konnten leider die Geschäftsleitung nicht überzeugen 150k+ auszugeben. Jetzt wird es für unser Team in Eigenregie, durch mich, umgesetzt.

Das beweist genau die Einschätzung von ayngush und mir: Wenn es auf einem Webserver läuft und im Browser bedient wird, ist es entweder; a) Wordpress und Co. oder b) teuer weil nicht mehr viele das Handwerk verstehen.
Mit Handwerk meine ich damit, dass es für manch spezielle Anwendungsfälle eben keinen Baukasten, Template-Desinger oder WYSIWYG gibt. Man muss jede Abfrage selbst schreiben, testen, dokumentieren und absichern.

Möchte mich nicht hier als großen Programmierer bewerben, aber die Sache ist wirklich einfach! Das Projekt, wie mein erstes größeres beim vorherigen Chef auch, ist simpel umzusetzen.

• Es kommt nie ans Internet, nur Intranet
• Es handelt sich im Grunde nur um mehrere Formulare, die per php/mysql ausgegeben/gespeichert werden
• ein kleiner Upload
• am Ende eine Seite, die alle Ergebnisse ausgibt, schön druckbar als table
• mehr nicht...

Das dafür renommierte Firmen so viel Geld verlangen ist entweder ganz schön clever oder pure Abzocke (oder beides).

Will dann nicht weiter stören