Server.MapPath i IIS6

Har upptäckt nått lustigt i IIS6
Om man använder Server.MapPath("../") så kommer man till samma katalog som filen ligger i, använder man Response.Write Server.MapPath("../../") så kommer man till underliggande katalog!
Någon som vet vad detta beror på?

Funkar hos mig ..

<%
Response.Write Server.MapPath(".") & "<br>"
Response.Write Server.MapPath("../") & "<br>"
Response.Write Server.MapPath("../../") & "<br>"
%>

ger hos mig:

d:\inetpub\wwwroot\test
d:\inetpub\wwwroot
d:\inetpub

både när "test" är en applikation och ett vanligt sub-dir. (På en helt clean .NET Enterprise Server Evaluation copy , Build 3718).

Det känns alltså som om "buggen" är nåt som tillkommit senare. Du kör inte nån lock-down tool eller URL-scan eller nåt sånt? Kan inte heller hitta nåt om problemet på nätet (vilket är konstigt).

Jag får på samma kod:
e:\www\admin2\userxx\html
e:\www\admin2\userxx\html
e:\www\admin2\userxx

Gör jag likadant på en annan site på samma server så funkar det, fast den siten har jag skapat för hand, den det inte funkar på är skapad via programmering.
Tittar jag med Meta Explorer så är siterna identiska, likadant i IIS. Rättigheterna är också identiska!

OK. Det som jag testade var (som synes) standardwebbplatsen. Men vilket fall som helst så låter det i mina öron som en bugg. Att man sen inte hittar nåt på nätet om det är lite skumt, men det kanske beror på Microsofts strävan att man inte ska använda dessa typer av relativa sökvägar längre (med Parent Paths disablade som default)?

Tänkte också på att det kunde ha att göra med Parent Paths att göra, har ni testat vad som händer om man har dem enable respektive disable?

japp, disabled då klagar den på det, enabled ovanstående fel

hittade felet :D
hade angett e:\www\admin2\userxx\html\ som homepath, det ska vara e:\www\admin2\userxx\html :r

hade angett e:\www\admin2\userxx\html\ som homepath, det ska vara e:\www\admin2\userxx\html

Du menar den avslutande back-slashen? Men det borde väl inte kunna ge den här effekten?

jo, tyvärr

jo, tyvärr

Tja, isåf tycker jag nog att det i allra högsta grad är en bugg. Ett applikation som IIS:en borde kunna hantera en trailing backslash utan att det får de här konsekvenserna.

definitivt!

Det är ju lätt att gissa hur buggen uppkommer:

Server.MapPath(".") -> e:\www\admin2\userxx\html\ (= e:\www\admin2\userxx\html )
Server.MapPath("../") -> e:\www\admin2\userxx\html
Server.MapPath("../../") -> e:\www\admin2\userxx
Server.MapPath("../../../") -> e:\www\admin2

Den plockar alltså bort en backslash på slutet per ".." utan att tänka på att en ensam "\" på slutet borde särbehandlas.

Har det varit så här i tidigare IIS-versioner? I vilket fall som helst så borde du nog rapportera till MS, tycker jag.

aleborg skrev:

hittade felet :D
hade angett e:\www\admin2\userxx\html\ som homepath, det ska vara e:\www\admin2\userxx\html :r

Tack!

niko skrev:

jo, tyvärr

Tja, isåf tycker jag nog att det i allra högsta grad är en bugg. Ett applikation som IIS:en borde kunna hantera en trailing backslash utan att det får de här konsekvenserna.

Nej, det är INGEN bugg. En ren säkerhetsåtgärd som gör att kunderna INTE kan leta sig uppåt i mappstrukturen utanför sin tilldelade wwwroot.

cya,
/PatrikB

Men detta gör ju inte att man inte kan leta sig uppåt. Kör man med Server.MapPath("../../") så kommer man ju uppåt...
Eller snackar du om Parent Paths?

PatrikB skrev:

Nej, det är INGEN bugg. En ren säkerhetsåtgärd som gör att kunderna INTE kan leta sig uppåt i mappstrukturen utanför sin tilldelade wwwroot.

Ja, men nu handlar det ju om funktionaliteten hos Server.MapPath när man medvetet har valt att enabla Parent Paths. Testa att läsa hela tråden, tack!

PatrikB skrev:

niko skrev:

jo, tyvärr

Tja, isåf tycker jag nog att det i allra högsta grad är en bugg. Ett applikation som IIS:en borde kunna hantera en trailing backslash utan att det får de här konsekvenserna.

Nej, det är INGEN bugg. En ren säkerhetsåtgärd som gör att kunderna INTE kan leta sig uppåt i mappstrukturen utanför sin tilldelade wwwroot.

cya,
/PatrikB

Nej, nej, nej :)
Säkerheten löser man på andra sätt, med rättigheter å mappar!

Jepp, att förhindra användande av Server.MapPath verkar muppigt eftersom att den bara används för att ta reda på sökväg till en mapp. Man kan ju skriva sökvägen själv.