Mennyire egyedi a machine key?

Az ASP.NET platform számos kriptográfiai funkciója épül a machine key-re, épp ezért különösen fontos, hogy az egymástól független alkalmazásokhoz egyedi machine key tartozzon. Szerencsére az alapbeállítás szerint látszólag minden alkalmazás egyedi kulcsot kap:

<machineKey validationKey="AutoGenerate,IsolateApps" 
decryptionKey="AutoGenerate,IsolateApps" />

Az AutoGenerate beállítás hatására a platform automatikusan generál kulcsot, az IsolateApps-nak köszönhetően pedig elvileg ezek a kulcsok alkalmazásonként egyediek lesznek.

De nem mindig!

Az ASP.NET valóban generál automatikusan kulcsot, csakhogy nem a validation key-t és a decryption key-t, hanem egy ős kulcsot (hívhatjuk ezt általánosan machine key-nek), amiből azután transzformációkkal áll elő a két kulcs.

A machine key-t  platform a registry-ben tárolja, a következő útvonalon:

HKCU\Software\Microsoft\ASP.NET\4.0.30319.0\AutoGenKeyV4

Érdemes észrevenni, hogy a tárolás a HKEY_CURRENT_USER hive-ban történik, azaz a generált machine key az adott felhasználó profiljához fog tartozni! Ebből logikusan következik, hogy ha az IIS-ben két alkalmazás ugyanannak a felhasználónak a nevében fut, akkor azonos machine key-t fognak használni! Íme egy újabb ok, hogy miért kell elfelejteni a SYSTEM, LOCAL SERVICE és NETWORK SERVICE felhasználókat, és miért kell helyettük önálló ApplicationPoolIdentity-vel futtatni minden egyes alkalmazást. Ebből is látszik, hogy az application pool az alkalmazások izolációjának eszköze.

Az, hogy két alkalmazásnak ugyanaz az ős kulcsa, még nem feltétlenül jelent problémát, hiszen tudjuk, hogy a két valóban használt kulcs transzformációkkal áll elő. Ezt a transzformációt határozza meg az AutoGenerate utáni módosító. Az IsolateApps hatására a transzformációba bekerül a HttpRuntime.AppDomainAppVirtualPath tulajdonság értéke, ami egy website-on belül, két különböző virtuális mappában ülő alkalmazás esetén eltérő lesz, így a két generált kulcs is el fog térni (pont ez a cél).

Ám nem fog eltérni abban az esetben, ha a két alkalmazás ugyanazon az útvonalon van, de eltérő webhelyeken. Például a gyökérben ülő alkalmazásnál ennek a tulajdonságnak az értéke mindkét esetben “/” lesz, azaz az IsolateApps egyáltalán nem teszi meg azt, amit várunk tőle!

Ilyen esetekre került az ASP.NET 4.5 be az IsolateByAppId módosító, ami nem a HttpRuntime.AppDomainAppVirtualPath, hanem AppDomainAppId tulajdonság felhasználásával készíti a két kulcsot. Ennek az értéke valami ilyesmi: 

/LM/W3SVC/3/ROOT 

A közepén a “3” az én esetemben a website azonosítója az IIS-ben, a “ROOT” pedig azt jelenti, hogy a site gyökerében van az alkalmazás.

Összegezve tehát: az alap AutoGenerate,IsolateApps beállítás nem minden esetben eredményez egyedi kulcsot, de ha az alkalmazásokat saját application poolba tesszük és azokat ApplicationPooldentity-vel futtatjuk, valamint az IsolateApps helyett az IsolateByAppId módosítót használjuk, akkor már nem biztosan egyedi kulcsokat fognak kapni az alkalmazásaink.

Ha nem hiszed, legegyszerűbben úgy járhatsz utána, hogy a localtest.me domain segítségével létrehozol két webhelyet az IIS-ben, majd azokon létrehozol két alkalmazást, ami például Milan Negovan kódja segítségével kiírja a kulcsokat.

 

Technorati-címkék: ,,

Vélemény, hozzászólás?

Adatok megadása vagy bejelentkezés valamelyik ikonnal:

WordPress.com Logo

Hozzászólhat a WordPress.com felhasználói fiók használatával. Kilépés / Módosítás )

Twitter kép

Hozzászólhat a Twitter felhasználói fiók használatával. Kilépés / Módosítás )

Facebook kép

Hozzászólhat a Facebook felhasználói fiók használatával. Kilépés / Módosítás )

Google+ kép

Hozzászólhat a Google+ felhasználói fiók használatával. Kilépés / Módosítás )

Kapcsolódás: %s