Witam!

W ramach pracy inżynierskiej projektuję aplikację działającą na podobnej zasadzie, jak Wirtualny Dziekanat, tyle że dla innej organizacji - baza członków około 400 osób, z informacjami typu PESEL, opłaty itd. Aplikacja zostanie wykorzystana w praktyce, stąd postanowiłem w możliwie dużej mierze skupić się na kwestiach bezpieczeństwa i temu tematowi poświęcić dużą część swojej pracy, szczególnie, że do tej pory temat traktowałem raczej pobieżnie (z racji, iż moje projekty w PHP&MySQL były robione na nieco mniejszą skalę). Również kwestię Inżynierii Oprogramowania traktowałem pobieżnie i też chciałbym tą wiedzę poszerzyć w ramach pisania pracy, ale mniejsza o to. Oto co wyniknęło z dwóch dni studiowania Google w tym zakresie.

Aktualne założenia:
1. Solidnie zaprojektowana aplikacja, w oparciu o wzorzec projektowy MVC, w końcowym etapie przetestowana pod kątem SQL Injection, Persistent XSS etc.
2. Dostęp do danych (dodawanie / czytanie / usuwanie) tylko za pomocą odpowiednich procedur utworzonych w MySQL (swego rodzaju zabezpieczenie przed SQL Injection), odpowiedni system uprawnień użytkowników po stronie MySQL. Do tego filtrowanie danych po stronie PHP.
3. Zastosowanie certyfikatów SSL dla systemu (zapewne darmowy StartSSL), być może również autoryzacja po certyfikatach.
4. Zablokowanie indeksowania systemu w Google przez .htaccess.
5. Dodatkowe zabezpieczenie hasłem wybranych katalogów na serwerze, odpowiednie określenie dostępu do plików.
6. Dostęp do FTP tylko i wyłącznie przy użyciu klienta z szyfrowaniem haseł przy pomocy hasła głównego (w moim przypadku TC + szyfrowanie AES 256) i z zaznaczoną opcją łączenia się przy pomocy SSL (OpenSSL).
7. O regularnych backupach nawet nie wspominam.

Pytania:
1. Na które elementy w szczególności należy zwrócić baczną uwagę w trakcie pisania kodu?
2. Czy utworzenie takiego systemu na subdomenie strony głównej tej instytucji to dobry pomysł, czy raczej z tego zrezygnować? Może przenieść system na inny serwer z zablokowanym dostępem np. dla IP zza granicy? Skoro na tym samym serwerze będzie strona WWW oparta o Wordpressa.
3. Na koniec pytanie podstawowe - co jeszcze? Czy są kwestie kluczowe, które w swoich założeniach pominąłem? Google przeanalizowałem już dosyć dokładnie, ale nie chcę czegokolwiek z ważnych rzeczy pominąć, stąd zwracam się do Was o pomoc w tej kwestii. Nie oczekuję dokładnego opisu danych problemów, tylko dosłownie hasłowego określenia tematów, z którymi jeszcze powinienem się zapoznać, ewentualnie jakiś ciekawych, prostych "kruczków" na podniesienie bezpieczeństwa.

Dostęp FTP chyba nie do www. Lepiej zrobić subdomene niż nowy serwer. Zablokować wszystkie "boty" skanujące. nie tylko google.

Mógłbyś ująć to ciut konkretniej bo nie mogę załapać?



Właśnie takiej odpowiedzi oczekiwałem, dziękuję. Co do subdomeny to moje wątpliwości są związane z Wordpressem - tzn. jeśli ktoś dorwie mi się do serwera przez jakąś lipną wtyczkę, to zapewne może dogrzebać się również do mojego systemu, czy też przesadzam i nie są to uzasadnione wątpliwości?

Wszystko co będzie na tym serwerze, może być potencjalną furtką do ataku.

I teraz pytanie, czy istnieje jakaś w miarę skuteczna metoda, aby odciąć to, co jest pod subdomeną od wspomnianej reszty?

Jest to możliwe, np chroot, albo wirtualizacja.

Z FTP mi chodziło o to, że jeśli dajesz dostęp do FTP to do takiego miejsca gdzie nie plików ze stroną lub moga do niej dojść.
Zastanów się tak naprawdę czy konieczny jest ten FTP.

Ja osobiście nie preferuje FTP jeśli już mam coś przesyłać dane to korzystam z SCP. Ale do tego musisz mieć konta w systemie. FTP w tym przypadku jest lepsze bo nie muszą istnieć konta fizycznie.

O widzisz, dzięki wielkie!



Oczywiście chodziło mi o siebie z tym dostępem do FTP, fakt, to oczywistość i standard, że powinienem się do takich zasad stosować, ale dla formalności również i to wymieniłem.

To jeśli Ci potrzebne FTP do wstawiania plików na www to zamień to na SCP. No chyba, że nie masz takiej możliwości.

Mam taką możliwośc i chyba też tak zrobię.

Jeszcze jedna kwestia, jeśli takową aplikację obsługuje się z jednego stanowiska, to czy rozsądnie byłoby ją postawić tam na localhoscie, czy w ogóle takiej praktyki się nie stosuje? Jaki wpływ miałoby to na kwestię bezpieczeństwa? Akurat to nie dotyczy mojego przykładu, ale innych już jak najbardziej.

Pozwolę się dołączyć.
Oczywiście nie ma problemy z tym, aby system działał na subdomenie. Jeżeli jednak masz jakiekolwiek wątpliwości, to proponuję system przenieść na inny serwer lub użytkownika i dla utworzonej subdomenu utworzyć odpowiedni wpis w DNS (typu A) i przekierować ją na lokalizację serwera docelowego. Jeżeli system ma działać jedynie w intranecie, możez tak skonfigurować, aby był dostępny za pomocą subdomeny, ale tylko dla użytkowników intranetu.

Jeżeli masz ochotę iść w dosć "paranoiczny" sposób jeśli chodzi o bezpieczeństwo, możesz podczzas autoryzacji użyć dodatkowych tokenów (np. SMS). Istnieje wiele serwisów, które umożliwiają takie usługi. Nie chcę tu robić żadnej reklamy, ale sam ostatnio korzystałem z takiego rozwiązania z platformy smsAPI

Jaką aplikację? Stronę WWW na localhoście? Jeśli wiesz, że Twój komputer jest bezpieczny i nie boisz, że ktoś wyniesie Ci dane to możesz postawić serwer testowy u siebie.