10 Nejčastější chyby zabezpečení webu

Obsah:

Anonim

OWASP nebo Open Web Security Project je nezisková charitativní organizace zaměřená na zlepšování zabezpečení softwaru a webových aplikací.

Organizace publikuje seznam nejzranitelnějších bezpečnostních chyb na webu na základě dat od různých bezpečnostních organizací.

Zranitelnosti zabezpečení webu jsou upřednostňovány v závislosti na využitelnosti, zjistitelnosti a dopadu na software.

  • Využitelnost -

    Co je nutné k zneužití této chyby zabezpečení? Nejvyšší využitelnost, když útok potřebuje pouze webový prohlížeč a nejnižší je pokročilé programování a nástroje.

  • Zjistitelnost -

    Jak snadné je detekovat hrozbu? Nejvyšší jsou informace zobrazené na URL, formuláři nebo chybové zprávě a nejnižší jsou zdrojový kód.

  • Náraz nebo poškození -

    Kolik škod bude způsobeno, pokud bude odhalena nebo napadena chyba zabezpečení? Nejvyšší je úplná havárie systému a nejnižší je vůbec nic.

Hlavním cílem OWASP Top 10 je vzdělávat vývojáře, designéry, manažery, architekty a organizace o nejdůležitějších bezpečnostních zranitelnostech.

Top 10 zranitelností zabezpečení podle OWASP Top 10 jsou:

  • SQL Injection
  • Cross Site Scripting
  • Broken Authentication and Session Management
  • Nezabezpečené přímé odkazy na objekty
  • Padělání mezi weby
  • Chybná konfigurace zabezpečení
  • Nezabezpečené kryptografické úložiště
  • Selhání omezení přístupu k URL
  • Nedostatečná ochrana transportní vrstvy
  • Neověřené přesměrování a přeposílání

SQL Injection

Popis

Injection je chyba zabezpečení, která umožňuje útočníkovi měnit back-endové příkazy SQL manipulací s daty poskytnutými uživatelem.

Injekce nastane, když je vstup uživatele odeslán tlumočníkovi jako součást příkazu nebo dotazu a přimět tlumočníka, aby provedl neúmyslné příkazy, a umožní přístup k neoprávněným datům.

Příkaz SQL, který při spuštění webovou aplikací může také vystavit back-end databázi.

Implikace

  • Útočník může do zranitelných polí vložit škodlivý obsah.
  • Citlivá data, jako jsou uživatelská jména, hesla atd., Lze načíst z databáze.
  • Data databáze lze upravit (Vložit / Aktualizovat / Odstranit).
  • V databázi lze provádět operace správy

Zranitelné objekty

  • Vstupní pole
  • Interakce adres URL s databází.

Příklady:

  • Vložení SQL na přihlašovací stránku

Přihlášení do aplikace bez platných pověření.

Platné uživatelské jméno je k dispozici a heslo není k dispozici.

Testovací URL: http://demo.testfire.net/default.aspx

Uživatelské jméno: sjones

Heslo: 1 = 1 'nebo pass123

SQL dotaz vytvořen a odeslán tlumočníkovi, jak je uvedeno níže

SELECT * FROM Users WHERE User_Name = sjones AND Password = 1 = 1 'or pass123;

Doporučení

  1. Bílá se seznamem vstupních polí
  2. Nezobrazujte podrobné chybové zprávy, které by byly pro útočníka užitečné.

Cross Site Scripting

Popis

Cross Site Scripting je také krátce známý jako XSS.

Zranitelnosti XSS cílí na skripty vložené do stránky, které jsou spouštěny na straně klienta, tj. V prohlížeči uživatele, nikoli na straně serveru. Tyto chyby mohou nastat, když aplikace vezme nedůvěryhodná data a odešle je do webového prohlížeče bez řádného ověření.

Útočníci mohou pomocí XSS spouštět škodlivé skripty na uživatelích, v tomto případě v prohlížečích obětí. Vzhledem k tomu, že prohlížeč nemůže vědět, zda je skript důvěryhodný, bude skript spuštěn a útočník může unést soubory cookie relace, znehodnotit webové stránky nebo přesměrovat uživatele na nežádoucí a škodlivé webové stránky.

XSS je útok, který umožňuje útočníkovi spouštět skripty v prohlížeči oběti.

Implikace:

  • Při použití této chyby zabezpečení může útočník vložit do aplikace skripty, může ukrást soubory cookie relace, znehodnotit webové stránky a může na počítačích oběti spustit malware.

Zranitelné objekty

  • Vstupní pole
  • URL

Příklady

1. http://www.vulnerablesite.com/home?" < script > alert(" xss") script >

Výše uvedený skript, když je spuštěn v prohlížeči, se zobrazí okno se zprávou, pokud je web zranitelný vůči XSS.

Vážnější útok lze provést, pokud chce útočník zobrazit nebo uložit cookie relace.

2. http://demo.testfire.net/search.aspx?txtSearch > http://google.com width = 500 height 500>

Při spuštění výše uvedeného skriptu načte prohlížeč neviditelný rámeček směřující na http://google.com .

Útok může být vážný spuštěním škodlivého skriptu v prohlížeči.

Doporučení

  1. Vstupní pole bílé listiny
  2. Kódování vstupního výstupu

Broken Authentication and Session Management

Popis

Webové stránky obvykle vytvářejí cookie relace a ID relace pro každou platnou relaci a tyto soubory cookie obsahují citlivá data, jako je uživatelské jméno, heslo atd. Po ukončení relace odhlášením nebo náhlým zavřením prohlížeče by tyto soubory cookie měly být zneplatněny, tj. Pro každou relaci. měl by existovat nový cookie.

Pokud cookies nejsou zneplatněny, budou v systému existovat citlivá data. Například uživatel, který používá veřejný počítač (Cyber ​​Cafe), soubory cookie zranitelného webu sedí v systému a jsou vystaveny útočníkovi. Útočník po určité době používá stejný veřejný počítač, citlivá data jsou ohrožena.

Stejným způsobem uživatel, který používá veřejný počítač, místo odhlášení náhle zavře prohlížeč. Útočník používá stejný systém, při procházení stejného zranitelného webu se otevře předchozí relace oběti. Útočník může dělat, co chce, od krádeže informací o profilu, údajů o kreditní kartě atd.

Měla by být provedena kontrola, aby se zjistila síla autentizace a správy relací. Klíče, tokeny relace, soubory cookie by měly být implementovány správně, aniž by byla ohrožena hesla.

Zranitelné objekty

  • ID relace vystavené na adrese URL mohou vést k útoku na fixaci relace.
  • ID relace stejná před i po odhlášení a přihlášení.
  • Časové limity relací nejsou implementovány správně.
  • Aplikace přiřazuje stejné ID relace pro každou novou relaci.
  • Ověřené části aplikace jsou chráněny pomocí SSL a hesla jsou uložena v hašovaném nebo šifrovaném formátu.
  • Relace může být znovu použita uživatelem s nízkými oprávněními.

Implikace

  • Útočník, který tuto chybu zabezpečení využije, může napadnout relaci, získat neoprávněný přístup do systému, který umožňuje odhalení a úpravu neoprávněných informací.
  • Relace mohou být vysoké s pomocí ukradených cookies nebo relací pomocí XSS.

Příklady

  1. Aplikace pro rezervaci leteckých společností podporuje přepisování adres URL a vkládání ID relací do adresy URL:

    http://Examples.com/sale/saleitems;jsessionid=2P0OC2oJM0DPXSNQPLME34SERTBG/dest=Maldives (Prodej letenek na Maledivy)

    Ověřený uživatel webu chce informovat své přátele o prodeji a pošle e-mail. Přátelé obdrží ID relace a mohou být použity k neoprávněným úpravám nebo zneužití uložených údajů o kreditní kartě.

  2. Aplikace je zranitelná vůči XSS, pomocí kterého může útočník získat přístup k ID relace a lze ji použít k únosu relace.
  3. Časové limity aplikací nejsou správně nastaveny. Uživatel používá veřejný počítač a místo odhlášení zavře prohlížeč a odejde. Útočník o stejný čas použije stejný prohlížeč a relace je ověřena.

Doporučení

  1. Všechny požadavky na ověřování a správu relací by měly být definovány podle standardu OWASP Application Security Verification Standard.
  2. Nikdy nevystavujte žádná pověření v adresách URL nebo protokolech.
  3. Je také třeba vyvinout značné úsilí, aby se zabránilo chybám XSS, které lze použít ke krádeži ID relace.

Nezabezpečené přímé odkazy na objekty

Popis

Dochází k němu, když vývojář vystaví odkaz na interní implementační objekt, například soubor, adresář nebo klíč databáze jako v URL nebo jako parametr FORM. Útočník může tyto informace použít k přístupu k dalším objektům a může vytvořit budoucí útok pro přístup k neoprávněným datům.

Implikace

  • Pomocí této chyby zabezpečení může útočník získat přístup k neoprávněným interním objektům, může upravovat data nebo ohrozit aplikaci.

Zranitelné objekty

  • V URL.

Příklady:

Změna „userid“ na následující adrese URL může přinést útočníkovi zobrazení dalších informací o uživateli.

http://www.vulnerablesite.com/userid=123 Upraveno na http://www.vulnerablesite.com/userid=124

