eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.wwwAjax - kwestie bezpieczeństwa
Ilość wypowiedzi w tym wątku: 34

  • 1. Data: 2012-12-17 16:04:47
    Temat: Ajax - kwestie bezpieczeństwa
    Od: Marek <p...@s...com>

    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.


  • 2. Data: 2012-12-17 20:49:10
    Temat: Re: Ajax - kwestie bezpieczeństwa
    Od: Tomek Kańka <t...@t...eu.org>

    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



  • 3. Data: 2012-12-18 23:19:31
    Temat: Re: Ajax - kwestie bezpieczeństwa
    Od: Marek <p...@s...com>

    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.



  • 4. Data: 2012-12-18 23:20:53
    Temat: Re: Ajax - kwestie bezpieczeństwa
    Od: Marek <p...@s...com>

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


  • 5. Data: 2012-12-18 23:48:06
    Temat: Re: Ajax - kwestie bezpieczeństwa
    Od: Tomek Kańka <t...@t...eu.org>

    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


  • 6. Data: 2012-12-19 12:18:50
    Temat: Re: Ajax - kwestie bezpieczeństwa
    Od: Marek <p...@s...com>

    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.


  • 7. Data: 2012-12-19 21:51:36
    Temat: Re: Ajax - kwestie bezpieczeństwa
    Od: Tomek Kańka <t...@t...eu.org>

    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


    >


  • 8. Data: 2012-12-19 23:35:54
    Temat: Re: Ajax - kwestie bezpieczeństwa
    Od: Marek <p...@s...com>

    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.


  • 9. Data: 2012-12-20 17:24:34
    Temat: Re: Ajax - kwestie bezpieczeństwa
    Od: Tomek Kańka <t...@t...eu.org>

    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.


  • 10. Data: 2012-12-20 21:13:39
    Temat: Re: Ajax - kwestie bezpieczeństwa
    Od: Marek <p...@s...com>

    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 :-)

strony : [ 1 ] . 2 ... 4


Szukaj w grupach

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: