Hallo Leute,
ich bin auf der Suche nach einem Artikel / Bericht, warum man aus
Sicherheitsgründe bei der Programmierung auf JavaScript verzichten und
nur PHP nutzen sollte.
Kann mir da jmd. weiter helfen? Ich hab leider nichts in der Art im
Netz gefunden.
Vielen Dank im Vorraus,
Matchello
..oO(matchello)
>ich bin auf der Suche nach einem Artikel / Bericht, warum man aus
>Sicherheitsgründe bei der Programmierung auf JavaScript verzichten und
>nur PHP nutzen sollte.
>Kann mir da jmd. weiter helfen? Ich hab leider nichts in der Art im
>Netz gefunden.
Würde mich auch wundern, wenn es das gäbe, denn es ist Blödsinn. Man
kann durch Unwissen mit PHP sehr viel mehr Schaden anrichten als mit JS.
Andererseits kann JS - sinnvoll eingesetzt - eine wirkliche Bereicherung
für eine Website sein.
Micha
matchello schrieb:
> Hallo Leute,
Hallo Herr/Frau Ello, Sie haben da wohl ein Leerzeichen vergessen oder so.
> ich bin auf der Suche nach einem Artikel / Bericht, warum man aus
> Sicherheitsgründe bei der Programmierung auf JavaScript verzichten und
> nur PHP nutzen sollte.
Die Frage ist imho so unfug.
Was gemeint sein könnte: Man sollte sich bei Datenvalidierung und
Sicherheitsrelevanten Funktionen _niemals_ auf clientseitige Sprachen
verlassen, weil da alles vom User manipuliert werden kann.
> Kann mir da jmd. weiter helfen? Ich hab leider nichts in der Art im
> Netz gefunden.
Wenn ich es richtig verstanden habe gibt es diese eine Grundregel und
alles andere baut darauf auf. ;)
regards,
Jens
"matchello"
>Hallo Leute,
>
>ich bin auf der Suche nach einem Artikel / Bericht, warum man aus
>Sicherheitsgründe bei der Programmierung auf JavaScript verzichten und
>nur PHP nutzen sollte.
>Kann mir da jmd. weiter helfen? Ich hab leider nichts in der Art im
>Netz gefunden.
Wahrscheinlich war eher gemeint, dass der Benutzer aus
Sicherheitsgründen JavaScript abstellen könnte - PHP läuft d=
agegen ja
auf dem Server und bietet so keine Kontrollmöglichkeiten durch den
Nutzer, was sinnvoll sein könnte, wenn etwas 100% funktionieren soll.
Gruss,
Claudius
--=20
E-Mail gültig, wird aber nicht gelesen, Post an:
*remove*claudiushubig-entfernen-at+expulser+gmxDOTnet
ICQ: 224491597 Jabber: X2017@jabber.ccc.de =20
MSN: claudiushubig@passport.com HTTP: x2017.homelinux.org
matchello schrieb:
> Hallo Leute,
>
> ich bin auf der Suche nach einem Artikel / Bericht, warum man aus
> Sicherheitsgründe bei der Programmierung auf JavaScript verzichten und
> nur PHP nutzen sollte.
> Kann mir da jmd. weiter helfen? Ich hab leider nichts in der Art im
> Netz gefunden.
>
Die Frage entkräftet sich irgendwie selbst. Mit PHP entwickelt man
Anwendungen, mit JavaScript macht man schicke Dialoge oder bunte Mauszeiger.
Wer schlechten Code schreibt, der setzt unter Umständen die Sicherheit
seiner Daten aufs Spiel, wer guten Code schreibt kann mit beiden
"Sprachen" sichere Dinge tun...
Um die Frage zu beantworten: "Man sollte es (eigentlich) nicht tun."
--
Florian 'rephlex' Panzer | icq 50640876
http://www.rephlex.de | .o0M
Claudius Hubig schrieb:
> "matchello"
>> Hallo Leute,
>>
>> ich bin auf der Suche nach einem Artikel / Bericht, warum man aus
>> Sicherheitsgründe bei der Programmierung auf JavaScript verzichten und
>> nur PHP nutzen sollte.
>> Kann mir da jmd. weiter helfen? Ich hab leider nichts in der Art im
>> Netz gefunden.
>
> Wahrscheinlich war eher gemeint, dass der Benutzer aus
> Sicherheitsgründen JavaScript abstellen könnte - PHP läuft dagegen ja
> auf dem Server und bietet so keine Kontrollmöglichkeiten durch den
> Nutzer, was sinnvoll sein könnte, wenn etwas 100% funktionieren soll.
>
Das ist natürlich sehr wichtig. Den User kaltstellen. Sehr gut gedacht ;)
Das halbiert quasi die Wahrscheinlichkeit, dass irgendwas verhau geht.
--
Florian 'rephlex' Panzer | icq 50640876
http://www.rephlex.de | .o0M
Florian 'rephlex' Panzer
>Claudius Hubig schrieb:
>> Wahrscheinlich war eher gemeint, dass der Benutzer aus
>> Sicherheitsgründen JavaScript abstellen könnte - PHP läuf=
t dagegen ja
>> auf dem Server und bietet so keine Kontrollmöglichkeiten durch den
>> Nutzer, was sinnvoll sein könnte, wenn etwas 100% funktionieren sol=
l.
>>=20
>
>Das ist natürlich sehr wichtig. Den User kaltstellen. Sehr gut gedach=
t ;)
Ich habe in meinem Opera JavaScript ausgeschaltet, d. h. alleine die
PHP-basierte Lösung funktioniert...
>Das halbiert quasi die Wahrscheinlichkeit, dass irgendwas verhau geht.
Jops - oder das irgendwer es ablehnt, irgendwas auszuführen.
Gruss,
Claudius
--=20
E-Mail gültig, wird aber nicht gelesen, Post an:
*remove*claudiushubig-entfernen-at+expulser+gmxDOTnet
ICQ: 224491597 Jabber: X2017@jabber.ccc.de =20
MSN: claudiushubig@passport.com HTTP: x2017.homelinux.org
matchello schrieb:
> ich bin auf der Suche nach einem Artikel / Bericht, warum man aus
> Sicherheitsgründe bei der Programmierung auf JavaScript verzichten und
> nur PHP nutzen sollte.
Den wirtst Du wohl nirgends finden, denn das sind vollkommen verschiedene
Paar Schuhe. PHP läuft auf dem Webserver und JS im Browser.
Im Web findest Du viele Artikel zu dem einen oder anderen. Es liegt in der
Natur des Netzes, dass Du auch viel Stuss finden wirst. Viele Artikel sind
ideologisch geprägt. Panikmache auf der einen Seite, Herunterspielen realer
Risiken auf der anderen.
Viel Spaße ber der Web-Recherche.
Martin
Florian 'rephlex' Panzer schrieb:
> Mit PHP entwickelt man
> Anwendungen, mit JavaScript macht man schicke Dialoge oder bunte Mauszeiger.
Auch mit JS kann man Anwendungen entwickeln. Die funktionieren dann aber
eben nur bei Leuten, bei denen JS fehlerfrei läuft.
Martin
Hallo,
wenn man bedenkt, daß
- php immer auf dem Server abläuft
- java (immer) auf dem "Clienten" abläuft
ist die Fragestellung reiner Unsinn ! Man kann natürlich
sehr einfach, Javascripte mit -PHP- erzeugen, das macht
sogar Sinn.
Beste Grüsse
Kucki
"matchello"
news:1162321052.478572.129310@h48g2000cwc.googlegroups.com.. .
Hallo Leute,
ich bin auf der Suche nach einem Artikel / Bericht, warum man aus
Sicherheitsgründe bei der Programmierung auf JavaScript verzichten und
nur PHP nutzen sollte.
Kann mir da jmd. weiter helfen? Ich hab leider nichts in der Art im
Netz gefunden.
Vielen Dank im Vorraus,
Matchello
Hi,
Friedrich Kuckhermann wrote:
> Hallo,
>
> wenn man bedenkt, daß
>
> - php immer auf dem Server abläuft
> - java (immer) auf dem "Clienten" abläuft
>
was hat den Java damit zu tun ???
Java ist nicht JavaScript wobei Java genau wie PHP auf dem Server
ausgeführt wird außer bei einem Java Applet.
Gruß Marc
Marc Filthaut schrieb:
> Java ist nicht JavaScript wobei Java genau wie PHP auf dem Server
> ausgeführt wird außer bei einem Java Applet.
Soso. Hmm... Mein Eclipse ist kein Applet. Und ich bin mir sicher, er
läuft auch nicht auf irgendeinem Server.
gruss, heli
Hi,
Helmut Chang wrote:
> Marc Filthaut schrieb:
>
>> Java ist nicht JavaScript wobei Java genau wie PHP auf dem Server
>> ausgeführt wird außer bei einem Java Applet.
>
> Soso. Hmm... Mein Eclipse ist kein Applet. Und ich bin mir sicher, er
> läuft auch nicht auf irgendeinem Server.
>
> gruss, heli
Wir können natürlich immer so weitermachen :-)
Mein PHP Script läuft lokal wenn ich den die php.exe script.php ausführe.
Gruß Marc
..oO(Marc Filthaut)
>Wir können natürlich immer so weitermachen :-)
>
>Mein PHP Script läuft lokal wenn ich den die php.exe script.php ausführe.
Mit entsprechendem Plugin läuft PHP auch direkt im Browser ...
Für IE gabs da mal was.
SCNR
Micha
> Helmut Chang wrote:
> Soso. Hmm... Mein Eclipse ist kein Applet. Und ich bin mir sicher, er
> läuft auch nicht auf irgendeinem Server.
Marc Filthaut schrieb:
> Wir können natürlich immer so weitermachen :-)
Geil sinnloses gegeneinander anreden, das macht sicher Spaß !!!!
Also java ist wie PHP einen interpreter sprache.
Läuft also nur im Zusammenhang mit diesem Interpreter.
Das heißt, man kann java so wie PHP als "normale" standalone Aplikation
so nicht betreiben.
ES ist möglich der jeweiligen interpreter im Zusammenhang mit einem
Webserver zu betreiben und so eine serverseite Sprache zu erhalten.
Javascript ist ebenfalls eine Interpretersprache, welche aber nicht
annähernd so mächtig wie java ist.
Es läuft jedoch genauso wie ein java aplet in einer sandbox auf dem Client.
Draus folgt, klint seitige Sprache wie JS, Java Aplet, ActivX... sind
gut geeignet und Seiten zu interaktiveren (AJAX) und vorwalidierung zu
betreiben unötigen Traffik und generve zu vermeiden.
Jedoch sollte die entvalidierung immer serverseitig geschehen, da dort
der Client nicht so einfach bescheissen kann.
Moral von der geschichte, Serverseitige Sprachen sind von Natur aus
sicherer.
Und clientseite Sprachen können "bloß" den Benutzungskomvor erhöhen.
Moral von der Geschicht.. Nicht verzichten, sondern beides nutzen, eine
Kombinierung ist immer das sinnvolste.
PS serverseitege Sprachen können auch Hochsprachen wie C++ oder Asempler
sein, das sit ganz den Vorlieben und perversitäten des Entwicklers
vorbelassen.
Michael Fesser schrieb:
> Mit entsprechendem Plugin läuft PHP auch direkt im Browser ...
> Für IE gabs da mal was.
Echt? wer denkt sich den den schmarn aus??
Sollte das eine Art IDE / XAMPP Ersatz sein oder was?
Hallo Marc,
danke, stimmt natürlich - Applets waren gemeint ! Gut zu wissen
wenn bekannt ist, was wo für welchen Zweck abläuft.
Gruß Fritz
"Marc Filthaut"
Newsbeitrag news:ei9ssk$hh$1@online.de...
> Hi,
>
> Friedrich Kuckhermann wrote:
> > Hallo,
> >
> > wenn man bedenkt, daß
> >
> > - php immer auf dem Server abläuft
> > - java (immer) auf dem "Clienten" abläuft
> >
>
> was hat den Java damit zu tun ???
>
> Java ist nicht JavaScript wobei Java genau wie PHP auf dem Server
> ausgeführt wird außer bei einem Java Applet.
>
> Gruß Marc
..oO(Heiko (GreenRover) Henning)
>Michael Fesser schrieb:
>> Mit entsprechendem Plugin läuft PHP auch direkt im Browser ...
>> Für IE gabs da mal was.
>
>Echt? wer denkt sich den den schmarn aus??
>Sollte das eine Art IDE / XAMPP Ersatz sein oder was?
http://netevil.org/node.php?nid=69&SC=1
Micha
On Wed, 01 Nov 2006 13:18:26 +0100, Heiko (GreenRover) Henning wrote:
> Das heißt, man kann java so wie PHP als "normale" standalone Aplikation
> so nicht betreiben.
Aber sicher doch. Es gibt auch Compiler für diese Sprachen.
> Es läuft jedoch genauso wie ein java aplet in einer sandbox auf dem Client.
Aha. [1]
> Draus folgt, klint seitige Sprache wie JS, Java Aplet, ActivX... sind
> gut geeignet und Seiten zu interaktiveren (AJAX) und vorwalidierung zu
> betreiben unötigen Traffik und generve zu vermeiden.
"Java Applet" ist eine Sprache, "ActiveX" ist eine Sprache ... ich bin
verblüfft, was man hier noch alles lernen kann. [1]
> Jedoch sollte die entvalidierung immer serverseitig geschehen, da dort
> der Client nicht so einfach bescheissen kann.
Warum möchtest du validierte Daten wieder entvalidieren? Es ist doch gut,
wenn sie validiert sind.
> PS serverseitege Sprachen können auch Hochsprachen wie C++ oder Asempler
> sein, [...]
Assembler ist also eine Hochsprache. [1]
Gruß,
Matthias
[1] Natürlich hat mein Vorposter hier einigen Blödsinn verzapft. Möge
man seine restlichen verbreiteten Weisheiten in diesem Kontext
sehen.
Matthias Esken wrote:
>> PS serverseitege Sprachen können auch Hochsprachen wie C++ oder Asempler
>> sein, [...]
>
> Assembler ist also eine Hochsprache. [1]
Vielleicht war sein Statement auch:
(hochsprachen wie C++) or Asempler
;)
Grus(s)
Casper
matchello wrote:
> Hallo Leute,
>
> ich bin auf der Suche nach einem Artikel / Bericht, warum man aus
> Sicherheitsgründe bei der Programmierung auf JavaScript verzichten und
> nur PHP nutzen sollte.
Den Artikel wirst Du wahrscheinlich weiterhin nicht finden. Und das mit den
Sicherheitsgründen kann ich heutzutage auch nicht mehr nachvollziehen.
Problematisch finde ich da eher die Cross-Browser-Funktionalität, aber die
hat man mit CSS auch.
Tatsache ist, daß Du heute php nur noch für das Versenden von xml-Trees
brauchst, wenn JavaScript mit dem XmlHttpRequest-Objekt verwendest.
Nein, ganz so ist das nicht.:) Natürlich gibt es Aufgaben, die nur auf dem
Server erledigt werden, wie das Versenden von Emails, Datenbankabfragen,
Sessions, u.a. Du kannst mit JSON sogar JavaScript Objekte erzeugen.
Aber JavaScript empfiehlt sich m.E. wieder mehr als früher. Besonders mit
dem XmlHTTPRequest-Objekt, mit dem man im Hintergrund Daten vom Server
anfordern kann, oder mit dem Einsatz von DHTML hat JavaScript eine wichtige
Funktion im www.
> Kann mir da jmd. weiter helfen?
Nein. Worum geht es Dir denn, oder, wofür brauchst Du den Artikel?
Gruß,
Oliver
--
Leben ist mehr als ...
Jens Himmelrath wrote:
> Die Frage ist imho so unfug.
> Was gemeint sein könnte: Man sollte sich bei Datenvalidierung und
> Sicherheitsrelevanten Funktionen _niemals_ auf clientseitige Sprachen
> verlassen, weil da alles vom User manipuliert werden kann.
Genaugenommen kann ich ein Skript aufrufen, und damit die clientseitige
Validierung umgehen. Allerdings kann man dieses Problem mit einem Token
(zumindest) einschränken.
Aber clientseitige Validierung hat auch Vorteile.
- weniger Netzlast
- der Benutzer braucht ein Formular nicht mehrfach ausfüllen
- die Daten können bereits im Browser so aufbereitet werden, daß sie auf dem
Server einfacher weiterverarbeitet werden können.
- weitere
Gruß,
Oliver
--
Leben ist mehr als ...
Oliver Block schrieb:
> Aber clientseitige Validierung hat auch Vorteile.
> - weniger Netzlast
> - der Benutzer braucht ein Formular nicht mehrfach ausfüllen
> - die Daten können bereits im Browser so aufbereitet werden, daß sie auf dem
> Server einfacher weiterverarbeitet werden können.
> - weitere
- Die Daten können schon vor dem Absenden in gewissen Grenzen auf
Vollständigkeit, Konsistenz und Plausibilität geprüft werden.
- Ungültige Eingabekombinationen können bereits bei der Eingabe
abgefangen und unterbunden werden.
Ein Beispiel aus meiner Praxis: ich habe eine größere Menge an
Auswahlkriterien (Checkboxen), von denen aber nur eine bestimmte
Maximalzahl gleichzeitig ausgewählt werden darf. Mit JavaScript ist es
ein Leichtes, bei Erreichen dieser Zahl alle anderen Kriterien zu
sperren und wieder freizugeben, sobald ein Kriterium wieder abgewählt wird.
Mit PHP geht das nicht. Hier kann erst der Server _nach_ dem Abschicken
des Formulars den Fehler erkennen und das Formular erneut zur Korrektur
anbieten.
Gruß. Claus
Oliver Block
> Aber clientseitige Validierung hat auch Vorteile.
> - weniger Netzlast
> - der Benutzer braucht ein Formular nicht mehrfach ausfüllen
> - die Daten können bereits im Browser so aufbereitet werden, daß sie
> auf dem Server einfacher weiterverarbeitet werden können.
> - weitere
Man kann zusammenfassen: bereits clientseitig, bspw. durch JavaScript,
eine Vorprüfung vorzunehmen hat Vorteile, kann aber die serverseitige
Prüfung nicht ersetzen, schon aus Sicherheitsgründen nicht, und außerdem
hat nicht jeder clientseitiges Scriptign aktiviert. Darum ist, wie immer,
eine Mittelposition die beste: man macht beides. JavaScript, um es dem
Benutzer, der es will, bequemer zu machen, und PHP, um das ganze sicher
zu machen.
--
( ROT-13 if you want to email me directly: uvuc@ervzjrexre.qr )
"Sie tragen Trauer? Der Untergang der DDR?" - "Nein, Leni Riefenstahl.
Der Führer hat sie zu sich genommen." -- Abschiedsshow Scheibenwischer,
02.10.2003
Matthias Esken schrieb:
> Aber sicher doch. Es gibt auch Compiler für diese Sprachen.
Geil, hast den / die PHP Compiler schon mal getestet?
Ich kenne nur einen Compiler, der Rest ist mehr oder weniger, PHP Source
und Interpreter gebundelt.
Der Compiler, ist auch noch schlecht, der er einfach nicht den vollen
Funktionsumfang von PHP hat. Also ist PHP eine Interpretersprache.
Oder hast du irgent wo einen aktuellen PHP 5.1 Compiler, der wirklich
funktioniert und auch Moduleindung beherrscht, aber ohne einfach nur
source und Interpreter zu bundeln.
Bei Java weiß ich es nicht, mir ist aber nichts bekannt.
Einzig für Perl kenne ich was brauchbares.
>> Es läuft jedoch genauso wie ein java aplet in einer sandbox auf dem Client.
>
> Aha. [1]
Was soll daran nicht stimmen?
Oder hast mit JS schon mal die registry oder das lokale Dateisystem
angefasst?
> "Java Applet" ist eine Sprache, "ActiveX" ist eine Sprache ... ich bin
> verblüfft, was man hier noch alles lernen kann. [1]
OK, dann schreibe doch gleich den richtigen Terminus
>
> Warum möchtest du validierte Daten wieder entvalidieren? Es ist doch gut,
> wenn sie validiert sind.
Ähmm hatte ich doch geschrieben, das JS validierung nicht zuverlässig ist.
Als JS nur für Kampfort...
> Assembler ist also eine Hochsprache. [1]
Nein aber würde auch gehen...
Heiko (GreenRover) Henning schrieb:
> Matthias Esken schrieb:
>
>> Aber sicher doch. Es gibt auch Compiler für diese Sprachen.
>
> Geil, hast den / die PHP Compiler schon mal getestet?
> Ich kenne nur einen Compiler, der Rest ist mehr oder weniger, PHP Source
> und Interpreter gebundelt.
> Der Compiler, ist auch noch schlecht, der er einfach nicht den vollen
> Funktionsumfang von PHP hat. Also ist PHP eine Interpretersprache.
> Oder hast du irgent wo einen aktuellen PHP 5.1 Compiler, der wirklich
> funktioniert und auch Moduleindung beherrscht, aber ohne einfach nur
> source und Interpreter zu bundeln.
Liest Du eigentlich Deine Postings noch einmal durch, bevor Du sie
abschickst? Die vielen Fehler und die schlampigen Formulierungen deuten
eher nicht darauf hin.
Bitte denke daran, dass Du mit Menschen kommunizierst. Du willst, dass
diese Menschen Deine Texte lesen? Dazu ist ein Mindestmaß an Form
erforderlich. Du willst, dass diese Menschen Deine Texte auch verstehen?
Dann solltest Du Dich etwas mehr bemühen, Dein Anliegen auch
verständlich zu formulieren.
Zum Inhalt Deines Textes: ob ich einen Interpreter benötige oder nicht,
ist zunächst einmal vollkommen irrelevant. Entscheidend ist, was ich mit
der Sprache anfangen kann. Sowohl für PHP als auch für Java gibt es
eigenständige Interpreter, die Dir den vollständigen Zugriff auf die
lokalen Betriebssystemressourcen gestatten. Damit ist es sehr wohl
möglich, beliebige lokale Applikationen zu schreiben.
Was "standalone" angeht: auch ausführbare Binärprogramme (häufig von
Unwissenden in Anlehnung an die DOS/Windows-Namensgebung als "EXE-Files"
bezeichnet) sind nicht standalone. Auch diese benötigen eine
Laufzeitumgebung, bestehend aus dem Betriebssystem und seinen Funktionen
sowie den Dienstprogrammen. Manche setzen sogar noch weitere Dienste von
Drittherstellern voraus. Bei PHP, Java, Basic, Perl und was da sonst
noch so an Scriptsprachen kreucht und fleucht kommt eben noch der
Interpreter hinzu. Das war's dann aber auch schon.
Ein anderes Thema ist JavaScript. Dies ist eine reine Browsersprache,
die nur innerhalb des jeweiligen Browsers funktioniert und aus dieser
Umgebung unter normalen Umständen auch nicht raus kann.
> Einzig für Perl kenne ich was brauchbares.
Dann kennst Du nicht viel.
>> "Java Applet" ist eine Sprache, "ActiveX" ist eine Sprache ... ich bin
>> verblüfft, was man hier noch alles lernen kann. [1]
>
> OK, dann schreibe doch gleich den richtigen Terminus
Du meinst die richtigen Termini. Es handest sich um zwei verschiedene Dinge.
Ein Java Applet ist ein Java-Programm, welches mit reduzierten Rechten
auf der lokalen Maschine vom lokalen Java-Interpreter ausgeführt wird.
ActiveX ist ein Mechanismus, den Microsoft eingeführt hat, um beliebige
externe Programme ohne Zutun des Benutzers auf dem lokalen System zu
installieren (also schon vom Konzept her das Sicherheitsloch auf
Windows-Systemen schlechthin).
>> Warum möchtest du validierte Daten wieder entvalidieren? Es ist doch gut,
>> wenn sie validiert sind.
>
> Ähmm hatte ich doch geschrieben, das JS validierung nicht zuverlässig ist.
> Als JS nur für Kampfort...
Matthias wollte Dich damit auf Deinen sinnentstellenden Schreibfehler
hinweisen. Du scheinst ihn aber trotzdem immer noch nicht entdeckt zu
haben - womit wir wieder beim Lesen vor dem Absenden angelangt wären.
Gruß. Claus
..oO(Claus Reibenstein)
>Ein anderes Thema ist JavaScript. Dies ist eine reine Browsersprache,
Es gibt auch für JavaScript/ECMAScript serverseitige Laufzeitumgebungen
und Compiler.
Eine Programmiersprache ist nicht auf eine bestimmte Umgebung oder Art
der Ausführung beschränkt. Es gibt Pascal-Interpreter und PHP-Compiler,
um nur mal zwei Beispiele anzuführen, welche bei den genannten Sprachen
eher unüblich sind, aber dennoch existieren.
Micha