Witam, czy mógłby ktoś wymienić rodzaje zabezpieczeń jakich można użyć przy tworzeniu stron? W miarę proste, takie jak hashowanie haseł, zablokowanie możliwości logowania po x nieudanych próbach, captcha? Potrzebuję tego do której prezentacji a później do implementacji na prostej stronie. Z góry dzięki.
1
11
- pilnowanie, aby adres IP się nie zmieniał podczas trwania sesji, a jeśli takie coś zostanie wykryte, sesja powinna zostać zakończona, a użytkownik zmuszony do ponownego logowania
- zabezpieczenie przed atakami typu XSS
- walidacja wprowadzonych przez użytkownika danych jeszcze po stronie przeglądarki
- wymogi dotyczące długości i skomplikowania hasła
- konieczność okresowej zmiany hasła
- zabezpieczenie przez atakami typu SQL Injection
- wspomniane przez Ciebie blokowanie możliwości logowania po X nieudanych próbach można zrealizować na 2 sposoby: blokada konta, na które ktoś stara się dobić oraz blokada IP, z którego jest przeprowadzany atak
- ograniczenie możliwości prób logowania do X razy w jednostce czasu oraz nie częściej niż co Y sekund/minut
- podczas rejestracji - mail z kodem aktywacyjnym, Może nie tyle zwiększyć bezpieczeństwo, co zmniejszyć spamowanie (w wypadku stron, gdzie użytkownicy mogą dodawać swoje treści)
- ogarnięcie komunikatów o błędach - żeby nie zdradził zbyt wielu sekretów "zaplecza" strony. Poczta Polska tego nie ogarnia - https://4programmers.net/Mikroblogi/View/39795#entry-39795 :D
Nie ze wszystkimi wytycznymi się zgadzam (np. konieczność okresowej zmiany hasła dla mnie to bzdura), ale nie zmienia to faktu, że w wielu miejscach się to stosuje, więc możesz śmiało o tym wspomnieć.
5
Widzę, że @cerrato podał dużo fajnych rzeczy, ale można jeszcze:
- Zablokować porty, który są nieużywane, np: wszystkie poza :80
- Podłączyć się pod cloudflare aby zabezpieczyć swoją stronę przed atakami
- Wyłączyć url_fopen - https://security.stackexchange.com/questions/103427/what-are-php-allow-url-fopen-security-risk
3
Dodatkowo można ograniczyć korzystanie w API z określonego serializatora i deseralizatora np. używać tylko JSONa a nie XML + Json, co też ma dosyć znaczny wpływ na bezpieczeństwo API.
W sprawie bezpieczeństwa polecam jeszcze zajrzeć na stronę sekuraka i jeśli ktoś korzysta z FB, to również puścić like'a bo mają sensowne materiały.
A jak w przypadku zabezpieczeń typowo serwerowych? Ma ktoś jakieś fajne materiały?
3
- pliki z danymi użytkowników trzymać poza katalogiem publicznym "public_html" (tzn. ani w nim, ani w żadnym z podkatalogów),
- W .htaccess zablokować możliwość:
- wyświetlania zawartości katalogów,
- uruchamiania plików PHP (wyjąwszy wybrane typu index.php),
- oprócz SQL Injection trzeba pilnować też żeby strona nie pozwalała nam na zwykłe wstrzyknięcie kodu PHP,
- wstrzyknięcia niechcianego JS też trzeba pilnować, bo może strony nie rozwali, ale może zaburzyć użytkownikom korzystanie z niej,
- nie ufać poprawności danych przesyłanych z formularzy i sprawdzać ich poprawność po stronie serwera. Przykładowo, jeśli w formularzu są do wyboru opcje: A, B i C, to serwer ma sprawdzić, czy zwrócone dane zawierają się w tym dostępnym zakresie, a jeśli nie, to obsłużyć błąd, a nie z automatu przetwarzać, bo jak nam tam ktoś złośliwie prześle D, to efekty mogą być dziwaczne.
0
Freja Draco napisał(a):
- pliki z danymi użytkowników trzymać poza katalogiem publicznym "public_html" (tzn. ani w nim, ani w żadnym z podkatalogów),
Pod pliki można jeszcze podciągnąć nie używanie nazw plików użytkownika do zapisywania i odczytywania ich z dysku, bo i w nazwie pliku da się wsadzić komendę php'ową która się odpali ;)
Ale teraz widzę, że tutaj to było tez, tylko w innych słowach
oprócz SQL Injection trzeba pilnować też żeby strona nie pozwalała nam na zwykłe wstrzyknięcie kodu PHP.
Nowe:
- Nie wyświetlać żadnych szczegółów dot. błędów użytkownikom.
0
Trochę offtop, ale to jest dziwne, że w 2019 gdy istnieją takie sprytne rozwiązania na radzenie sobie z SQL Injection, to nadal jest to wysoko w kategorii ataków.
2
@cerrato: Wymogi dotyczące długości i skomplikowania hasła - akurat skomplikowanie hasła najlepiej przedstawia ten obrazek
https://imgs.xkcd.com/comics/password_strength.png
0
I najważniejsze, nie pisać w czystym PHP :D
0
czysteskarpety napisał(a):
I najważniejsze, nie pisać w czystym PHP :D
A w czym?
0
Pod pliki można jeszcze podciągnąć nie używanie nazw plików użytkownika do zapisywania i odczytywania ich z dysku, bo i w nazwie pliku da się wsadzić komendę php'ową która się odpali ;)
Moglbys rozwinac
1
marcio napisał(a):
Pod pliki można jeszcze podciągnąć nie używanie nazw plików użytkownika do zapisywania i odczytywania ich z dysku, bo i w nazwie pliku da się wsadzić komendę php'ową która się odpali ;)
Moglbys rozwinac
- Upload: haker_atak.php.
- Open: haker_atak.php.
- All your base are belong to us!
1
@marcio: ja to rozumiem w ten sposób, że jeśli użytkownik wrzuca plik o nazwie gole_zdjecia_stefana_mielno_2015.zip to Ty zapisujesz to na serwerze jako plik o nazwie file_98902745890_sdfjsdh.XYZ, ale jednocześnie umieszczasz w bazie informację, jak ten plik się pierwotnie nazywał, żeby potem była możliwość przywrócenia oryginalnej nazwy w chwili zwracania pliku użytkownikowi.
0
ale zwykle jak robisz upload plików to i tak jest walidacja, sanityzacja, określone rozszerzenia itp. ew. najlepiej skorzystać z zewnętrznego serwisu, analogicznie jak np. z systemem komentarzy, jakieś disqus i po sprawie, mogę se hakować do woli
1
zwykle jak robisz upload plików to i tak jest walidacja, sanityzacja
No zależy, jak to zrobisz. Poza tym właśnie tego dotyczy ten wątek - jakie zabezpieczenia należy stosować, żeby było OK.
0
czysteskarpety napisał(a):
skorzystać z zewnętrznego serwisu, analogicznie jak np. z systemem komentarzy, jakieś disqus i po sprawie, mogę se hakować do woli
Disqus rozwiązuje jeden problem, przynosząc w jego miejsce inne. No chyba, że lubisz znienacka zobaczyć na swojej stronie reklamy, lubisz jak obce skrypty zmieniając ci identyfikatory w linkach afiliacyjnych i blokują komentarze, za linkowanie do sjp.pl.