Na początek kilka tekstów do przeczytania w ramach wprowadzenia:
Ja nie do końca zgadzam się z twierdzeniem, że wybór języka programowania, a właściwie szerzej - całego środowiska, w którym powstaje aplikacja, nie ma wpływu na bezpieczeństwo produktu wyjściowego.
Oczywiście, jakość produktu zależy od jakości programistów, od tego, czy potrafią oni tworzyć bezpieczny kod, czy znane są im zasady bezpiecznego programowania. Zależy również od tego, jak zorganizowany jest proces tworzenia aplikacji, bo przecież tworzenie aplikacji to nie tylko pisanie kodu. Bezpieczeństwo jednak zależy również od wykorzystywanych technologii, bo co prawda zawsze można sobie strzelić z łuku w kolano, czasami jednak można zrobić to nieco łatwiej.
W tym kontekście warto zapoznać się z kolejną już wersją Secure Web Application Framework Manifesto. Dokument ten zawiera sporo postulatów (wymagań), które dotyczą następujących obszarów:
- Injection Prevention,
- Input Validation,
- Authentication and Authorization,
- Session Management,
- XML Specific,
- Cryptography,
- Configuration Security,
- File Upload,
O wszystkich z powyższych zagadnień mówi się wiele. To, że dane wejściowe trzeba walidować, że konieczny jest encoding danych, że (...) jest oczywistą oczywistością (tak, są programiści, którzy o tym nie wiedzą). Trzeba dostarczyć narzędzi, które wykonanie tych zadań ułatwiają i zmniejszą prawdopodobieństwo popełnienia błędu, bo przecież można źle walidować dane wejściowe, można zastosować zły encoding. Prawdopodobieństwo takich błędów jest większe, jeśli programista będzie musiał sam napisać funkcje realizujące te zadania. Jeśli będzie mógł użyć już gotowej funkcji, ma mniejszą możliwość popełnienia błędu. Mniejszą, ale oczywiście nie zerową.
Oczywiście, implementacja postulatów zawartych w tym dokumencie nie kończy sprawy. Nadal będzie potrzebna edukacja programistów w zakresie tworzenia bezpiecznego kodu, nadal będzie potrzebny SDL, będą potrzebne również testy. Solidny fundament jest jednak pożądany.
