25 najpoważniejszych błędów programistów
Przedstawiamy listę 25 najważniejszych błędów programistycznych, które według organizacji MITRE przyczyniają się do powszechnej podatności oprogramowania na ataki.
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.
Oceń artykuł
Komentarze (5)
Ja (trochę) widać, środowisko programistyczne może oszczędzać (lub marnować) bardzo wiele czasu i zdrowia bardzo wielu programistom - a ich szefom pieniędzy i klientów. Dlatego taką przewagę ma VS ze swoim otoczeniem mimo, że licencje kosztują ale znacznie mniej niż zyski względem konkurentków.
własne algorytmy szyfrujące tym się głównie różnią od tzw. "standardów", ze utrudniają prace rozmaitym szpiclom całego świata, wszystkie AES, DES-y, itp. są znane z tego, że posiadają luki opisane w tajnych specyfikacjach służbowych, to co napisał tu autor myli się ZDECYDOWANIE
Prawdopodobnie literówka. Chodzi o to by wreszcie się wymigrowali z PHP 4. Dla mnie detal bo i tak każdy rozsądny deweloper wie z której się trzeba migrować i dlaczego.
No wlasnie. Jak pozostale rady sa na tym poziomie to ja dziekuje za taki artykul.
PHP6? a ja myślałem, że to jakaś beta jest w tej chwili ;) może spuścicie z tonu do poziomu 5.3?
Najpopularniejsze
- Pierwsze w Polsce testy transmisji danych z...
- Magdalena Gaj została Przewodniczącą Rady...
- Asseco wątpi w obiektywny wybór dostawcy w...
- Raport Państwo 2.0, czyli nowa wizja...
- Sygnity: wezwanie Asseco i sezonowość...
- Ogromna liczba komputerów Mac wciąż...
- Nasza Klasa uruchomiła inkubator...
- Google prezentuje okulary z Augmented Reality
- Oracle daje klientom bezpłatny system do...
- CBA kontroluje przetargi związane z CEPiK
Rekomendacje
Serwisy IDG - Warunki obsługi - Kontakt - Redakcja - Regulamin - O nas - Polityka prywatności - Serwis zgodny z ASME
Reklama - Licencjonowanie treści - Prenumerata: Computerworld, Networld, PC World
Computerworld Polska i Computerworld Polska online są znakami towarowymi IDG Poland SA.
© Copyright 2012 International Data Group Poland S.A. 04-204 Warszawa ul. Jordanowska 12 tel.(+4822)321-78-00 fax(+4822)321-78-88