Útočník může zobrazit ostatní informace změnou hodnoty ID uživatele.

Doporučení:

  1. Implementujte kontroly kontroly přístupu.
  2. Nevystavujte odkazy na objekty v adresách URL.
  3. Ověřte autorizaci pro všechny referenční objekty.

Padělání mezi weby

Popis

Cross Site Request Forgery je padělaný požadavek pocházející z cross site.

Útok CSRF je útok, ke kterému dochází, když škodlivý web, e-mail nebo program způsobí, že prohlížeč uživatele provede nežádoucí akci na důvěryhodném webu, pro který je uživatel aktuálně ověřen.

Útok CSRF donutí přihlášený prohlížeč oběti k odeslání falešného požadavku HTTP, včetně souboru cookie relace oběti a dalších automaticky zahrnutých ověřovacích informací, do zranitelné webové aplikace.

Útočník pošle odkaz oběti, když uživatel klikne na adresu URL při přihlášení na původní web, data budou z webu odcizena.

Implikace

  • Použití této chyby zabezpečení jako útočníka může změnit informace o profilu uživatele, změnit stav, vytvořit nového uživatele jménem správce atd.

Zranitelné objekty

  • Stránka profilu uživatele
  • Formuláře uživatelských účtů
  • Stránka obchodních transakcí

Příklady

Oběť je přihlášena na web banky pomocí platných údajů. Dostává poštu od útočníka a říká: „Klikněte prosím sem, abyste darovali $ 1.“

Když na něj oběť klikne, bude vytvořena platná žádost o darování $ 1 na konkrétní účet.

http://www.vulnerablebank.com/transfer.do?account=cause&amount=1

Útočník tento požadavek zachytí a vytvoří níže uvedený požadavek a vloží tlačítko s nápisem „Podporuji příčinu“.

http://www.vulnerablebank.com/transfer.do?account=Attacker&amount=1000

Jelikož je relace ověřena a požadavek přichází přes web banky, server by převedl útočníkovi 1 000 dolarů.

Doporučení

  1. Pověřte přítomnost uživatele při provádění citlivých akcí.
  2. Implementujte mechanismy jako CAPTCHA, opětovné ověření a tokeny jedinečných požadavků.

Chybná konfigurace zabezpečení

Popis

Konfiguraci zabezpečení je třeba definovat a nasadit pro aplikaci, rozhraní, aplikační server, webový server, databázový server a platformu. Pokud jsou správně nakonfigurovány, může mít útočník neoprávněný přístup k citlivým datům nebo funkcím.

Někdy takové chyby vedou k úplnému kompromisu systému. Udržování softwaru v aktuálním stavu je také dobrá bezpečnost.

Implikace

  • Díky využití této chyby zabezpečení může útočník vyjmenovat základní informace o technologii a verzi aplikačního serveru, informace o databázi a získat informace o aplikaci, aby mohl připojit několik dalších útoků.

Zranitelné předměty

  • URL
  • Pole formuláře
  • Vstupní pole

Příklady

  1. Konzole pro správu aplikačního serveru se automaticky nainstaluje a neodstraní. Výchozí účty se nezmění. Útočník se může přihlásit pomocí výchozích hesel a může získat neoprávněný přístup.
  2. Výpis adresářů není na vašem serveru zakázán. Útočník zjistí a může jednoduše vypsat adresáře a najít libovolný soubor.

Doporučení

  1. Silná aplikační architektura, která poskytuje dobré oddělení a zabezpečení mezi komponentami.
  2. Změňte výchozí uživatelská jména a hesla.
  3. Zakažte výpisy adresářů a implementujte kontroly řízení přístupu.

Nezabezpečené kryptografické úložiště

Popis

Nezabezpečené kryptografické úložiště je běžná chyba zabezpečení, která existuje, když citlivá data nejsou bezpečně uložena.

Přihlašovací údaje uživatele, informace o profilu, zdravotní údaje, informace o kreditní kartě atd. Spadají pod citlivé údaje na webu.

Tato data budou uložena v databázi aplikace. Pokud jsou tato data uložena nesprávně, protože nepoužívají šifrování ani hašování *, budou zranitelná vůči útočníkům.

(* Hashing je transformace znaků řetězce na kratší řetězce pevné délky nebo klíče. K dešifrování řetězce by měl být k dispozici algoritmus použitý k vytvoření klíče)

Implikace

  • Pomocí této chyby zabezpečení může útočník krást, upravovat takto slabě chráněná data za účelem krádeže identity, podvodu s kreditní kartou nebo jiných trestných činů.

Zranitelné předměty

  • Databáze aplikací.

Příklady

