• Najnowsze pytania
  • Bez odpowiedzi
  • Zadaj pytanie
  • Kategorie
  • Tagi
  • Zdobyte punkty
  • Ekipa ninja
  • IRC
  • FAQ
  • Regulamin
  • Książki warte uwagi

Bezpieczeństwo ponad wszystko!

VPS Starter Arubacloud
0 głosów
229 wizyt
pytanie zadane 10 marca 2019 w SQL, bazy danych przez DanJ93 Użytkownik (860 p.)
edycja 10 marca 2019 przez DanJ93

Witam drogich forumowiczów!
Aktualnie pracuję nad serwisem internetowym, gdzie znaczącą jego część ma zajmować bezpieczeństwo ów serwisu, dlatego kieruję pytanie do Was: Jakie znacie zabezpieczenia przed wszelakimi włamaniami/wstrzykiwaniami i innymi tego typu rzeczami?

  1. - Czy używając PDO, zamiast MySQLi jest sens filtrować formularze wysłane przez użytkownika?
  2. - Czy jest możliwość ograniczenia ilości zapytań do jednej tabeli? Np. do tabeli 'users' maks 1 zapytanie (logowanie/rejestracja), tak żeby się nie dało pobrać wszystkich userów
  3. - Czy ktoś może 'podglądnąć' mój skrypt PHP, jeśli po wpisaniu go w przeglądarkę przenosi go do innej podstrony?
  4. - Aktualne wersje SQL i PHP
  5. - Używanie osobnego formularza do logowania przez administratorów
  6. - Ukrywanie błędów z bazy danych, podając tylko własny kod (kody wymyślone przez siebie, aby w razie czego samemu łatwiej znaleźć błąd)
  7. - Oczywiście HASH haseł, a w późniejszym etapie może i dodanie 'soli'
  8. - Recaptcha przy formularzach logowania/rejestracji
  9. - Ograniczenia czasowe do edycji swojego konta w ów serwisie (np. 1 raz na 20 sekund)

Co jeszcze możecie dodać, tak, aby było w pełni bezpiecznie?

PS. serwer oczywiście będzie na Linuxie (obecnie używam Windowsa)

2 odpowiedzi

+2 głosów
odpowiedź 10 marca 2019 przez Ehlert Ekspert (212,630 p.)
  1. Walidacja nie powinna być zależna od tego w jaki sposób realizujesz deale z bazą. Waliduj zawsze.
  2. Nie rozumiem po co ograniczać zapytania do jednej tabeli. Po to masz całą schemę żeby swobodnie z niej korzystać. 
  3. Php 7.3 mysql 8.0.15
  4. Używanie osobnego formularza nic nie zmienia, w mojej opinii pogarsza sytuację.

 serwer oczywiście będzie na Linuxie (obecnie używam Windowsa)

Domyślam się że zaczynasz przygodę, a przynajmniej z php. Nie mniej jednak wiesz, że jest to błąd. Warto uruchamiać aplikację w takich samych środowiskach. Pomoże Ci w tym vagrant np laravel homestead, docker lub puphpet. 

+2 głosów
odpowiedź 10 marca 2019 przez Arkadiusz Waluk Ekspert (287,550 p.)

- Czy używając PDO, zamiast MySQLi jest sens filtrować formularze wysłane przez użytkownika?

A co ma jedno do drugiego? Zawsze jest sens pilnować bezpieczeństwa tego, co przychodzi z zewnątrz, powiedziałbym nawet że to konieczność i obowiązek.

- Czy jest możliwość ograniczenia ilości zapytań do jednej tabeli? Np. do tabeli 'users' maks 1 zapytanie (logowanie/rejestracja), tak żeby się nie dało pobrać wszystkich userów

Na poziomie bazy to nie ma sensu (przecież na raz może próbować rejestrować się 10 osób) i nie za bardzo sobie to wyobrażam. Nie będzie się dało pobrać wszystkich userów jeśli nie dasz nigdzie takiej opcji. Przecież użytkownik sam nie wysyła zapytań do bazy, robi to aplikacja, którą można odpowiednio oprogramować.

