Clicky

Skocz do zawartości


Zdjęcie
- - - - -

[K3] CSRF - a podkładanie "świni"

11 odpowiedzi w tym temacie

  • Zaloguj się, aby dodać odpowiedź

#1 Daredzik

Daredzik

    Młodszy Mastah

  • Użytkownik
  • PipPip
  • 308 postów
  • Skąd:Pszczyna

Napisano 23 lipiec 2013 - 11:51

Witam,
tak sobie dzisiaj rozkminiałem nad bezpieczeństwem.
kohana sama w sobie chroni nas przed kilkoma atakami, ale wyobraźmy sobie taką sytuację (z życia wziętą).
User aby mieć dostęp do panelu musi się zalogować, następnie w każdym miejscu w panelu w before() jest sprawdzane jego role i prawa itd. (dajmy na to Simple_Auth) user może dodawać nowe posty, edytować ja oraz usuwać swoje posty. Przed usunięciem innego posta niż swojego odpowiednio się zabezpieczamy sprawdzając czy user jest jego właścicielem, jeśli tak dopiero usuwamy jeśli nie rzucamy wyjątek.
Przed przypadkowym usunięciem chroni nas okno modalne z prośbą o potwierdzenie, a następnie jesteśmy kierowani (czy to ajaxem czy redirectem na controller usuwający dajmy na to: domena.pl/auth/user/deletepost/123) a następnie po usunięciu jest redirect do listy wszystkich postów.
Dajmy na to, że sesja zalogowania trwa 1h, w tym samym czasie user może przeglądać inne strony, dajmy na to, że odwiedza jakieś forum i w pewnym poście natrafia na podpis usera
[IMG]domena.pl/auth/user/deletepost/123[/IMG]
bbcode oczywiście przepuści to a w tym momencie mamy aktywną sesję i co, post leci do kosza. (niedobra świnia)...

No i teraz moje pytanko, jak się przed tym draństwem zabezpieczyć, kohana ma fajny helper security gdzie mamy security::token().
ale doklejanie za każdym razem tokenu do linku i sprawdzanie go przed usunięciem, nie jest za fajnym sposobem.

Mamy tutaj mega super uber mastachów ;) więc podzielcie się wiedzą ;)

#2 thejw23

thejw23

    Senior Mastah

  • Webmastahy
  • PipPipPip
  • 824 postów

Napisano 23 lipiec 2013 - 12:20

Dlaczego doklejanie tokena do linku uważasz za słabe rozwiązanie?

Zamiast doklejać do linku można też w oknie modalnym ustawić token w sesji, taki do skasowania konkretnego typu (np. artykuł) i konkretnego ID, przy kasowaniu sprawdzamy czy token w sesji jest (i zgadza się typ i ID). W przypadku linka z img tokena nie będzie, przy ręcznym kombinowaniu też nie będzie (nawet jak jestem zalogowany, to będę musiał przeklikać aby skasować)


#3 sv85

sv85

    Początkujący

  • Użytkownik
  • Pip
  • 19 postów

Napisano 24 lipiec 2013 - 20:52

Możesz też pozwalać na kasowanie tylko poprzez zapytania POST to pozornie zabezpieczy aplikacje przed tego typu atakiem :)

Token wydaje się najmniej inwazyjny, bo zawsze zostaje opcja utrudnienia życia uzytkownikowi poprzez przepisywanie czegoś:  captcha, token sprzętowy/






#4 lukaskolista

lukaskolista

    Młodszy Mastah

  • Użytkownik
  • PipPip
  • 414 postów

Napisano 27 lipiec 2013 - 09:04

To ja sie podziele swoja wiedza z zakresu ogromnego systemu informatycznego. Tam ten problem wystepuje i jest rozwiazany nastepujaco:
Nie ujawniamy userom prawdziwych danych identyfikujacych na podstawie ktorych sa wykonywane operacje. I wystarczy. A jest to robione tak, ze np. identyfikator rekordy jest kodowany na podstawie sesji. Czyli 2 rozne id w 2 roznych sesjach teoretycznie moga miec ten sam hash, ale po wyslaniu do serwera i odhashowaniu sa juz unikalne. Podsumowywujac:
- id hashujemy kluczem sesji + solimy to bo klucz sesji mozna wyciagnac z cookie (lub jakikolwiek inny mechanizm nieznany userowi),
- do klienta (przegladarki) wysylamy jedynie hash,
- klient do serwera wysyla tylko hash.

W zwiazku z powyzszym odgadniecie hasha id rekordy jest niemozliwe, poniewaz dla sesji x hash dla wartosci 3 moze wygladac tak: fsiofgseu, a dla tej samej wartosci tylko ze w innej sesji moze wygladac tak: hodrgdrghdr. Prawdopodobienstwo trafienia takiego hasha jest rowne z trafieniem tokena, czyli bliskie 0.

Pomijajac cale te hashowanie i zabezpieczanie kluczami wystarczy sprawdzic referrer, wtedy linki na forach przestana dzialac. To tak na pierwsza linie obrony. Ktos powie, ze referrer mozna podmienic: oczywiscie, ze mozna, ale trzeba tez znac klucz sesji.

