Oświadczenie o bezpieczeństwie aplikacji internetowych
31.10.2014
Skopiuj linkProcedura troski o bezpieczeństwo przy tworzeniu aplikacji internetowych Plio.pl
Pełnego bezpieczeństwa w internecie, podobnie jak w życiu realnym, nie da się zagwarantować. Ktoś podejrzy przez ramię wpisywane hasło, ktoś inny wejdzie w posiadanie klucza używanego przez amerykańskie służby do śledzenia internetu, ktoś wreszcie wykorzysta do ataku tysiące komputerów-zombie. Można zrobić jednak bardzo wiele, żeby uzyskać poziom bezpieczeństwa rozsądnie wystarczający dla normalnych zastosowań.
Procedura tworzenia aplikacji internetowych Plio.pl zawiera poniższe elementy:
- Regularne przeglądy i walidacja kodu: ręczna (wyszukiwanie i analiza potencjalnie ryzykownych fraz), automatyczna (systemy automatycznie testujące bezpieczeństwo aplikacji internetowych) i dodatkowe wykonywane przez klientów
- Stale rozwijana wiedza i śledzenie informacji o nowych typach zagrożeń
- Gdzie tylko się da, używanie „super-bezpiecznych parametrów” zapytania użytkownika. Są one automatycznie sprowadzane do czystych liczb naturalnych albo do ciągów znaków zawierających wyłącznie angielskie litery, cyfry oraz znaki - oraz _
- Ostrzeżenia PHP są cały czas włączone w czasie tworzenia aplikacji i żaden komunikat nie jest lekceważony. Ostrzeżenia są za to są całkowicie wyłączane po zakończeniu prac, tak żeby nie podpowiadać niczego atakującym (ochrona przed Insecure Direct Object Reference i Improper Error Handling)
- Wszystkie dane, które wprowadza użytkownik, są przepuszczane przez specjalne API — dla zasady i dobrego odruchu (ochrona przed SQL Injection Flaws). Dotyczy to absolutnie wszystkiego, na co złośliwy użytkownik może mieć wpływ: od ukrytych pól formularza, przez pliki cookie aż po nagłówki zapytania do serwera, takie jak rodzaj przeglądarki czy adres poprzednio odwiedzonej strony. Ta procedura dotyczy nawet danych wprowadzanych przez administratorów
- Komunikaty o błędach zapytań do bazy danych są zredukowane do unikalnego oznaczenia kodowego nie ujawniającego szczegółów zapytania (ochrona przed Improper Error Handling)
- W plikach cookie nie są przechowywane żadne istotne dane, jedynie klucz sesji (ochrona przed Broken Authentication and Session Menagement)
- Skomplikowane dane wprowadzane przez użytkownika są rozkładane na „atomy”, weryfikowane semantycznie a następnie te z nich, które zostaną uznane za poprawne, służą do skonstruowania wprowadzonych danych na nowo. Dotyczy to zarówno tekstów, jak i np. listy tagów. Używane jest do tego m.in. specjalne API przetwarzające kod HTML wprowadzony przez użytkownika (ochrona przed Cross Site Scripting — XSS i Cross Site Request Forgery — CSRF)
- Hasła użytkowników nie są przechowywane w żadnej zrozumiałej formie a jedynie jako hashe zbudowane innym dla każdego klienta algorytmem. Stosowane są też inne metody zabezpieczenia procesu logowania, które pozostają poufne (ochrona przed Insecure Cryptographic Storage)
- Pliki przesyłane przez użytkowników mają tworzone zupełnie nowe nazwy i weryfikowane rozszerzenia. Nigdy nie używamy funkcji wykonujących kod, tj. np. dla języka PHP system, eval, passthru; podobnie do tworzenia wyrażeń regularnych używamy wyłącznie danych przefiltrowanych przez API (ochrona przed Malicious File Execution)
W zależności od wielkości projektu zalecamy też włączanie bezpiecznej transmisji SSL na serwerze, na którym aplikacja ma działać.