- Czy ktoś może 'podglądnąć' mój skrypt PHP, jeśli po wpisaniu go w przeglądarkę przenosi go do innej podstrony?

Przy dobrej konfiguracji serwera (i zakładając że sam kod nie ma jakichś luk, które mogłyby zwrócić pliki z kodem) nie ma opcji, aby wyświetlił się kod PHP.

- Aktualne wersje SQL i PHP

Hm? Używanie możliwie najnowszych wersji oprogramowania raczej wydaje się logiczne, nie wiem o co Ci tu chodziło.

- Używanie osobnego formularza do logowania przez administratorów 

Nie wiem jakie to może mieć znaczenie czy to będzie jeden formularz czy 10 osobnych. Bardziej się liczy ich działanie, czy będą ewentualnie jakieś różne elementy dla poszczególnych poziomów dostępu czy nie.

- Ukrywanie błędów z bazy danych, podając tylko własny kod (kody wymyślone przez siebie, aby w razie czego samemu łatwiej znaleźć błąd)

 W ogóle nie podawałbym informacji o tym co się zepsuło. Po prostu 500 i jakiś ładny dla użytkownika komunikat, a pełne treści błędów powinny być gdzieś logowane, abyś mógł Ty czy ktoś inny obsługujący aplikację to sprawdzić.

- Oczywiście HASH haseł, a w późniejszym etapie może i dodanie 'soli'

Przy obecnych algorytmach (bcrypt, argon) dodatkowa sól jest już raczej zbędna.

- Recaptcha przy formularzach logowania/rejestracji

Może się przydać jeśli boisz się spamu.

- Ograniczenia czasowe do edycji swojego konta w ów serwisie (np. 1 raz na 20 sekund)

No można, ale jeśli ktoś będzie chciał męczyć serwer to napisze skrypt, który będzie odpytywał co te 20 sekund i i tak będzie męczył. Więc tu trzeba pomyśleć nad sensem takich rzeczy, aby to się nie stało uciążliwe dla użytkownika i jednocześnie nic nie wnoszące dla spamera czy jakiegoś bota.

Co jeszcze możecie dodać, tak, aby było w pełni bezpiecznie? 

Dużo by tu wymieniać. Błąd można popełnić z każdej strony: od tego, że źle skonfigurujesz serwer i wyciekną dane do bazy, przez różnego rodzaju ataki, po błędy w kodzie i inne zdarzenia. Nikt Ci nie poda listy rzeczy, którą sobie odhaczysz i będzie super, bo zawsze może coś jeszcze wyjść.

1
komentarz 10 marca 2019 przez Comandeer Guru (599,730 p.)

Przy obecnych algorytmach (bcrypt, argon) dodatkowa sól jest już raczej zbędna.

Warto to uściślić: dodatkowa sól dodawana ręcznie przez nas. W PHP password_hash taką sól generuje sobie sam, z losowych bitów. 

komentarz 10 marca 2019 przez DanJ93 Użytkownik (860 p.)

Domyślam się że zaczynasz przygodę, a przynajmniej z php. Nie mniej jednak wiesz, że jest to błąd. Warto uruchamiać aplikację w takich samych środowiskach. Pomoże Ci w tym vagrant np laravel homestead, docker lub puphpet.

Myślę, że to na jakim systemie napiszę kod, nie będzie miało jakiegoś większego przełożenia na późniejsze jego przeniesienie

A co ma jedno do drugiego? Zawsze jest sens pilnować bezpieczeństwa tego, co przychodzi z zewnątrz, powiedziałbym nawet że to konieczność i obowiązek.

To chyba zostałem źle poinformowany, bo z tego co słyszałem, to PDO wyklucza możliwość wstrzykiwania danych i właśnie przez to poświęciłem dziś niemal cały dzień, aby przepisać MySQLi na PDO.

Nie wiem jakie to może mieć znaczenie czy to będzie jeden formularz czy 10 osobnych. Bardziej się liczy ich działanie, czy będą ewentualnie jakieś różne elementy dla poszczególnych poziomów dostępu czy nie.

