Bezpieczeństwo strony, a GET Opcje

[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

[HTML] pobierz, plaintext 
a href="strona.domena/post/like.php?id=666"
[HTML] pobierz, plaintext 

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! ((IMG:style_emoticons/default/haha.gif) ) Jak patrzyłem to FB sprytnie sobie radzi - bez JS nie działa (przynajmniej wersja, którą mam zainstalowaną - jakaś testowa) (IMG:style_emoticons/default/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]

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 (IMG:style_emoticons/default/smile.gif) Dlatego najbardziej poprawny/bezpieczny jest sposob 1 (IMG:style_emoticons/default/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>

Ten post edytował virtualman 20.10.2013, 17:33:07

[nospor]

Hm, a są jakieś zastrzeżenia do sposobu PrinceOfPersia'ego?

Wymusic klikniecie takiego linka mozna przez spreparowanie forma na jakiejs stronie

[wujek2009]

[HTML] pobierz, plaintext 
<form action="strona.domena/post/like.php" method="post">
  <input type="hidden" name="id" value="666" />
  <input type="hidden" name="sid" value="Identyfikator sesji lub coś podonego" />
</form>
[HTML] pobierz, plaintext 

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.

Ten post edytował Crozin 20.10.2013, 18:36:30