Tag Archives: security

Hány kérés kell egy authentikációhoz?

Adott egy webszolgáltatás, amiről tudjuk, hogy csak Basic hitelesítéssel érhető el, de ez nem gond, hiszen szerencsére .NET-ben a generált proxy osztály Credentials tulajdonságán keresztül könnyű beállítani a szükséges felhasználónevet és jelszót:

MyService ws = new MyService
{
    Credentials = new NetworkCredential( "user", "password" )
};

Az ember azt gondolná, hogy ennek hatására olyan HTTP kérés megy majd a webszolgáltatás felé, amely tartalmazza az authenkációhoz szükséges adatokat, de a valóságban sajnos nem ez történik. Először elmegy egy olyan kérés, amiben nincs Authorization fejléc, azután ha a szerver ezt zokon veszi és 401 Authenticate válasszal tér vissza, akkor a kliens küld egy újabb kérést, ezúttal mellékelve hozzá a felhasználónevet és a jelszót. Az eredmény tehát dupla forgalom. Ha ez nem szimpatikus, és persze miért is lenne az, akkor jól jöhet a PreAuthenticate tulajdonság:

MyService ws = new MyService
{
    Credentials = new NetworkCredential( "user", "password" ),
PreAuthenticate = true };

 

Technorati-címkék: ,
Advertisements

Távoli asztal jelszó megjegyzése

Igen bosszantó, hogy a remote desktop kliens egyes esetekben csak a felhasználónevet hajlandó megjegyezni, a jelszót nem, mert:

Your credentials did not work

Your system administrator does not allow the use of saved credentials to log on to the remote computer COMPUTER because its identity is not fully verified. Please enter new credentials.

rdp-credentials

Ezen úgy lehet segíteni, ha megnyitjuk a Local Group Policy Editort (gpedit.msc), majd elnavigálunk ehhez az ághoz: Computer Configuration –> Administrative Templates –> System –> Credentials Delegation. Itt az Allow delegating saved credentials with NTLM-only server authentication opciót kell Enabled értékre állítani.

