20 najważniejszych luk w zabezpieczeniach OWASP i jak je naprawić Infografika
Open Web Application Security Project (OWASP) to organizacja o ugruntowanej pozycji, której celem jest poprawa bezpieczeństwa aplikacji internetowych poprzez tworzenie narzędzi, dokumentacji i informacji — te ostatnie obejmują corocznie 10 największych luk w zabezpieczeniach aplikacji internetowych. Poniżej znajduje się kompilacja najnowszych krytycznych luk w zabezpieczeniach, które pojawiły się na listach, a także informacje o tym, jak zaradzić każdej z nich.
Najważniejsze luki w zabezpieczeniach OWASP
1. SQL Wtrysk
Opis: Luki w zabezpieczeniach polegające na wstrzyknięciu kodu SQL występują, gdy dane są wprowadzane do aplikacji z niezaufanego źródła i są używane do dynamicznego konstruowania zapytania SQL. Wstrzyknięcie kodu SQL może spowodować utratę lub uszkodzenie danych, brak odpowiedzialności lub odmowę dostępu. Wstrzyknięcie może czasami prowadzić do całkowitego przejęcia hosta.
Poprawka/zalecenie: Do filtrowania niebezpiecznych znaków z danych wejściowych użytkownika należy użyć prawidłowej walidacji danych wejściowych po stronie serwera. Dodatkowo, korzystanie z przygotowanych instrukcji/sparametryzowanych procedur składowanych może zapewnić, że dane wejściowe są przetwarzane jako tekst.
Przykładowy fragment kodu (walidacja danych wejściowych):
Ciąg danych wejściowych=request.getParameter ("SeqNo");
String characterPattern="[0-9a-zA-Z]";
Jeśli (! dane wejściowe pasują do (characterPattern))
{
out.println ("Nieprawidłowe dane wejściowe ");
}
2. Skrypty między witrynami (XSS)
Opis: W takich przypadkach w aplikacji są przetwarzane nieprawidłowe dane kontrolowane przez użytkownika, co prowadzi do wykonywania złośliwych skryptów. Luki w zabezpieczeniach XSS mogą umożliwić atakującym przechwycenie informacji o użytkowniku i/lub wstrzyknięcie kodu HTML do podatnej na ataki aplikacji internetowej.
Poprawka/zalecenie: Prawidłowa walidacja danych wejściowych i kodowanie danych wyjściowych po stronie serwera powinny być stosowane zarówno po stronie klienta, jak i serwera, aby zapobiec wykonywaniu skryptów. Niebezpieczne znaki powinny być odfiltrowywane z danych wprowadzanych przez użytkownika [np.: | , & , ; $, % , @ , ' , " , \' , \" , <> ,() , + , CR (Powrót karetki, ASCII 0x0d) , LF (Znak nowego wiersza, ASCII 0x0a), (znak przecinka) ,\].
Przykładowy fragment kodu (technika kodowania):
<input type="text" maxlength="30" name="ecsChangePwdForm" size="40" readonly="true" value='<%=ESAPI.encoder().encodeForHTML(request.getParameter("userName"))%>'/>
3. Wyciek informacji
Opis: aplikacja internetowa może ujawniać dane systemowe lub informacje debugowania, zgłaszając wyjątki lub generując komunikaty o błędach. Wyciek danych systemowych lub debugowanie informacji za pośrednictwem strumienia wyjściowego lub funkcji rejestrowania może umożliwić atakującym zdobycie wiedzy o aplikacji i przeprowadzenie na nią wyspecjalizowanych ataków.
Poprawka/Zalecenie:
- Upewnij się, że kody błędów i inne komunikaty widoczne dla użytkowników końcowych nie zawierają poufnych informacji.
- Oczyść wszystkie wiadomości, usuwając wszelkie niepotrzebne poufne informacje.
- Upewnij się, że debugowanie, komunikaty o błędach i wyjątki nie są widoczne.
Przykładowy fragment kodu:
catch (Wyjątek e)
{
if(log.isDebugEnabled()) log.debug (kontekst, ZDARZENIA. ADHOC,
"Przechwycono wyjątek InvalidGSMException -- "
+ e.toString() );
}
4. Wtrysk ramy
Opis: nieprawidłowa walidacja parametrów wejściowych może prowadzić do wstrzykiwania ramek przez osoby atakujące w celu naruszenia poufnych informacji użytkownika. Wstrzykiwanie ramek jest powszechną metodą stosowaną w atakach phishingowych
Poprawka/Zalecenie: Użyj białej listy akceptowalnych danych wejściowych, która jest ściśle zgodna z bezpiecznymi specyfikacjami
Przykładowy fragment kodu:
Ciąg danych wejściowych=request.getParameter ("dane wejściowe");
Wzorzec znaku ciągu="[./a-zA-Z0-9?"="&]";
If (! input. pasuje (wzorzec znaku))
{
out.println ("Nieprawidłowe dane wejściowe ");
}
5. Przekierowanie adresu URL
Opis: mimo że aplikacje internetowe często przekierowują użytkowników do innych witryn lub stron, osoby atakujące często wykorzystują aplikacje zawierające luki bez odpowiedniej weryfikacji przekierowań. Może to prowadzić do złośliwego przekierowania na niezaufaną stronę.
Poprawka/zalecenie: Użyj białej listy akceptowalnych danych wejściowych, które są ściśle zgodne ze specyfikacjami i dla zatwierdzonych adresów URL lub domen używanych do przekierowania.
Przykładowy fragment kodu:
Ciąg danych wejściowych=request.getParameter ("dane wejściowe");
Wzorzec znaku ciągu="[./a-zA-Z0-9?"="&]";
If (! input. pasuje (wzorzec znaku))
{
out.println ("Nieprawidłowe dane wejściowe ");
}
6. Brakujący limit czasu sesji
Opis: osoby atakujące mogą uzyskać nieautoryzowany dostęp do aplikacji internetowych, jeśli limity czasu braku aktywności nie są poprawnie skonfigurowane.
Poprawka/zalecenie: Upewnij się, że funkcja limitu czasu jest prawidłowo skonfigurowana i działa.
Przykładowy fragment kodu:
<webapp>
<session-config>
<session-timeout>15</session-timeout>
</session-config>
</webapp>
7. Poufne informacje przekazywane jako zwykły tekst w GET URL
Opis: Aplikacje sieci Web korzystające z żądań GET do przekazywania informacji za pośrednictwem ciągu zapytania robią to w postaci zwykłego tekstu. Dzięki temu wszelkie poufne informacje przekazane za pomocą GET są widoczne w historii przeglądarki i logach serwera.
Poprawka/zalecenie: Użycie metody POST zamiast GET gwarantuje, że poufne informacje nie są widoczne w parametrach ciągu zapytania.
8. Pliki cookie z identyfikatorem sesji nie są oznaczone jako bezpieczne
Opis: Jeśli pliki cookie z identyfikatorem sesji dla aplikacji internetowej są oznaczone jako bezpieczne, przeglądarka nie będzie ich przesyłać za pośrednictwem niezaszyfrowanego żądania HTTP. Nieoznaczenie ich jako takich pozwala na dostęp do plików cookie i wyświetlanie ich przez atakujących w postaci zwykłego tekstu.
Poprawka/zalecenie: Upewnij się, że poufne pliki cookie są ustawione z atrybutem "secure", aby zapewnić, że zawsze są przesyłane przez HTTPS.
Przykładowy fragment kodu:
Plik cookie cookie=nowy plik cookie("myCookieName");
cookie.secure(prawda);
9. Skrypty krzyżowe (XFS)
Opis: exploity XFS są używane w połączeniu z XSS w celu przekierowania przeglądarek na stronę internetową kontrolowaną przez osoby atakujące. W takich przypadkach złośliwa strona ładuje stronę innej firmy w ramce HTML. Skrypty na stronie atakującego są następnie w stanie wykraść dane ze strony innej firmy, bez wiedzy użytkownika.
>Poprawka/Zalecenie: Właściwa walidacja powinna być używana do odfiltrowywania wszelkich złośliwych danych wejściowych, które mogą zostać wstrzyknięte do ramki i wykonane w przeglądarce użytkownika, w kontekście ramki strony głównej.
Przykładowy fragment kodu:
if (top == self) }
document.documentElement.style.display='blok';
}
else {
top.location=self.location;
}
10. Poufne informacje wyświetlane jako czysty tekst na ekranie
Opis: informacje poufne (np. hasła, informacje o karcie kredytowej) nie powinny być wyświetlane na ekranie w postaci zwykłego tekstu. Oprócz ataków typu shoulder surfing, poufne dane przechowywane w postaci zwykłego tekstu często trafiają do pamięci podręcznej po stronie klienta, która może zostać łatwo skradziona, jeśli zostanie wykryta.
Poprawka/zalecenie: Poufne informacje powinny być maskowane, aby nie były widoczne dla użytkowników
Przykładowy fragment kodu:
<asp:TextBox ID="txtSSN" TabIndex="6" runat="serwer" Width="206px" MaxLength="11" TextMode="Hasło"></asp:TextBox>
11. Poufne informacje w pamięci podręcznej
Opis: przeglądarki zazwyczaj przechowują w swoich pamięciach podręcznych kopię żądanych elementów: stron internetowych, obrazów i innych elementów. Tworzy to lukę w zabezpieczeniach aplikacji, które przechowują, przetwarzają i wyświetlają poufne dane, ponieważ osoby atakujące, które uzyskują dostęp do pamięci podręcznej przeglądarki użytkownika, mają dostęp do wszelkich zawartych w niej informacji.
Poprawka/Zalecenie: Należy używać nagłówków HTTP Cache-Control, takich jak Cache-Control: no-cache, no-store Pragma: no-cache.
Przykładowy fragment kodu:
<meta http-equiv="Cache-Control" content="no-cache, no-store, must-revalidate" />
<meta http-equiv="Pragma" content="no-cache" />
<meta http-equiv="Expires" content="0" />
12. Niewystarczająca siła szyfrowania
Opis: aplikacje używające do szyfrowania kluczy o rozmiarze mniejszym niż 1024 bity mogą być wykorzystywane za pomocą ataków siłowych.
Poprawka/zalecenie: Użyj klucza bitowego o wyższym rozmiarze, 2048 bitów lub większym.
13. Wtrysk CRLF (powrót wózka i podawanie linii)
Opis: luki w zabezpieczeniach CRLF występują, gdy złośliwa zawartość jest wstawiana do nagłówków odpowiedzi HTTP przeglądarki po tym, jak niczego niepodejrzewający użytkownik kliknie złośliwy link. Hakerzy zazwyczaj wstrzykują złośliwy kod do przeglądarki użytkownika za pośrednictwem aplikacji internetowej/serwera, co utrudnia przypadkowe wykrycie.
Poprawka/Zalecenie: Zakoduj wszystkie ciągi znaków w adresie URL przed transmisją. Upewnij się, że metaznaki powłoki i terminatory poleceń (np. ; CR lub LF) są odfiltrowywane z danych użytkownika przed ich przesłaniem.
Przykładowy fragment kodu:
Ciąg author=request.getParameter(AUTHOR_PARAM);
Plik cookie=nowy plik cookie("author", ESAPI.encoder().encodeForURL(author));
cookie.setMaxAge(wygaśnięcie pliku cookie);
response.addCookie(plik cookie);
14. Naruszenie granic zaufania
Opis: aplikacje internetowe często błędnie mieszają zaufane i niezaufane dane w tych samych strukturach danych, co prowadzi do incydentów, w których niezweryfikowane/niefiltrowane dane są zaufane/używane.
Poprawka/zalecenie: Prawidłowa walidacja danych wejściowych i kodowanie danych wyjściowych powinny być używane na danych przed przeniesieniem ich do zaufanych granic.
Przykładowy fragment kodu:
Ciąg sessionPolicyId=request.getParameter("id");
if(sessionPolicyId.matches("[0-9a-zA-Z_]+") {
session.setAttribute("sessionPolicyId",sessionPolicyId);
}
15. Przechodzenie przez katalog
Opis: akceptując dane wejściowe użytkownika, które kontrolują lub wpływają na ścieżki/nazwy plików używane w operacjach systemu plików, aplikacje internetowe zawierające luki mogą umożliwić atakującym dostęp do chronionych zasobów systemowych lub ich modyfikowanie.
Poprawka/Zalecenie: Biała lista akceptowalnych danych wejściowych, która jest ściśle zgodna ze specyfikacjami, może zapobiec exploitom polegającym na przechodzeniu przez katalogi.
Przykładowy fragment kodu:
Ciąg danych wejściowych=request.getParameter("nazwa_pliku");
if (ESAPI.validator().isValidFileName(Kontekst ciągu, Ciąg wejściowy, wartość logiczna allowNull))
{
Plik plik=nowy Plik(wejście);
}
16. Utrwalenie sesji
Opis: w takich przypadkach aplikacje internetowe zawierające luki uwierzytelniają użytkowników bez uprzedniego niszczenia istniejących sesji skojarzonych z tymi użytkownikami. Dzięki temu osoby atakujące mogą uzyskać dostęp do kont użytkowników poprzez przejęcie ich aktywnych sesji.
Poprawka/zalecenie: Zniszcz wszystkie istniejące identyfikatory sesji przed autoryzacją nowej sesji użytkownika.
Przykładowy fragment kodu:
session.invalidate();
session=request.getSession(prawda);
17. Użycie ryzykownego algorytmu kryptograficznego
Opis: Aplikacje internetowe korzystające z niestandardowych algorytmów są słabo zaszyfrowane, co pozwala hakerom stosunkowo łatwo uzyskać dostęp przy użyciu metod brute force.
Poprawka/zalecenie: Podczas przechowywania lub przesyłania poufnych danych używaj silnych, aktualnych algorytmów kryptograficznych do szyfrowania tych danych przed wysłaniem/przechowywaniem.
Przykładowy fragment kodu:
MessageDigest md=MessageDigest.getInstance("SHA-256");
FileInputStream fis=new FileInputStream("c:\\loging.log");
byte[] dataBytes=nowy bajt[1024];
int nread=0;
while ((nread=fis.read(dataBytes)) != -1) {
md.update(dataBytes, 0, nread);
};
bajt[] mdbytes=md.digest();
18. Zarządzanie danymi uwierzytelniającymi
Opis: przechowywanie haseł w postaci zwykłego tekstu może łatwo doprowadzić do naruszenia bezpieczeństwa systemu, zwłaszcza jeśli w grę wchodzą pliki konfiguracyjne/źródłowe.
Poprawka/Zalecenie: Unikaj przechowywania haseł w łatwo dostępnych miejscach. Używaj skrótów kryptograficznych jako alternatywy dla zwykłego tekstu.
19. SQL hibernacja iniekcyjna
Opis: Hibernate to popularna struktura ORM dla języka Java — w związku z tym udostępnia kilka metod, które umożliwiają wykonywanie natywnych zapytań SQL. Osoby atakujące często wykorzystują hibernację do wykonywania złośliwych, dynamicznie tworzonych instrukcji SQL.
Poprawka/Zalecenie: Właściwa walidacja danych wejściowych po stronie serwera może służyć jako podstawowa ochrona przed niebezpiecznymi znakami. Przygotowane instrukcje/sparametryzowane procedury składowane mogą być używane do renderowania danych jako tekstu przed przetworzeniem lub zapisaniem.
Przykładowy fragment kodu:
Zapytanie hqlQuery=session.createQuery("wybierz produkt z Zamówień jako zamówienia, gdzie orders.id =?");
Lista wyników=hqlQuery.setString(0, "123-ADB-567-QTWYTFDL").list();
20. Niewłaściwe wyłączanie lub zwalnianie zasobów
Opis: Nieprawidłowe zamykanie zasobów występuje, gdy aplikacja sieci Web nie może zwolnić zasobu systemowego przed udostępnieniem go do ponownego użycia. Następnie można przeprowadzić atak typu "odmowa usługi" (Dos), wyczerpując pulę zasobów serwera.
Poprawka/Zalecenie: Wszystkie utworzone lub przydzielone zasoby muszą zostać poprawnie zwolnione po użyciu.
Przykładowy fragment kodu:
try {
Connection con=DriverManager.getConnection(some_connection_string);
}
catch ( Wyjątek e ) {
log( e );
}
finally {
if( stmt != null )
stmt.close();
con.close() }
Krótko mówiąc, 20 elementów wymienionych powyżej to najczęściej spotykane luki w zabezpieczeniach aplikacji internetowych według OWASP. Chociaż wiele z nich można naprawić za pomocą bezpieczniejszych praktyk kodowania, niektóre mogą wymagać zidentyfikowania odpowiednich poprawek specyficznych dla dostawcy. Ostatecznie zależy to od tego, jakie konkretne technologie, struktury i pakiety są używane w Twojej aplikacji internetowej.
Potrzebujesz łatwiejszego sposobu wykrywania luk w zabezpieczeniach w swojej aplikacji internetowej? Oparty na testach opartych na zasadach, UpGuard może automatycznie skanować i monitorować aplikację internetową pod kątem błędnych konfiguracji i luk w zabezpieczeniach.
Infografika
