🚀 go-pugleaf

On Friday, September 25, 2015 at 9:37:54 AM UTC+2, mwitko...@gmail.com wrote:
> Proszę o wskazówkę w poniższym temacie:
> 
> Użytkownik loguje się na stronę WWW. Przegląda jej zawartość i w pewnym momencie
> może skopiować aktualne url i wkleić go w przeglądarce stron WWW do nowej zakładki.
> W efekcie zobaczy na obu zakładkach taką samą treść. 
> 
> Podejrzewam, że umożliwia to fakt, że całość odbywa się w ramach sesji. Dlatego podejrzenie treści strony po wklejeniu url do nowej zakładki działa. Po wylogowaniu się użytkownika sesja jest niszczona i wklejenie url nie umożliwia podejrzenia zawartości strony, pojawia się okno logowania (tyle potrafię rozróżnić),\
> 
> 
> Chciałbym jednak zablokować taką możliwość uzyskania dostępu do zawartości strony przez kopiowanie url, nawet dla poprawnie zalogowanego użytkownika.

Może gdy napiszesz w jakim celu chciałbyś to blokować, to się wyjaśni, o
co pytasz?

Pozdrawiam

Robią mi audyt strony.
Panowie od audytu uznali, że to nie jest bezpieczne, aby użytkownik mógł kopiować url i wklejać do sąsiednich zakładek uzyskując tym samym dostęp do danych, bez logowania. Oczywiście to się odbywa podczas sesji. Wcześniej nastąpiła pozytywna weryfikacja użytkownika (prawidłowa autoryzacja i logowanie). Niestety taki jest wymóg.

Podobny mechanizm jest np. na stronie w PKO BP. Tam jak się zaloguję na swoje konto bankowe to również nie można uzyskać dostępu do danych kopiując do następnej zakładki url uzyskany już po zalogowaniu się (tam idą jeszcze krok dalej, w linii adresu url jest widoczny cały czas ten sam adres, bez względu na to jaką się wybierze pozycję z menu). Tam skopiowanie takiego url skutkuje pojawienie się okna logowania - i ja chcę uzyskać dokładnie taki sam efekt.


Pozdrawiam
MW

On Friday, September 25, 2015 at 2:31:40 PM UTC+2, mwitko...@gmail.com wrote:
> Robią mi audyt strony.
> Panowie od audytu uznali, że to nie jest bezpieczne, aby użytkownik mógł kopiować url i wklejać do sąsiednich zakładek uzyskując tym samym dostęp do danych, bez logowania. Oczywiście to się odbywa podczas sesji. Wcześniej nastąpiła pozytywna weryfikacja użytkownika (prawidłowa autoryzacja i logowanie). Niestety taki jest wymóg.
> 
> Podobny mechanizm jest np. na stronie w PKO BP. Tam jak się zaloguję na swoje konto bankowe to również nie można uzyskać dostępu do danych kopiując do następnej zakładki url uzyskany już po zalogowaniu się (tam idą jeszcze krok dalej, w linii adresu url jest widoczny cały czas ten sam adres, bez względu na to jaką się wybierze pozycję z menu). Tam skopiowanie takiego url skutkuje pojawienie się okna logowania - i ja chcę uzyskać dokładnie taki sam efekt.
> 
> 
> Pozdrawiam
> MW

Polecam regenerację sesji. 
Pozdrawiam

session_regenerate_id() zwróci mi inny numer sesji, OK, tylko nie wiem w jaki sposób mam odróżnić, że dana strona została wyklikana po zalogowaniu a nie wywołana przez wklejenie url, własnie na to nie mam pomysłu.


Pozdrawiam
MW

On Friday, September 25, 2015 at 4:14:13 PM UTC+2, mwitko...@gmail.com wrote:
> session_regenerate_id() zwróci mi inny numer sesji, OK, tylko nie wiem w jaki sposób mam odróżnić, że dana strona została wyklikana po zalogowaniu a nie wywołana przez wklejenie url, własnie na to nie mam pomysłu.

Rozpoznaje się czy dostęp do danych jest autoryzowany, a nie czy
użytkownik klikną, wkleił, wpisał prawą ręką czy lewą ;-)

https://pl.wikibooks.org/wiki/PHP/Sesje

Pozdrawiam

Robisz tak umieszczasz tylko jedna sparametryzowana akcje ktora wola dane na kontrolerze budujesz caly mechanizm po stronie przegladarki. A ajax podmieniasz dane bez zmiany tresci strony

