nicht angemeldet
"parent path" zu unsicher?
hallo,
mein serverbetreuer teilte mir mit, dass die "parent path"- funktion wegen hackerangriffe abgeschaltet werden muß.
ich habe aber in meinen scripten viele relative pfadangaben, und dachte auch bis dato, dass dies guter programmierstil ist, damit das web auch jederzeit übersiedelt werden kann, etc.
ist es wirklich besser, sich nicht auf die relative pfadangabe zu verlassen, oder soll ich mir einen anderen server suchen?
danke für die hilfe!
-
Hi,
mein serverbetreuer teilte mir mit, dass die "parent path"- funktion wegen hackerangriffe abgeschaltet werden muß.
Was fuer eine "Funktion" soll das sein?
Welche Art von Angriff ermoeglicht(e) sie?ich habe aber in meinen scripten viele relative pfadangaben, und dachte auch bis dato, dass dies guter programmierstil ist, damit das web auch jederzeit übersiedelt werden kann, etc.
Kommt drauf an, in manchen Faellen kommt man um absolute Pfadangaben nicht herum.
In aller Regel setzt man diese dann aus aktuellem Scriptpfad, Document_Root u.ae. dynamisch zusammen.ist es wirklich besser, sich nicht auf die relative pfadangabe zu verlassen, oder soll ich mir einen anderen server suchen?
Wenn der Hoster wirklich keine praezisere Aussage macht/machen kann - dann vielleicht ja; aber nicht auf Grund des aktuellen Problems an sich, sondern weil man dann vermutlich nicht zu Unrecht Unkompetenz unterstellen darf.
MfG ChrisB
-
Hi,
mein serverbetreuer teilte mir mit, dass die "parent path"- funktion wegen hackerangriffe abgeschaltet werden muß.
Was fuer eine "Funktion" soll das sein?
Welche Art von Angriff ermoeglicht(e) sie?parent paths erlaubt im IIS relative angaben für includes auch ausserhalb des document root - leider gibts nur absolut oder relativ mit zugriff auf ausserhalb (microsoft ist dämlich ;)
ich habe aber in meinen scripten viele relative pfadangaben, und dachte auch bis dato, dass dies guter programmierstil ist, damit das web auch jederzeit übersiedelt werden kann, etc.
Kommt drauf an, in manchen Faellen kommt man um absolute Pfadangaben nicht herum.
In aller Regel setzt man diese dann aus aktuellem Scriptpfad, Document_Root u.ae. dynamisch zusammen.die includes des IIS laufen VOR den anderen script interpretern, von der seite lassen sich die pfade nicht dynamisch zusammenbauen - absolut zu einem geteilten scriptverzeichnis im document root ist die bessere lösung
Wenn der Hoster wirklich keine praezisere Aussage macht/machen kann - dann vielleicht ja; aber nicht auf Grund des aktuellen Problems an sich, sondern weil man dann vermutlich nicht zu Unrecht Unkompetenz unterstellen darf.
diese einstellung ist lt. microsoft selbst sicherheitskritisch, das ist gängige praxis und alles andere ist sehr bedenklich, da man problemlos dann einen relativen pfad angeben kann, der zb kernel32.ddl includiert (vorrausgesetzt der webserver/iis- benutzer hat die berechtigung dafür)
ist es wirklich besser, sich nicht auf die relative pfadangabe zu verlassen, oder soll ich mir einen anderen server suchen?
wenns keine großen umstände bereitet, steige vom IIS auf einen vernünftigen webserver um, wenn du mit ASP/VBS arbeitest, tritts in die Tonne und steige um zu einer moderneren Sprache (PHP oder im Notfall zu aspx/vb.net oder C#).
-
hi,
wenns keine großen umstände bereitet, steige vom IIS auf einen vernünftigen webserver um, wenn du mit ASP/VBS arbeitest, tritts in die Tonne und steige um zu einer moderneren Sprache (PHP oder im Notfall zu aspx/vb.net oder C#).
danke für die tipps. ich schreibe meine webs seit längerem in php, dieses ist aber halt nun mal auf asp-basis, und das problem betrifft viele scripte. das bedeutet wohl oder übel, dass ich die alle umschreiben muß, oder?
-
danke für die tipps. ich schreibe meine webs seit längerem in php, dieses ist aber halt nun mal auf asp-basis, und das problem betrifft viele scripte. das bedeutet wohl oder übel, dass ich die alle umschreiben muß, oder?
oder du bringst deinen hoster dazu, diese einstellung zu ändern - wird er aber nicht tun (ich würds auch nicht tun und ich hab hier noch "einige" asp webs am laufen)
-
-
-