Tips&Tricks: Standard bezpiecznych aplikacji

Od jakiegoś czasu zastanawiam się jak napisać dobry standard bezpieczeństwa dla programistów aplikacji webowych. Z tego powodu zapytałem na blipie o dobre praktyki przy tworzeniu takiego dokumentu. Niestety nikt nie odpisał, ale z racji kończącego się dzisiaj SecDay'a wierzę, że np. w komentarzach do tego posta ktoś podzieli się ze mną swoim doświadczeniem i pomysłami.

Dlaczego w ogóle chcę napisać dobry standard?

Po pierwsze... chcę napisać dobry, bo napisałem już kilka (każda wersja mam nadzieję lepsza od poprzedniej), ale nadal nie jestem zadowolony z tego jak to wygląda. Po drugie... OWASP Top 10 jako spis najczęściej wykorzystywanych podatności, OWASP Development Guide jako przewodnik tworzenia bezpiecznych aplikacji webowych moim zdaniem nie do końca nadają się na zestaw rekomendacji i wymagań dla programisty, który powinien wiedzieć jak napisać bezpieczną aplikację webową. Dlaczego tak uważam? OWASP Top 10 to co najmniej 10 kategorii podatności, którymi m.in. powinni zajmować się ludzie od bezpieczeństwa aplikacji. Moim zdaniem to nie spis podatności powinien być bazą dla standardu, a ogólne i szczegółowe propozycje zastosowania środków/rozwiązań, dzięki którym podatności nie występują albo są trudne do wykorzystania. Niestety podobnie ma się sytuacja z projektem OWASP Development Guide. Ostatnia aktualizacja dokumentu miała miejsce w roku 2005. Od tego czasu w świecie bezpieczeństwa aplikacji webowych sporo się zmieniło, a niestety nikt nie zadbał o świeżość dokumentu. Może jestem zbyt wybredny, ale moim zdaniem przewodnik nie proponuje rozwiązań w sposób pozwalający łatwo zaadoptować je w dowolnej aplikacji. Każdy programista jest inny, inna jest szkoła wg. której uczył się programować, ale nadal mam nadzieję, że moja propozycja podejścia do tworzenia standardu może być dla niego przyjazna i w rezultacie efektywna. Ważne jest zrozumienie różnicy pomiędzy dwoma rodzajami zapisów w standardzie - rekomendacje (nice to have!) i wymagania (must be!). Nie zawsze chodzi o 100% zgodność ze standardem, bo obejmuje on znacznie szerszy zakres zagadnień niż aplikacja potrzebuje lub pewne rozwiązania mogące mieć znamiona podatności zostały zaakceptowane w procesie analizy ryzka. O tym więcej trochę później - modelowanie zagrożeń.

Dlaczego mam szansę napisać dobry standard?

Albo przewrotnie dlaczego takich szans nie mam ;-) Ogólnie mówi się, że tylko programista powinien szkolić programistów z pisania bezpieczniejszych (bo bezpiecznych w 100% nie ma ;>) aplikacji. Żaden ze mnie etatowy programista, a jedynie okazjonalny koder. Ba, nie lubię pisać aplikacji webowych. Wychowałem się na języku C, ASM (8-... bitowym) i shellu w latach (1999-...) kiedy proste CGI w C/Perlu i HTML z SSI był czymś 'jami' w dzisiejszych czasach. Wygląda na to, że powinienem trzymać się daleko od programistów, a jednak życie i sam zdecydowałem inaczej. Jestem bardzo otwarty na programistów, od lat rozmawiam z nimi chociaż zajmują się różnymi rodzajami aplikacji. Od programistów sterowników, kawałków kernela systemów operacyjnych, przez aplikacje systemowe, usługi, aplikacje webowe, aż po GUI. Rozmawiam, czasami próbuję napisać fragment aplikacji by zrozumieć na czym polega implementacja zabezpieczeń z ich perspektywy. Staram się uczyć przekładać zagrożenia z wykorzystaniem podatności na ogólne sposoby uniknięcia zaimplementowania ich przez programistę. Moim skromnym zdaniem kluczem do napisania dobrego standardu jest zrozumienie genezy powstawania podatności. W skrócie, pomogą dobre praktyki i wzorce projektowe. Jeżeli nikogo poza samym sobą nie przekonałem do tego, że mam szansę napisać niezły standard to śmiało można zamknąć to okno przeglądarki :-)

Co warto wziąć pod uwagę przy pisaniu standardu tworzenia bezpiecznych aplikacji?

Poza ogólnymi 'best practices' nie można zapominać, że aplikacja pracująca w danej warstwie (np. webowa w przeglądarce, po stronie serwera) rządzi się swoimi prawami. Przykładowo pisząc standard dla aplikacji systemowej pisanej w języku niskiego poziomu jak C będzie trzeba pamiętać o takich rzeczach jak zarządzanie pamięcią na stercie czy odpowiednią kontrolą otwieranych plików by nie doszło do sytuacji wyścigów, obcinania plików i innych konsekwencji podobnych podatności. W aplikacji webowej pisanej w J2EE czy PHP nie będziemy bezpośrednio przejmować się zarządzaniem stertą bo robi to za nas inna warstwa środowiska, w której pracujemy.

Następnym elementem pisania standardu jest pokora. Trudno napisać uniwersalny standard bo zaraz się okaże, że dany framework nie realizuje pewnych wymagań, inne realizuje w sposób odmienny od oczekiwanego, a przecież nagle zespół programistów nie będzie przepisywał połowy kodu bazowego większości aplikacji. W takich przypadkach proponuję nieco inne podejście - dopisanie fragmentu kodu, który będzie możliwie prosty do dołączenia i użycia w popularnym dla danego zespołu frameworku. Są też inne, ale ciekawa sprawa tuż, tuż. Właściwie dotykam tutaj moim zdaniem bardzo śliskiego tematu. Trudno jest oczekiwać od programistów z mniejszym albo większym doświadczeniem w pisaniu bezpiecznych aplikacji, że nagle zaimplementują dla swojej wygody klasy/metody, funkcje realizujące wymagania i rekomendacje ze standardu bezpieczeństwa. Fakt, faktem tak powinno być, powinien taki stały pakiet 'bezpieczeństwa' chodzić za każdą aplikacją i w ten sposób gwarantować możliwość szybkiego podniesienia poprzeczki dla napastników. Dla coraz większej ilości języków myślę tutaj o wykorzystaniu projektu OWASP ESAPI, który wkrótce zamierzam opisać bardziej szczegółowo. Póki nie ma stałego frameworka dla nowych aplikacji webowych będziemy mieli sporo pracy z programistami, a oni z nami :) zanim dojdziemy do satysfakcjonującego poziomu bezpieczeństwa by default.

Kontynuując podobnie ma się sprawa z różnymi językami. Standard powinien być ponad podziałami w tej kwestii, ale już przykłady, które można dodać w załącznikach warto gromadzić i pokazywać na potrzeby potomnych.

Podsumowanie.

Tematu rzecz jasna nie wyczerpałem. Mam nadzieję, że pokazałem kulisy powstawania standardów dla programistów i może komuś się to nawet przyda. Chętnie przyjmę wszelkie uwagi, szczególnie te krytyczne jak podejść do tematu by standard był praktykowany. Na koniec będąc natchniony przez kumpla (dzięki qba!) mam prośbę do ludzi, którzy 'zmuszają' programistów do pisania bezpieczniejszych aplikacji: Nie ubierajcie się mentalnie i na co dzień w takie ciuszki z wyrazem twarzy: "Nie mogę Ci pomóc, jestem koniem." :) Do następnej części: trening dla programistów w oparciu o standard i nie tylko...

PS
Liczę na szczere uwagi także od programistów ;)