M.M. pisze:
> On Friday, September 25, 2015 at 4:14:13 PM UTC+2, mwitko...@gmail.com wrote:
>> session_regenerate_id() zwróci mi inny numer sesji, OK, tylko nie wiem w jaki sposób mam odróżnić, że dana strona została wyklikana po zalogowaniu a nie wywołana przez wklejenie url, własnie na to nie mam pomysłu.
> 
> Rozpoznaje się czy dostęp do danych jest autoryzowany, a nie czy
> użytkownik klikną, wkleił, wpisał prawą ręką czy lewą ;-)
Jeden z nas chyba nie rozumie działania powyższej funkcji,
a raczej moim zdaniem powyższa funkcja nie pomoże
w rozwiązaniu problemu o którym mowa.

Jak to kolego poniżej napisał:
Jeśli żądanie zostało wysłane metodą GET to wyświetlasz panel logowania.
Jeśli żądanie zostało wysłane metodą POST weryfikujesz dane autoryzacyjne,
i zapamiętujesz w sesji informację o statusie autoryzacji.
Pozostałe akcje wykonujesz używając JavaScript XMLHttpRequest
i po stronie serwera sprawdzasz czy jest to żądanie z XMLHttpRequest.
Przeglądarka sama automatycznie doda odpowiednie Cookie w nagłówkach,
także sprawa korzystania z tej samej sesji
zostanie zapewniona przez Przeglądarkę.

Poprzez wklejenie URLa do adresu przeglądarki nie można
za symulować żądania XMLHttpRequest
(mam na myśli nagłówek "X-Requested-With: XMLHttpRequest").

Dnia Sat, 26 Sep 2015 12:10:51 +0200, PawelS cbrbob(at)wbcd(dot)pl
napisał(a):

>> Rozpoznaje się czy dostęp do danych jest autoryzowany, a nie czy
>> użytkownik klikną, wkleił, wpisał prawą ręką czy lewą ;-)
> Jeden z nas chyba nie rozumie działania powyższej funkcji,
> a raczej moim zdaniem powyższa funkcja nie pomoże
> w rozwiązaniu problemu o którym mowa.

Przepisanie aplikacji na PJAX też w niczym nie pomoże.

Nie do końca rozumiem opis problemu autora, są dwie możliwości:
1) audytorzy są idiotami
2) identyfikator sesji jest przekazywany w URL

Na pierwszy przypadek za wiele zaradzić nie można. Jeśli faktycznie chcemy
uzyskać sytuację, że nawet po uwierzytelnieniu nie da się otworzyć tej
samej strony w dwóch kartach przeglądarki, to zostają chyba tylko jakieś
tokeny jednorazowe.

A drugi przypadek to klasyczne session fixation, czemu bardzo łatwo
zaradzić - identyfikator do ciacha i generować go od nowa przy każdym
logowaniu.

-- 
Borys Pogoreło
borys(#)leszno,edu,pl

Rozumiem, że Pan Borys uważa wszystkich audytorów pracujących np. w bankach za idiotów, bo większość banków stosuje tego typu zabezpieczenie.

W ramach swojej strony nie przekazuję id sesji w URL, wszystkie dane są przekazywane metoda POST i są odpowiednio walidowane.

Stosowanie identyfikatora w COOKIE, po pozytywnym logowaniu nie wystarcza.
Poniżej prosty przykład na sprawdzenie tej tezy (plik index.php wywołuje plik dwa.php):

[plik index.php]
<?php
// może być np: uniqid(), ale chodzi tylko o sprawdzenie
// nastapiło pozytywne logowanie więc ustawiam jakiś identyfikator
$token = "12345";
setcookie("token", $token);
echo "Jestem w INDEX.PHP " . "<br>";
echo "Ustawiam cookie na " . $token . "<br>";
?>

<html>
<form action="dwa.php" method="POST">
<p>Test</p>
<input type="submit" value="DWA"> 
</form>
</html>

[plik dwa.php]
<?php
echo "Jestem w DWA.PHP " . "<br>";
$token = "";
$token = $_COOKIE["token"];
echo "czytam cookie = " . $token . "<br>";
?>
<html>
<a href="index.php">Back</a>
<html>


Uruchamiamy plik index.php, wybieramy przycisk "DWA" pojawia się zawartość wygenerowana przez dwa.php. Teraz kopiujemy url do sąsiedniej zakładki i niestety
bez problemu da się zobaczyć efekt działania pliku dwa.php. Więc cookie nie wystarcza. Chyba, że ja czegoś nie rozumiem?


Pozdrawiam
MW

W dniu 2015-09-25 o 09:37, mwitkowski2b@gmail.com pisze:

>
> Chciałbym jednak zablokować taką możliwość uzyskania dostępu do zawartości strony przez kopiowanie url, nawet dla poprawnie zalogowanego użytkownika.
>

Można sprawdzać referer:
https://pl.wikipedia.org/wiki/HTTP_referer
Oczywiście jest to do obejścia, ale proste kopiuj-wklej wykryjesz.

Bolek

>Można sprawdzać referer: 
>https://pl.wikipedia.org/wiki/HTTP_referer 
>Oczywiście jest to do obejścia, ale proste kopiuj-wklej wykryjesz. 

To tez jest niezła wskazówka, ale tez nie wystarczająca, bo jestem w stanie na etapie logowania zapamiętać IP z jakiego jest logowanie i potem je sprawdzić, gdyby atak był z innego IP to jednak łatwo to wykryć.

Tutaj zakładamy, że komuś z zewnątrz udało się przejąć sesję, wtedy po wklejeniu url obok uzyskamy dostęp jak po zalogowaniu. Dlatego do testowania stosuję sytuację, gdy wszystko dzieje się na tym samym komputerze i w ramach tej samej sesji. 

Pozdrawiam
MW

On Saturday, September 26, 2015 at 12:10:53 PM UTC+2, PawelS cbrbob(at)wbcd(dot)pl wrote:
> M.M. pisze:
> > On Friday, September 25, 2015 at 4:14:13 PM UTC+2, mwitko...@gmail.com wrote:
> >> session_regenerate_id() zwróci mi inny numer sesji, OK, tylko nie wiem w jaki sposób mam odróżnić, że dana strona została wyklikana po zalogowaniu a nie wywołana przez wklejenie url, własnie na to nie mam pomysłu.
> > 
> > Rozpoznaje się czy dostęp do danych jest autoryzowany, a nie czy
> > użytkownik klikną, wkleił, wpisał prawą ręką czy lewą ;-)
> Jeden z nas chyba nie rozumie działania powyższej funkcji,
> a raczej moim zdaniem powyższa funkcja nie pomoże
> w rozwiązaniu problemu o którym mowa.
Jeden z nas nie wczytał się iż chodzi o zwiększenie
bezpieczeństwa. A przecież można dowolne zapytanie
dowolnie spreparować po stronie przeglądarki. Ilość
stanów aplikacji można ograniczyć przez unieważnienie
sesji po dowolnym jednym requescie, to z kolei
ułatwia przewidzenie zachowania użytkownika, ułatwia
napisanie aplikacji i minimalnie zwiększa bezpieczeństwo.

Pozdrawiam

Dnia Mon, 28 Sep 2015 01:06:06 -0700 (PDT), mwitkowski2b@gmail.com
napisał(a):

> Rozumiem, że Pan Borys uważa wszystkich audytorów pracujących np. w
> bankach za idiotów, bo większość banków stosuje tego typu
> zabezpieczenie.

Bo to są banki i muszą mieć hopla na tym punkcie. Nie sądzę, byś tworzył
produkt mający takie wymagania.

Btw, mały test:

- nowy mBank: blokuje
- Multibank: nie blokuje
- BZWBK: nie blokuje
- ING: nie blokuje
Do Getinu nie pamiętam hasła, to nie sprawdzę.

Jak na razie ciężko mówić o "większości". W mBanku z tego co widzę, to
wszystko lata metodą POST i z tokenami.

> Uruchamiamy plik index.php, wybieramy przycisk "DWA" pojawia się
> zawartość wygenerowana przez dwa.php. Teraz kopiujemy url do sąsiedniej
> zakładki i niestety bez problemu da się zobaczyć efekt działania pliku
> dwa.php. Więc cookie nie wystarcza. Chyba, że ja czegoś nie rozumiem?

Token musi być każdorazowo niszczony i generowany od nowa.

