Witam,

Mam pewien kłopot z zastosowaniem tej technologii przy operacjach
wymagających bezpieczeństwa. Hipotetyczny przykład:

- mamy 2 tabele w bazie: grupy transakcji i transakcje
- wchodzimy na stronkę i dostajemy listing transakcji z określonej grupy
- Ajax ma za zadanie wyedytować jeden z rekordów transakcyjnych
- aby otworzyć edytor rekordu o ID 100 musimy przekazać np. POSTem z
poziomu Ajaxa, że operacja dotyczy ID 100

No i tu powstaje problem. Mianowicie ktoś może majstrować na poziomie
przeglądarki i spowodować, ze Ajax poprosi o ID 101. Pal sześć jeśli
jest to rekord należący do tej samej grupy transakcji. Ale w ten sposób
ktoś może się dostać do edycji rekordu z niedozwolonej grupy. Jak temu
przeciwdziałać? Przekazywać ID grupy transakcji? Bez sensu, bo i ten
numer można sfałszować łatwo w/w sposobem.

do góry

Marek <p...@s...com> napisał(a)
>[...]
> No i tu powstaje problem. Mianowicie ktoś może majstrować na poziomie
> przeglądarki i spowodować, ze Ajax poprosi o ID 101.
> [...]

I czym to się rózni od nie-ajaxa?

--
Tomek

do góry

W dniu 2012-12-17 20:49, Tomek Kańka pisze:

> I czym to się rózni od nie-ajaxa?

Jawnością przekazywania parametrów. Jeśli PHP sobie coś przekazuje w
zmiennych sesyjnych to przeglądarka o tym nie wie.

do góry

Chociaż może masz rację... i da się to jakoś połączyć ze sobą.

do góry

Marek <p...@s...com> napisał(a)
> Chociaż może masz rację... i da się to jakoś połączyć ze sobą.

Jedną z zasad pisania bezpiecznych serwisów webowych jest "nie ufaj temu
co przychodzi z przeglądarki". Czyli jeśli przychodzi request "pokaż
rekord id=101", to sprawdzasz, czy ten kto wysłał to zapytanie ma prawo
do rekordu 101, choćby z logiki aplikacji wynikało, że odpowiedni link
wyświetla się tylko uprawnionym uzytkownikom. Na każdym kroku
zakłądasz, że ktos mógł podmenić nr sesji, zawartośc cookie, parametry
itp.

--
Tomek

do góry

W dniu 2012-12-18 23:48, Tomek Kańka pisze:

> Jedną z zasad pisania bezpiecznych serwisów webowych jest "nie ufaj temu
> co przychodzi z przeglądarki".

Stąd mój post. Dlatego właśnie zastanawiałem się jak to w przypadku
Ajaxa działającego w sposób jawny po stronie przeglądarki zrealizować.

> Czyli jeśli przychodzi request "pokaż
> rekord id=101", to sprawdzasz, czy ten kto wysłał to zapytanie ma prawo
> do rekordu 101, choćby z logiki aplikacji wynikało, że odpowiedni link
> wyświetla się tylko uprawnionym uzytkownikom. Na każdym kroku
> zakłądasz, że ktos mógł podmenić nr sesji, zawartośc cookie, parametry
> itp.
>

Tak, właśnie to wszystko chcę uwzględniać + Ajax, który komplikuje
jeszcze bardziej. W omawianym hipotetycznym przykładzie muszę do Ajaxa
przesłać 2 parametry: ID grupy transakcji i ID konkretnej transakcji po
to aby potrafił on zapytać się systemu o dane (załóżmy, że oba te ID są
niezbędne). Tymczasem to samo rozwiązanie bez Ajaxa, w samym PHP, wymaga
ujawnienia wyłącznie ID transakcji gdyż w sesji mogę pamiętać ID grupy
transakcji. No i w tym momencie jeśli ktoś podmieniłby ID transakcji, to
PHP stwierdzi, że w ramach danej grupy nie ma takiej transakcji.
Tymczasem w Ajaxie ktoś może podmienić oba te ID i trudno jest
weryfikować czy autoryzować takie zapytanie czy też nie.

