Dzieki :-) Chyba będę musiał poczytać :-)



Bawiłem się w takie tokeny w zabezpieczeniach typu captcha do komentarzy na serwisach. Hmm... zastanawiam się bo mam pewien serwis który muszę dobrze zabezpieczyć, czy zrobić w nim taką tokenową wędrówkę po całym serwisie.... Uważasz, że zabezpieczałoby to skutecznie przed 'lądowaniem na podstronach z niewłaściwego miejsca' ? czyli to o co mi wcześniej chodziło?

tak zalozmy ze wchodzisz na strone profil.php na ktorej jest link do strony usun_konto.php, parametrem tego linku jest token, teraz po wejsciu na strone usun_konto spr czy token z url jest taki sam jak w sesji, jesli tak to znaczy ze user kliknal na odpowiedni link na odpowiedniej stronie

I oczywiście bełdzio dasz sobie czapkę z avatara zerwać, że żadna wtyczka przyśpieszająca przeglądanie stron nie postanowi odczytać z wyprzedzeniem strony usun.php?token=najlepszy_z_najlepszych i nie spowoduje usunięcia danych ?

Pozdr.
Łukasz

generalnie to czapki nie oddam a co do wtyczek sie nie wypowiem bo nie do konca wiem o jakie cudenka chodzi

Był temat na forum kiedy o tym rozmawialiśmy - nie wiem czy to przypadkiem nie był ten temat.

To mogło by popsuć wiele rzeczy nie tylko przy korzystaniu z tokenów. Mam nadzieje, że żadna przeglądarka/wtyczka nie robi ładuje w tle innych linków niż oznaczone przez `rel="prefetch"`.

Nie w tym celu powstało zabezpieczenie przez CSRF - chodzi o to, aby np. nieświadoma osoba nie mogła kliknąć na złośliwie wysłany link typu plik.php?akcja=skasujProfil&confirm=1.

W sumie jak tak teraz pomyslalem ze maja racje nie wiedzialem ze tak sie mozna bronic przed CSRF.

Wyobrazcie sobie sytuacje jest sobie forum z takim bugiem i jest jakis temat powiedzymy ze forum ktore uzywaja to jakis open-source ktos podaje np link do usuwanie news'a z odpowiednim id ktorys z adminow klika i po news'ie ale gdy token ktory podal napastnik z linku jest inny do nicy z tego w sumie ciekawy jest i atak jak i obrona

Czy mozecie powiedziec jakies inne sytuacje?

A do wikipedii, to Waść zaglądał...?

Zagladac zagldalem ale nie zawsze w wikipedi jest duzo napisane w sumie jest napisane to sam co ja napisalem czytalem inne linki i atak polega tylko na tym co opisalem przynajmniej z tego co ja wywnioskowalem.

Mowicie zeby dodac mozliwosc takeigo tokena do wszystkich waznych akcji, bo w sumie atak jest latwiejszy do przeprowadzenia niz XSS z kradzieza cookie.

Wymyśliłem sobie coś takiego

[PHP] pobierz, plaintext 
<?php
function checktoken()  {
  if($_SESSION['zeton']!=$_GET['token']) diee_close(); }
 
function generate_token() {
 $literki="abcdefghijklmnopqrstuwvxyzABCDEFGHIJKLMNOPQRSTUWVXYZ";
 $cyferki="0123456789";
 for($tokelen=1;$tokenlen<=32;$tokenlen++) {
   $token.=substr($literki,rand(0,strlen($literki)-1),1).substr($cyferki,rand(0,strlen($cyferki)-1),1);  }
 $_SESSION['zeton']=$token;
 return $token; }
?>
[PHP] pobierz, plaintext 

no i oczywiście na początku skryptów daję
checktoken();
$token=generate_token();

i wklejam ?token={$token} do linków...

To chyba lepsze niż moje poprzednie (raczej rzeczywiście beznadziejne) rozwiązanie ?
Jeżeli to jest OK to będę musiał to dodać w kilku serwisach.... no i chyba przyda się linuchowy sed do pododawania tokena w linkach :-)

Nie wiem co robi diee_close() ale jesli nic nie zwraca to moze nie dzialac bo troche nie ma sensu to raz a dwa to jakos kombinujesz ze sklejaniem ciagu i jeszcze nie bedzie on az taki losowy ja 2 dni temu napisac cos takiego jeszcze w praktyce nie uzywalem ale dzialac dziala:

