JSON i sens same-origin policy

Witam,

Dzisiaj pytanie z pokroju filozofii egzystencjalnej, otóż jaki jest sens blokowania pobierania plików .json (używanych np. w właściwości url, metody ajax) przez 'same-origin policy', skoro to tylko zwykłe dane, jakieś cyferki, literki, kompletnie bezbronne. Z kolei bardziej niebezpieczne, całe skrypty javascript hostowane na zewnętrznych serwerach/domenach można przez element 'script' podpinać bez problemu.

Nie tyle pytam jak (bo już wiem, użyłem jsonp :) ), ale dlaczego tak jest, bo trochę nie rozumiem sensowności.

Bo pod tymi literkami może kryć się logika typu "wywal wszystkie pliki na literę A, następnie w jsonie zwróć listę pozostałych plików".

URL nie ma znaczenia w dobie tak powszechnego rewrite. To tylko parę literek.

Z kolei bardziej niebezpieczne, całe skrypty javascript hostowane na zewnętrznych serwerach/domenach można przez element 'script' podpinać bez problemu.

Na to już powstają nagłówki jakieś z tego co kojarzę.

Np żeby ktoś Ci nie obciążał serwera zapytaniami do API, którego nie chcesz udostępniać.

Coś w tym jest. W sumie i tak z poziomu przeglądarki mógłbym wpisać odpowiedni url i wyświetlić sobie json, ale pewnie byłaby to operacja jednorazowa, a np na swojej stronie / aplikacji mógłbym zrobić rekurencyjny setTimeout() i np. pobierać te dane co 0.5s. A że użytkowników teoretycznie byłoby by dużo i długo by mieli otworzoną aplikacje, to i duże obciążenie mogłoby być generowane na serwerze udostępniającym .json

Wydaje mi się jednak, że jsonp generuje obciążenie w ten sam sposób, tak ? Są w takim razie jakieś sposoby na zablokowanie wykorzystanie mojego pliku .json w ten sposób przez inne osoby ?

Tak, udostępnianie jsonow nie bezpośrednio, tylko przez skrypt backendowy + autoryzacja.

same-origin-policy nie blokuje ani wyjścia żądania, ani odebrania odpowiedzi. Dla mnie zawsze było to bez sensu, możesz wysłać request, dostać response, dostać informację o tym, że response przyszedł, ale nie możesz dobrać się ani do jego treści, ani nawet statusu http odpowiedzi.
DDOS ajaksem cross-domain jest jak najbardziej możliwy. Zresztą są inne sposoby - załadowanie cross-domain js (mniejsza o to, czy faktycznie będzie to olbrzymi obrazek czy polecenie usunięcia czegoś) - z tego korzysta jsonp, załadowanie obrazka/iframe/css z obcej strony. Do treści odpowiedzi się nie dostaniesz, ale sam request zostanie wykonany.

@ŁF to ma jakiś tam sens, są lepsze rozwiązania, ale jeżeli domyślnie to działa jak działa - to z powodu tego w jaki sposób działa protokół HTTP - to i tak najlepsze co można było przygotować.

Gdyby nie taka domyślna blokada (nikt Ci nie broni stosować lepszych rozwiązań!) to załóżmy, że na 4p pod adresem: /user/data.json miałbyś dane zalogowanego użytkownika potrzebne do wypełnienia formularza edycji konta. Wtedy taki dzek na swojej stronie zrobiłby ajax pod ten adres i wyciągał dane ludzi, którzy wchodzą na jego stronę i są zalogowani na 4p.

BA!

To rozwiązanie jest jeszcze bardziej idiotoodporne, nawet przy niedoskonałościach HTTP.

Domyślnie ajax WYSYŁANY poza własną domenę nie ma ciastek/sesji. Jak już z poziomu JS poprosisz o wysłanie ciastek ALE na serwerze Allow-Control-Allow-Origin będzie ustawiony na *, a nie konkretną domenę (bo na 4p komuś tak każą, a ktoś bez wiedzy posłucha) - to ciastka także się nie wyślą.

Tak więc mamy out-of-the-box niezłe zabezpieczenie, które możemy samemu ulepszyć, bo domyślnie jest niedoskonałe, ale to już wina HTTP, a nie tych co wymyślili taki CORS.