Witaj Gościu! ( Zaloguj | Rejestruj )

Forum PHP.pl

> Bezpieczeństwo strony, a GET
virtualman
post
Post #1





Grupa: Zarejestrowani
Postów: 41
Pomógł: 0
Dołączył: 17.03.2011

Ostrzeżenie: (0%)
-----


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! ((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!
Go to the top of the page
+Quote Post
 
Start new topic
Odpowiedzi
Crozin
post
Post #2





Grupa: Zarejestrowani
Postów: 6 476
Pomógł: 1306
Dołączył: 6.08.2006
Skąd: Kraków

Ostrzeżenie: (0%)
-----


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
Go to the top of the page
+Quote Post

Posty w temacie


Reply to this topicStart new topic
2 Użytkowników czyta ten temat (2 Gości i 0 Anonimowych użytkowników)
0 Zarejestrowanych:

 



RSS Aktualny czas: 14.10.2025 - 17:07