[PHP] pobierz, plaintext 
<?php
function InitCsrfSession() {
 
  $InitLenght = rand(1,5);
  $EndLenght = rand(10,20);
 
  return substr(md5(time()), $InitLenght,$EndLenght);
 
}
 
 
function CheckCsrfSession($GetSession) {
 
  ($GetSession == $_SESSION['CSRF']) ? $bool = true : $bool =  false;
  
  return $bool;
 
}
 
//Przypisujesz
session_start();
$_SESSION['CSRF'] = InitCsrfSession();
?>
[PHP] pobierz, plaintext 

No masz racje :-) U mnie jest rzeczywiście mało losowo :-( Chyba będę musiał dodać coś z md5 tak jak u Ciebie. Dzięki za podpowiedź.

ob_start" title="Zobacz w manualu PHP" target="_manual + preg_replace" title="Zobacz w manualu PHP" target="_manual

O co chodzi^^

Prawdopodobnie można zbuforować zawartość stronki, podmienić określone wyrażenia i zapisać ponownie :-)

Tak, jak to robi mechanizm sesyjny dopisując SID w przypadku włączonego rewriter_tags.

przejrzałem posty w tym temacie, i ogólnie to wszystkie mówią o trochę bardziej skomplikowanych sytuacjach niż te, z którą ja mam do czynienia tzn:

Strona jest praktycznie statyczna, a php używam tylko do zaincludowania nagłówka i stopki, ale nazwy plików nie pochodzą z posta/geta tylko są zahardcodowane. Czy ciągnie to za sobą jakieś niebezpieczeństwo? Wolę się upewnić. Drugie pytanie, czy mechanizm google search engine może wpłynąć na bezpieczeństwo strony? Uzywam go w ten sposób:

Na stroni z wynikami:

[HTML] pobierz, plaintext 
<div id="cse-search-results"></div>
<script type="text/javascript">
  var googleSearchIframeName = "cse-search-results";
  var googleSearchFormName = "cse-search-box";
  var googleSearchFrameWidth = 600;
  var googleSearchDomain = "www.google.com";
  var googleSearchPath = "/cse";
</script>
<script type="text/javascript" src="http://www.google.com/afsonline/show_afs_search.js"></script>
[HTML] pobierz, plaintext 

formatka wyszukiwarki:

[HTML] pobierz, plaintext 
<form action="szukaj.php" id="cse-search-box">
              <div>
                <input type="hidden" name="cx" value="004632895002302782970:fakn9rzjcvi" />
                <input type="hidden" name="cof" value="FORID:11" />
                <input type="hidden" name="ie" value="UTF-8" />
                <input type="text" name="q" size="31" />
                <input type="submit" name="sa" value="Szukaj" />
              </div>
            </form>
 
<script type="text/javascript" src="http://www.google.com/coop/cse/brand?form=cse-search-box&lang=pl"></script>
[HTML] pobierz, plaintext 

ad1. poki nie pobierasz niczego z zewnatrz skryptu wsio jest ok
ad2. nie - no chyba ze Googla shakuja

Chciałem dowiedzieć się jak zabezpieczać się przed atakami CSRF więc zrobiłem testową aplikację do tego celu:
użytkownik może dodawać i usuwać znajomych oraz pisać komentarze a w nich umieszczać linki. Użytkownik może usunąć ze znajomych użytkownika klikając na link 'usuń' w swoim profilu w znajomych - na końcu linka jest podawany id znajomego do usunięcia:

[HTML] pobierz, plaintext 
<a href="/profil/znajomi/usun/<?php echo $z->getIdentyfikator() ?>" >usuń ze znajomych</a>
[HTML] pobierz, plaintext 

Po kliknięciu w linka, id jest oczywiście zamieniane na liczbę całkowitą, jest sprawdzenie czy w ogóle podano id, czy użytkownik o takim id istnieje oraz czy zalogowany użytkownik, który chce usunąć znajomego ma w swoich znajomych użytkownika o danym id.

Użytkownik o id=2 ma w znajomych uzytkownika o id=4.

Jako użytkownika o id=999 dodałem komentarz:
"Bla, bla,<IMG src="/profil/znajomi/usun/4"> bla, bla"

Następnie zalogowałem się jako użytkownik o id=2 i wszedłem na stronę z tym komentarzem, w skutek czego nie zobaczyłem oczywiście obrazka a z moich znajomych został usunięty użytkownik o id=4 bez mojej wiedzy i zgody - klasyczny przykład ataku CSRF.

