Mam stronę z formularzem. Liczy on około 50 pól, a więc sporo. Na obecnym etapie przesyłam to do PHP i tam generuję plik PDF.
Walidacja po stronie PHP jak i JS "robi" się, ale zastanawiam się jeszcze nad zabezpieczeniem przycisku "generuj PDF".
Jest sens dodawać element typu recaptcha? Albo pole tekstowe "ile to jest 2+2?"? Chodzi o zabezpieczenie przeciwko automatom. Z drugiej strony czy tutaj jest coś niebezpiecznego jeżeli chodzi o generowanie pliku PDF?
0
3
Co do ryzyka - jeśli jakiś XSS nie wchodzi w grę, to jedynie można się obawiać zalewu śmieciowych PDF'ów.
Pytanie - czy ten formularz jest ogólnodostępny, czy jedynie po zalogowaniu/dla wybranych userów?
Jeśli captcha odpada, to ja bym się zabezpieczył tak:
- po stronie frontu jakieś ciasteczko, które będzie miało podaną godzinę ostatniej wysyłki - żeby koleś nie mógł spamować wysyłką
- po stronie serwera jakiś limit X wysłań formularza na jakiś czas. Konkretne wartości do ustalenia metodą prób i błędów.
5
Kiedyś widziałem taki system, że sprawdzał ile mniej więcej potrzeba czasu na wypełnienie formularza i jak ktoś (automat) zrobił to za szybko to się nie wykonywała akacja. 50 pól dla normalnego człowieka to będzie powyżej 1 min dla automatu poniżej 10 sekund. Jak połączysz to z tym, co zaproponował @cerrato to będziesz miał full opcje.
0
Można zrobić dodatkowe pole formularza z typu "Ile to 2 + 2" i rzucić gdzieś indziej informacją, żeby pozostawić to pole puste. Na pewno jakieś boty nie dadzą sobie z tym rady.
0
PDF jest generowany w oknie przeglądarki, na serwerze nic nie zasypuję. Założenie jest takie, że klient to drukuje, podpisuje i wysyła skan.
0
No to w ogóle nie rozumiem, w czym jest problem.
Jeśli cała akcja w żaden sposób nie obciąża serwera (poza przesłaniem treści formularza, który jest wypełniany i przetwarzany po stronie frontu) to o co chodzi? Niech sobie boty generują i miliony takich PDF'ów ;)
0
Odpowiem jeszcze na poprzednie pytanie: formularz jest ogólnodostępny.
A ciasteczek staram się unikać. Inaczej będzie robota z zaimplementowaniem kodu komunikatu odnośnie zgody.
Co do zabezpieczenia, to zdecyduje się na opcję "można wysłać 1 formularz w przeciągu 2 minut".
2
kosmonauta80 napisał(a):
Odpowiem jeszcze na poprzednie pytanie: formularz jest ogólnodostępny.
Mam wrażenie, że cos kombinujesz. Nie wiem, jaki to ma problem rozwiązać, ale chyba coś przekombinowałeś.
A ciasteczek staram się unikać. Inaczej będzie robota z zaimplementowaniem kodu komunikatu odnośnie zgody.
Jak dobrze wiem o technicznych ciastkach nie musisz już informować.
0
PDF generuje skrypt PHP, a więc back-end. Moim zdaniem nie ma tu zagrożenia dla serwera, aczkolwiek wolałem się zapytać :)
Później dodam zapis do bazy SQL, ale to faktycznie będzie wymagało "pancernych" zabezpieczeń.
1
No to się wcześniej nieprecyzyjnie wyraziłeś - bo dla mnie fragment PDF jest generowany w oknie przeglądarki oznacza, że wszystko się dzieje na froncie.
A co do serwera - jeśli na razie nie masz żadnych DOS'ów z powodu tysięcy jednocześnie wypełnianych wniosków przez automaty, to bym nie tracił na to czasu.
0
Po stronie JS formularz zabezpieczyłem tak, że skrypt nie pozwoli na wpisanie w formularz znaków innych, niż litery, cyfry oraz wybranych znaków specjalnych: ./”“"'& -
Pytanie teraz odnośnie domyślnej walidacji, jaką wykona przeglądarka po naciśnięciu przycisku submit: zostawić ją jako 2 linę obrony, czy wyłączyć i zdać się na JS?
Oczywiście po stronie PHP też będzie filtr.
Jak by kogoś ciekawiło, to poniżej fragment kodu:
for (let n = 1 ; n < liczba_pol ; n++)
{
formularz[n].addEventListener('blur', function()
{
...
if (!wyrazenie_regularne.test(tresc_pola))
A po co tyle kombinowania? Docelowo zawartość formularza będzie trafiać do bazy SQL na serwerze.