W tegorocznej liście, opublikowanej przez CWE/SANS, królują błędy, które można łatwo znaleźć i jeszcze łatwiej wykorzystać. Są niebezpieczne, gdyż często umożliwiają napastnikom przejęcie kontroli nad oprogramowaniem, kradzież lub modyfikację danych lub ataki odmowy obsługi, czy też wyłączają daną aplikację z pracy. Lista powstała we współpracy między instytutem SANS, organizacją MITRE oraz wieloma amerykańskimi i europejskimi ekspertami do spraw bezpieczeństwa oprogramowania. Prezentujemy ją w kolejności od najmniej do najbardziej groźnych. Podajemy też sposoby ustrzeżenia się przed tymi błędami.

25. Wyścig (race condition)

Ten błąd jest spowodowany współzależnością między fragmentami kodu, gdy wiele procesów wykonuje operacje na tych samych danych, a wynik zależy od kolejności wykonania obliczeń. Błąd ten można wykorzystać do przejęcia kontroli nad innym wątkiem, do naruszenia spójności danych i ataku odmowy obsługi. Należy wykorzystywać architekturę i implementację, która jest bezpieczna przy programowaniu wielowątkowym (thread safe), minimalizując użycie zasobów współdzielonych.

24. Używanie złych algorytmów kryptograficznych

Przy szyfrowaniu wrażliwych danych, twórcy oprogramowania często próbują tworzyć własne algorytmy - jest to bardzo poważny problem, gdyż algorytm taki prawie na pewno będzie słabszy od standardów w tej dziedzinie. Niejednokrotnie używa się zbyt słabych lub złamanych algorytmów, do których od dawna są narzędzia przeznaczone do szybkiego łamania. Zamiast nich należy wykorzystać uznane standardy (algorytm, zarządzanie kluczami, gotowe biblioteki). Należy też okresowo sprawdzać, czy nie są one już przestarzałe.

23. Otwarte przekierowania

Hiperłącza są częścią Internetu i wprowadzane są do wielu aplikacji. Brak kontroli łączy można wykorzystać na przykład do ataków polegających na przekierowaniu do fałszywej strony (phishing, eksploitowanie błędu przeglądarki do instalacji trojana). Przy przekierowaniach na adres dostarczany z zewnątrz (na przykład w URL strony jako parametr) należy sprawdzać każdy parametr i korzystać z ustalonej białej listy adresów lub parametryzować adresy wewnątrz aplikacji.

22. Nielimitowana alokacja zasobów

Brak kontroli nad ilością zasobów, które może wykorzystać dany program, może prowadzić do ataku odmowy obsługi, gdy jedna aplikacja zużywa niemal wszystkie dostępne zasoby (pamięć, CPU, przestrzeń dyskowa). Taki atak może też umożliwić przeprowadzenie innych ataków, dlatego należy wprowadzić twarde limity alokacji zasobów (na przykład per user) oraz mechanizm elastycznego i bezpiecznego ich przydzielania.

21. Złe uprawnienia do krytycznych zasobów

Błąd polegający na udostępnieniu obiektów bez żadnego sensownego uwierzytelnienia sprawia, że dane są dostępne dla każdego, kto tylko ich zażąda. Należy unikać przyznawania jakichkolwiek uprawnień dla "całego świata", wprowadzając model przyznawania dostępu dla uwierzytelnionych użytkowników.

20. Pobieranie niesprawdzonego kodu

Przy pobieraniu i wykonaniu kodu, przeważnie ufa się stronie udostępniającej oprogramowanie. Z tej własności można skorzystać, włamując się na stronę, podstawiając przekierowanie do jej imitacji, stosując podszywanie DNS lub zatrucie jego cache, a nawet modyfikując w locie już pobierany kod. Scenariusz ten może być wykorzystany także przy aktualizacji oprogramowania.

Należy odpytać DNS w obie strony, stosować mechanizmy kryptograficzne zapewniające autentyczność i integralność pobieranego pliku.