Powiedzmy, że jest taki oto request:

https://foo.example.com/?param1=foo&login=test&passw
ord=mojehaslo&inne=parametry

Niestety, ale ów request musi być cross-domenowy i używam do tego JSONP.
O ile samo połączenie SSL-owe to już jest lepiej, o tyle problem jest, że:

- idzie to GET-em, bo <script> z JSONP
- nie może iść POST-em, bo musiałbym wykonać cross-domenowe XHR, ale
serwer na to nie pozwala (poza sytuacją, kiedy mógłbym ustawić do tego
odpowiednio nagłówek Access-Control-Allow-Credentials w odpowiedzi z
serwera)

POST-em by było najlepiej, bo wszystkie parametry byłyby zakodowane w
nagłówku, ale na razie POST być nie może.

Co mnie martwi mimo SSL-a?

- URL zostaje zapisany w logach serwera, a także może być po drodze w proxy
- Zostaje ślad w historii, która jest w przeglądarce; a także możliwe,
że niektóre pluginy gromadzą sobie takie dane
- URL może być wysłany do Google Analytics i tym podobnych serwisów

Jakieś pomysły jak zabezpieczyć parametry w URL-u gdzie request idzie po
GET-cie mimo SSL-a?

--
Cezary Tomczyk
http://www.ctomczyk.pl/

do góry

On Wed, 05 Dec 2012 23:10:32 +0100, Cezary Tomczyk wrote:
> Powiedzmy, że jest taki oto request:
>
> https://foo.example.com/?param1=foo&login=test&passw
ord=mojehaslo&inne=parametry
> [...]
> Jakieś pomysły jak zabezpieczyć parametry w URL-u gdzie request idzie po
> GET-cie mimo SSL-a?

Argumenty potraktowałbym jako ciąg znaków, użył funkcji szyfrującej
i wysłał jako jeden argument:

?all_params=hash

HARY

--

do góry

W dniu 2012-12-06 12:53, HARY pisze:
> On Wed, 05 Dec 2012 23:10:32 +0100, Cezary Tomczyk wrote:
>> Powiedzmy, że jest taki oto request:
>>
>> https://foo.example.com/?param1=foo&login=test&passw
ord=mojehaslo&inne=parametry
>> [...]
>> Jakieś pomysły jak zabezpieczyć parametry w URL-u gdzie request idzie po
>> GET-cie mimo SSL-a?
>
> Argumenty potraktowałbym jako ciąg znaków, użył funkcji szyfrującej
> i wysłał jako jeden argument:
>
> ?all_params=hash

No ale algorytm jest publiczny i siedzi w JavaScripcie. Więc znając
algorytm i URL można go łatwo odkodować.

Ja myślałem o tym, by użyć publicznego klucza z serwera, zakodować,
wysłać i na serwerze za pomocą klucza prywatnego odkodować. Ale to
rozwiązanie na razie nie przejdzie.

--
Cezary Tomczyk
http://www.ctomczyk.pl/

do góry

On Thu, 06 Dec 2012 20:43:45 +0100, Cezary Tomczyk wrote:
> W dniu 2012-12-06 12:53, HARY pisze:
>> On Wed, 05 Dec 2012 23:10:32 +0100, Cezary Tomczyk wrote:
>>> Powiedzmy, że jest taki oto request:
> No ale algorytm jest publiczny i siedzi w JavaScripcie. Więc znając
> algorytm i URL można go łatwo odkodować.

Odniosłem się do tego:

=============
Co mnie martwi mimo SSL-a?

- URL zostaje zapisany w logach serwera, a także może być po drodze w
proxy
- Zostaje ślad w historii, która jest w przeglądarce; a także możliwe,
że niektóre pluginy gromadzą sobie takie dane
- URL może być wysłany do Google Analytics i tym podobnych serwisów
=============

I uznałem, że Ci wystarczy, żeby argumenty były widoczne "na żywca" w
różnych miejscach, gdzie mogą się dostać.

> Ja myślałem o tym, by użyć publicznego klucza z serwera, zakodować,
> wysłać i na serwerze za pomocą klucza prywatnego odkodować. Ale to
> rozwiązanie na razie nie przejdzie.

1. Logowanie z formularza i POST. Zwykły HTML wystarczy.

2. Na serwerze szyfrowanie jednokierunkowe i przekierowanie GET (do
adresu URL/?arg=hash).

3. W dalszych działaniach JS nie musi nic wiedzieć o szyfrowaniu, ma
tylko "podać dalej" otrzymany hash, a serwer za każdym razem sprawdzić,
czy hash jest poprawny.

Chyba że nie kumam, do czego zmierzasz.

HARY


--
Newton's Fourth Law: Every action has an equal and opposite satisfaction.

do góry

W dniu 2012-12-07 08:35, HARY pisze:
> On Thu, 06 Dec 2012 20:43:45 +0100, Cezary Tomczyk wrote:
[...]
>> Ja myślałem o tym, by użyć publicznego klucza z serwera, zakodować,
>> wysłać i na serwerze za pomocą klucza prywatnego odkodować. Ale to
>> rozwiązanie na razie nie przejdzie.
>
> 1. Logowanie z formularza i POST. Zwykły HTML wystarczy.

Nie mogę użyć <form>-a, bo serwer nie zwróci potrzebnych mi danych w
postaci obiektu JSON z danymi (np. z informacją czy użytkownik jest
autoryzowany czy nie).

Użytkownik wpisuje login i hasło a ja go chcę autoryzować (w moim
przypadku poprzez wysłanie zapytania z użyciem JSONP; jestem w domenie
example.com a muszę odwołać się do innej domeny, niż example.com) celem
autoryzacji użytkownika).

> 2. Na serwerze szyfrowanie jednokierunkowe i przekierowanie GET (do
> adresu URL/?arg=hash).

To przypomina mi rozwiązanie z użyciem Proxy :-)

> 3. W dalszych działaniach JS nie musi nic wiedzieć o szyfrowaniu, ma
> tylko "podać dalej" otrzymany hash, a serwer za każdym razem sprawdzić,
> czy hash jest poprawny.
>
> Chyba że nie kumam, do czego zmierzasz.

O ile dobrze zrozumiałem, to mogłoby to wyglądać tak:

1. <form> type POST -> serwer Proxy.
2. Proxy przesyła dalej dane do docelowego serwera.

Pytanie tylko jak odebrać odpowiedź od serwera docelowego?

--
Cezary Tomczyk
http://www.ctomczyk.pl/

do góry

W dniu 2012-12-09 19:50, Cezary Tomczyk pisze:
> W dniu 2012-12-07 08:35, HARY pisze:
>> On Thu, 06 Dec 2012 20:43:45 +0100, Cezary Tomczyk wrote:
> [...]
>>> Ja myślałem o tym, by użyć publicznego klucza z serwera, zakodować,
>>> wysłać i na serwerze za pomocą klucza prywatnego odkodować. Ale to
>>> rozwiązanie na razie nie przejdzie.
>>
>> 1. Logowanie z formularza i POST. Zwykły HTML wystarczy.
>
> Nie mogę użyć <form>-a, bo serwer nie zwróci potrzebnych mi danych w
> postaci obiektu JSON z danymi (np. z informacją czy użytkownik jest
> autoryzowany czy nie).

Dla ścisłości, bo wyraziłem się niejasno: serwer może mi wysłać dane,
ale <form> nie ma czegoś takiego jak callback :-). Skądinąd XHR ma, ale
nie mogę dokonać komunikacji cross-domenowej. Wiem, nowe przeglądarki
już to wspierają, ale jest jeszcze taki warunek, by był wysłany z
serwera odpowiedni nagłówek. No i inna sprawa, że nadal muszę wspierać
IE7 :-( (inaczej: przeglądarki, co nie wspierają CORS-a w XHR-ze).

--
Cezary Tomczyk
http://www.ctomczyk.pl/

do góry

On Sun, 09 Dec 2012 19:50:42 +0100, Cezary Tomczyk wrote:
> W dniu 2012-12-07 08:35, HARY pisze:
>> 2. Na serwerze szyfrowanie jednokierunkowe i przekierowanie GET (do
>> adresu URL/?arg=hash).
> To przypomina mi rozwiązanie z użyciem Proxy :-)