V jedné z bankovních aplikací používá databáze hesel nesolené hashy * k ukládání hesel všech. Chyba injekce SQL umožňuje útočníkovi získat soubor hesla. Všechny nesolené hashe mohou být brutálně vynuceny v žádném okamžiku, zatímco solené hesla by trvaly tisíce let.

(* Nesolené hash - sůl je náhodná data připojená k původním datům. Sůl je připojena k heslu před hašováním)

Doporučení

  1. Zajistěte vhodné silné standardní algoritmy. Nevytvářejte vlastní kryptografické algoritmy. Používejte pouze schválené veřejné algoritmy, jako je AES, kryptografie veřejného klíče RSA a SHA-256 atd.
  2. Zajistěte šifrování záloh mimo pracoviště, ale klíče jsou spravovány a zálohovány samostatně.

Selhání omezení přístupu k URL

Popis

Webové aplikace před vykreslením chráněných odkazů a tlačítek kontrolují přístupová práva k URL. Aplikace musí provádět podobné kontroly přístupu při každém přístupu na tyto stránky.

Ve většině aplikací se privilegované stránky, umístění a prostředky nezobrazují privilegovaným uživatelům.

Inteligentním odhadem může útočník přistupovat na stránky privilegií. Útočník může přistupovat k citlivým stránkám, vyvolávat funkce a prohlížet důvěrné informace.

Implikace

  • Využití této chyby zabezpečení může útočníkovi získat přístup k neoprávněným adresám URL, aniž by se musel přihlašovat do aplikace a tuto chybu zabezpečení zneužít. Útočník může přistupovat k citlivým stránkám, vyvolávat funkce a prohlížet důvěrné informace.

Zranitelné objekty:

  • URL

Příklady

  1. Útočník si všimne, že adresa URL označuje roli jako „/ user / getaccounts“. Upraví se jako „/ admin / getaccounts“.
  2. Útočník může k adrese URL připojit roli.

http://www.vulnerablsite.com lze upravit jako http://www.vulnerablesite.com/admin

Doporučení

  1. Implementujte silné kontroly kontroly přístupu.
  2. Zásady ověřování a autorizace by měly být založeny na rolích.
  3. Omezte přístup k nechtěným adresám URL.

Nedostatečná ochrana transportní vrstvy

Popis

Zabývá se výměnou informací mezi uživatelem (klientem) a serverem (aplikací). Aplikace často přenášejí po síti citlivé informace, jako jsou podrobnosti ověřování, informace o kreditní kartě a tokeny relací.

Použitím slabých algoritmů nebo použitím prošlých nebo neplatných certifikátů nebo nepoužíváním SSL můžete umožnit vystavení komunikace nedůvěryhodným uživatelům, což může ohrozit webovou aplikaci nebo ukrást citlivé informace.

Implikace

  • Díky využití této chyby zabezpečení webu může útočník čichat legitimní pověření uživatele a získat přístup k aplikaci.
  • Může ukrást informace o kreditní kartě.

Zranitelné předměty

  • Data odeslaná po síti.

Doporučení

  1. Povolte zabezpečený protokol HTTP a vynuťte přenos pověření pouze přes HTTPS.
  2. Ujistěte se, že váš certifikát je platný a jeho platnost nevypršela.

Příklady:

1. Aplikace, která nepoužívá SSL, bude útočník jednoduše monitorovat síťový provoz a bude sledovat ověřený soubor cookie relace oběti. Útočník může tento soubor cookie ukrást a provést útok Man-in-the-Middle.

Neověřené přesměrování a přeposílání

Popis

Webová aplikace používá několik metod k přesměrování a předání uživatelů na jiné stránky pro zamýšlený účel.

Pokud při přesměrování na jiné stránky nedojde k řádnému ověření, mohou to útočníci využít a mohou oběti přesměrovat na phishingové nebo malwarové stránky nebo použít vpřed pro přístup k neoprávněným stránkám.

Implikace

  • Útočník může uživateli odeslat adresu URL, která obsahuje skutečnou adresu URL s kódovanou škodlivou adresou URL. Uživatel, který pouze uvidí skutečnou část adresy URL zaslané útočníkem, ji může procházet a může se stát obětí.

Příklady

1. http://www.vulnerablesite.com/login.aspx?redirectURL=ownsite.com

Upraveno na

http://www.vulnerablesite.com/login.aspx?redirectURL=evilsite.com

Doporučení

  1. Jednoduše se vyhněte použití přesměrování a přeposílání v aplikaci. Pokud je použit, nezahrnujte při výpočtu cíle použití uživatelských parametrů.
  2. Pokud nelze zabránit cílovým parametrům, ujistěte se, že zadaná hodnota je platná a autorizovaná pro uživatele.

Do tohoto článku přispívá Prasanthi Eati