Wymyśliłem więc sobie, że żeby usunąć użytkownika ze znajomych trzeba to potwierdzić - do czego użyłem ajaxa:

[HTML] pobierz, plaintext 
<a href="/profil/znajomi" onclick="potwierdzUsuniecieZnajomego(<?php echo $z->getIdentyfikator() ?>); " >usuń ze znajomych</a>
[HTML] pobierz, plaintext 

Po kliknięciu na linka wyskakuje messagebox z prośbą o potwierdzenie, w przypadku potwierdzenia do funkcji php z funkcji javascript jest przesyłany id użytkownika do usunięcia ze znajomych metodą post, w funkcji php jest sprawdzane czy żądanie przyszło metodą post itd. czego skutkiem jest usunięcie osoby ze znajomych.

Po wyłaczeniu w przeglądarce javascripta usunięcie uzytkownika ze znajomych nie jest możliwe, ale:
"Bla, bla,<IMG src="/profil/znajomi/usun/4"> bla, bla" już nie działa

Czy to wystarczające zabezpieczenie przed atakiem CSRF ?

nie przeciez zamiast odwolywac sie do adresu /profil/znajomi/usun/4 moge odwolac sie do adresu strony z potwierdzeniem, wlasnie kopiuje na blogaska notke o csrf tak wiec rzuc okiem za jakies 5 - 10 min

bełdzio wielkie dzięki - dzięki Tobie nareszcie zrozumiałem jak zabezpieczać się przed tymi atakami Super artykuł.

------------------
@edycja

Mam jeszcze pytanie odnośnie ataków CSRF - w przypadku linków usuwających coś z bazy danych wystarczy, że atakujący w komentarzu wpisze np.:

[HTML] pobierz, plaintext 
<img src="http://adres.pl?usun=10" />
[HTML] pobierz, plaintext 

Ofiara po wejściu na tę stronę z takim wpisem usunie nieświadomie coś tam o id=10. W takim wypadku rozumiem doklejanie unikatowego tokena do linku i potem go sprawdzanie.

Natomiast nie bardzo rozumiem dodawania do formularza ukrytego pola z tokenem. Co atakujący miałby wpisać żeby ofiara po wejściu na stronę z tym niebezpiecznym wpisem została nieświadomie przekierowana na stronę z formularzem i nieświadomie kliknęła na button typu submit ? To jest chyba niemożliwe w przypadku formularzy ?

wystarczy ze stworze na swojej stronie formularz z ukrytymi inputami i widocznym przyciskiem "WYgraj 100 000 pln"; user klika na button i na właściwy serwer przesyłane są dane, których autorem jest nasza ofiara

A jak macie formularze, np. żeby było bardziej obrazowo: formularz do wysyłania odpowiedzi na otrzymane prywatne wiadomości:

[HTML] pobierz, plaintext 
<form method="post" action="/wyslij_odpowiedz/na_wiadomosc/68/do_uzytkownika/11">
..........
</form>
[HTML] pobierz, plaintext 

To te numery - id w action można pozmieniać w dodatku do firefoxa: firebug. Więc po zatwierdzeniu formularza też należy sprawdzać czy dany użytkownik dostał wiadomość o danym id od danej osoby o danym id itd. ?

Najprostszym zabezpieczeniem przed atakami CSRF jest poprostu dodawanie id sesji i sprawdzanie jej. Np:

[PHP] pobierz, plaintext 
<?php
/*
...
tu wysylam jakis formularz i jako hidden daję id sesji
...
*/
 
if(empty($_POST['sess_id']) || $_POST['sess_id'] != session_id())
{
die('Czy napewno nie próbujesz mi zaszkodzić Panie majster?');
}
?>
[PHP] pobierz, plaintext 

Ale nie chodzi mi o ataki csrf tylko ataki wykonane programem firebug, dzięki któremu można dowolnie modyfikować kod html strony i dzięki temu zmieniać ID w akcji formularza, co w konsekwencji mego poprzedniego posta spowoduje wysłanie odpowiedzi do innej osoby niż nadawca danej wiadomości. Inny przykład to jak edytujemy dany post na jakimś forum i w akcji formularza za pomocą firebuga zmienimy ID to w ten sposób moglibyśmy zmodyfikować posta innej osoby jeśli po zatwierdzeniu formularza nie sprawdzimy czy dany użytkownik edytuje swój własny post ufając temu, że akcja formularza nie została zmieniona. Chodzi mi o to, że akcje formularza są tak samo niebezpieczne jak adresy URL i łatwe do modyfikacji programami typu firebug. Rozumie ktoś czy dać przykład ?

Rozumie. Tylko nie widzę pytania... bo na jedyne jakie postawiłeś sam sobie odpowiedziałeś.

Dopisująć się do Crozina:

@nieraczek, wygląda na to, że gadasz sam ze sobą

jakie są ograniczenia na wysylanie prywatych wiadomosci? bo jesli moge wyslac do kazdego to co za problem czy klikne w jego profilu "napisz wiadomosc" czy sobie zmienie w formie?

@bełdzio: A co jak ustawisz ID użytkownika, które nie istnieje? W przypadku gdy masz ustawione klucze obce w tabeli piękny błąd wywali.
Poza tym luki, które nawet potencjalnie są niegroźne powinny być szybko poprawiane.

1. wyslanie wiadomosci do nieistniejacego usera to nie luka
2. co za problem przechwycic blad i obsluzyc go? co za problem przed wyslaniem spr czy user istnieje? insert ignore?

Czesc, mam pytanie dotyczace tablicy $_POST. Wiec napisalem wyrazenie regularne ktorego uzywam w funkcji preg_match.

Wiec wyrazenie to sprawdza czy tablica $_POST['dana'] przechowuje wartosc alfanumeryczna o dlugosci od 5 do 15 znakow, funkcja zwraca false lub true w przypadku gdy zwroci true wartosc z tablicy POST chce umiescic w bazie danych. Czy ten preg_match uchroni mnie przed kazdym atakie z pola formularza o nazwie "dana"? Czy moze lepiej zastosowac ctype_alnum, strlen i po otrzymaniu TRUE bawic sie dalej z ta zmienna?

Bo tak na chlopski rozum to powinno bronic

Nie wiem było nie było, erix mnie już zbeształ że leniwy jestem i mi się szukać nie chce, to się odkupuje i kopie linkiem do funkcji zabezpieczającej przed atakami typu XSS:
http://snipplr.com/view/9596/secure-advanc...ip-tagsantixss/

pozdro.

A mogę wiedzieć w czym ta funkcja _Strip_Tag() podana przez cojacka w linku i inne tego typu funkcje pisane w tym wątku mają być lepsze od rdzennej strip_tags() napisanej przez osoby zajmujące się rozwojem języka PHP - osoby z wieloletnim, olbrzymim doświadczeniem oraz wiedzą ? Czyli jak rozumiem uważacie, że Wasza własna funkcja strip_tags() będzie lepsza od tej opracowanej przez ekspertów PHP ?

Nie rozumiesz... strip_tags usuwa znaczniki html, http://pl2.php.net/strip_tags
a ten link co ja podałem wywala nam dodatkowo encje z linków. skrypty js etc..

A po co wywalać skrypty js skoro strip_tags() sprawia, że te skrypty - a właściwie już nie skrypty przestają być groźne, np.:

[PHP] pobierz, plaintext 
<?php
echo strip_tags("<script>alert('test')</script>");
?>
[PHP] pobierz, plaintext 

daje nam: alert('test')

[PHP] pobierz, plaintext 
<?php
echo strip_tags("<a href='test'>test</a>");
?>
[PHP] pobierz, plaintext 

daje nam: test

Nie bardzo widzę zwiększenia bezpieczeństwa.

[HTML] pobierz, plaintext 
<a href='test' onclick="alert('test');">test</a>
[HTML] pobierz, plaintext 

I Twoja teoria została obalona.

Chyba nie czytałeś tego wątku od początku...

Nie bardzo rozumiem - zrobiłem specjalnie formularz żeby sprawdzić:

[PHP] pobierz, plaintext 
<?php
if(isset($_POST['przycisk']))
{
echo strip_tags($_POST['pole']);
//echo $_POST['pole'];
}
?>
 
<form action="index.php" method="post">
<input name="pole" type="text" />
<input name="przycisk" type="submit" />
</form>
[PHP] pobierz, plaintext 

Bez uzycia strip_tags() dostaję link po kliknięciu na który wyskakuje mi alert, ALE po użyciu strip_tags() dostaję zwykły tekst 'test'. Więc ?

