Witam,
jak w czasach SPA zabezpieczyć żądania AJAX?. Np wysyłam call z JSON'em który pobiera maile dla zalogowanego usera, oczywiście to mogą być inne parametry, które wynikają ze stanu aplikacji.... Jako programista wiem, że nie jest problemem otworzyć Postmana i wygenerować JSON'a i podejrzeć cudze dane
{
'tableProvider':'operatorEmails',
'idOperator':12
}
i podejrzeć cudze dane
Jak to cudze? Napisałeś przecież sam: aktualnie zalogowanego usera.
No ale aktualne id operatora idzie w żądaniu, tak samo może iść pobierz listę cenników dla firmy gdzie idFirmy idzie jako parametr, a co za tym idzie można to podmienić
Po stronie API powinieneś dokonywać walidacji czy dany użytkownik może uzyskać dostęp do wskazanego zasobu, ew. zmienić nieco założenia.
Np. w celu pobrania danych aktualnie zalogowanego użytkownika możesz udostępnić route /my/data zamiast /users/{id}.
To spora zadyma z ta walidacją. Można wyobrazić sobie tabelkę master slave. Klikam na wiersz master i mam pozycje.... Dane pozycji uzyskiwane są
items/{idSaleDocument} - i już mamy możliwość oszustwa
Dlatego powinieneś dla każdej akcji walidować czy dany użytkownik ma do niej dostęp (po stronie API!).
Dzięki, jestem ciekawy czy tak ludzie robią(pamiętają) bo w necie nie wiele info o tym. A może jakieś hashowanie żądań
Praktycznie każdy framework webowy ma wbudowane mniej lub bardziej automatyczne rozwiązania w kwestii ACL, dzięki którym dodanie takiej walidacji to kwestia jednej linijki kodu.
Nie baw się w żadne szyfrowanie żądań - wszystko, co dzieje się po stronie użytkownika, jest niebezpieczne i podatne na złamanie oraz wykorzystanie.
Połączenie HTTPS + np. JWT i jesteś względnie bezpieczny, a robi się to w dosłownie kilku linijkach.
JWT polega w skrócie na tym, że serwer w trakcie logowania generuje token, który zawiera info o algorytmie szyfrującym, dacie wygaśnięcia, jakieś własne dane (np. id usera czy jego imię) i zaszyfrowane poprzednie części. Szyfrowanie jest z użyciem klucza znanego tylko serwerowi. Serwer odsyła token po zalogowaniu, a potem klient musi go do każdego żądania dodać. Tylko serwer potrafi odszyfrować ostatnią część tokena więc może sprawdzić czy to co się tam znajduje jest ok. Jeżeli po stronie klienta token jest trzymany w sensowny sposób, np. w bezpiecznym ciasteczku, do którego nie ma bezpośrednio dostępu z JSa to jest ok.
Tak to robię dla aplikacji korzystających z REST API.
HTTPS zapewnia bezpieczeństwo informacji m.in. w trakcie logowania (nikt teoretycznie nie podsłucha).
Pomijając już kwestię autentykacji i autoryzacji - wystawianie w API idików bazodanowych zamiast jakiś uuid to zwykle głupi pomysł.
@mar-ek1 JWT rozwiązuje całkowicie inny problem. Jak rozwiążesz mój problem z pomocą ciasteczek??? Przecież żądanie idzie z klienta
Wszystkie żądania wymagające uprawnień (np. dla danych widocznych tylko dla konkretnego użytkownika) powinno wymagać obecności np. JWT w requeście. Nie ma tokena == nie ma odpowiedzi z danymi. Żeby mieć token użytkownik musi dostać go z serwera. To serwer na podstawie odesłanej informacji o użytkowniku z tokena ( czy to w body czy w ciasteczku) decyduje czy ten ma prawo dostać odpowiedź czy nie.
Jeśli wygenerujesz JSON np. w Postmanie i nie dodasz tokena albo dodasz niepoprawny to serwer po prostu zwróci status 403 (czy jaki tam mu ustawisz) i nie zobaczysz danych nie będąc zalogowanym.
Dodatkowo jeżeli nie udostępniamy API publicznie to można ograniczyć przyjmowanie zapytań do jednej domeny, na której stoi nasza SPA.
Dobra na podstawie wypowiedzi mamy ustalone, że po stronie serwera musi być weryfikacja. Znacie jakieś frameowrki ze świata JS które ogarniają takie rzeczy bo szukając znalazłem tylko ACL(do expressa) ala Role Based czyli użytkownik z rolą X może wejść i zrobić jakieś operacje. Ale nigdzie nie widzę jak definiować ograniczenia na zasadzie użytkownik X jest właścicielem danych Y więc może je edytować....albo użytkownik X należy do firmy Y więc może widzieć dane z tej firmy....chyba, że takie rzeczy trzeba ręcznie oprogramować
Takie rzeczy jak "użytkownik X jest właścicielem danych Y więc może je edytować....albo użytkownik X należy do firmy Y więc może widzieć dane z tej firmy" to już są wymagania biznesowe więc trzeba je po części ręcznie obsłużyć. Czy zrobisz to na zasadzie "dane Y zostały utworzone przez użytkownika X i mają przypisane jego ID" albo "Użytkownik X z rolą Z może edytować dane z tabeli Y" to już zależy od Ciebie.
Frameworki mogą Ci co najwyżej w tym pomóc, np. ułatwiając zarządzanie rolami czy wyciąganie konkretnych danych.
@Szczery: W czym masz postawiony backend, że szukasz JSowych frameworków?