it-swarm-eu.dev

Proč je stejná politika původu tak důležitá?

Nemůžu úplně pochopit, co znamená stejná doména původ. Vím, že to znamená, že když získává prostředek z jiné domény (řekněme soubor JS), bude spuštěn z kontextu domény, která mu slouží (jako je kód Google Analytics), což znamená, že nemůže upravovat data ani je číst. v doméně, která „zahrnuje zdroj“.

Pokud tedy doména a.com vkládá soubor js z google.com ve svém zdroji, který bude spuštěn zgoogle.com a nemá přístup k DOM\cookies\žádnému jinému prvku na a.com -- mám pravdu?

Zde je definice stejných zásad původu, kterým opravdu nerozumím:

Zásada stejného původu je klíčovým mechanismem implementovaným v prohlížečích, který je navržen tak, aby zabránil vzájemnému ovlivňování obsahu pocházejícího z jiného původu. Obsah přijímaný z jednoho webu je v zásadě oprávněn číst a upravovat jiný obsah přijímaný ze stejného webu, ale nemá přístup k obsahu přijatému z jiných webů.

Co to vlastně znamená? Můžete mi prosím dát příklad skutečného života?

Další otázkou je: jaký je účel záhlaví Origin a jak stále existují požadavky napříč doménami? Proč to neovlivní zabezpečení ani stejnou politiku původu?

143
YSY

Proč je stejná politika původu důležitá?

Předpokládejme, že jste přihlášeni na Facebook a navštivte nebezpečný web na jiné kartě prohlížeče. Bez stejných zásad původu by JavaScript na tomto webu mohl udělat pro váš účet na Facebooku cokoli, co můžete dělat. Například čtení soukromých zpráv, aktualizace stavu příspěvků, analýza HTML DOM stromu po zadání hesla před odesláním formuláře.

Ale samozřejmě chce Facebook používat JavaScript, aby zlepšil uživatelský komfort. Je proto důležité, aby prohlížeč zjistil, že tento JavaScript je důvěryhodný pro přístup ke zdrojům Facebooku. To je místo, kde platí stejná zásada původu: Pokud je JavaScript zahrnut ze stránky HTML na facebook.com, může přistupovat ke zdrojům facebook.com.

Nyní vyměňte Facebook za web online bankovnictví a bude zřejmé, že se jedná o problém.

Jaký je původ?

Nemůžu úplně pochopit, co stejná doména původu znamená. Vím, že to znamená, že když získávám zdroj z jiné domény (řekněme soubor JS), bude spuštěn z kontextu domény, která mu slouží (jako je analytický kód google), což znamená, že nemůže upravovat data ani číst data v doméně, která „zahrnuje zdroj“.

To není správné: Původ souboru JavaScript je definován doménou stránky HTML, která jej obsahuje. Pokud tedy zahrnete kód Google Analytics s tagem <script>, může to na vašem webu udělat cokoli, ale na webu Google nemá stejná oprávnění k původu.

Jak funguje komunikace napříč doménami?

Stejná zásada původu není uplatněna u všech požadavků. Mimo jiné mohou tagy <script> - a <img> načíst zdroje z jakékoli domény. Je také možné odesílat formuláře a odkazovat na jiné domény. Rámce a prvky iframe zobrazují informace z jiných domén, ale interakce s tímto obsahem je omezená.

Existuje několik způsobů, jak povolit volání XMLHttpRequest (ajax) do jiných domén bezpečným způsobem, ale běžné prohlížeče nejsou dobře podporovány. Běžný způsob, jak povolit komunikaci s jinou doménou, je JSONP :

Je založen na tagu <script>. Informace, které mají být odeslány do jiné domény, jsou zakódovány v URL jako parametry. Vrácený JavaScript se skládá z volání funkce s požadovanými informacemi jako parametr:

<script type="text/javascript" src="http://example.com/
     ?some-variable=some-data&jsonp=parseResponse">
</script>

Dynamicky generovaný JavaScript z example.com může vypadat takto:

parseResponse({"variable": "value", "variable2": "value2"})

Co je skriptování mezi weby?

Cross Site Scripting je zranitelnost , která umožňuje útočníkovi vložit JavaScript kód na web, takže pochází z napadeného web z pohledu prohlížeče.

K tomu může dojít, pokud není vstup uživatele dostatečně dezinfikován. Například vyhledávací funkce může zobrazit řetězec „Vaše výsledky vyhledávání pro [userinput]“. Pokud [userinput] neunikne, může útočník vyhledat:

