Błąd 1: Programowanie "na luzie"

Przy zbyt frasobliwym podejściu do programowania, często można przeoczyć, jak na działanie programu może wpływać arbitralne zachowanie użytkownika. Czy wprowadzone zero nie pojawi się jako dzielnik w operacji dzielenia? Czy wprowadzony tekst ma właściwą długość? Czy formaty danych są weryfikowane? Czy nazwa użytkownika jest weryfikowana w bazie danych? Takie błędy często powodują, że program się sypie.

Postępy w rozwoju języków programowania zmierzające do rozwiązania tego problemu nie są zadowalające. Ulepszenia składniowe nie zapewniają użyteczności kodu i nie eliminują źródła problemu: rozprzestrzeniania się pustych wskaźników.

Zobacz również:

• Wyjaśniamy czym jest SD-WAN i jakie są zalety tego rozwiązania
• Premiera GitHub Copilot Enterprise

Błąd 2: Zbytnie przywiązanie do szczegółów

Z drugiej strony "szczelnie pozapinane" oprogramowanie może być powolne w działaniu. Kontrolowanie kilku pustych wskaźników może nie robić wielkiej różnicy, ale niektóre programy są pisane z obsesją przypominającą maniakalne sprawdzanie zamknięcia drzwi przed pójściem do łóżka. Zbytnie skupianie się na detalach może nawet zablokować program, jeżeli obsesyjna kontrola wymaga skomunikowania się z odległym ośrodkiem przez sieć.

Błąd 3: Nie upraszczanie kontroli

Zbyt często programiści nie upraszczają kontroli nad zadaniami w projektowanym programie. W kodzie powinno być jedno i tylko jedno miejsce dla każdego zadania. Jeżeli są dwa, istnieje szansa, że ktoś zmieni jedno, ale już nie to drugie. Przy większej liczbie, szansa ta zwiększa się. Zwięzły kod osiąga się w strukturach programistycznych, które zakładają, że większość struktury programu "ustawia się" w powszechnie znane wzorce.

Błąd 4: Zbytnie poleganie na strukturach programistycznych

Czasami jednak "magiczne" narzędzia projektowe wprowadzają zamęt. Wychwytując funkcjonalność i zakładając to czego się oczekuje, struktury programistyczne mogą zbyt często stawiać programistę w sytuacji braku wiedzy, co robić, kiedy coś nie działa w jego kodzie. Wielu programistów jest uzależnionych od narzędzi automatycznych, a w miarę jak aplikacja się rozrasta, zależy coraz bardziej od tych, niemal trywialnych, kawałków "wiedzy zewnętrznej". Struktury programistyczne mogą często pozostawiać programistę z eleganckim kodem, który jest trudny do zrozumienia, zrewidowania czy rozszerzenia.

Błąd 5: Nadmierne zaufanie do klienta

Wiele błędów związanych z bezpieczeństwem pojawia się wtedy, gdy programista zakłada, że urządzenie klienckie będzie działać poprawnie. Kod napisany do pracy w przeglądarce może być pobrany przez przeglądarkę do realizacji dowolnej akcji. Jeżeli programista nie wykona podwójnej kontroli wszystkich danych dostarczanych zwrotnie, wszystko może pójść źle. Istnieje wiele innych sposobów nadużywania zaufania serwera. Przepełnienie bufora nadal jest jedną z najprostszych dróg do uszkadzania programów. Poważne luki bezpieczeństwa mogą powstawać, kiedy trzy lub cztery pozornie łagodne luki połączą się w jeden łańcuch.

Błąd 6: Nadmierna ostrożność

Czasami zbytnia ostrożność może - paradoksalnie - prowadzić do otwartych luk. Przykładem mogą być formularze webowe. Długie kwestionariusze danych osobowych i wymóg potwierdzania adresów poczty elektronicznej zniechęcają do rejestrowania się. Dlatego programiści webowi często poszukują sposobów na możliwie maksymalne redukowanie wymogów bezpieczeństwa, nie tylko żeby ułatwić życie użytkownikom, ale również, by zmniejszyć kłopoty związane z ochroną nadmiernej liczby danych niezbędnych do założenia konta.

Błąd 7: Czar "magicznych skrzynek"

Martwisz się o bezpieczeństwo? Dodaj trochę kryptografii. Chcesz zachowywać swoją bazę danych? Wprowadź klawisz automatycznej replikacji. Problem polega jednak na tym, że łatwość, z jaką możemy coś zrobić, przysłania złożone problemy, których nie dostrzegamy. Gorzej, gdy wprowadzimy nowe pułapki do kodu. Kryptografia jest tutaj głównym źródłem słabości - zbyt wielu programistów zakłada, że może w prosty sposób skorzystać z odwołania do biblioteki szyfrowania.

