Zabezpieczenia stron

1

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.

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 - Chciałem sobie sprawdzić kod... :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:

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.

OWASP v4

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

@mefsh:

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

@mefsh:

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. Upload: haker_atak.php.
  2. Open: haker_atak.php.
  3. 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.

1 użytkowników online, w tym zalogowanych: 0, gości: 1