Błąd nr 4: Zbyt duża zależność od frameworków

Czasem magiczne narzędzia, tworząc warstwy abstrakcji i domyślając się, czego chcemy, mogą ukryć przed programistą, gdzie leży błąd. G. Blake Meike, programista z okolic Seattle, jest jednym z wielu, którzy za przeszkodę w tworzeniu czystego kodu uznają nadmierną zależność od zautomatyzowanych narzędzi.

"Konwencja, z definicji, jest czymś poza kodem" - mówi Meike. "Jeśli nie zna się zasad, których używa Ruby on Rails, żeby zamienić URL w wywołanie metody, to nie ma sposobu, by dojść, co naprawdę dzieje się w odpowiedzi na zapytanie".

Często czytanie kodu oznacza dla programisty ślęczenie nad instrukcją, żeby rozszyfrować, co kod robi za jego plecami. Osoba przejmująca projekt musi spędzić wiele czasu, by analizować piękny, lecz niezrozumiały i trudny do poprawienia i rozbudowy kod.

Błąd nr 5: Zaufanie do klienta

Wiele błędów powstaje wskutek założenia programisty, że urządzenie klienta zrobi wszystko tak jak trzeba. Jeśli programista nie sprawdzi otrzymanych danych, mogą być poważne problemy.

Jeden z najprostszych ataków opiera się na tym, że niektórzy programiści przekazują do bazy danych wszystkie dane przesłane przez klienta. To może działać całkiem nieźle, aż klient postanowi przesłać zamiast oczekiwanej odpowiedzi zapytanie SQL. Jeśli strona pyta użytkownika o nazwisko i dodaje je do zapytania, to napastnik może wpisać zamiast nazwiska wartość x; DROP TABLE users;. Baza danych posłusznie przyjmie, że nazwisko to x, po czym przejdzie do następnego polecenia, którym jest usunięcie całej tabeli pełnej użytkowników.

Jest wiele innych sposobów nadużycia zaufania serwera. Przepełnienie bufora to nadal jedna z najprostszych metod psucia oprogramowania. Mogą powstać bardzo poważne błędy bezpieczeństwa, kiedy kilka pozornie nieszkodliwych usterek wystąpi jednocześnie, umożliwiając atak o wiele groźniejszy od wykorzystania każdej z nich z osobna.

Błąd nr 6: Brak wystarczającego zaufania do klienta

Czasem nadmiar bezpieczeństwa prowadzi paradoksalnie do luk - zbyt restrykcyjne reguły mogą skutkować obchodzeniem zabezpieczeń po to, by procesy mogły działać. Zmiany takie przynoszą więcej szkód od luźniejszej, ale przestrzeganej polityki.

Formularze internetowe i rejestracja użytkowników to kolejne miejsce, gdzie zaufanie dla klienta może przynosić korzyści. Zamiast wprowadzać bezpieczeństwo na poziomie banku przy długich kwestionariuszach oraz potwierdzanie przez e-mail (co zniechęci ludzi i będzie wymagało ochrony zebranych danych), znacznie prościej zapisać tylko minimum informacji niezbędnych do założenia konta. Niekiedy można uruchomić rozwiązania, które nie zapisują niczego czytelnego.

Błąd nr 7: Nadmierne poleganie na magicznych skrzynkach

Utworzono wiele bibliotek, które mogą naprawić to, czego brakuje naszemu kodowi (na przykład kryptografię), ale mogą one również wprowadzić ukryte, skomplikowane problemy lub nawet nowe pułapki w kodzie.

"Kryptografia staje się w takiej sytuacji poważnym źródłem zagrożenia" - mówi John Viega, współautor książki "24 Deadly Sins of Software Security: Programming Flaws and How to Fix Them". "Zbyt wielu programistów zakłada, że mogą zlinkować program z biblioteką szyfrującą i mieć stuprocentowe bezpieczeństwo".

A w rzeczywistości wiele z tych magicznych algorytmów ma subtelne słabości. Żeby ich uniknąć, trzeba wiedzieć o wiele więcej, niż napisano w instrukcji instalacji.

Błąd nr 8: Odkrywanie koła

Z drugiej strony realizacja różnych bibliotek samodzielnie przynosi niepożądane skutki. "Domorosła kryptografia jest chętnie widziana przez napastników" - mówi Viega, zauważając, że nawet eksperci popełniają błędy, próbując powstrzymać innych przed znalezieniem i wykorzystaniem słabości w ich systemach.

Komu ufać? Sobie czy tak zwanym ekspertom, którzy również popełniają błędy? Odpowiedź leży w zakresie zarządzania ryzykiem. Wiele bibliotek nie musi być doskonałymi, więc użycie magicznego pudełka będzie lepszym wyborem niż samodzielne pisanie kodu. Biblioteki zawierają procedury napisane i zoptymizowane przez grupę. Oni też popełniają błędy, ale większy proces pozwala wyeliminować wiele z nich.