To klasyka poprawnie zrealizowanego POST. Tzw. Get-after-post.

> 1. <form> type POST -> serwer Proxy.
> 2. Proxy przesyła dalej dane do docelowego serwera.
> Pytanie tylko jak odebrać odpowiedź od serwera docelowego?

Tak jak pierwotny użytkownik, gdyby się do niego odwołał bezpośrednio.

Pewnie jakiś szczegół mi umyka...

HARY

--
Własny styl to przedzieranie się przez gąszcz własnej banalności.

do góry

W dniu 2012-12-09 20:46, HARY pisze:
> On Sun, 09 Dec 2012 19:50:42 +0100, Cezary Tomczyk wrote:
>> W dniu 2012-12-07 08:35, HARY pisze:
>>> 2. Na serwerze szyfrowanie jednokierunkowe i przekierowanie GET (do
>>> adresu URL/?arg=hash).
>> To przypomina mi rozwiązanie z użyciem Proxy :-)
>
> To klasyka poprawnie zrealizowanego POST. Tzw. Get-after-post.
>> 1. <form> type POST -> serwer Proxy.
>> 2. Proxy przesyła dalej dane do docelowego serwera.
>> Pytanie tylko jak odebrać odpowiedź od serwera docelowego?
>
> Tak jak pierwotny użytkownik, gdyby się do niego odwołał bezpośrednio.
>
> Pewnie jakiś szczegół mi umyka...

Chyba tak. Przekierowanie Get-after-post niczego specjalnie mi nie
rozwiązuje a jeszcze bardziej komplikuje. Po stronie serwera robię
przekierowanie, ale:

1. Ewentualnie dane, jakie chciałbym przesłać do przeglądarki z powrotem
w ramach odpowiedzi z serwera, są w URL-u, bo to GET.
2. Rozumiem, że wówczas callback będzie, powiedzmy, kiedy strona się
załaduje po przekierowaniu a ja sprawdzę czy w URL-u są odpowiednie dane
z serwera.

To, co ja chcę zrobić, to wysłanie dane nie GET-em, ale POST-em i nie
mogę użyć XHR-a do tego w przeglądarkach, które nie wspierają CORS-u.
Robię to za pomocą JSNOP, ale jest z tym trochę problemów odnośnie
bezpieczeństwa, a których to wcześniej pisałem.

Mi nie chodzi o zabezpieczenie się przed wielokrotnym submitem, ale o
przesłanie danych POST-em po SSL-u lub użycie czegoś, co nie będzie
GET-em. Tak bym to ujął.

--
Cezary Tomczyk
http://www.ctomczyk.pl/

do góry

W dniu 2012-12-09 20:46, HARY pisze:
> On Sun, 09 Dec 2012 19:50:42 +0100, Cezary Tomczyk wrote:
>> W dniu 2012-12-07 08:35, HARY pisze:
>>> 2. Na serwerze szyfrowanie jednokierunkowe i przekierowanie GET (do
>>> adresu URL/?arg=hash).
>> To przypomina mi rozwiązanie z użyciem Proxy :-)
>
> To klasyka poprawnie zrealizowanego POST. Tzw. Get-after-post.
>
>> 1. <form> type POST -> serwer Proxy.
>> 2. Proxy przesyła dalej dane do docelowego serwera.
>> Pytanie tylko jak odebrać odpowiedź od serwera docelowego?
>
> Tak jak pierwotny użytkownik, gdyby się do niego odwołał bezpośrednio.

Sądzę, że taki wariant powinien być dobry:

1. Tworzę iframe a w nim wysyłam XHR-a z POST-em.
2. Serwera odpowiada a ja odbieram dane i wywołuję funkcję z host-a
gdzie parametrem będą dane z XHR-a.

Hm, nie wygląda mi to tak źle.

--
Cezary Tomczyk
http://www.ctomczyk.pl/

do góry