Chrome 4 naprawia trzynaście luk w zabezpieczeniach

Zainstalowanie opublikowanej wczoraj czwartej wersji przeglądarki Google Chrome opłaca się nie tylko ze względu na nowe funkcje, ale i z tego powodu, że usunięto w niej trzynaście luk w zabezpieczeniach. Sześć z nich autorzy Chrome’a oznaczyli jako krytyczne - korzystający z nich napastnik najprawdopodobniej może się włamać do komputera z systemem Windows.

Chrome 4 naprawia trzynaście luk w zabezpieczeniach
Źródło zdjęć: © Google

27.01.2010 | aktual.: 27.01.2010 14:59

Zainstalowanie opublikowanej wczoraj opłaca się nie tylko ze względu na nowe funkcje, ale i z tego powodu, że usunięto w niej trzynaście luk w zabezpieczeniach.

Sześć z nich autorzy Chrome’a oznaczyli jako krytyczne – korzystający z nich napastnik najprawdopodobniej może się włamać do komputera z systemem Windows. Według raportu bezpieczeństwa Google’a usterki wykryto w funkcjach odpowiedzialnych za obsługę elementów canvas, przetwarzanie obrazów i blokowania dostępu do obiektów w innych domenach.

Obraz
© (fot. Google)

Pierwszy błąd na liście jest opisany intrygująco niskim numerem – 3275. Może to oznaczać, że był on znany programistom już od jakiegoś czasu, ale naprawa wymagała wiele wysiłku. Pozostałe usterki mają status mniej krytycznych. Jedna z luk pozwala napastnikowi na wyśledzenie informacji umieszczonych w adresie URL –. takich jak parametry albo dane logowania. Ten sam błąd wykryto w przeglądarce Safari. Nie wiadomo, czy inne luki z Chrome’a także pojawiają się w browserze Apple’a. Nie da się tego jednak wykluczyć, zważywszy, że obie aplikacje bazują na silniku WebKit.

Przeglądarka Chrome 4.x została poza tym wyposażona w dwie nowe funkcje zabezpieczające. Mechanizm Strict Transport Security pozwala serwerowi zmusić aplikację do zmiany niezabezpieczonego połączenia http na szyfrowane https. Ponadto Chrome 4 dysponuje eksperymentalnym modułem zabezpieczającym przed atakami XSS. Filtr XSS Auditor kontroluje kod napisany w JavaScripcie – sprawdza mianowicie, czy umieszczono go już w żądaniu wygenerowania strony WWW. Jeżeli tak było, to najprawdopodobniej mamy do czynienia z tzw. refleksywnym atakiem XSS, w którym napastnik manipuluje adresem URL. W takiej sytuacji przeglądarka nie wykonuje skryptu.

Komentarze (1)