Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: Bezpieczeństwo strony, a GET
Forum PHP.pl > Forum > PHP
virtualman
Witam,
programuje pewną stronę, która ma kilka funkcji społecznościowych. Problemy z jakim się spotkałem wygląda następująco - dla użytkowników, którzy mają wyłączone JS przycisk do funkcji takiej jak np.: lubię to ma wyglądać jakoś tak
  1. a href="strona.domena/post/like.php?id=666"

Tylko nie jestem pewny czy takie rozwiązania się stosuje? Oczywiście w like.php będzie filtrowane czy jest to ID i czy dany użytkownik ma uprawnienia do wykonania tej akcji, ale co będzie jeśli jakiś cwaniak wyśle nieświadomemu użytkownikowi "ej wejdź na strona.domena/post/like.php?id=666", a ten idiota to kliknie? Wtedy dany post zostanie polubiony czy mu się to podoba czy nie. Niby dla takich funkcji jak dodawanie np.: lubie to, nie jest to jakieś szczególne zagrożenie, ale teraz weźmy sytuację gdy przycisk ma funkcję usuwania użytkownika z znajomych, a ktoś zrobić psikusa i wyśle link do tego - ofiara usunie znajomego z przyjaciół i jakie mogą być tego konsekwencje! (haha.gif) Jak patrzyłem to FB sprytnie sobie radzi - bez JS nie działa (przynajmniej wersja, którą mam zainstalowaną - jakaś testowa) biggrin.gif
Myślę, że rozumiecie o co mi chodzi, macie jakieś pomysły na rozwiązanie problemu?
Pozdrawiam - Maciek!
nospor
Rozwiazan jest kilka:
1) Jak ktos klika link: strona.domena/post/like.php?id=666 to mu wyswietlasz info: "Jestes pewien?" i Dopiero jak potwiedzi to wykonujesz.
2) Mozesz sprawdzac skad przyszedl, przez REFERERA. Jak nie ze strony, gdzie moze byc taki link to go odwalasz. To ma jednak wade, ze nie zawsze idzie REFERER nawet jak jest z poprawnej strony odsylany i mozesz przez to blokowac uczciwe like
3) W sesji zapamietujesz gdzie byl ostatnio. Jak na stronie gdzie moze byc link, to pozwalasz na LIKE
virtualman
Hm, a co jeśli użytkownik otworzy stronę jedną i potem w nowym oknie drugą, a następnie wykona akcję z pierwszej(mówimy o sposobie z sesjami)? Wtedy "pozycja" nie będzie określona poprawnie, bo będzie nadpisana przez otworzenie drugiej strony...
PrinceOfPersia
jak chcesz, żeby działało bez JS, to możesz zrobić tak, że zamiast <a href... robisz formularz z jednym polem submit:

<form action="strona.domena/post/like.php?id=666" method="POST">
<input type="submit">polub</input>
</form>

z tym, że formularz powinien być wysyłany POST, żeby było najbardziej prawidłowo (bo żądanie GET zwyczajowo nie powinno nic zmieniać)

nospor
Cytat
Hm, a co jeśli użytkownik otworzy stronę jedną i potem w nowym oknie drugą, a następnie wykona akcję z pierwszej(mówimy o sposobie z sesjami)? Wtedy "pozycja" nie będzie określona poprawnie, bo będzie nadpisana przez otworzenie drugiej strony...
Zgadza sie smile.gif Dlatego najbardziej poprawny/bezpieczny jest sposob 1 smile.gif

Zas co do bledu sesji co napisales, to mozna w sesji pamierac historie wywolan i sprawdzac czy żądana strona znajduje sie w historii a nie bezposrednio w ostatniej
virtualman
Hm, a są jakieś zastrzeżenia do sposobu PrinceOfPersia'ego?
Tzn.: <form action="strona.domena/post/like.php" method="POST"><button type="submit" name="id" value="666">polub</button></form>
nospor
Cytat
Hm, a są jakieś zastrzeżenia do sposobu PrinceOfPersia'ego?
Wymusic klikniecie takiego linka mozna przez spreparowanie forma na jakiejs stronie
wujek2009
  1. <form action="strona.domena/post/like.php" method="post">
  2. <input type="hidden" name="id" value="666" />
  3. <input type="hidden" name="sid" value="Identyfikator sesji lub coś podonego" />
  4. </form>


Dla pewności możesz nadać nowy parametr, gdzie przekazujesz ID sesji - choć w tym przypadku nieobowiązkowy.
Poza tym Facebook dobrze robi, że blokuje w całkowicie klikanie bez włączonej obsługi JS w przeglądarce. Użytkownik sam sobie działa na szkodę, że wyłącza takie dodatki.
Crozin
Wystarczy tutaj najzwyklejsza ochrona przed CSRF w postaci tokenu. Większość artykułów/przykładów znajdziesz w zastosowaniu w kontekście formularzy (ukryte pole z kluczem), ale w przypadku linków wygląda ono dokładnie tak samo. Po prostu, poza ID obiektu do polubienia dodaj dodatkowy parametr z tokenem CSRF.

Rozwiązania typu sprawdzanie nagłówka Referer czy tworzenie jego odpowiednika przy pomocy sesji, to tylko kulawe protezy. Samo zmienienie typu żądania HTTP z GET na POST jedynie w minimalnym stopniu utrudnia wykonanie takiego ataku - samo w sobie nie jest rozwiązaniem.
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2025 Invision Power Services, Inc.