Denial of Service (DoS) útoků je zaměřena na to, aby nedostupný zdroj (místo, aplikace, server) za účelem, že byl navržen. Existuje mnoho způsobů, jak službu k dispozici pro oprávněné uživatele tím, že manipuluje síťové pakety, programování, logické, nebo zdroje manipulační chyby, mezi ostatními. Pokud služba přijímá velmi velký počet žádostí, může zastavit poskytování služeb oprávněným uživatelům. Stejným způsobem, může být služba zastaví v případě, programovací chyba je využíván, nebo tak, jak je služba zpracovává prostředky používané něj.
Někdy může útočník aplikovat a spustit libovolný kód při provádění útok DoS, aby se přístup k důležité informace nebo provádět příkazy na serveru. Denial-of-service útoků významně zhoršují kvalitu služeb, kterou zažívají oprávněných uživatelů. Zavádí velké odezvy zpoždění, nadměrné ztráty a servisní přerušení, což vede k přímým dopadem na dostupnosti.
TBD
Následující DoS techniky a příklady byly získány z testování OWASP Guide v2.
Pokud uživatelé mohou dodávat, přímo nebo nepřímo, na hodnotu, která bude určit, kolik z objektu vytvořit na aplikačním serveru, a pokud server nevynucuje pevný horní limit na této hodnotě, je možné způsobit prostředí spustit z dostupné paměti. Server může začít přidělit požadovaný počet specifikovaných předmětů, ale pokud je to mimořádně velké množství, může to způsobit vážné problémy na serveru, případně vyplní jeho celou dostupnou paměť a kazit jeho výkon.
Následuje jednoduchý příklad zranitelných kódu v jazyce Java:
String TotalObjects = request.getParameter ("numberofobjects"); int NumOfObjects = Integer.parseInt (TotalObjects); ComplexObject [] = new anArray ComplexObject [NumOfObjects]; / / špatně!
Podobně jako v předchozím problému uživatel zadal objektu přidělení, v případě, že uživatel může přímo nebo nepřímo přiřadit hodnotu, která se používá jako čítač ve smyčce funkce, může to způsobit problémy s výkonem na serveru.
Následující příklad kódu v jazyce Java ohrožených:
public class MyServlet rozšiřuje ActionServlet { public void doPost (HttpServletRequest požadavek, HttpServletResponse odpověď) hodí ServletException, IOException { . . . String [] hodnoty = request.getParameterValues ("CheckBoxField"); / / Procesní údaje jsou bez délka kontroly na rozumné míře - špatné! for (int i = 0; i <values.length; i + +) { / / Spousta logiky zpracovat žádost } . . . } . . . }
Jak je vidět na tomto jednoduchém příkladu má uživatel kontrolu nad smyčky čítače. Pokud kód uvnitř smyčky je velmi náročné z hlediska zdrojů, a útočník ji nutí být provedeny velmi vysoký počet opakování, mohlo by to snížit výkon serveru při zacházení s další žádostí, což je stav DoS.
Péče musí být vzata ukládat příliš mnoho dat v objektu relace uživatele.Ukládání příliš mnoho informací v relaci, jako je například velké množství dat získaných z databáze, může způsobit odmítnutí služby otázek. Tento problém se zhoršuje, pokud data relace je sledována také před přihlašovací údaje, jako uživatel může spustit útok bez nutnosti účtu.
První DoS případ zvážit zahrnuje ověřování systému cílové aplikaci. Společná obrana proti brute-force objev uživatelských hesel je zamknout účet z provozu po tři až pět neúspěšných pokusů pro přihlášení. To znamená, že i když oprávněný uživatel měl poskytovat své platné heslo, by nemohli přihlásit do systému, dokud jejich účet bylo odemčeno. Tento obranný mechanismus může být obrácená do útoku DoS proti žádosti, pokud existuje způsob, jak předpovědět platné přihlašovací účty.
Poznámka, tam je obchodní vs bezpečnostní rovnováhy, které musí být dosaženo na základě zvláštních okolnostech dané aplikaci. K dispozici jsou výhody a nevýhody zamykání účtů, k zákazníkům mají možnost vybrat si své vlastní názvy účtů, s pomocí systémů, jako je CAPTCHA, a podobně. Každý podnik se bude muset vyrovnat tato rizika a výhody, ale ne všechny podrobnosti o těchto rozhodnutích jsou pokryty zde.
Pokud dojde k chybě v aplikaci, která zabraňuje uvolňování v průběhu používání zdrojů, může se stát k dispozici pro další použití. Možné příklady zahrnují:
Následující příklad kódu v jazyce Java ohrožených. V příkladu, by oba připojení a CallableStatement být uzavřen v bloku finally.
public class AccountDAO { ...... public void CreateAccount (AccountInfo acct) hodí AcctCreationException { ...... try { Připojení conn = DAOFactory.getConnection (); CallableStatement calStmt = conn.prepareCall (...); ...... calStmt.executeUpdate (); calStmt.close (); Conn.Close (); } Catch (java.sql.SQLException e) { házet AcctCreationException (...); } } }
Každý jazyk, kde developer má přímou odpovědnost za řízení alokace paměti, nejvíce pozoruhodně C & C + +, má potenciál pro buffer overflow . Zatímco nejzávažnější riziko vztahující se k přetečení vyrovnávací paměti, je schopnost spustit libovolný kód na serveru, První riziko pochází z odmítnutí služby, které mohou nastat v případě, že dojde k chybě aplikace.
Následuje zjednodušený příklad zranitelných kódu v C:
void overflow (char * str) { char buffer [10]; strcpy (buffer, str); / / Dangerous! } int main () { char * str = "Toto je řetězec, který je větší než vyrovnávací paměti 10"; přetečení (str); }
Pokud tento příklad kódu byly provedeny, by to způsobit segmentation fault a dump jádro. Důvodem je, že strcpy se pokusí zkopírovat 53 znaků do pole 10 prvků pouze přepsání přilehlé paměťových míst. Zatímco v tomto příkladu shora je velmi jednoduchý případ, skutečností je, že ve webové aplikace může být místa, kde je vstup uživatele není dostatečně ověřena jeho délky, aby byl tento druh útoku možné.