<script>alert(document.cookie)</script>

Prohlížeč nemá žádný způsob, jak zjistit, že tento kód nebyl poskytnut vlastníkem webu, takže jej provede. V dnešní době je skriptování mezi weby hlavním problémem, a proto je třeba zabránit této chybě zabezpečení. Nejvýznamnější je přístup Content Security Policy .

122

Co to vlastně znamená? Můžete mi prosím dát příklad skutečného života?

Příklad útoku 1: Padělání požadavků na více stránek (CSRF) s formulářem HTML

Na stránku na evil.com Uvedl útočník:

<form method="post" action="http://bank.com/trasfer">
    <input type="hidden" name="to" value="ciro">
    <input type="hidden" name="ammount" value="100000000">
    <input type="submit" value="CLICK TO CLAIM YOUR PRIZE!!!">
</form>

Bez dalších bezpečnostních opatření by to:

  • žádost je odeslána. Parametr SOP) nezakazuje odeslání této žádosti.
  • zahrnuje ověřovací soubory cookie z bank.com, které vás přihlašují

Je to vzor tokenů synchronizátoru, sám o sobě, i bez SOP, tomu brání v práci.

Vzor tokenů synchronizátoru

Pro každý formulář v bank.com Vývojáři vygenerují jednorázovou náhodnou sekvenci jako skrytý parametr a požadavek přijmou, pouze pokud server tento parametr získá.

Pomocníci HTML společnosti Rails například do HTML automaticky přidají parametr authenticity_token, Takže legitimní forma bude vypadat takto:

<form action="http://bank.com/transfer" method="post">
  <p><input type="hidden" name="authenticity_token"
            value="j/DcoJ2VZvr7vdf8CHKsvjdlDbmiizaOb5B8DMALg6s=" ></p>
  <p><input type="hidden" name="to"      value="ciro"></p>
  <p><input type="hidden" name="ammount" value="100000000"></p>
  <p><button type="submit">Send 100000000$ to Ciro.</button></p>
</form>

jak je uvedeno na: https://stackoverflow.com/questions/941594/understanding-the-Rails-authenticity-token/26895980#2689598

Pokud tedy evil.com Podá požadavek na jeden příspěvek, nikdy by tento token neuhodl a server by transakci odmítl!

Viz také: vzor tokenů synchronizátoru na OWASP .

Příklad útoku 2: Padělání požadavků na více stránek (CSRF) s JavaScript AJAX

Co ale brání evil.com Ve vytváření 2 požadavků pomocí JavaScriptu, stejně jako by to udělal legitimní prohlížeč:

  1. XHR ZÍSKEJTE token
  2. XHR POST) obsahující dobrý token

takže evil.com zkusí něco podobného (jQuery protože líný):

$.get('http://bank.com/transfer')
// Parse HTML reply and extract token.
$.post('http://bank.com/transfer', {
  to: 'ciro',
  ammount: '100000000',
  authenticity_token: extracted_token
})

Toto je místo, kde se hraje SOP). Ačkoli $.get A $.post skutečně odeslat ověřený požadavek, stejně jako formulář HTML, prohlížeč odesílatele zabrání kódu JavaScript ve čtení odpovědi HTML zpět, protože žádost byla odeslána do samostatné domény!

Konzola pro vývojáře Chromium zobrazuje chybu typu:

Přístup k XMLHttpRequest na ' http://bank.com ' from Origin ' http://evil.com ' byl zablokován zásadou CORS: Ne 'Access-Control -Allow-Origin 'záhlaví je na požadovaném zdroji.

který byl požádán na: https://stackoverflow.com/questions/20035101/why-does-my-javascript-code-get-a-no-access-control-allow-Origin-header-is- pr

Proč nejen neposílat soubory cookie s křížovým požadavkem?

Co kdyby implementace měly pravidlo jako: „povolit jakýkoli požadavek, ale posílat pouze cookies na aktuální doméně XHR“? Nebylo by to jednodušší?

Ale to by stále umožňovalo jiný typ útoku: když ověření není založeno na cookies, ale na zdroji (IP) požadavku!

Například jste v intranetu vaší společnosti a odtud máte přístup k internímu serveru, který není zvenčí viditelný a slouží tajným datům.

Jsou zakázány všechny žádosti o křížový původ?

I když zapomínáme na CORS, ne , děláme je každý den!

