2010. május havi bejegyzések

Managed Service Account vs. SQL Server

A Windows Server 2008 R2 újdonságai közül az egyik kedvencem a Managed Service Accountok és a Virtual Accountok megjelenése. Persze ez nem egy látványos újdonság, talán ezért is nem szerepel óriási betűkkel kiemelve a What’s new oldalon, pedig üzemeltetők számára igen-igen hasznos. Persze csak azoknak, akik nem minden szolgáltatás Local System felhasználóval futtatnak.

A minap SQL Server 2008 R2-t akartam telepíteni, ám csalódva kellett tapasztalnom, hogy még az R2 változat sem támogatja ezt a két új fióktípust 😦 Az SQL Server 2008-ról ez ismert volt, de most az R2-vel kapcsolatban is megerősítették a fórumban:

SQL Server 2008 and SQL Server 2008 R2 do NOT support managed service account and virtual account when running on Win7 and Win2k8 R2.

Maradt a szokásos helyi Gipsz Jakab felhasználóval történő futtatás, ami nem is zavart volna, ha a Windows Remote Desktop login képernyőjén nem virított volna feltűnően bárki számára, hogy van egy ilyen felhasználó. Onnan pedig leginkább registry matatással lehet eltűntetni az ilyen persona non gratat:

  1. Létre kell hozni a HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ Winlogon\SpecialAccounts\UserList kulcsot – nálam az utolsó 2 szint nem létezett.
  2. Ezen belül egy DWORD típusú kulcsot kell létrehozni, aminek a neve legyen az eltüntetendő felhasználó neve (pl. gjakab), az értéke pedig 0.

Továbbá azok a felhasználók is eltűnnek a Welcome Screenről, akiknek Deny log on locally jogot “adunk”, amit egyébként is ajánlatos megtenni.

Technorati-címkék: ,

Eval HtmlEncode-dal

Nagyon bosszantó tud lenni, hogy az ASP.NET-es vezérlők közül még a legalapvetőbbek sem végeznek HTML kódolást, így kénytelenek vagyunk ezt mi magunk elvégezni adatkötéskor. Az eredmény egy ismétlődő és nehezen olvasható kifejezés lesz.

Például:

  Text='<%# this.Server.HtmlEncode( Eval( "NewsTitle" ).ToString() ) %>'

A legszebb az lenne, ha az Evalt fel tudnánk váltani egy saját EncodeEval metódusra, amely belül megcsinálja a ToStringet és a HtmlEncode-ot is. Tudva, hogy az Eval belül valójában DataBinder.Eval és bevetve az extension metódusok erejét, meg is lehet csinálni:

  public static string EncodeEval( this Control control, string expression )
  {
    return HttpUtility.HtmlEncode(
       DataBinder.Eval( control.Page.GetDataItem(), expression ).ToString() );
  }

Sőt, ha kell a formázás is, akkor írhatunk belőle még egyet:

  public static string EncodeEval( this Control control, string expression, string format )
  {    return HttpUtility.HtmlEncode(
       DataBinder.Eval( control.Page.GetDataItem(),
                        expression, format ).ToString() );
  }

Így már csak ennyi kerül a markupba:

  Text='<%# this.EncodeEval( "NewsTitle" ) %>'

A dolognak egyetlen apró szépséghibája van: ez belül éppúgy reflectiont használ, mint a hagyományos Eval. Erre akar utalni az MSDN is, csak éppen nagyon félreérthetően teszi a DataBinder.Eval leírásánál:

Because this method performs late-bound evaluation, using reflection at run time, it can cause performance to noticeably slow compared to standard ASP.NET data-binding syntax. Use this method judiciously, particularly when string formatting is not required.

A nagy kérdés persze, hogy hogyan lehet elkerülni a reflectiont? Én azt szoktam csinálni, hogy megnézem, mi van az aktuális rekordban, például így:

  Text='<%# Container.DataItem %>'

ListView esetén például System.Data.DataRowView, amit megindexelhetünk oszlopnévvel:

  Text='<%# ( (System.Data.DataRowView) Container.DataItem )[ "NewsTitle" ] %>'

Ez már nem használ reflectiont, cserébe hosszú és nem is végez HTML kódolást.

Vissza a Start mezőre 🙂

A teljes implementáció letölthető innen.

Technorati-címkék: ,,

 

Facebook Like button XSS

