Zabezpieczenia stron

Odpowiedz Nowy wątek
2019-03-06 14:34
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.

Pozostało 580 znaków

2019-03-06 14:35
2019-03-06 15:15
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ć.


That game of life is hard to play
I'm gonna lose it anyway
The losing card I'll someday lay
So this is all I have to say
edytowany 2x, ostatnio: cerrato, 2019-03-06 16:35
konieczność okresowej zmiany hasła chyba najbardziej wkurzająca rzecz, a przy okazji chyba najmniej zwiększająca bezpieczeństwo :D - WeiXiao 2019-03-07 00:08
Dlatego napisałem też, że do mnie to nie przemawia,ale jednak wiele stron ma takiego buga... Znaczy ficzera ;) - cerrato 2019-03-07 08:16
przydatna sprawa, zmian hasła przypomina mi że nowy miesiąc i migawkę trzeba kopić ;) - Miang 2019-03-07 09:37
@Miang: zdradzę Ci sekret - można to zautomatyzować, albo skorzystać z https://www.google.com/calendar :D - cerrato 2019-03-07 09:41

Pozostało 580 znaków

2019-03-06 15:51
5

Widzę, że @cerrato podał dużo fajnych rzeczy, ale można jeszcze:


edytowany 2x, ostatnio: MasterOf, 2019-03-06 15:52

Pozostało 580 znaków

2019-03-06 15:55
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?

edytowany 2x, ostatnio: Bogu, 2019-03-06 18:11

Pozostało 580 znaków

2019-03-06 18:48
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.

edytowany 3x, ostatnio: Freja Draco, 2019-03-06 21:14

Pozostało 580 znaków

2019-03-07 00:02
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.
edytowany 3x, ostatnio: mefsh, 2019-03-07 00:07
Pokaż pozostałe 5 komentarzy
Obstawiam że o ilość, w końcu masz teraz 500+ zależne od ilości ;) Aczkolwiek podziękuję, lepiej nie :P - mefsh 2019-03-07 14:47
Pomyśl - 20 dzieciaków i masz 10kpln bez wychodzenia z domu. Moim zdaniem warto. - cerrato 2019-03-07 14:48
Opcja 0 za 0 wydaje się również korzystna :p - mefsh 2019-03-07 14:54
Wystarczy 10. W moim rodzinnym mieście babka ma 10-tke i łącznie(500+, dodatki, zasiłki) dostaje ponad 10k. Jak ja urząd pracy wysłał przymusowo do roboty pod groźba utraty zasiłków, ta oczywiscie pracy się brzydzila, nastepnie poskarzyla się do Szydło i do UP wpłynęło pismo z ministerstwa, by biednej kobiecie jednak przywrócić zasiłki. Ojcowie dzieci nieznani, alimenty i się żyje z naszych pensji :) - axelbest 2019-03-07 14:54
masz na nią jakiś namiar? Widać, że obrotna babeczka, warto się koło takiej zakręcić ;) - cerrato 2019-03-07 14:57

Pozostało 580 znaków

2019-03-07 00:14
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.

edytowany 1x, ostatnio: WeiXiao, 2019-03-07 00:22
Jak ludzie olewają tak podstawowe zabezpieczenia jak SQL Injetion bo "kto to sprawdzi" / "zrobię to potem, teraz się uczę to mi zbędne", a potem jednak ktoś sprawdził, albo po prostu przez brak rutyny w zabezpieczaniu zapominamy o tym, to jest wysoko. Tym bardziej że przecież SQL Injection to jedna z pierwszych rzeczy które są do sprawdzenia przy ataku strony. - mefsh 2019-03-07 02:34

Pozostało 580 znaków

2019-03-07 06:39
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

sam miałem zamiar to wstawić, ale nie chciało mi się szukać :D - cerrato 2019-03-07 10:43

Pozostało 580 znaków

2019-03-07 10:41
0

I najważniejsze, nie pisać w czystym PHP :D


Brudny php i czyste skarpety -> C-c-c-combo breaker - axelbest 2019-03-07 10:58
@axelbest: copy-paste programmer :) - czysteskarpety 2019-03-07 11:08

Pozostało 580 znaków

2019-03-07 11:42
0
czysteskarpety napisał(a):

I najważniejsze, nie pisać w czystym PHP :D

A w czym?


jak nie w czystym, to pewnie w brudnym. Czyli z błędami, używając konstrukcji deprecated i w oparciu o zmienne globalne ;) - cerrato 2019-03-07 11:47
otóż to :] a na powaga to we frameworkach, sam php jest średnio zjadliwy na czysto - czysteskarpety 2019-03-07 11:49
@mysl_query - axelbest 2019-03-07 11:53
Brudny kod to moja specjalność :> A z frejmłorków lubię tylko te, które sama napisałam :> - Freja Draco 2019-03-07 12:14
i które także są brudne, prawda? :D - cerrato 2019-03-07 12:18
@cerrato: ktoś ma tu chyba brudne myśli :p A swoją drogą, czysty PHP można rozumieć jeszcze inaczej: dziewiczy, niesplamiony skuteczną interpretacją, nie to co jakieś profesjonalne skrypty wyśmigane na wszystkie strony ;) - Freja Draco 2019-03-07 12:47

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

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