Aplikační bezpečnost na platformě Windows: Za vším hledej IIS (1)

21. 4. 2012

Sdílet

 Autor: Maksim Samasiuk - Fotolia.com
Dnes obrátíme pozornost k základnímu kameni mnoha aplikací vůbec – k webovým službám sdruženým ve Windows pod označením Internet Information Services (IIS).

Microsoft uvolnil již verzi 7.5, jež je součástí Windows 2008 R2 a která představuje základní kámen mnoha aplikací. IIS se dočkaly zásadních změn ve své architektuře, a to především při přechodu z verze 6.0 (ve Windows 2003) na verzi 7.0 ve Windows 2008.

Proměna souvisela jak s masivním rozvojem technologie .NET pro běh aplikací, tak s požadavky na další zvýšení aplikační bezpečnosti výkonnosti. V následujících odstavcích zmiňujeme vybrané mechanizmy zabezpečení, které se buďto dočkaly zajímavého vývoje, nebo se objevily jako novinky.

Webové aplikace jsou citlivým místem už ze své podstaty. Na jednu stranu záměrně otevřeny přístupu zvenčí, na druhou stranu pracující s databázemi s mnoha citlivými údaji, z nichž jen ty správné by se měly navracet k žadatelům.

Microsoft jako obvykle posiluje na několika frontách. Samotná běhová platforma .NET přináší své vlastní, nezávislé bezpečnostní mechanizmy, jež podporují bezpečný provoz webu ze své podstaty. Nalezneme zde však řadu zajímavých změn: příchozí požadavky jsou důsledně kontrolovány, aplikace běží v rámci vlastních oddělených prostorů v izolaci a přístup na zdroje může být řízen pomocí speciálních identit, jež nemají žádná práva na běžné činnosti v operačním systému, jako jiné běžné účty. Poslední varianty IIS zkrátka přinášejí opravdu zajímavé možnosti.

 

Identita a její ověření

Ověření identity uživatele samozřejmě představuje základní pilíř zabezpečení webových aplikací v nejširším smyslu slova. Služby IIS nabízejí škálu ověřovacích protokolů již poměrně dlouho, přesto se objevila v posledních verzích varianta, která dnes patří mezi nejužívanější.

Jedná se o univerzální formulářové ověřování, tedy tzv. form-based authentication, které se stalo pilířem řady aplikací na bázi webových služeb. Jde vlastně o dočasné přesměrování na přihlašovací formulář, po jehož přijetí vrátí IIS řízení zpět původně dotazované aplikaci, tedy podle výsledku přihlášení.

Zajímavé je, že samotný přenos jména a hesla se děje v podobě běžného nešifrovaného textu, a proto je v podstatě nutností ochrana pomocí SSL. Vývoj tedy v tomto případě nešel cestou vylepšování šifer a různých hešovacích algoritmů pro ochranu jména a hesla, ale naopak jednoznačnou sázkou na prověřenou technologii SSL/TLS.

Druhým ověřovacím mechanizmem, který zmíníme, je tzv. Windows authentication. Z pohledu koncepčního představuje naprostý protipól – využívá zabudované protokoly Kerberos či NTLM2, provádí tedy hešování a šifrování přihlašovacích údajů a je zcela svázán s platformou Windows a prostředím Active Directory. Jde tedy vlastně o řešení výhradně pro intranetové aplikace, kde usnadňuje integraci s existujícími účty.

Vedle samotných metod ověřování je jistě významné též samotné uložení uživatelských účtů či přesněji místo, kde jsou založeny pro potřeby aplikací v IIS. Dříve byly převažujícími variantami mapování účtů z Active Directory či lokální databáze účtů Windows.

Takový scénář s sebou nese problém nemožnosti vymezení přístupu čistě k webovým aplikacím, což je možno dnes vyřešit díky platformě .NET, na níž moderní webové aplikace běží. Právě .NET dovoluje ustanovit role a skupiny uživatelů, pro jejichž ověřování budeme sahat do zcela jiných zdrojů, než jsou ony výchozí databáze účtů ve Windows.

Nabízí se tak nezávislá instance adresářových služeb (separátní LDAP v provedení ADAM, nezávislý na Active Directory) nebo třeba databáze SQL Express, v jejíchž tabulkách můžeme také držet seznam oprávněných uživatelů.

V této souvislosti je jistě na místě zmínit novou koncepci spouštění anonymních aplikací či anonymně dostupných webových stránek. Jejich činnost byla reprezentována zástupným účtem IUSR_JmenoPocitace, který pak sloužil k řízení přístupu anonymních požadavků.

Problémem bylo, že se jednalo o tradiční účet ve Windows, který tak dovoloval již svou pouhou existencí mnohem více, než webová aplikace vlastně potřebuje. Navíc se jeho užíváním zhoršovala přenositelnost aplikací, neboť jeho přístup ke zdrojům je řízen (jako u všech ostatních) pomocí ACL, v němž figuruje identifikátor SID. Ten se na každém serveru lišil nebo se jednalo o odlišené lokální účty, a proto nebylo možné aplikaci prostě přenést jinam a spoléhat, že se dostane ke složkám a souborům.

Nová koncepce poskytuje na IIS 7 účet IUSR. Jde o entitu, která nefiguruje v lokální databázi účtů Windows a pracuje jako soukromá záležitost webového serveru. Nutné spojení s vnějším světem zdrojů na souborovém systému pak zajišťuje možnost přiřadit této entitě práva NTFS, a to přesto, že ve Windows vlastně neexistuje.

ICTS24

Netrápíme se tedy potenciálním nebezpečím jeho zneužití, nemusíme nastavovat heslo a navíc se můžeme spolehnout, že má všude stejné jméno a případně i SID. Jeho použití je určeno v konfiguračním souboru webu, což zajišťuje snadné přenesení tohoto nastavení.

Příště se podíváme na problematiku přístupu ke zdroji a také na filtrování požadavků