A tak na marginesie: rozwiązałem w PHP (ale nie w Ajaxie) kwestie
bezpieczeństwa w taki sposób, że generuję do każdego formularza losowy,
zmienny za każdym razem, ID transakcji. Jeśli ktoś podmieni ID sesji, to
numer transakcji nie będzie się pokrywał z innym - wygenerowanym podczas
innej sesji. Prosty zabieg, który ucina problemy weryfikacji operacji.

do góry

Marek <p...@s...com> napisał(a)
>
> Tak, właśnie to wszystko chcę uwzględniać + Ajax, który komplikuje
> jeszcze bardziej. W omawianym hipotetycznym przykładzie muszę do Ajaxa
> przesłać 2 parametry: ID grupy transakcji i ID konkretnej transakcji po
> to aby potrafił on zapytać się systemu o dane (załóżmy, że oba te ID są
> niezbędne). Tymczasem to samo rozwiązanie bez Ajaxa, w samym PHP, wymaga
> ujawnienia wyłącznie ID transakcji gdyż w sesji mogę pamiętać ID grupy
> transakcji. [...]

Dlaczego Twoje ajaxowe requesty odbywają się poza sesją i jak udało Ci
się ro osiągnąć?

--
Tomek


>

do góry

W dniu 2012-12-19 21:51, Tomek Kańka pisze:

> Dlaczego Twoje ajaxowe requesty odbywają się poza sesją i jak udało Ci
> się ro osiągnąć?

Nie odbywają się poza sesją. Tego nie napisałem. Może bardziej
konkretnie, Jest sobie w PHP moduł A, który wyświetla rekordy z jakiejś
tabeli. Gdy wybierzemy jakiś rekord do edycji, to przeładowujemy
formularz, dane trafiają do modułu A, który waliduje nasze żądanie i
jeśli wszystko jest ok, to ustawia w sesji kontekst i przekierowuje na
inny URL. Tam moduł B odbiera kontekst i wyświetla inny formularz, w
którym możemy edytować kliknięty rekord.

Takie rozwiązanie daje nam bezpieczeństwo w takiej postaci, że
bezpośrednie wejście na ten "inny URL", gdzie pracuje moduł B, i
przesyłanie czegokolwiek GETem lub POSTem, nie będzie w stanie uruchomić
edycji jakiegokolwiek rekordu bo moduł B nie nasłuchuje tych zmiennych
wcale. On czego na zmienne sesyjne.

Teraz wkracza Ajax. Jesteśmy na pierwszym URL z listą rekordów. Klikamy
jakiś do edycji no i Ajax musiałby w tym momencie wyświetlić od razu
edytor - no bo po to jest Ajax aby strona się nie przeładowywała. Nie ma
etapu komunikacji za pomocą sesji. Ajax włazi na drugi URL i musi mu
podesłać kontekst jakoś. No a to byłoby już za pośrednictwem
przeglądarki, co nie jest dopuszczalne.

Teraz kombinuję... a może Ajax dokonywałby 2 requestów? Pierwszy
dokonywałby komunikacji z modułem A wystawiającym kontekst, a potem
łączył się z innym URL w celu wyświetlenia edytora rekordu we współpracy
z modułem B, który to potrafi.

Dodam, że pojęcie kontekstu nie jest banalne. To może być bardzo wiele
informacji.

do góry

Marek <p...@s...com> napisał(a)
> W dniu 2012-12-19 21:51, Tomek Kańka pisze:
>
>> Dlaczego Twoje ajaxowe requesty odbywają się poza sesją i jak udało Ci
>> się ro osiągnąć?
>
> Nie odbywają się poza sesją. Tego nie napisałem. Może bardziej
> konkretnie, Jest sobie w PHP moduł A, który wyświetla rekordy z jakiejś
> tabeli. Gdy wybierzemy jakiś rekord do edycji, to przeładowujemy
> formularz, dane trafiają do modułu A, który waliduje nasze żądanie i
> jeśli wszystko jest ok, to ustawia w sesji kontekst i przekierowuje na
> inny URL. Tam moduł B odbiera kontekst i wyświetla inny formularz, w
> którym możemy edytować kliknięty rekord.
>
> Takie rozwiązanie daje nam bezpieczeństwo w takiej postaci, że
> bezpośrednie wejście na ten "inny URL", gdzie pracuje moduł B, i
> przesyłanie czegokolwiek GETem lub POSTem, nie będzie w stanie uruchomić
> edycji jakiegokolwiek rekordu bo moduł B nie nasłuchuje tych zmiennych
> wcale. On czego na zmienne sesyjne.
>
> Teraz wkracza Ajax. Jesteśmy na pierwszym URL z listą rekordów. Klikamy
> jakiś do edycji no i Ajax musiałby w tym momencie wyświetlić od razu
> edytor - no bo po to jest Ajax aby strona się nie przeładowywała.