#5 Daredzik

Daredzik

    Młodszy Mastah

  • Użytkownik
  • PipPip
  • 308 postów
  • Skąd:Pszczyna

Napisano 28 lipiec 2013 - 10:15

@up
sposób przedstawiony przez ciebie chroni tylko przed kradnieciem sesji, a ja chce zabezpieczyć się przed podlozeniem swini. Bo user moze być cały czas zalogowany a ktoś podesle mu linka do usunięcia np. Jako obrazek w bbcode albo mailu i co? Twoj sposób nie chroni przed tym bo sesja jest cały czas aktywna ;)

#6 sv85

sv85

    Początkujący

  • Użytkownik
  • Pip
  • 19 postów

Napisano 28 lipiec 2013 - 11:38

@up

nie do końca bo atakujący nie znając id sesji nie jest w stanie wygenerować linku z poprawnym id obiektu skoro jest ono szyfrowane

#7 lukaskolista

lukaskolista

    Młodszy Mastah

  • Użytkownik
  • PipPip
  • 414 postów

Napisano 28 lipiec 2013 - 20:03

Moj sposob nie chroni przed kradzieza sesji a przed podlozeniem swini, przeczytaj ze zrozumieniem :) za pomoca klucza sesji i soli hashuje id rekordu z bazy, wiec podlozenie swini jest tak samo prawdopodobne, jak trafienie 6 w lotka

#8 Daredzik

Daredzik

    Młodszy Mastah

  • Użytkownik
  • PipPip
  • 308 postów
  • Skąd:Pszczyna

Napisano 28 lipiec 2013 - 20:48

Mea culpa, faktycznie zle zrozumiałem, myslalem ze chodzi ci o id uaera a nie obiektu do usunięcia bądź modyfikacji.
Ale w takim razie i tak wykonujesz o jeden redirect wiecej, no chyba ze druga sesje z sola tworzysz za pomocą ajaxa. ???
Jesli nie no to kiedy tworzysz i jak drugi hash?? Przecież nie po kliknięciu w link.

#9 lukaskolista

lukaskolista

    Młodszy Mastah

  • Użytkownik
  • PipPip
  • 414 postów

Napisano 29 lipiec 2013 - 08:18

Dalej nie rozumiesz xD

Hash tworze na serwerze i na serwerze go odkodowywuje, czyli (na szybko):

public function action_index()
{
$hash = $this->request->param('id');
$id = $this->decode($hash);
$book = ORM::factory('Book', $id);
echo '<a href="books/index/'.$this->code($book->id).'">'.$book->title.'</a>';
}
Nie ma zadnych redirectow i ajaxow do kodowania :) Metoda decode() dekoduje hash do id, natomiast metoda code() koduje id do hasha.

W rezultacie dla usera widoczny w linku jest hash np. gsdoghdraghrdgdr, natomiast na serwerze operacje wykonywane sa na id np. 10, a poniewaz hash jest na podstawie klucza sesji i soli (mozna inny algorytm symetryczny), to dla kazdej sesji id 10 ma inny hash w rezultacie czego wygenerowanie szkodliwych linkow jest praktycznie niemozliwe.

#10 Daredzik

Daredzik

    Młodszy Mastah

  • Użytkownik
  • PipPip
  • 308 postów
  • Skąd:Pszczyna

Napisano 29 lipiec 2013 - 18:15

No to chyba ty nie rozumiesz ;) to sprowadza się do dopisania hasha do linku tak samo jak token. Pierwsza odpowiedz w tym temacie pokrywa się z tym co napisałeś, a ja zaznaczyłem na początku, ze chce to zrobic bez tokena. A w swoim poprzednim liście nic nie wspomniałeś o dopisywaniu do linka ;) tak wiec znów chciałeś na mnie wjechać nie wiedząc czemu i po co no ale nie pyklo ;)

#11 mck

mck

    Jestę Blogerę

  • Admin
  • 1544 postów

Napisano 29 lipiec 2013 - 19:46

U nas w przypadku odpalenia GET costam/delete/id wyskakuje formularz z potwierdzeniem (radio tak/nie). Po stronie serwera ofc odpowiednia weryfikacja, csrf w formie, itp. Możesz sprawdzać też referrera i w podejrzanych wypadkach do forma dorzucić np. captchę.
Przed usunięciem bezpośrednio przez GET-a bez dodatkowych zabezpieczeń się nie uchronisz - zawsze musisz dorzucić mu jakiś token albo posadzić ciastko, itp.

#12 lukaskolista

lukaskolista

    Młodszy Mastah

  • Użytkownik
  • PipPip
  • 414 postów

Napisano 29 lipiec 2013 - 21:08

Nic nie doklejam do linka... nie doklejam zadnego tokena, tylko hashuje id rekordu (lub inne dane jezeli trzeba je przekazac)... nie bede po raz 5 tlumaczyl. Moj sposob od tokena jest lepszy o tyle, ze user nie widzi identyfikatorow rekordow ktorych ze wzgledow bezpieczenstwa czesto nie powinien widziec (np. bankowosc internetowa)




Użytkownicy przeglądający ten temat: 0

0 użytkowników, 0 gości, 0 anonimowych