Od MDN :

  • Psaní napříč původem jsou obvykle povolena: odkazy, přesměrování a odesílání formulářů.

    [Můj komentář]: např. Když kliknete na odkaz, často jste očekávali, že se přihlásíte na web, a to vyžaduje provedení ověřeného požadavku GET, který vrátí novou stránku.

  • Vkládání napříč původem je obvykle povoleno: obrázky, externí CSS a Javascript, iframe.

  • Čtení křížového původu obvykle není povoleno: XHR (příklad výše), iframe čtení.

    Přístup ke čtení je však často vložením vložen. Můžete například číst šířku a výšku vloženého obrazu, akce vloženého skriptu nebo dostupnost vloženého zdroje (a tedy případně, pokud je uživatel přihlášen nebo ne doména)

Zejména by bylo možné použít formulář v evil.com, Který vytvoří autentizovaný POST požadavek na bank.com). Z tohoto důvodu SOP nestačí: je potřeba také synchronizační token.

Viz také: CSRF na OSWAP .

Jiné preventivní přístupy

Nebojte se. Zjistil jsem, že je složité obtočit si hlavu.

Ukázalo se, že Google Analytics může teoreticky udělat cokoli, co chtějí svým uživatelům. (<script> tagy vytvořte výjimk k omezením zásad stejného původu)

To je jeden z největších důvodů XSS útoky jsou Bad Thing ™ a jeden z důvodů, proč Mozilla navrhla Content Security Policy což je nyní - na cestě k tomu, že je standardizovaný . (Užitečná může být také implementace atributu HTML5 atribut iframe sandbox pomocí WebKit).

Protože se nemohli dostat pryč s porušením zpětné kompatibility, politika stejného původu je spíše o prevenci věcí, jako je <iframe> a XMLHttpRequest z triků, jako je používání souborů cookie „Zapamatovat si mě“ nebo ležících přihlašovacích dialogů pro přístup k vašim účtům. (Záhlaví X-Frame-Options vám umožňuje zamknout rámy ještě více, abyste chránili před věcmi jako Clickjacking .)

Záhlaví Origin je používána mechanismem s názvem „Cross-Origin Resource Sharing“, který umožňuje webům udělit omezené výjimky z politiky stejného původu pro bezpečnou interakci mezi weby. (plně podporováno v všechny aktuální prohlížeče kromě Opera a Internet Explorer a částečně v IE8 + pomocí proprietárního objektu XDomainRequest, který vynechává cookies)

V zásadě, když se pokusíte vytvořit XMLHttpRequest do jiné domény, prohlížeč provede jedna ze dvou věcí :

  1. Pokud se jedná o požadavek GET nebo POST, který splňuje určité limity (které tvůrci standardu určili, že pro [~ # ~] csrf [~ # ~ nepřidají žádné další riziko) ] útoky), pak prohlížeč požadavek pouze projde.

  2. Jinak provede to, co se nazývá "preflighted request", kde nejprve odešle místo toho požadavek OPTIONS a provede pouze to, co jste požadovali, pokud šeky vyhoví požadavku OPTIONS.

V obou případech prohlížeč připojí záhlaví Origin, které informuje cílový web, který volá. (Je to něco jako záhlaví Referer, ale pro zajištění řádného zabezpečení je vyžadováno a přísněji specifikováno)

Server na přijímajícím konci (ten, který se silně spoléhá na politiku stejného původu pro ochranu), pak může žádost schválit zahrnutím Access-Control-Allow-Origin záhlaví, které obsahuje buď * nebo hodnota záhlaví Origin požadavku.

Pokud tomu tak není, prohlížeč jednoduše zahodí odpověď a vrátí chybu zpětnému volání jazyka Javascript. MDN jde do detailů (1)(2) o tom, co se děje pod kapotou v obou scénářích a jaké další záhlaví může cílový systém nastavit, aby dále uvolnil kontrolovaným způsobem. (např. Povolení přístupu k vlastním záhlavím HTTP, které nastavujete)

Požadavky GET a povolená podmnožina požadavků POST lze již použít pro útoky CSRF pomocí jiných mechanismů, pokud není cílová webová aplikace řádně chráněna, takže bylo rozhodnuto, že pro zdvojnásobení počet požadavků HTTP zapojených do provozních služeb, jako je Knihovna písem Google.

19
ssokolow

Ve skutečnosti v tomto případě je původem analytického skriptu Google a.com

Citace z JavaScript: The Definitive Guide :

Je důležité pochopit, že samotný původ skriptu není relevantní pro politiku stejného původu: záleží na původu dokumentu, ve kterém je skript vložen.

1
nandin