To nie ma sensu robić strony do logowania dla adminów np. pod adresem www.strona.pl/a83mansa.php ? Bo niby poznać taki adres, to też nie jest wielka sztuka, więc się właśnie zastanawiam, czy jest w ogóle sens? Czy po prostu logowanie jak zwykły użytkownik + drugie hasło

 W ogóle nie podawałbym informacji o tym co się zepsuło. Po prostu 500 i jakiś ładny dla użytkownika komunikat, a pełne treści błędów powinny być gdzieś logowane, abyś mógł Ty czy ktoś inny obsługujący aplikację to sprawdzić.

W sumie, to masz rację! Zapomniałem, że można zrobić logi i będzie to nawet lepsze, bo log się zapisze zawsze, a użytkownik zgłosi błąd niekoniecznie

Przy obecnych algorytmach (bcrypt, argon) dodatkowa sól jest już raczej zbędna.

Dobrze wiedzieć :)

No można, ale jeśli ktoś będzie chciał męczyć serwer to napisze skrypt, który będzie odpytywał co te 20 sekund i i tak będzie męczył. Więc tu trzeba pomyśleć nad sensem takich rzeczy, aby to się nie stało uciążliwe dla użytkownika i jednocześnie nic nie wnoszące dla spamera czy jakiegoś bota.

No tak, ale zawsze to mniejszy spam. Przy okazji zapytam, czy użytkownik ma możliwość zmiany $_SESSION? Bo chciałbym zapisywać czas ostatniej edycji właśnie w tej zmiennej, by nie zapisywać go od razu w bazie, bo wtedy ten 'anty-spam' i tak by nawiązywał połączenie, by sprawdzić czas ostatniej edycji.

Dużo by tu wymieniać.

Fajnie, gdybyś jednak wymienił choć trochę :)


a

3
komentarz 10 marca 2019 przez Comandeer Guru (599,730 p.)

Myślę, że to na jakim systemie napiszę kod, nie będzie miało jakiegoś większego przełożenia na późniejsze jego przeniesienie

To źle myślisz ;) Czasami wystarczy, że separator ścieżki jest inny (np. Linux/macOS – /, Windows – \).

To chyba zostałem źle poinformowany, bo z tego co słyszałem, to PDO wyklucza możliwość wstrzykiwania danych i właśnie przez to poświęciłem dziś niemal cały dzień, aby przepisać MySQLi na PDO.

Nie PDO, a prepared statements. Poza tym to chroni tylko bazę, a co z XSS-em czy choćby czymś tak trywialnym jak dane niepoprawne z biznesowego punktu widzenia?

1
komentarz 10 marca 2019 przez Arkadiusz Waluk Ekspert (287,550 p.)

Warto to uściślić: dodatkowa sól dodawana ręcznie przez nas. W PHP password_hash taką sól generuje sobie sam, z losowych bitów. 

Racja, skrót myślowy. Miałem na myśli właśnie dodawanie czegoś ponad to, co już się robi samo.

Myślę, że to na jakim systemie napiszę kod, nie będzie miało jakiegoś większego przełożenia na późniejsze jego przeniesienie

To bardziej do odpowiedzi Ehlerta, ale już Comandeer podał najprostsze. Już pomijam sytuacje, gdy masz nieco różne wersje tych samych narzędzi i nagle okazuje się, że o czymś nie wiesz, czegoś nie sprawdziłeś i na innej działa coś nieco inaczej albo w ogóle się wykłada. Nie musi się tak stać, często może nawet zadziałać, ale to nie znaczy że warto takie sytuacje prowokować.

To nie ma sensu robić strony do logowania dla adminów np. pod adresem www.strona.pl/a83mansa.php ? Bo niby poznać taki adres, to też nie jest wielka sztuka, więc się właśnie zastanawiam, czy jest w ogóle sens? Czy po prostu logowanie jak zwykły użytkownik + drugie hasło

Jak chcesz, jak dla mnie to trochę sztuka dla sztuki. Lepiej pomyślałbym o lepszym zabezpieczeniu, np. poprzez wdrożenie 2FA dla wszystkich.

No tak, ale zawsze to mniejszy spam. Przy okazji zapytam, czy użytkownik ma możliwość zmiany $_SESSION? Bo chciałbym zapisywać czas ostatniej edycji właśnie w tej zmiennej, by nie zapisywać go od razu w bazie, bo wtedy ten 'anty-spam' i tak by nawiązywał połączenie, by sprawdzić czas ostatniej edycji.