Prawda jest jednak taka, że te magiczne algorytmy zawierają subtelne niedoskonałości, a dla ich uniknięcia wymagane jest poznanie czegoś więcej niż tylko rozdziału Quick Start w podręczniku. Wyjście poza ten rozdział zakłada pewien poziom wiedzy i jest to jeden z powodów, dla których programiści nabierają przekonania o bezpieczeństwie swojego kodu tylko na podstawie lektury Quick Start.

Błąd 8: Wymyślanie koła

Pisanie własnych bibliotek z przekonaniem, że zna się lepsze sposoby kodowania - może być niebezpieczne. Nawet eksperci popełniają pomyłki, kiedy próbują chronić innych przed wynajdywaniem i wykorzystywaniem słabości w ich systemach. Komu więc można zaufać: sobie czy ekspertom, którzy także popełniają błędy? Odpowiedź daje dziedzina zarządzania ryzykiem. Wiele bibliotek nie musi spełniać kryterium doskonałości i korzystanie z "magicznych skrzynek" jest najczęściej lepszym wyjściem niż pisanie kodu we własnym zakresie. Biblioteki zawierają rutynowe instrukcje pisane i optymalizowane przez zespoły. Tam też mogą znajdować się błędy, ale rozbudowane procesy tworzenia pozwalają na wyeliminowanie wielu z nich.

Błąd 9: Zbyt wiele opcji dla użytkownika

Programiści lubią mnożyć opcje i mechanizmy - w ich mniemaniu - poszerzające możliwości użytkownika. Jednak składanie brzemienia konfigurowania takich mechanizmów na barki użytkownika, który dostosowuje funkcjonalność, nie w pełni rozumiejąc ich przeznaczenia, może sprowadzić katastrofę w postaci nieumyślnych luk bezpieczeństwa, nie mówiąc o tym, że oprogramowanie takie może okazać się zbyt frustrujące czy zagmatwane, aby mogło zdobyć uznanie na rynku. Zbyt często dodatkowe mechanizmy czynią oprogramowanie trudnym do nawigowania i użytkowania.

Błąd 10: Niedocenianie potrzeb użytkownika

Niektórzy programiści decydują się na unikanie problemu zbyt dużej liczby mechanizmów, oferując jedno rozwiązanie. Jednak użytkownicy nie lubią takich pomysłów i mogą poszukiwać sposobów na obejście takich ograniczeń, co może się powodować potencjalne luki w zakresie bezpieczeństwa lub rodzić niepożądaną konkurencję. Poszukiwanie dobrego rozwiązania pośredniego między prostym a bogatym zestawem mechanizmów, jest stałym wyzwaniem, które czasami może okazać się kosztowne.

Błąd 11: Ukrycie źródła

Jednym z bardziej skomplikowanych wyzwań jest decyzja o udostępnieniu kodu źródłowego użytkownikom oprogramowania. Decyzja "na nie" może działać na niekorzyść integralności kodu, zniechęcając do innowacji i, co ważniejsze, wykrywania i usuwania błędów. Praktyczne korzyści z udostępnienia kodu źródłowego, to możliwość włączenia wielu osób do ulepszania oprogramowania. Często sam kod staje się bardziej modularny i lepiej strukturalizowany, kiedy inni rekompilują program i przenoszą na inne platformy. Otwarcie kodu zmusza programistów do tworzenie bardziej dostępnej, zrozumiałej, a tym samym lepszej informacji o nim.

Błąd 12: Otwartość jako lekarstwo na wszystko

Z setek tysięcy projektów open source, jedynie mała część kiedykolwiek przyciągnie więcej niż kilku chętnych do utrzymywania, rewidowania lub poszerzania kodu. Chociaż "otwartość" umożliwia innym ulepszanie kodu, to zazwyczaj sama nic nie wnosi, jeśli nie ma innej zachęty do współpracy. Nie chroni też przed lukami bezpieczeństwa, nie eliminuje możliwości załamania programu ani też nie czyni takiego kodu z natury użytecznym. Może natomiast wnosić nowe koszty związane z komunikowaniem i dokumentowaniem. Zwieńczeniem projektu jest solidna dokumentacja dla użytkownika. Dobre projekty open source mają zazwyczaj rozległą dokumentację API i przyszłych kierunków rozwoju, a dodatkowy wysiłek dokumentacyjny opłaca się tylko przy dużych projektach. Trzeba też mieć na uwadze fakt, że wolontariat często jest nieprzewidywalny.