> Nie ma etapu komunikacji za pomocą sesji.

Może wynika to z tego, że nie znam PHP i w związku z tym nie rozumiem
Twojego mechanizmu, ale...

co to znaczy "nie ma etapu komunikacji za pomocą sesji"?

Przecież (już stosując niskopoziomowy żargon) te ajaxowe requesty
zawierają te same cookie i należą do tej samej sesji. Dlaczego ich nie
wysyłasz do tego modułu A? ROzumiem, że on wysyła header 30x z urlem do modułu
B? Jest jakiś problem z 30x i ajaxem? Nie wiem, tego na pewno, ale nie
wydaje mi się, że to jest jakiś problem.



> Ajax włazi na drugi URL i musi mu
> podesłać kontekst jakoś. No a to byłoby już za pośrednictwem
> przeglądarki, co nie jest dopuszczalne.
>
> Teraz kombinuję... a może Ajax dokonywałby 2 requestów? Pierwszy
> dokonywałby komunikacji z modułem A wystawiającym kontekst, a potem
> łączył się z innym URL w celu wyświetlenia edytora rekordu we współpracy
> z modułem B, który to potrafi.
>
> Dodam, że pojęcie kontekstu nie jest banalne. To może być bardzo wiele
> informacji.

do góry

W dniu 2012-12-20 17:24, Tomek Kańka pisze:

> Może wynika to z tego, że nie znam PHP i w związku z tym nie rozumiem
> Twojego mechanizmu, ale...

W zasadzie jest podobnie jak w ASP, jeśli go znasz. Mechanizm jest
banalny: nie patrząc już na to jak fizycznie odbywa się zarządzanie
sesją, to można sobie sesję wyobrazić jako obiekt widziany przez każdy
skrypt PHP wywoływany przez przeglądarkę w ramach jednej sesji. Możesz w
niego upakować wszystko co chcesz. Możesz np. zbudować w oparciu o sesję
komunikację między modułami PHP. O to dalej pytasz właśnie.

> co to znaczy "nie ma etapu komunikacji za pomocą sesji"?

Przykład przetwarzania formularza:
1. Wypełniamy go, klikamy submit, PHP przetwarza go, wrzuca coś do
sesji, wysyła przekierowanie na inny URL gdzie moduł B (PHP) pobiera
sobie to co wcześniejszy moduł przekazał i generuje w oparciu o te dane
inny screen, np. tabelę rekordów z zaznaczonym tym, który był właśnie
edytowany. A ma zaznaczyć? Tego dowiaduje się z sesji. To jest ta
komunikacja.

2. Wersja Ajax. Wypełniamy formularz, nie ma guzika submit bo zastępuje
go button ajaxowy. Klikamy ten button, Ajax go przesyła do PHP i zbiera
odpowiedź. Pozostajemy na tym samym URLu z punktu widzenia przeglądarki.

> Przecież (już stosując niskopoziomowy żargon) te ajaxowe requesty
> zawierają te same cookie i należą do tej samej sesji.

Owszem

> Dlaczego ich nie
> wysyłasz do tego modułu A?

No wysyłam do modułu A ale ten w odpowiedzi nie może wygenerować
przekierowania na inny URL bo wysłałby je nie do przeglądarki lecz do JS.

> ROzumiem, że on wysyła header 30x z urlem do modułu
> B? Jest jakiś problem z 30x i ajaxem? Nie wiem, tego na pewno, ale nie
> wydaje mi się, że to jest jakiś problem.

No w zasadzie w poprzednim dialogu dałeś mi do myślenia. W zasadzie Ajax
może odebrać kod 3xx i przekierować przeglądarkę. Wtedy można nadal
utrzymywać komunikację na dotychczasowym poziomie, w której tajne dane
przemieszczają się w obrębie sesji między modułami. Tak więc
ukierunkowałeś mnie :-)

do góry