IMO strip_tags to jedna z durniejszych funkcji. Ktoś coś wpisuje, patrzy... a tu część tekstu ucięta. Zdecydowanie lepiej użyć htmlspecialchars" title="Zobacz w manualu PHP" target="_manual.

Ok Crozin - ale istnieje w końcu coś co obali moją teorię o tym, że nie trzeba zastępować strip_tags() swoją własną bezpieczniejszą funkcją w stylu strip_tags() czy nie ? Wpisanie jakiego kodu w tym formularzu rozłożyłoby tę funkcję na łopatki ?

Zdecydowanie jestem za ~Crozin-em , więcej w tym wątku: http://forum.php.pl/index.php?showtopic=119475

Ale chodzi o to, że w całym tym wątku co kilka postów ludzie próbują pisać własne wersje tych dwóch funkcji: htmlspecialchars() i strip_tags() i podają swoje wersje tych funkcji - chciałbym więc po prostu dowiedzieć się w czym ich własne funkcje są bezpieczniejsze od tych opracowanych przez ekspertów PHP

Blah, pomyślałem o czym innym. [;

"Blah, pomyślałem o czym innym. [; " - wiem o czym myślałeś, dlatego zrobiłem formularz ;] hehe

tru tru w zdecydowanej wiekszosci przypadkow pisanie wlasnych systemow filtracji nie sprawdza sie na polu walki :-) zawsze pominie sie 1 rzecz i cale zabezpieczenie idzie sie walic :-)

tak wiec tak gdzie jest to niewskazane, a nawet niezalecane lepiej nie wymyslac swoich tworow

kiedys zreszta pisalem o tym na blogu, ktorego jestem jedynym czytelnikiem http://www.beldzio.com/sens-tworzenia-wlas...temow-filtracji ;-)

Napisałem na potrzeby skryptu CMS nakładkę na htmlspecialchars(), która zajmuje się jeszcze cenzurą słów - http://pastebin.pl/9298 - mam nadzieję, że to nie jest złe podejście. BTW nie implementuję zaawansowanych mechanizmów cenzury.

Co do strip_tags - webmasterzy często nadużywają tej funkcji. Wywołują ją zamiast htmlspecialchars() i myślą, że ich skrypt jest teraz bezpieczny. Kod HTML pochodzący z zewnątrz należy po prostu zamienić na encje. Funkcja czasami się jednak przydaje - gdy trzeba wyświetlić czysty tekst bez formatowania i bez kodu HTML.

Ale macie problemy, jak komuś jest potrzebne strip_tags to go użyje mi np do routingu jest potrzebny i go używam ile wlezie, w dodatku z joomli zakosiłem parę wyrażen regularnych, o to one

[PHP] pobierz, plaintext 
<?php
if(preg_match('/mosConfig_[a-zA-Z_]{1,21}(=|%3D)/',$strInput))
            {
                $strInput = preg_replace('/mosConfig_[a-zA-Z_]{1,21}(=|%3D)/','',$strInput);
            }
            if(preg_match('/base64_encode.*(.*)/',$strInput))
            {
                $strInput = preg_replace('/base64_encode.*(.*)/','',$strInput);
            }
            if(preg_match('/(<|%3C).*script.*(>|%3E)/',$strInput))
            {
                $strInput = preg_replace('/(<|%3C).*script.*(>|%3E)/','',$strInput);
            }
            if(preg_match('/GLOBALS(=|[|%[0-9A-Z]{0,2})/',$strInput))
            {
                $strInput = preg_replace('/GLOBALS(=|[|%[0-9A-Z]{0,2})/','',$strInput);
            }
            if(preg_match('/_REQUEST(=|[|%[0-9A-Z]{0,2})/',$strInput))
            {
                $strInput = preg_replace('/_REQUEST(=|[|%[0-9A-Z]{0,2})/','',$strInput);
            }
?>
[PHP] pobierz, plaintext 

Śmiało, teraz mogą mi w gecie wsadzac co chcą, imo nie dadza rady.

A mnie zastanawia po jakie licho Ci preg_matche w tym.

Co wy na to, żeby zamiast backslashowania dane wysyłane do MySQL zakodować w base64 i w takiej postaci je trzymać w bazie? A przy wyświetlaniu odkodować i np. usunąć tagi html?

Tylko jaki ma to sens? Po co kombinować ? Dasz backslashe i po sprawie. ;d