[Khaine]

#webdev #programowanie

Jak się zabezpiecza strony internetowe przed modyfikowaniem i ręcznym wywoływaniem pewnych rzeczy? Przykładowo mielibyśmy sobie jakąś funkcję JSową typu "SaveUserData", która zapisuje ustawienia użytkownika do bazy. No i teraz jakby ktoś był sprytny, to mógłby sobie pod F12 taką funkcję odkopać (ma przecież nawet debuger, może sobie popatrzeć co się dzieje w programie jak ktoś kliknie przycisk) i ją sobie wywołać z innymi argumentami albo po prostu ją skopiować, przepisać po swojemu i podmienić aby aplikacja sama siebie zrobiła w wuja. Jak są zabezpieczone fejzbuki, banki i inne takie?

[dziekuje]

@Khaine: Od tego jest osobny dział IT. A przed wypuszczeniem takiej aplikacji robi się testy penetracyjne u firm, które się w tym specjalizują.

[Gilbertus]

Frontend to tylko graficzna nakładka, dane wejściowe zawsze musisz weryfikować w backendzie tak aby ktoś nie narozrabiał za bardzo.

[Khaine]

@dziekuje: Ja się nie pytam kto to robi, tylko jak się to robi xD

[Rst00]

@Khaine: backend po prostu musi być zabezpieczony. Jak user "wywołuje" daną akcję np. modyfikacja hasła to przesyła do serwera pewne dane pozwalające na identyfikację np. cookies, nagłówek z tokenem itd. Backend następnie te dane sprawdza i jeżeli stwierdzi że user może wykonać tę akcję to ją wykonuje, jeżeli nie no to zwraca odpowiedni kod błędu np. 401

[Khaine]

@Gilbertus: A skąd ja mam wiedzieć w backendzie kto jest zalogowany w tej chwili skoro sesja jest zapisana po stronie klienta? Backend dostaje POST i go obsługuje. Jak mam zweryfikować, że ktoś nie podmienił ID użytkownika przykładowo?

[Rst00]

@Khaine: jak sesja jest zapisana po stronie klienta? Sesje masz na serwerze, a user ma tylko jakiś identyfikator sesji który jest przesyłany razem z zapytaniem np. w cookiesie czy jako header np. token. Jak tego nie ma lub jest błędne to backend zwraca "spadaj".

[Yahoo_]

@Khaine zasada taka jak przy grach multiplayer. To serwer weryfikuje prawidłowość danych, autoryzuje możliwość wykonania żądania. Czyli Twoje SaveUserData powinno z poziomu JS powinno pozwalać na zmianę tylko tych parametrów, które użytkownik ma prawo zmieniać samemu (np. Adres). Nie możesz np. wysłać informacji, że zapłacił jakąś fakturę, bo będziesz miał problem jak opisałeś powyżej.
Do tego istnieją programy, które skracają i podmieniają nazwy zmiennych, żeby kod był lżejszy i mniej czytelny,

[Desseres]

@Khaine: jeżeli mówimy o SPA które jest odcięte od backendu to używaj JWT: https://jwt.io/
Jeżeli masz backend renderujący front to tutaj masz informację o zarządzaniu sesją: https://www.owasp.org/index.php/Session_Management_Cheat_Sheet

[juniordev]

@Khaine: czy ty serio myślisz, że na backendzie nie jesteś w stanie zweryfikować usera/sesji? Chociażby taki JWT

[Gilbertus]

Sesja po stronie klienta? Śmiałe podejście. Jeśli rozmawiamy o PHP to sesja jest po stronie backendu, a jedynie klucz sesji jest po stronie klienta.

[Yahoo_]

@Khaine widzę że się spóźniłem trochę. Jeśli chodzi o taką zmianę hasła no to przykładzik jest oczywisty. Musisz mieć sesje powiązaną z użytkownikiem i użytkownik ma prawo zmieniać tylko swoje hasło. W każdym innym przypadku zwracasz błąd autoryzacji.

[Khaine]

@Rst00: Czyli mówiąc krótko backend nie jest bezstanowy i pamięta kto się logował? Każdorazowo pewnie sprawdza także autoryzację użytkownika do uzyskania pewnych danych, bo jakiś cwaniak mógłby kombinować z wywoływaniem funkcji z konsoli.

[Gilbertus]

@Khaine: tak

[juniordev]

@Khaine: Do samej autoryzacji i autentykacji użytkownika dochodzi jeszcze autoryzacja aplikacji. Serwer moze byc tak skonfigurowany że nie zaakceptuje zapytań pochodzących z nieznanych domen/aplikacji.

[Rst00]

@Khaine: no oczywiście że nie jest bezstanowy, musi pamiętać kto wywołuje tę akcję bo np. w przypadku zmiany hasła komu miałby je zmienić? W dużym skrócie w nowoczesnej aplikacji:
1. User wywołuje strzał do API np. zmiana hasła
2. Leci request z headerem Authorization: JWT TOKEN
3. Backend odczytuje request, w "kontrolerze" ma warunek np. isUserAuth() a ta metoda z kolei sprawdza czy token jest poprawny i jeżeli tak to

[dog_meat]

@juniordev: w teorii może być bezstanowy. Jeśli front wyśle żądanie z tokenem JWT, to backend może zajrzeć do niego i tylko sprawdzić, czy jest prawidłowo podpisany

[veranoo]

@Khaine: nie pisz takich bzdur, po oczy bolą od czytania