Nie, sesja jest po stronie serwera, czyli użytkownik jej nie ruszy, dostaje tylko jej id i dopóki ono nie trafi w niepowołane ręce jest bezpiecznie. Jednak bez problemu może się zalogować drugi raz (poprzednio wylogowując czy po prostu z innej przeglądarki) i utworzy się nowa sesja. Także to zabezpieczenie w takiej formie będzie lekko kulawe - zabezpieczy tylko dla tej samej sesji.

Fajnie, gdybyś jednak wymienił choć trochę :) 

Jedno podałem, chyba z głupszych, ale da się bez problemu zrobić: plik z danymi konfiguracyjnymi do bazy lub innymi danymi ogólnodostępny na serwerze. Generalnie jeśli masz tam jakieś inne pliki, które nie powinny być publiczne, to trzeba upewnić się, że tak właśnie jest. Kolejne podał Comandeer, jak zapomnisz albo walidować albo odpowiednio escapeować inputa to ktoś tam sobie coś może dorzucić. Wspomniał też o bindowaniu, które uchroni Cię przed SQL injection. Jeśli masz upload plików i nie zrobisz odpowiedniej walidacji takiego i jednocześnie umieścisz go gdzieś publicznie, to ktoś będzie mógł go wykonać. Możesz zapisać coś co nie powinno być zmieniane/widoczne dla klienta w ciasteczku. Możesz nie sprawdzić/źle sprawdzać uprawnienia do danego zasobu - na widoku jest super, guzik ukryty, a jak ktoś ręcznie wywoła requesta pod ten adres to przejdzie. Można pobrać złe dane z bazy (np. gdzieś przypisać złe id relacji) i już wyświetlisz komuś informacje dotyczące kogoś innego. Masa takich kwestii nad którymi trzeba po prostu myśleć podczas pisania. Możesz zapomnieć włączyć HTTPS, które jest standardem, aby nikt nie podsłuchał komunikacji. Generalnie to wcale nie muszą być nie wiadomo jak wyrafinowane ataki, czasem po prostu głupie przeoczenia albo niezbyt przemyślane ruchy.

Podobne pytania

0 głosów
2 odpowiedzi 312 wizyt
pytanie zadane 12 lipca 2022 w JavaScript przez Doge Gaduła (3,320 p.)
0 głosów
3 odpowiedzi 350 wizyt
0 głosów
1 odpowiedź 516 wizyt
pytanie zadane 8 marca 2021 w PHP przez fff Gaduła (3,950 p.)

92,452 zapytań

141,262 odpowiedzi

319,080 komentarzy

61,854 pasjonatów

Motyw:

Akcja Pajacyk

Pajacyk od wielu lat dożywia dzieci. Pomóż klikając w zielony brzuszek na stronie. Dziękujemy! ♡

Oto polecana książka warta uwagi.
Pełną listę książek znajdziesz tutaj.

Akademia Sekuraka

Akademia Sekuraka 2024 zapewnia dostęp do minimum 15 szkoleń online z bezpieczeństwa IT oraz dostęp także do materiałów z edycji Sekurak Academy z roku 2023!

Przy zakupie możecie skorzystać z kodu: pasja-akademia - użyjcie go w koszyku, a uzyskacie rabat -30% na bilety w wersji "Standard"! Więcej informacji na temat akademii 2024 znajdziecie tutaj. Dziękujemy ekipie Sekuraka za taką fajną zniżkę dla wszystkich Pasjonatów!

Akademia Sekuraka

Niedawno wystartował dodruk tej świetnej, rozchwytywanej książki (około 940 stron). Mamy dla Was kod: pasja (wpiszcie go w koszyku), dzięki któremu otrzymujemy 10% zniżki - dziękujemy zaprzyjaźnionej ekipie Sekuraka za taki bonus dla Pasjonatów! Książka to pierwszy tom z serii o ITsec, który łagodnie wprowadzi w świat bezpieczeństwa IT każdą osobę - warto, polecamy!

...