Javascript auf dem Server
-
árn[y]ék schrieb:
- JavaScript unterstützt eine "andere" Objektorientierung, als z.B. C++ oder PHP. Ein Objekt ist in JavaScript lediglich ein Hash. Nix private oder protected ...
Das stört mich aber nicht soo sehr.
árn[y]ék schrieb:
- JavaScript besitzt keine Standardbibliothek die annähernd benutzbar ist. Keine Datenbankanbindung. Keine Template-Engine. Nichts.
Hmm doch, da gibt es ein paar Sachen. Trotzdem ein guter Punkt.
árn[y]ék schrieb:
- Der Code wird vom Browser interpretiert. Wer aber interpretiert den serverseitigen Code? Super, jetzt haben wir nicht mehr nur 3 Browser, die sich nicht einig werden, sondern auch noch verschiedene Webserver ...
Wer interpretiert PHP-Code?
árn[y]ék schrieb:
Ich könnte noch weiter machen
Ja bitte!
-
Mr. N schrieb:
Es ist ja nicht wirklich üblich, JavaScript auf dem Server einzusetzen
Meinst du vielleicht JScript (vergl. http://de.wikipedia.org/wiki/JScript)? JScript ist in großen Teilen kompatibel zu JavaScript und wird als Alternative zu VBScript auf so manchem (Web-) Server eigesetzt.
-
schmidt-webdesign.net schrieb:
Mr. N schrieb:
Es ist ja nicht wirklich üblich, JavaScript auf dem Server einzusetzen
Meinst du vielleicht JScript (vergl. http://de.wikipedia.org/wiki/JScript)? JScript ist in großen Teilen kompatibel zu JavaScript und wird als Alternative zu VBScript auf so manchem (Web-) Server eigesetzt.
Nein, ich meine eigentlich Javascript. - Aber sind ja glaub verwandte Sprachen. - Gegen die Verwendung von JScript würde wohl sprechen, dass es AFAIK nicht auf Linux-Servern funktioniert.
-
wozu noch so ne dreckssprache auf nem server? damit noch mehr hilfsfrickler ne zu ihnen passende sprache haben um sicherheitslöcher zu produzieren?
-
auf der schachtel schrieb:
wozu noch so ne dreckssprache auf nem server? damit noch mehr hilfsfrickler ne zu ihnen passende sprache haben um sicherheitslöcher zu produzieren?
Hast du vielleicht ein Beispiel, das zeigt, wie sich mittels serverseitigem JScript / JavaScript Sicherheitslöcher produzieren lassen?
-
Mr. N schrieb:
Bzw. was würdet ihr zu Javascript auf dem Server meinen - einfach mal angenommen?
Super Idee. Es fehlt lediglich an Libraries - aber die würden ja kommen wenn JS auf dem Server eingesetzt werden würde.
Das Problem dabei ist denke ich nur, dass kein Know-How vorhanden ist. Kaum ein Webentwickler kann wirklich JavaScript - es wird meistens nur zusammen gehackt.
Aber im Prinzip wäre JS eine Super Serverseitige Sprache - vorallem weil es dann die Möglichkeit bietet dynamisch zu entscheiden ob ich den Code jetzt auf dem Server ausführen will oder auf dem Client.
Wenn es zB einen import von PHP oder Perl Libraries gäbe und der Serverseitige JS Interpreter technisch OK wäre und eine halbwegs ordentliche Verbreitung hätte - würde ich JS wohl PHP vorziehen. Wie gesagt - hauptproblem wäre, dass es keine Libs gibt um sinnvolle Sachen zu machen - wenn man aber PHP oder Perl Libraries importieren könnte - wäre das Problem gelöst.
-
das sollte mit parrot innerhalb nicht vorhersehbarer zeit machbar sein
-
-
Shade Of Mine schrieb:
Wenn es zB einen import von PHP oder Perl Libraries gäbe und der Serverseitige JS Interpreter technisch OK wäre und eine halbwegs ordentliche Verbreitung hätte - würde ich JS wohl PHP vorziehen. Wie gesagt - hauptproblem wäre, dass es keine Libs gibt um sinnvolle Sachen zu machen - wenn man aber PHP oder Perl Libraries importieren könnte - wäre das Problem gelöst.
Einen Import aus PHP oder Perl stell ich mir relativ aufwendig vor, aber Import aus Java geht wohl, wenn man einen Java-Interpreter benutzt.
headhunter schrieb:
http://www.onlamp.com/pub/a/onlamp/2007/08/30/introducing-trimpath-junction.html
Bin wohl nicht der einzige, der sich die Frage gestellt hat.
-
schmidt-webdesign.net schrieb:
auf der schachtel schrieb:
wozu noch so ne dreckssprache auf nem server? damit noch mehr hilfsfrickler ne zu ihnen passende sprache haben um sicherheitslöcher zu produzieren?
Hast du vielleicht ein Beispiel, das zeigt, wie sich mittels serverseitigem JScript / JavaScript Sicherheitslöcher produzieren lassen?
Wenns mal Libraries gibt mit denen man auf Server DBs usw zugreifen kann, dann bekommen die Frickler das sicher hin.
-
es gibt ja sogar schon eval. da bekommt es so n Homepagefrikler der noch Javascript kann sicher hin, dass man mit "Javascript injection" den server hacken kann.
-
auf der schachtel schrieb:
es gibt ja sogar schon eval. da bekommt es so n Homepagefrikler der noch Javascript kann sicher hin, dass man mit "Javascript injection" den server hacken kann.
Ein Beispiel, wie sich mittels serverseitigem JScript / JavaScript Sicherheitslöcher produzieren lassen, hast du also nicht (hätte mich auch gewundert). Hast du dir den Begriff "Javascript-Injection" selbst ausgedacht oder nur mit SQL-Injection verwechselt?
-
schmidt-webdesign.net schrieb:
auf der schachtel schrieb:
es gibt ja sogar schon eval. da bekommt es so n Homepagefrikler der noch Javascript kann sicher hin, dass man mit "Javascript injection" den server hacken kann.
Ein Beispiel, wie sich mittels serverseitigem JScript / JavaScript Sicherheitslöcher produzieren lassen, hast du also nicht (hätte mich auch gewundert). Hast du dir den Begriff "Javascript-Injection" selbst ausgedacht oder nur mit SQL-Injection verwechselt?
eval(formdata.mytextfield)Aber ich behaupte, das ist nicht Javascript-spezifisch.
-
schmidt-webdesign.net schrieb:
auf der schachtel schrieb:
es gibt ja sogar schon eval. da bekommt es so n Homepagefrikler der noch Javascript kann sicher hin, dass man mit "Javascript injection" den server hacken kann.
Ein Beispiel, wie sich mittels serverseitigem JScript / JavaScript Sicherheitslöcher produzieren lassen, hast du also nicht (hätte mich auch gewundert).
Ist es doch. Ich gehe mal davon aus, dass man mit serverseitigem Javascript auch die Möglichkeit hat auf eine DB zuzugreifen, sonst bringt es auf dem Server ja nix.Hast du dir den Begriff "Javascript-Injection" selbst ausgedacht oder nur mit SQL-Injection verwechselt?
Google: Javascript-Injection Im Moment kann man "nur" Clientseitig HTML Seiten "hacken", aber sobald es auf dem Server läuft geht viel mehr.
-
auf der schachtel schrieb:
Google: Javascript-Injection Im Moment kann man "nur" Clientseitig HTML Seiten "hacken", aber sobald es auf dem Server läuft geht viel mehr.
Quasi jede Scriptsprache hat ein eval()
-
Nur weil die Sprache bei Client und Server die gleiche ist heißt das doch noch lange nicht, dass deswegen plötzlich andere/mehr Sicherheitslücken auf dem Server entstehen als bei einer anderen serverseitigen Sprache.
So eval()-Hacks gibts bei thedailywtf.com regelmäßig wo per ajax/js irgendwas an ein php-Skript geschickt wird welches das ganze mit eval() ausführt.
-
lolz schrieb:
Nur weil die Sprache bei Client und Server die gleiche ist heißt das doch noch lange nicht, dass deswegen plötzlich andere/mehr Sicherheitslücken auf dem Server entstehen als bei einer anderen serverseitigen Sprache.
So eval()-Hacks gibts bei thedailywtf.com regelmäßig wo per ajax/js irgendwas an ein php-Skript geschickt wird welches das ganze mit eval() ausführt.
Man könnte aber mehr anstellen, wenn man mit js auf die Server DB zugreifen könnte. Die Möglichkeit fremden Code auf dem Server auszuühren hat man bei ner normalen Sprache halt nicht, außer SQL Injection.
-
auf der schachtel schrieb:
lolz schrieb:
Nur weil die Sprache bei Client und Server die gleiche ist heißt das doch noch lange nicht, dass deswegen plötzlich andere/mehr Sicherheitslücken auf dem Server entstehen als bei einer anderen serverseitigen Sprache.
So eval()-Hacks gibts bei thedailywtf.com regelmäßig wo per ajax/js irgendwas an ein php-Skript geschickt wird welches das ganze mit eval() ausführt.
Man könnte aber mehr anstellen, wenn man mit js auf die Server DB zugreifen könnte. Die Möglichkeit fremden Code auf dem Server auszuühren hat man bei ner normalen Sprache halt nicht, außer SQL Injection.
Doch hat man. Könnten wir vielleicht über richtige Vor- und Nachteile diskutieren?
-
Mr. N schrieb:
auf der schachtel schrieb:
lolz schrieb:
Nur weil die Sprache bei Client und Server die gleiche ist heißt das doch noch lange nicht, dass deswegen plötzlich andere/mehr Sicherheitslücken auf dem Server entstehen als bei einer anderen serverseitigen Sprache.
So eval()-Hacks gibts bei thedailywtf.com regelmäßig wo per ajax/js irgendwas an ein php-Skript geschickt wird welches das ganze mit eval() ausführt.
Man könnte aber mehr anstellen, wenn man mit js auf die Server DB zugreifen könnte. Die Möglichkeit fremden Code auf dem Server auszuühren hat man bei ner normalen Sprache halt nicht, außer SQL Injection.
Doch hat man.
Ja, wenn C/C++ Programmierer richtige Fehler machen und über den Speicher raus schreiben lassen oder Formatstrings falsch einsetzen. Da muss man aber schon richtig was drauf haben um einen Server so zu hacken. Bei Javascript ist sowas ein Sprachfeature, damit jeder der nur ein bisschen js kann, seinen Code auf den Server bringen kann.
Könnten wir vielleicht über richtige Vor- und Nachteile diskutieren?
Javascript Injection, Keine Vererbung, keine Typsicherheit, noch langsamer als Java, viele Syntaxfehler können erst zur Laufzeit erkannt werden.
Was waren den die richtigen Vorteile?
-
auf der schachtel schrieb:
Ja, wenn C/C++ Programmierer richtige Fehler machen und über den Speicher raus schreiben lassen oder Formatstrings falsch einsetzen. Da muss man aber schon richtig was drauf haben um einen Server so zu hacken. Bei Javascript ist sowas ein Sprachfeature, damit jeder der nur ein bisschen js kann, seinen Code auf den Server bringen kann.
Jede Scriptsprache hat ein eval(). Willst du jetzt behaupten PHP, Python, Perl, Ruby,... sind ungeeignet?
Javascript Injection, Keine Vererbung, keine Typsicherheit, noch langsamer als Java, viele Syntaxfehler können erst zur Laufzeit erkannt werden.
Keine Vererbung ist kein Grund. Der Rest ist bei Jeder Scriptsprache so.