marcoos:
Usilnie wytężam swój umysł, ale nie mogę sobie przypomnieć gdzie mi się przydaje tego typu udogodnienie. Nie potrafię przypomnieć sobie serwisu który wymagałby ode mnie podawania na różnych podstronach pary login plus hasło. Ale nawet gdyby to moim zdaniem user powinien mieć świadomość, że musi podać hasło na każdej podstronie za pierwszym razem.

Ancestor:
Nie zrozumiałem pierwszego pytania. Jaki skrypt ma odczytać zawartość i czego? Pliku cookie? Czy zawartość pliku z hasłami na komputerze usera?
Uważam, że nie jest naturalne aby przeglądarka kojarzyła zapamiętane login i hasło z wirtyną na podstawie FQDN. Właśnie dlatego, że można to bardzo łatwo wykorzystać. Kojarzony powinien być cały URL. Chociaż nie twierdzę, że nie będzie problemów w momencie gdy w URLu będzie zaszyty np. session id.
Innym rozwiązaniem problemu jest uniemożliwienie przeglądarce klejenia w ukryte pola formularza (z atrybutem hidden). Ale to również będzie można łatwo obejść (ramki, przykryte formularze wyższymi layerami itp.).

Tym razem definitywnie EOT. ;-)

Pierwszy akapit brzmi:
“Niekoniecznie. Co przeszkodzi skryptowi po prostu odczytać zawartość pola z hasłem?”

A jeżeli już nawiązujemy do XSS to technika ta nie umożliwia kradzieży haseł i innych wrażliwych danych jeżeli nie są one zapisane w plikach cookie, URLu jako parametr (GET),

Niekoniecznie. Co przeszkodzi skryptowi po prostu odczytać zawartość ?

Generalnie, sprawa wygląda wg mnie następująco. Technologie, na który oparte jest www nie są dostosowane do tworzenia “stron w stronach”. Witryny, które to robią muszą pamiętać, że wkraczają na bardzo grząski grunt, bo przeglądarki od zawsze identyfikują poszczególne strony po hoście i nie mogą w żaden sposób rozróżnić co jest stroną macierzystą, a co potencjalnie podejrzaną zawartością. Kiedy więc tego rodzaju witryny łamią bardzo wiele konwencji, na których opierają mechanizmy bezpieczeństwa przeglądarek, są one odpowiedzialne za bezpieczeństwo swojej zawartości.

Jest zupełnie naturalne, że przeglądarka kojarzy zapamiętane hasło z witryną (hostem), do którego ono przynależy. MySpace dobrze wie, że fakt, iż łamie tę konwencję i że czyni go odpowiedzialnym za skutki – dlatego przecież filtruje zawartość, dlatego usuwa skrypty. Jak widać filtruje nie dość dokładnie.

Ja na to patrzę tak: jest to przykład błędu w filtrowaniu zawartości przez witrynę. Okazało się, że akurat na ten błąd przeglądarka może być odporna, choć trudno mieć do niej wielkie pretensje, że wcześniej nie była. Ale tak czy inaczej, w przypadku niemal wszystkich pozostałych błędów w filtrowaniu zawartości przeglądarki są bezradne.
Jedynym wyjściem jest samodzielne dbanie o bezpieczeństwo swojej zawartości przez hostujące ją witryny.

To nie jest ‘niedostateczne’ sprawdzenie URL-a. To jest rozwiązanie dla wygody użytkownika, który nie musi osobno wpisywać go na 40 różnych stronach na tym samym hoście. To udogodnienie ma jednak tę wadę, że pozwala twórcom witryn strzelić sobie w stopę.

Teraz chodzi o to, czy da się zachować to udogodnienie przy jednoczesnym uniemożliwieniu strzału w stopę.

grunt to prawda na temat m$iE

I co ma XSS do wspomnianego błędu klejenia przez Fx haseł do pól forumalrzy gdzie popadnie (uogólniając)?

To jest praktycznie to samo – bez filtrów po stronie serwera użytkownik MySpace’a mógłby a) wykraść hasła; b) wykraść cookies za pomocą XSS. Skutek mniej-więcej taki sam…

Zabezpieczenie przed (a) i (b) jest przede wszystkim powinnością operatorów witryny, przeglądarka może tylko ‘zabrać małpie brzytwę’, czego Firefox faktycznie nie robił, ale będzie.