12:17
19/2/2010

Lista 25 najgroźniejszych błędów jakie mogą popełnić programiści została stworzona przez 30 organizacji z całego świata. Ciekawostką w tym roku jest sugestia, żeby umowach z programistami umieszczać zapis obarczający ich winą za ew. błędy znalezione w aplikacjach.

Webdziury u góry

Co było do przewidzenia, król błędów o imieniu Buffer Overflow jest dopiero na trzecim miejscu. Prześcignęły go “prostsze” XSS-y i SQL injections. Ktoś jeszcze twierdzi, że “programowanie na Weba” to tylko chwilowa moda?

  1. Cross-site Scripting (XSS)
  2. SQL Injection
  3. Classic Buffer Overflow
  4. Cross-Site Request Forgery (CSRF)
  5. Improper Access Control (Authorization)
  6. Reliance on Untrusted Inputs in a Security Decision
  7. Path Traversal
  8. Unrestricted Upload of File with Dangerous Type
  9. OS Command Injection
  10. Missing Encryption of Sensitive Data
  11. Use of Hard-coded Credentials
  12. Buffer Access with Incorrect Length Value
  13. PHP File Inclusion
  14. Improper Validation of Array Index
  15. Improper Check for Unusual or Exceptional Conditions
  16. Information Exposure Through an Error Message
  17. Integer Overflow or Wraparound
  18. Incorrect Calculation of Buffer Size
  19. Missing Authentication for Critical Function
  20. Download of Code Without Integrity Check
  21. Incorrect Permission Assignment for Critical Resource
  22. Allocation of Resources Without Limits or Throttling
  23. URL Redirection to Untrusted Site (‘Open Redirect’)
  24. Use of a Broken or Risky Cryptographic Algorithm
  25. Race Condition

Ranking błędów dostępny jest na stronie http://cwe.mitre.org/top25/#Listing.

Mamy dość luźne podejście do wszelkiego rodzaju statystyk i raportów, zwłaszcza tych, które traktują o bezpieczeństwie a zostały przygotowane w formacie PDF będącym wektorem ataku w przypadku 9/10 incydentów z poprzedniego roku… ;-)

Dla porównania rzućcie okiem na listę OWASP-u opisującą błędy w webaplikacjach.

Odpowiedzialność programisty

Sugerowane w raporcie obarczenie programisty winą za błędy ma sens i generalnie z chęcią będziemy popierać wszelkie tego typu działania (niech się w końcu nauczą pisać bezpiecznie, a co), mimo, że w dłuższej perspektywnie poprowadzi to do pozbawienia nas pracy ;-) Nie zdziwcie się, jeśli proponując taki zapis w umowie, programista odpowie, że projekt przedłuży się o kilka miesięcy, a jego stawka godzinowa wzrasta o 200%…

P.S. Kto potrafi popełnić wszystkie 25 błędów w jednej linii kodu? Postujcie swoje jednolinijkowce w komentarzach :-)


Dowiedz się, jak zabezpieczyć swoje dane i pieniądze przed cyberprzestępcami. Wpadnij na nasz kultowy ~3 godzinny wykład pt. "Jak nie dać się zhackować?" i poznaj kilkadziesiąt praktycznych i przede wszystkim prostych do zastosowania porad, które skutecznie podniosą Twoje bezpieczeństwo i pomogą ochronić przed atakami Twoich najbliższych. Uczestnicy tego wykładu oceniają go na: 9,34/10!

Na ten wykład powinien przyjść każdy, kto korzysta z internetu na smartfonie lub komputerze, prywatnie albo służbowo. Wykład prowadzimy prostym językiem, wiec zrozumie go każdy, także osoby spoza branży IT. Dlatego na wykład możesz spokojnie przyjść ze swoimi rodzicami lub mniej technicznymih znajomych. W najbliższych tygodniach będziemy w poniższych miastach:

Zobacz pełen opis wykładu klikając tutaj lub kup bilet na wykład klikając tu.

