Oświadczenie o bezpieczeństwie aplikacji internetowych

31.10.2014 Michał Prysłopski

Procedura 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:

1. 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

2. Stale rozwijana wiedza i śledzenie informacji o nowych typach zagrożeń

3. 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 _

4. 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 ReferenceImproper Error Handling)

5. 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

6. 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)

7. W plikach cookie nie są przechowywane żadne istotne dane, jedynie klucz sesji (ochrona przed Broken Authentication and Session Menagement)

8. 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 — XSSCross Site Request Forgery — CSRF)

9. 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)

10. 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ć.



Lorem ipsum po polsku, z polskimi znakami Przetestuj mój popularny generator. Nie pierwszy tego typu, ale posługuje się zmielonymi tekstami współczesnymi. Można wybrać jeden z kilku stylów: teksty polityczne, naukowe, przyrodnicze. Losuje też nazwiska autorów tekstów. »
Polecamy: Blog o tym, że Polska jest Najładniejsza (ładne zdjęcia)