Sdílet prostřednictvím

Zveřejnění informací

  • Článek

Zpřístupnění informací umožňuje útočníkovi získat cenné informace o systému. Proto vždy zvažte, jaké informace odhalíte a jestli je může uživatel se zlými úmysly používat. Následující seznam uvádí možné útoky na zpřístupnění informací a poskytuje zmírnění rizik pro každý z nich.

Zabezpečení zpráv a PROTOKOL HTTP

Pokud používáte zabezpečení na úrovni zpráv přes vrstvu přenosu HTTP, mějte na paměti, že zabezpečení na úrovni zpráv nechrání hlavičky HTTP. Jediným způsobem, jak chránit hlavičky HTTP, je použití přenosu HTTPS místo PROTOKOLU HTTP. Přenos HTTPS způsobí šifrování celé zprávy, včetně hlaviček HTTP, pomocí protokolu SSL (Secure Sockets Layer).

Informace o zásadách

Zabezpečení zásad je důležité, zejména ve scénářích federace, kdy jsou v zásadách vystaveny citlivé požadavky na vystavený token nebo informace vystavitele tokenů. V těchto případech doporučujeme zabezpečit koncový bod zásad federované služby, aby útočníci nemohli získat informace o službě, například typ deklarací identity, které se mají vložit do vystaveného tokenu, nebo přesměrovat klienty na vystavitele škodlivých tokenů. Útočník může například zjistit páry uživatelského jména a hesla tak, že překonfiguruje federovaný řetězec důvěryhodnosti tak, aby se ukončil v vystaviteli, který spustil útok man-in-the-middle. Doporučujeme také federovaným klientům, kteří získávají vazby prostřednictvím načtení zásad, ověřit, že vystavitelům důvěřují v získaném federovaného řetězu důvěryhodnosti. Další informace o scénářích federace najdete v tématu Federace.

Výpisy paměti můžou odhalit informace o deklaraci identity

Pokud aplikace selže, mohou soubory protokolu, jako jsou soubory vytvořené dr. Watsonem, obsahovat informace o deklaraci identity. Tyto informace by neměly být exportovány do jiných entit, jako jsou týmy podpory; jinak se exportují i informace o deklaraci identity, která obsahuje soukromá data. Můžete to zmírnit tím, že neodesíláte soubory protokolu neznámým entitům.

Adresy koncových bodů

Adresa koncového bodu obsahuje informace potřebné ke komunikaci s koncovým bodem. Aby bylo možné vyjednat symetrický klíč mezi klientem a serverem, musí zabezpečení PROTOKOLU SOAP obsahovat úplnou adresu ve zprávách vyjednávání o zabezpečení. Protože vyjednávání zabezpečení je proces bootstrap, hlavičky adres nelze během tohoto procesu zašifrovat. Adresa by proto neměla obsahovat žádná důvěrná data; jinak vede k útokům na zpřístupnění informací.

Certifikáty převedené nešifrované

Když k ověření klienta použijete certifikát X.509, certifikát se přenese v nezaškrtnuté hlavičce SOAP. Mějte na paměti, že jde o potenciální zpřístupnění osobních údajů (PII). Nejedná se o problém v TransportWithMessageCredential režimu, kdy je celá zpráva šifrovaná pomocí zabezpečení na úrovni přenosu.

Odkazy na služby

Odkaz na službu je odkaz na jinou službu. Například služba může v průběhu operace předat klientovi odkaz na službu. Odkaz na službu se také používá s ověřovatelem identity důvěryhodnosti, interní komponentou, která zajišťuje identitu cílového objektu zabezpečení před zveřejněním informací, jako jsou data aplikace nebo přihlašovací údaje k cíli. Pokud identitu vzdáleného vztahu důvěryhodnosti nelze ověřit nebo je nesprávná, odesílatel by měl zajistit, aby se nezveřejnila žádná data, která by mohla ohrozit samotnou identitu, aplikaci nebo uživatele.

Zmírnění rizik zahrnuje následující:

  • Předpokládá se, že odkazy na služby jsou důvěryhodné. Při přenosu instancí odkazů na služby dbejte na to, aby se zajistilo, že s sebou nebyly manipulovány.

  • Některé aplikace můžou prezentovat uživatelské prostředí, které umožňuje interaktivní vytvoření důvěryhodnosti na základě dat v referenčních informacích služby a dat důvěryhodnosti prokázáno vzdáleným hostitelem. WCF poskytuje pro takové zařízení body rozšiřitelnosti, ale uživatel je musí implementovat.

NTLM

Ve výchozím nastavení ověřování systému Windows používá ověřování systému Windows protokol Kerberos k ověřování a autorizaci uživatelů. Pokud protokol Kerberos nelze z nějakého důvodu použít, použije se jako záložní protokol NT LAN Manager (NTLM). Toto chování můžete zakázat nastavením AllowNtlm vlastnosti na falsehodnotu . Mezi problémy, které je potřeba vědět při povolování protokolu NTLM, patří:

  • PROTOKOL NTLM zveřejňuje uživatelské jméno klienta. Pokud uživatelské jméno musí být důvěrné, nastavte AllowNTLM vlastnost vazby na false.

  • PROTOKOL NTLM neposkytuje ověřování serveru. Klient proto nemůže zajistit, aby komunikoval se správnou službou při použití protokolu NTLM jako ověřovacího protokolu.

Zadání přihlašovacích údajů klienta nebo neplatné identity vynutí použití protokolu NTLM.

Při vytváření klienta, zadání přihlašovacích údajů klienta bez názvu domény nebo zadání neplatné identity serveru způsobí, že se místo protokolu Kerberos použije protokol NTLM (pokud AllowNtlm je vlastnost nastavená na true). Vzhledem k tomu, že NTLM neprovádí ověřování serveru, mohou být informace potenciálně zpřístupněny.

Můžete například zadat přihlašovací údaje klienta systému Windows bez názvu domény, jak je znázorněno v následujícím kódu Visual C#.

MyChannelFactory.Credentials.Windows.ClientCredential = new System.Net.NetworkCredential("username", "password");

Kód nezadá název domény, a proto se použije protokol NTLM.

Pokud je doména zadaná, ale pomocí funkce identity koncového bodu je zadán neplatný název instančního objektu, použije se protokol NTLM. Další informace o tom, jak je zadaná identita koncového bodu, najdete v tématu Identita služby a ověřování.

Viz také