A Facebook Like gombjának egy csomó előnye van. Az egyik például az, hogy mivel előbb-utóbb ott lesz minden weboldalon, ha esetleg valamilyen security bug van benne, akkor az szinte a teljes internetet érinteni fogja. Mint ahogyan érinti is.

Lássuk csak, hogyan készül egy Like button!

Kezdetben vala a gombra vágyó felhasználó (szándékosan nem fejlesztőt írtam), aki elvándorol a Facebook ide vonatkozó oldalára és varázsol magának egy iframe darabkát, amit beilleszt az oldalába. Ezzel még nincs is gond. A probléma ott jön elő, amikor emberünk rájön, hogy “de jó lenne ez a gomb az összes oldalamra!”, és elkezdi anatómiailag elemezni a bemásolt kódrészletet, például:

  <iframe src="http://www.facebook.com/plugins/like.php?
href=http%253A%252F%252Fbalassy.spaces.live.com
&amp;layout=standard
&amp;show_faces=false
&amp;width=450
&amp;action=like
&amp;font
&amp;colorscheme=light
&amp;height=35" scrolling="no" frameborder="0"
style="border:none; overflow:hidden; width:350px; height:22px;"
allowTransparency="true">
</iframe>

Nem kell atomfizikusnak lennie, hogy rájöjjön, a href után az aktuális oldal URL-jét kell bemásolni. Hogy is szoktuk azt csinálni? “Hát ASP.NET-ben például azt írjuk oda, hogy <%= this.Request.Url %>, Javascriptben meg azt, hogy document.URL, és biztos PHP-ben is van hasonló.” Az sem gond, ha elsőre nem működik, hiszen a Google mindenre tudja a választ, hamar lehet működő kódrészletet vagy plugint találni. Nem is kell hozzá programozónak lenni, elég hozzá olvasni és kopipésztelni tudni.

Mivel főhősünk nem programozó, észre sem fogja venni, hogy a neten terjedő kódrészletek igen jelentős hányada ész nélkül másolja be a kapott URL-t a weboldal forráskódjába. Tipikus cross-site scripting melegágy, nem is kell hozzá atomfizikusnak lenni, hogy találjunk egy olyan inputot, ami kihasználja, például:

  http://example.com/oldal.kiterjesztes?" onload="javascript:alert('XSS')" nincsilyen="

Nyilván környezettől és böngészőtől függ, hogy pontosan hogyan és meddig lehet eljutni, de a lényeg, hogy sebesen terjednek a kihasználható kódrészletek, ráadásul szerencsétlen felhasználók észre sem veszik, ha ilyen oldalba futnak.

Még az is lehet, hogy meglájkolják.

 

Technorati-címkék: ,,,

Még egyszer az Ajax Library jövőjéről

Közel két hónapja, hogy megírtam, a nagy testvér kikukázta a Microsoft Ajax Library-t és a jQuery mellett tette le a voksát. Azóta megjelent a .NET 4 és ez hozott némi félreértést a köztudatba, amit most megpróbálok kicsit helyre tenni.

Az ASP.NET platform kapcsán igazából 2 Ajaxról beszélhetünk:

  1. Az ASP.NET 4-ben megjelent ASP.NET Ajax – ebben nincsenek benne az igazi új szépségek, a kliens oldali sablonok, kliens oldali adatkötés, sőt még a script loader sem. De van benne minden régi alapozó komponens: osztályok, interfészek, felsorolt típusok. Ez az ASP.NET Ajax elkészült, kiadták (ott feszít a Frameworkben) és támogatott.
  2. Az ASP.NET Ajax .NET-től független, ún. out-of-band kiadása – ezzel lehetett kipróbálni a sablonokat, adatkötést stb. Na ezt nem fejlesztik tovább, ebből nem lesz több verzió, sőt még release sem.

A jQuery csak a 2. esetet “fenyegeti”, bár valójában jót tesz ám neki, csak sokáig tart. Az 1. esetben – legalábbis az ASP.NET WebForms esetén biztosan – nincs tervbe véve, hogy ezeket a funkciókat felváltsa a jQuery.

Ami a két legérdekesebb funkciót, a sablonokat és az adatkötést illeti, már elkezdődött a Microsoft és a jQuery team között az együttműködés. A Microsoft kidolgozott egy módszert a kliens oldali sablonok használatára, amit a community a szokásos eljáráson belül véleményezett, jó sok ötletet és javaslatot küldtek hozzá. A folyamat kezd a vége felé közeledni, az elkészült kód sorsáról (bekerül-e a jQuery cora-ba, hivatalos plug-in lesz-e stb.) pedig mint minden esetben, most is a jQuery team fog dönteni.

A második nagyobb funkció halmaz a kliens oldali adatkötés, amit itt data-linking-nek fognak hívni, mert a “bind” elnevezés már foglalt a jQuery világban. A data-linking valójában adatkötés, méghozzá kétirányú és támogatja a WPF-ből megszokott konvertereket is.

A két funkció természetesen a kliens oldali, deklaratív adatkötés terén fog egymásra találni, ami komoly eredmény lesz. Most ugyan vannak erre egyedi megoldások, de nagyon kellene egy elterjedt, standard megközelítés.

Akit érdekel mindez kód szinten, annak feltétlenül ajánlom Scott Guthrie ide vonatkozó blog bejegyzését.

 

Technorati-címkék: ,,,

Microsoft Desktop Player

Talán nem is hinnénk, hogy a Microsoftnál és a Microsoft megbízásából milyen iszonyatos mennyiségű oktatóanyag keletkezik webcastok és podcastok formájában. Tudod-e például, hogy mi érhető el magyarul a Technet Portálon? A rendszer egyetlen hibája, hogy szinte képtelenség megtalálni azt, amire valóban nekem szükségem van. Ezen próbál segíteni a Microsoft Desktop Player, ami elérhető Silverlightos online változatban és WPF-es offline változatban is.

Most még csak bétában van, de reméljük tovább pumpálják tartalommal és nem hal el a projekt. Próbáljátok ki online vagy offline:

Microsoft Desktop Player

Silverlightok

Azt mondod magadról, hogy értesz a Silverlighthoz? Remek! Melyikhez?

Rövid nekifutás után ennyi Silverlight változatot sikerült összeszednem:

  • Silverlight 4 újabb Windowsokra MacOS X-re
  • Silverlight for Windows Phone 7 = Silverlight 3 néhány extrával és megszorítással
  • Silverlight for Windows Embedded = Silverlight 2 néhány extrával, de C++
  • Silverlight for Symbian = Silverlight 2 jópár megszorítással
  • Silverlight 1.1 régebbi Windowsokra és MacOS 9-re
  • Silverlight set-top-boxokra, TV-re és Blu-ray lejátszókra
  • Moonlight = Silverlight 2-3-4 turmix

Na most akkor pontosan melyikre is fejlesztünk? Mintha az eredeti célok között az is szerepelt volna, hogy készítünk egy alkalmazást, ami azután minden platformon működik?

Azt már csak félve merem megkérdezni, hogy nem hagytam ki valamit a listáról?

Technorati-címkék:

Ethical Hacking ASP.NET

Csütörtökön lezajlott a harmadik Ethical Hacking konferencia, ám az első, amin volt .NET-es téma is. Íme egy rövid összefoglaló arról, hogy hány sebből vérzik az ASP.NET.

A jól működő védelmeket nem is írom, csak néhány fontosabb sebezhetőséget. Itt is kiemelném, hogy bár az ASP.NET-et vettük nagyító alá, hasonló sebezhetőségek más platformokban is megtalálhatóak.

Session kezelés:

  • Session cookie lehallgatás-visszaküldés
  • Sesssion fixation

Űrlap alapú hitelesítés:

  • Authentication cookie lehallgatás-visszaküldés

ViewState:

  • Betekintés (information disclosure)
  • Lehallgatás és visszaküldés

Eseménykezelés:

  • Eseménykezelő átugrása
  • Kikapcsolt (disabled) gomb megnyomása
  • Rejtett gomb megnyomása

One-click támadás.

Aki ott volt az előadáson, mindegyikre láthatott példát. Aki nem tudott eljönni, de érdeklődik, innen letöltheti a prezentációt és a videók is hamarosan kikerülnek a netre.

Készülőben van egy tesztelő eszköz, amellyel ASP.NET-es webhelyek sebezhetőségeit lehet automatizáltam vizsgálni, egyes funkcióit be is mutattam az előadáson. A CodePlexen fogom közreadni a közeljövőben, természetesen csak a védekezés lehetőségeit leíró cikksorozattal együtt.

A csütörtöki egyike volt azon kevés konferenciáknak, ahol az utolsó előadást is ugyanolyan éberségi állapotban ültem végig, mint az elsőt. Számomra nagyon hasznos volt. Nektek? Megérte eljönni? Hallottatok újdonságokat, érdekességeket?

 

Technorati-címkék: ,,