Sicherheit: ASP.Net >> PHP?

[creave]

Ich gebe zu, der Post hier ist etwas mager, jedoch kann es die Antwort dafür auch sein (was nicht heißen soll, dass sie nicht ausführlicher sein darf). Das Resultiert einfach aus der späten Stunde momentan.
Und zwar arbeite ich schon länger mit PHP, habe mir nun auch mal C# angeschaut, um kleine Tools für den eigenen Rechner zu schreiben.
Dabei kam mir der Gedanke, meine PHP-Werke durch ASP.NET zu ersetzen, wenn man schon am C# lernen ist. Die Vor- und Nachteile jeder Sprache sind mir im großen und ganzen bewusst, doch leider bin ich noch etwas unentschlossen (da großer Aufwand für nicht allzu großen Fortschritt) und will die Entscheidung an einem Kriterium festmachen: der Sicherheit. Also:

1.) Was macht ASP.NET bei der Sicherheit besser als PHP, wie steht es dabei mit der Sicherheit überhaupt? (ich nehme ja nur an, das ASP.NET sicherer ist...wissen tu ich das nicht. Aber das ist der allgemeine Tenor, wenn man etwas rumliest). Zur ersten Teilfrage wäre eine Antwort a la "Bei PHP muss man noch dies und das absichern, bei ASP.NET fällt das weg" oder ähnliches sehr hilfreich.

2.) Auf welche Dinge muss man trotzdem noch achten bei ASP.NET? Ein paar Stichworte wären nett. Sich in Sicherheit wiegen könnte gefährlich sein.


Danke schonmal ;)

[Expandable]

Prinzipiell sind beide Sprachen gleichermaßen unsicher, wenn Du nicht weißt, was Du tust. Und worauf genau beziehst Du "Sicherheit" in diesem Fall?

[The_Invisible]

Prinzipiell sind beide Sprachen gleichermaßen unsicher, wenn Du nicht weißt, was Du tust. Und worauf genau beziehst Du "Sicherheit" in diesem Fall?

jop, post/get daten zb muss man immer noch selber überprüfen bzw festlegen was damit gemacht wird. die meiste unsicherheit kommt eh vom programmierer der seite selbst. da asp im web gegenüber php aber stark in der minderheit ist, hast du nicht so viel gegenüber angreifer zu befürchten.

mfg

[Coda]

Ich würde sagen, der größte Nachteil von PHP ist, wenn man direkt String-SQL-Queries und Register Globals verwendet.

Muss man beides aber nicht tun.

[HellHorse]

Prinzipiell sind beide Sprachen gleichermaßen unsicher, wenn Du nicht weißt, was Du tust. Und worauf genau beziehst Du "Sicherheit" in diesem Fall?
PHP hat zum Beispiel staendig irgendwelche Sicherheitsluecken in all den Funktionen, die clevererweise in C und nicht in PHP implementiert sind.

[Expandable]

... Funktionen, die clevererweise in C und nicht in PHP implementiert sind.

Gott sei Dank... sonst wär PHP ja noch langsamer als es eh schon ist.

[HellHorse]

Gott sei Dank... sonst wär PHP ja noch langsamer als es eh schon ist.
Dann sollte man besser etwas Zeit in die Optimierung von PHP stecken, ist ja nicht so schwer.

[Coda]

Naja. Solange es rein interpretiert ist, ist es schon nicht so einfach. Bytecode mit Cache ist halt noch ne andere Sache.

[HellHorse]

Naja. Solange es rein interpretiert ist, ist es schon nicht so einfach. Bytecode mit Cache ist halt noch ne andere Sache.
Ach wo. Java hat das schon gemacht bevor man ueberhaupt einen JIT hatte. Auch bein Interpretern gibt es diverse Unterschiede. Man muss sich halt einfach nicht so doof anstellen und einen switch-loop bauen. In Anbetracht dessen, dass schlussendlich sowieso MySQL (oder aus auch immer als DB verwendet wird) die Performance limitieren wird, sollte das ueberhaupt kein Problem sein. Number crunching wird lahm sein, aber niemand macht number crunching mit PHP.

[Scream]

hier ein artikel zu php vs. asp
http://www.roscripts.com/PHP_vs_ASP-20.html

[Gast]

jop, post/get daten zb muss man immer noch selber überprüfen bzw festlegen was damit gemacht wird. die meiste unsicherheit kommt eh vom programmierer der seite selbst.


Schau dir mal das Attribut ValidateRequest an, dass in die Page Direktive kommt bzw. standardmäßig auf true ist.


da asp im web gegenüber php aber stark in der minderheit ist, hast du nicht so viel gegenüber angreifer zu befürchten.


Viele große kommerzielle Seiten verwenden ASP.NET. Aber wenn man von den Gesamtzahlen ausgeht, hst du sicher recht. Nur das liegt daran, weil dann jede Hans Wurst Seite mit in die Statistik geht.

[Coda]

Ach wo. Java hat das schon gemacht bevor man ueberhaupt einen JIT hatte. Auch bein Interpretern gibt es diverse Unterschiede. Man muss sich halt einfach nicht so doof anstellen und einen switch-loop bauen. In Anbetracht dessen, dass schlussendlich sowieso MySQL (oder aus auch immer als DB verwendet wird) die Performance limitieren wird, sollte das ueberhaupt kein Problem sein. Number crunching wird lahm sein, aber niemand macht number crunching mit PHP.
Mal rein aus Interesse: Was ist denn besser als ein Switch-Loop?

hier ein artikel zu php vs. asp
http://www.roscripts.com/PHP_vs_ASP-20.html
Veraltet... ASP.NET ist was ganz anderes.

[HellHorse]

Was ist denn besser als ein Switch-Loop?
Switch-loop ist so ziemlich die langsamste Art einen bytecode Interpreter auf einer modernen CPU zu implentieren. Wer so was macht ist entweder faul oder hat null Plan. Weniger schlecht ist zum Beispiel eine Art threaded Interpreter. Im Groben ersetzt du jeden bytecode mit einem Jump zu der Implementation. Zudem haengst du am Ende der Implementation noch den Code an, um den naechsten bytecode zu holen. Google liefert recht brauchbare Resultate.

[SentinelBorg]

Der Vergleich ist ziemlich Äpfel vs. Birnen. Beide Systeme wurden doch unter ganz anderen Grundprämissen entwickelt. Php als Skriptsprache zur schnellen Erzeugung von Html-Seiten, ASP.Net als Bestandteil einer ganzen neuen Entwicklungsplattform. Funktionsorientiert (zumindest bis Php 5 noch stark) vs. Objektorientiert usw.

Die Sicherheit sollte in ASP.Net durch viele grundlegende Eigenschaften (Typsicherheit, Code Access Level usw.) des dahinter stehenden Frameworks höher sein. Letztendlich liegt die Sicherheit natürlich dennoch meist in den Händen des Entwicklers selbst.