Az Add servers to the list opció melletti Show… gombra kattintva felvehetjük azokat a gépeket, amelyekre ezt alkalmazni szeretnénk, mégpedig TERMSRV/gépnév formában, sőt akár minden gépre is hivatkozhatunk a TERMSRV/* érték megadásával.

 

Technorati-címkék: ,

Kiberbiztonsági jóslatok 2014-re

A Microsoft Security Blogon Tim Rains, a cég Trustworthy Computing részegének igazgatója közzétett nyolc kiberbiztonsággal kapcsolatos jóslatot az idei évre:

  1. Cybersecurity Regulatory Efforts Will Spark Greater Need for Harmonization
  2. Service-Impacting Interruptions for Online Services Will Persist
  3. We Will See an Increase in Cybercrime Activity Related to the World Cup
  4. Rise of Regional Cloud Services
  5. Dev-Ops Security Integration Fast Becoming Critical
  6. Cybercrime that Leverages Unsupported Software will Increase
  7. Increase in Social Engineering
  8. Ransomware will Impact More People

Érdemes elolvasni őket bővebben is.

 

Technorati-címkék:

Átirányítás a bejelentkező oldalra Ajaxnál

A hitelesítés korrekt megvalósításának egyik legproblémásabb része annak megoldása, hogy mi történjen akkor, ha az alkalmazáshoz a szükséges engedélyek nélküli kérések érkeznek. Ez így nagyon bénán hangzik, úgyhogy íme egy példa: a /admin URL-re bejelentkezés nélkül nem érkezhetnek kérések, sőt még azokat a kéréseket is el kell utasítani, amik bejelentkezett felhasználóhoz tartoznak, de a felhasználó nincs az Admins csoportban.

ASP.NET esetén szerencsére a FormsAuthenticationModule modul gondoskodik a probléma megoldásáról. Az OnLeave eseménykezelővel feliratkozik az EndRequest eseményre, és ha a HTTP státusz kód 401, akkor átirányítja a felhasználót a bejelentkező oldalra. Ez egy kiváló szolgáltatás hagyományos kérések esetén, de kifejezetten kellemetlen Ajaxnál.

Az átirányítás hatására ugyanis a kliens nem kapja meg a 401 Unauthorized hibát, hanem egy 302 Redirect fejléc fog visszajönni a szervertől, amit az XMLHttpRequest kliens oldalon az előírásnak megfelelően transzparens módon követ, azaz beküld egy kérést a Location fejlécben megadott útvonalra. Ez az útvonal tipikusan a Login.aspx oldalra mutat, aminek a szerver visszaküldi a HTML kódját, és ezt a HTML kódot fogja megkapni az XHR az Ajax hívás eredményeként 200 OK státusz kóddal. Ember legyen a talpán, aki ezt a helyzetet kliens oldalon értelmesen kezelni tudja.

Sajnos .NET 4.0-ig nem volt más megoldás a probléma kezelésére, mint egy saját HTTP modul beillesztése az ASP.NET csővezetékbe. Az ASP.NET 4.5 azonban bevezetett egy új lehetőséget a HttpResponse.SuppressFormsAuthenticationRedirect tulajdonság formájában, amit true értékre állítva elkerülhető az átirányítás, és helyette az eredeti 401-es hibakódot fogja megkapni a kliens. Mivel ez a tulajdonság a Response része, ezért nem tudjuk globálisan beállítani, hanem minden olyan kérésnél be kell billenteni, ahol el akarjuk kerülni az átirányítást. Ha esetleg minden kérésnél így akarunk eljárni, akkor tehetjük ezt a tulajdonság állítást a global.asax fájlban lévő Application_EndRequest eseménykezelőbe.

Miután a kliens megkapja az egyértelmű hibakódot, JavaScriptből már úgy járhatunk el, ahogy az igényeink megkívánják, például feldobhatunk egy hibaüzenetet vagy egy bejelentkező ablakot. De ez a kód már eddig is megvolt, nem igaz?

 

Technorati-címkék: ,,

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: ,,

Árulkodó HTTP fejlécek eltávolítása

Ha megnézzük egy ASP.NET alkalmazásunk hálózati forgalmát, akkor könnyen felfedezhetjük az alábbi fejléceket a HTTP válaszban:

Server: Microsoft-IIS/8.0
X-Powered-By: ASP.NET
X-AspNet-Version: 4.0.30319
X-AspNetMvc-Version: 5.0

Ezek a fejléc mezők egyáltalán nem befolyásolják az alkalmazás működését, az egyetlen céljuk, hogy a Bing bot több információt nyerjen a webhelyről.

Sajnos azonban ezek a fejlécek a támadók dolgát jelentősen megkönnyítik, hiszen ha pontosan ismert a platform és a verziószám, akkor már elég csak azokkal az támadásokkal próbálkozni, amik ebben a környezetben működnek. Éppen ezért biztonsági okokból célszerű megváltoztatni az alapbeállításokat és eltávolítani ezeket a fejléceket.

 

Server

A Server fejléc “sugárzása” bele van drótozva az IIS-be, én nem tudok olyan kapcsolóról, amivel kényelmesen kikapcsolható lenne. Lehet használni az UrlScant, bár az az eszköz utoljára 2008-ban frissült. Ha ASP.NET alkalmazásunk van, akkor a global.asax-ban leszedhetjük ezt a fejléc mezőt, mielőtt a HTTP válasz kimenne a szerverről:

protected void Application_PreSendRequestHeaders()
{
  this.Response.Headers.Remove( "Server" ); }

 

X-Powered-By

Az X-Powered-By fejlécet az IIS pakolja rá a HTTP válaszokra, így akár szerver szinten megszabadulhatunk tőle az IIS Managerben:

header-x-powered-by

 

Vagy akár web.configban is:

<system.webServer>
   <httpProtocol>
     <customHeaders>
       <remove name="X-Powered-By" />
     </customHeaders>
   </httpProtocol>
</system.webServer>

 

X-AspNet-Version

Az X-AspNet-Version fejlécet viszonylag egyszerű kikapcsolni a web.configban:

<httpRuntime enableVersionHeader="false" />

 

X-AspNetMvc-Version

Az X-AspNet-Version fejlécet az alkalmazásunk indulásakor kapcsolhatjuk ki:

protected void Application_Start()
{
MvcHandler.DisableMvcResponseHeader = true; }

 

Ha mindezeket a beállításokat egyszerűbben szeretnénk elvégezni, akkor támaszkodhatunk a CodePlexen ingyenesen elérhető NWebsec projektre, amely a konfiguráció szigorításán kívül további lehetőségeket nyújt MVC-s és Azure-os projektek számára, illetve a session kezelés biztonságosabbá tételére. Ezek a funkciók egymástól függetlenül, önállóan is elérhetők NuGet csomagok formájában.

 

Technorati-címkék: ,,

IIS konfiguráció auditálás

Az IIS konfigurációs beállításai között nem nehéz olyat találni, aminek az átbillentése egy csapásra nem biztonságossá teszi a szervert. Éppen ezért nagyon fontos, hogy a konfiguráció változásait tudjuk követni, monitorozni. Szerencsére ez egy beépített lehetőség a webszerverben, csak nem ott kell keresni, ahol az összes többi opciót.

Indítsuk el az Event Viewert, majd navigáljunk el az Application and Services Logs –> Microsoft –> Windows –> IIS Configuration –> Operational ágig. Kattintsunk ezen az ágon jobb egérgombbal és válasszuk az Enable Log menüpontot az auditálás bekapcsolásához:

iis-config-audit-log

Ezek után minden egyes IIS módosítás megjelenik ebben a naplóban:

iis-config-audit-general

A General nézetben a módosított beállításon kívül jóformán csak a módosítás ideje és a felhasználó neve jelenik meg, de a Details nézetben több információt is találunk:

iis-config-details

Nem árt tudni, hogy csak azok a módosítások jelennek meg, amik az IIS Manageren vagy az objektum modellen keresztül történnek; ha az applicationHost.config fájlt Notepaddel szerkesztjük, annak sajnos nem lesz nyoma a naplóban.

 

Technorati-címkék: ,,,