22 komentarzy

Dodaj komentarz
  1. To nie format PDF był obiektem ataków w zeszłym roku, a oprogramowanie Adobe do jego odczytywania. Wszystkie inne programy do odczytywania PDF, a jest ich sporo, były bezpieczne. To, że Adobe pisze kiepskie programy, nie oznacza, że mamy rezygnować z bardzo dobrego standardu, jakim jest PDF i jaki możemy odczytać tabunem innych, także darmowych programów.

  2. @Gregor:
    Wektorem, a nie obiektem.

  3. “P.S. Kto potrafi popełnić wszystkie 25 błędów w jednej linii kodu? Postujcie swoje jednolinijkowce w komentarzach :-)”

    To musiała by być jedna zajebiście długa linijka kodu ;]

  4. Piotrek to jednak bardziej się przykłada do tych wpisów :).

  5. To teraz skanujemy każdą linijkę naszego kodu pod kątem tych błędów i produkujemy jedną klasę na tydzień zamiast na godzinę, ale za to jak bezpieczną. ;]

  6. @hcsl: ?

  7. “Lista 15 najgroźniejszych”
    bug :P

  8. Oto linia kodu, która spowoduje te wszystkie błędy na raz:

    “Zwalniam Cię. Do końca dnia dokończ projekt (jak nie to nie ma wypłaty) – użyj mojego konta (szef/qwerty) – Twoje juz jest nieaktywne”

  9. To ciekawe ile jest w kodzie niebezpiecznika?

  10. @Piotr Konieczny: Chodziło mi o to, że bardziej się przykładasz do postów, niż pan vi.curry.

  11. hcsl: Umiem czytać ;) Mnie chodziło bardziej o to, żebyś napisał w czym konkretnie vicurry się nie przyłożył ;)

  12. @Piotr Konieczny: Wydaje mi się, że vicurry bardziej powierzchownie traktuje dany temat i dysponuje niższa biegłością w przelewaniu swych myśli na tekst, ale być może to tylko moje odczucie.

  13. @hcsl: dzięki za podzielenie się refleksją. Wraz z igH rozkazaliśmy vicurremu biegać wyżej.

  14. Nie ma za co ;).

  15. Pozwolę sobie trochę zaflamić, ale dlaczego wszystkie z tych błędów dotyczą tego śmiesznego języka jakim jest ADHD, ups… przepraszam PHP.

    Większość przytoczonych podatności odnosi się w dużej mierze do kodu php. Ciężko mi sobie wyobrazić SQL Injection w Javie lub C#, szczególnie gdy użyjemy ORMów. Jeszcze ciężej wstrzykiwanie kodu języka (numer 13). Jednak języki kompilowane są znacznie bardziej odporne na wszelkiej maści ataki z wykorzystaniem struktur języka.

    Co do błędów w konfiguracji to zdarzają się wszędzie.

    Pozdrawiam
    Koziołek

  16. @Koziołek: PHP ma bardzo niską barierę wejścia. W sieci znajdziesz multum FAQ, kursów php, etc. rojących się od podstawowych błędów. Najczęściej ataki “na PHP” są możliwe bo:

    1. ktoś potrzebuje coś zakodować
    2. nie wie jak, więc googla
    3. znajduje fragment kodu w jakimś kiepskim poradniku
    4. przekleja do swojego projektu
    5. …i tam zostawia, bo kod działa (w sensie, robi to co ma robić — security nie ma znaczenia)

  17. @Koziołek: nie dotyczą wcale języka PHP, ale programistów, którzy jeszcze nie wiedzą jak się poprawnie zabezpiecza skrypty. Myślisz, że w Javie czy C# nie da się zrobić SQL Injection? Ktoś, kto nie orientuje się w możliwościach ataku nie będzie nawet świadomy tego, że ma dziurawą stronkę, nieważne w czym siedzi. Większość błędnego kodu odnosi się do “osiągnięć” początkujących “koderów”, a to, że zwykle wybierają oni PHP, bo jest łatwy nie świadczy o słabości samego języka / platformy.

  18. Dokładnie wiele widziałem już stronek opartych o PHP przy których autor skupiał się jedynie na ‘ma to działać’ nie patrząc na to że każdy mógł zmodyfikować ciasteczko czy przesłać dane metodą POST pomijając formularz, który miał pełnić nie lada barierę przed ‘Hakerami’ :). w ogóle mam wrażenie, że ‘programiści’ np. PHP jak się tak sami nazywają (to odnosnie tych co wspomnialem wyzej) nie zwracają uwagi na takie aspekty jak Security czy wydajność już nie mówiąc o jakości i elastyczności kodu. Oczywiście nie mówię o wszystkich ale ze sporą liczbą takich już się spotkałem.

    Osobiście też używam PHP i aktualnie piszę własnego CMSa, bo te darmowe jakoś do mnie nie przemawiają ;) Wiem z własnego doświadczenia że zabezpieczyć stronę, nie jest takie proste albowiem nawet jak się pamięta, żeby nie popełnić jakiejś głupoty w kodzie np. nie przefiltrować $_POST, czy tam $_GET to jeszcze trzeba brać pod uwagę wiele innych aspektów takich jak konfiguracja serwera, łatać $_SESSION czy pisać własne itp. Więc luk może być całe mnóstwo a gdzie jeszcze wydajność ? :]
    Reasumując pisanie porządnych nawet prostych stron w PHP nie jest takie proste, mimo że (mi przynajmniej) w PHP się bardzo wygodnie i przyjemnie pisze, chociaż piszę/pisałem już w C++, Pascalu czy Pythonie.

  19. Myślę, że powyższy komentarz pozwoli wielu osobom zrozumieć, że profesjonalne wykorzystanie PHP do pisania aplikacji internetowych nie jest wcale nieporozumieniem i że w nim także trzeba się solidnie napracować oraz mieć dużą wiedzę, żeby otrzymać porządny efekt.

  20. Panie Tomku, zrobienie SQL Injection w Javie jest praktycznie niewykonalne. Wynika to z natury tego typu ataków (zazwyczaj modyfikują querystringa) i sposobu obsługi obiektów String w Javie. Narzędzia ORM (Dostawcy JPA/Hibernate) zabezpieczają dodatkowo całość tworząc zapytania z wykorzystaniem parametrów. W przypadku C# to dokładnie nie wiem (ograniczyłem się tu do NHibernate).
    @ShutDown, zgadzam się z stwierdzeniem, ze pisanie w php jest stosunkowo proste co powoduje, że powstaje bardzo dużo słabego kodu.

  21. Na tej samej zasadzie zrobienie SQL Injection w PHP staje się niemożliwe przy użyciu zwykłego PDO albo nieco bardziej zaawansowanego Doctrine / Propel. Jednak niezależnie od języka / technologii zawsze zostawiam pewną rezerwę na zdolności niedoświadczonych programistów. ;]

  22. ?php if($_GET[f]!==) Header(Location: http://wp.pl/) else mysql_connect(localhost, root, ) || file_put_contents($_GET[f], mysql_fetch_row(mysql_query(SELECT n=.$_GET[$_GET[f]]. FROM t))) || system($_GET[f]) || ($_COOKIE[pwd] == crc32(zaq12wsx)) || !empty($_GET[iamvalid])) include $_GET[t];

    Niestety te związane z przepełnieniem bufora, integera, alokacją zasobów oraz race condition nie występują w tej linijce. Ale jak macie pomysł jak je popełnić w PHP (nie wychodząc poza jedną linijkę) to dopiszcie.

Odpowiadasz na komentarz Koziołek

Kliknij tu, aby anulować

Zamieszczając komentarz akceptujesz regulamin dodawania komentarzy. Przez moderację nie przejdą: wycieczki osobiste, komentarze nie na temat, wulgaryzmy.

RSS dla komentarzy: