Temat: Jak zabezpieczyć część serwerową, aby umożliwiała obsługę...

Chodzi mi o to, że jest sobie skrypt javascript i wykonuje on serię żądań ajax do serwera, który jest dostępny powiedzmy pod nazwą example.pl

Czy są jakieś sposoby, aby zabezpieczyć wykonywanie skryptu php np. pod adresem example.pl/ajaxscript.php tylko dla skryptów, które się załadowały z tej właśnie domeny example.pl

Nie chciałbym sytuacji w której np. ktoś kto ma stronę na domenie inna.pl załączy sobie mój skrypt javascript i będzie wykonywał żądania ajax do mojego skryptu serwerowego z example.pl/ajaxscript.php lub bezpośrednio go wywoływał.

Jakie znacie zabezpieczenia przed tego typu sytuacjami, jak one się nazywają i jak bardzo są one skuteczne? Chodzi mi o zabezpieczenie danych, żeby nikt inny nie mógł sobie żadnym robotem/spiderem pobrać ich i zapisać w swojej bazie danych.Marcin Kapusta edytował(a) ten post dnia 10.10.11 o godzinie 23:19

Temat: Jak zabezpieczyć część serwerową, aby umożliwiała obsługę...

@Marcin,

Uruchom dwie domeny lokalnie i z jednej spróbuj wysłać zapytanie AJAX’owe do drugiej – zapytania AJAX nie są crossdomain.

Temat: Jak zabezpieczyć część serwerową, aby umożliwiała obsługę...

Tak na szybko:
1. $_SERVER['HTTP_REFERER'] - nie zadziała dla ludzi z wyłączoną obsługą
2. $_COOKIE - nie zadziała jak ludzie mają wyłączoną obsługę
3. $_SESSION - powinno zadziałać

Ad3. Po wejściu na główną stronę startujemy sesję, wrzucamy do niej jakąś zmienną z losową nazwą i wartością. Na początku skryptu odpalanego przez ajaxa robimy session_start() i odczytujemy z $_SESSION zawartość tej losowej zmiennej. Jest taka jak trzeba? To idziemy dalej. Nie ma? exit();
Jeśli na serwerze są cuda z wygasającymi bez powodu sesjami, to wywołania ajaxowe będą się tracić. Jak się kopiujący zorientuje w czym rzecz, to najpierw odpali sobie stronę główną, a następnie właściwy skrypt.

PS. Jak ktoś będzie chciał skopiować, to i tak skopiuje.Janusz Skudrzyk edytował(a) ten post dnia 11.10.11 o godzinie 00:29

Temat: Jak zabezpieczyć część serwerową, aby umożliwiała obsługę...

@Janusz
A czy przypadkiem sesja nie używa ciasteczka?
Przesyłanie SID'a w urlu jest ... co najmniej złym pomysłem.

@Marcin
Nie jesteś w stanie zabezpieczyć.
Jeśli udostępniasz coś na zewnątrz - udostępniasz wszystkim.
Wszystko da się obejść, to tylko kwestia 'chcenia'.

Temat: Jak zabezpieczyć część serwerową, aby umożliwiała obsługę...

Michał Wachowski:
@Janusz
A czy przypadkiem sesja nie używa ciasteczka?
Przesyłanie SID'a w urlu jest ... co najmniej złym pomysłem.

można napisać własny mechanizm sesji oparty o pliki tekstowe czy bazę danych ;)

Krzysztof Safjanowski:
@Marcin,

Uruchom dwie domeny lokalnie i z jednej spróbuj wysłać zapytanie AJAX’owe do drugiej – zapytania AJAX nie są crossdomain.

jak to nie? :) http://blog.kamilbrenk.pl/cross-domain-javascript-cors/

Co do samego tematu - można sprawdzać nagłówek "Referer", ale łatwo go odpowiednio zmodyfikować. Innym sposobem jest zaszyfrowanie danych przesyłanych między adresami z kluczem, który będzie generowany z Twojej domeny.Kamil Brenk edytował(a) ten post dnia 11.10.11 o godzinie 01:27

Temat: Jak zabezpieczyć część serwerową, aby umożliwiała obsługę...

Kamil B.:

Michał Wachowski:
@Janusz
A czy przypadkiem sesja nie używa ciasteczka?
Przesyłanie SID'a w urlu jest ... co najmniej złym pomysłem.

można napisać własny mechanizm sesji oparty o pliki tekstowe czy bazę danych ;)

Nie do końca.
Sesja jest po stronie serwera, jak jest przechowywana - nie jest istotne (plik, db, łatever).
Cały bajer polega, że klient MUSI dostać identyfikator, który jest dostępny dla serwera.
Ergo - ciasteczko, url...

Temat: Jak zabezpieczyć część serwerową, aby umożliwiała obsługę...

Michał Wachowski:
Nie do końca.
Sesja jest po stronie serwera, jak jest przechowywana - nie jest istotne (plik, db, łatever).
Cały bajer polega, że klient MUSI dostać identyfikator, który jest dostępny dla serwera.
Ergo - ciasteczko, url...

W sumie racja, sesja musi być jakoś identyfikowana. Tylko wprowadziłem w błąd, dzięki za poprawę :)

Temat: Jak zabezpieczyć część serwerową, aby umożliwiała obsługę...

Kamil B.:

Michał Wachowski:
@Janusz
A czy przypadkiem sesja nie używa ciasteczka?
Przesyłanie SID'a w urlu jest ... co najmniej złym pomysłem.

można napisać własny mechanizm sesji oparty o pliki tekstowe czy bazę danych ;)

Krzysztof Safjanowski:
@Marcin,

Uruchom dwie domeny lokalnie i z jednej spróbuj wysłać zapytanie AJAX’owe do drugiej – zapytania AJAX nie są crossdomain.

jak to nie? :) http://blog.kamilbrenk.pl/cross-domain-javascript-cors/

Co do samego tematu - można sprawdzać nagłówek "Referer", ale łatwo go odpowiednio zmodyfikować. Innym sposobem jest zaszyfrowanie danych przesyłanych między adresami z kluczem, który będzie generowany z Twojej domeny.

Serwer musi zezwalać na CORS z tego co wiem. Chodzi o nagłówek Access-Control-Allow-Origin. W innych wypadkach symuluje się to za pomocą np PHP (skrypt JS wykonuje zapytanie do skryptu PHP który pobiera zawartość zewnętrznej strony).

Temat: Jak zabezpieczyć część serwerową, aby umożliwiała obsługę...

REFERER łatwo podrobić - pisałem kiedyś takie specjalne skrypciki więc to nie jest w ogóle zabezpieczenie.

Ciasteczka - też nie zda egzaminu dla chcącego
Sesja - no ona jest identyfikowana po tym co przeglądarka przesyła (ciasteczka, request-id itp)

Ajax może być CROSS DOMAIN - wiem bo nie raz korzystałem z usług dostępnych na innych domenach, żeby nie obciążać mojego serwera.

Myślałem nad rozwiązaniem takim, że np. codziennie na serwerze generować sobie jakiś identyfikator, klucz szyfrujący i w oparciu o ten klucz wysyłać dane do przeglądarki. Te dane normalnie można będzie przechwycić, ale np. haker nie zrobi tego mając jeden dzień bo jest ich po prostu za dużo. Podczas gdy w serwerze klucz szyfrujący się zmieni to wówczas dane pochodzące z serwera zmienią np. swoje identyfikatory gdyż one będą wyliczane na podstawie jakiegoś wyrażenia + ten klucz szyfrujący, który istnieje tylko po stronie serwera.
To są dane, które muszą mieć spójne identyfikatory bo są hierarchicznie ułożone w całość. Jeśli któryś id nie będzie się zgadzał albo będzie zdublowany to haker ich nie ułoży bo nie będzie wiedział jaki na dzień w którym je ściągał był wygenerowany klucz szyfrujący. Spotkaliście się kiedyś z takimi patentami? Czy ma to jakąś nazwę, żebym mógł o tym poczytać?

Z góry dzięki za Wasze sugestie...Marcin Kapusta edytował(a) ten post dnia 11.10.11 o godzinie 14:37

Temat: Jak zabezpieczyć część serwerową, aby umożliwiała obsługę...

Dariusz Półtorak:
Serwer musi zezwalać na CORS z tego co wiem. Chodzi o nagłówek Access-Control-Allow-Origin. W innych wypadkach symuluje się to za pomocą np PHP (skrypt JS wykonuje zapytanie do skryptu PHP który pobiera zawartość zewnętrznej strony).

Nie czytałeś mojej kryptoreklamy, prawda? :D tam wszystko jest wyjaśnione, tzn. to co dokładnie powtórzyłeś :)

@Marcin Kapusta: też dobre rozwiązanie, które proponujesz => wysyłasz do skryptu token wygenerowany na swojej domenie i jeśli się zgadza to skrypt wyświetla prawidłowe dane

Temat: Jak zabezpieczyć część serwerową, aby umożliwiała obsługę...

Kamil B.:

Dariusz Półtorak:
Serwer musi zezwalać na CORS z tego co wiem. Chodzi o nagłówek Access-Control-Allow-Origin. W innych wypadkach symuluje się to za pomocą np PHP (skrypt JS wykonuje zapytanie do skryptu PHP który pobiera zawartość zewnętrznej strony).

Nie czytałeś mojej kryptoreklamy, prawda? :D tam wszystko jest wyjaśnione, tzn. to co dokładnie powtórzyłeś :)

@Marcin Kapusta: też dobre rozwiązanie, które proponujesz => wysyłasz do skryptu token wygenerowany na swojej domenie i jeśli się zgadza to skrypt wyświetla prawidłowe dane

Rzuciłem okiem na temat w przerwie na kawę i link mi umknął. Znaczy nie popatrzyłem do czego prowadzi zakładając że jest tam tylko ogólnie o CORS.