-- 
Borys Pogoreło
borys(#)leszno,edu,pl

Dnia Mon, 28 Sep 2015 12:57:23 +0200, Bolek napisał(a):

>> Chciałbym jednak zablokować taką możliwość uzyskania dostępu do zawartości strony przez kopiowanie url, nawet dla poprawnie zalogowanego użytkownika.
> 
> Można sprawdzać referer:
> https://pl.wikipedia.org/wiki/HTTP_referer
> Oczywiście jest to do obejścia, ale proste kopiuj-wklej wykryjesz.

WSZYSTKO co przychodzi od użytkownika z zasady jest niezaufane. W tym
referer, który bardzo łatwo zmodyfikować.

-- 
Borys Pogoreło
borys(#)leszno,edu,pl

On Monday, September 28, 2015 at 6:48:25 PM UTC+2, Borys Pogoreło wrote:
> Dnia Mon, 28 Sep 2015 12:57:23 +0200, Bolek napisał(a):
> 
> >> Chciałbym jednak zablokować taką możliwość uzyskania dostępu do zawartości strony przez kopiowanie url, nawet dla poprawnie zalogowanego użytkownika.
> > 
> > Można sprawdzać referer:
> > https://pl.wikipedia.org/wiki/HTTP_referer
> > Oczywiście jest to do obejścia, ale proste kopiuj-wklej wykryjesz.
> 
> WSZYSTKO co przychodzi od użytkownika z zasady jest niezaufane. W tym
> referer, który bardzo łatwo zmodyfikować.

W końcu coś mądrego w temacie.
Pozdrawiam

W dniu 2015-09-28 o 18:48, Borys Pogoreło pisze:
> Dnia Mon, 28 Sep 2015 12:57:23 +0200, Bolek napisał(a):
>
>>> Chciałbym jednak zablokować taką możliwość uzyskania dostępu do zawartości
strony przez kopiowanie url, nawet dla poprawnie zalogowanego użytkownika.
>>
>> Można sprawdzać referer:
>> https://pl.wikipedia.org/wiki/HTTP_referer
>> Oczywiście jest to do obejścia, ale proste kopiuj-wklej wykryjesz.
>
> WSZYSTKO co przychodzi od użytkownika z zasady jest niezaufane. W tym
> referer, który bardzo łatwo zmodyfikować.
>

Twoja wypowiedź niestety nie wnosi nic nowego, przecież już napisałem, 
że jest to do obejścia, spełnia jednak powyżej postawione wymaganie 
założyciela wątku. To, że pytający po otrzymaniu odpowiedzi "generuje"
kolejne wymagania to inna sprawa i norma na grupach.

pozdrawiam
Bolek

Dziękuję bardzo wszystkim za pomoc.

Generalnie postaram się wykorzystać wiele z opisanych elementów, po uzupełnieniu informacji na temat sesji będą to:
- sesja w innym katalogu niż domyślny
- używany token
- session_regenerate_id()
- kontrola czasu trwania sesji
- $_SERVER['HTTP_REFERER'] do wykrywania czy przeklejono URL


Pozdrawiam
MW

Borys Pogoreło pisze:
> Dnia Mon, 28 Sep 2015 01:06:06 -0700 (PDT), mwitkowski2b@gmail.com
> napisał(a):
> 
>> Rozumiem, że Pan Borys uważa wszystkich audytorów pracujących np. w
>> bankach za idiotów, bo większość banków stosuje tego typu
>> zabezpieczenie.
> 
> Bo to są banki i muszą mieć hopla na tym punkcie. Nie sądzę, byś tworzył
> produkt mający takie wymagania.
> 
> Btw, mały test:
> 
> - nowy mBank: blokuje
Wcale nie taki nowy :D :D :D

Potrzebowałem danych (numeru konta dla operacji przed 2012)
i niestety w nowy interfejs nie potrafi wyświetlić
operacji wykonanych przed 2012 rokiem,
ale, ale, ale jest dostęp/widok ... niestandardowy
(nie pamiętam w tej chwili, ale tak się to chyba nazywa).
Tam otwierana jest jest historia osadzona w ramce,
a tą ramkę można spokojnie przenieść do nowej karty,
w ten sposób wykonałem przelew do osoby,
korzystając z informacji o przelewie otwartej w drugiej karcie.

Dnia Fri, 02 Oct 2015 23:08:45 +0200, PawelS cbrbob(at)wbcd(dot)pl
napisał(a):

> ale, ale, ale jest dostęp/widok ... niestandardowy
> (nie pamiętam w tej chwili, ale tak się to chyba nazywa).
> Tam otwierana jest jest historia osadzona w ramce,
> a tą ramkę można spokojnie przenieść do nowej karty,

Pewnie klasyka: ktoś nie pomyślał, a później programista musiał na boku
dorabiać "na wczoraj" i działa jak działa :)

-- 
Borys Pogoreło
borys(#)leszno,edu,pl