2010-04-23 18 views
6

Jestem częścią zespołu testującego i otrzymałem zadanie "zachowywania się źle" przy użyciu JavaScript w przeglądarce Firefox. Próbowałem, aby wyłączyć przeglądarkę, ale żadna z nich nie robi nic gorszego, niż polecenie wyskakujące z pytaniem o zamknięcie skryptu.Awaria firefox przy użyciu JavaScriptu

Jakieś inne pomysły?

+18

Wygląda to tak: Znajdź mnie jako błąd dla zero-dayz! –

Odpowiedz

9

Nieco podobny do widelca „bomby”

<html> 
<body> 
<a href="#" onclick="die()">click me!</a> 
<script> 
function die() { 
    setTimeout(function() {die(); die()}, 0) 
} 
</script> 
</body> 
</html> 

Nie jest stoppable przez FF 3.6 i poniżej (o ile użytkownik nie dzieje, aby zamknąć kartę naruszającego dość szybko). Im dłużej pozwolisz, aby działała, tym bardziej jest to złośliwe. W końcu pochłonie całą pamięć dostępną dla procesu. Obciążenie procesora również powinno wzrosnąć. Niektóre systemy operacyjne radzą sobie z niewłaściwie zachowującym się FF lepiej niż inne. Możesz uczynić to bardziej zdegenerowanym, jeśli zastosujesz odpowiednie obciążenie do DOM w każdym cyklu.

Edytuj: "Użyj tej wiedzy tylko dla dobra świata". :-)

+1

Używam Firefoksa 13 i nadal nie jest na to odporny. Kilka minut później Firefox wyświetla mi okienko "We're Sorry". – bwDraco

+2

Ugh, co za usterka.W 32-bitowych wersjach Firefoksa jest to łatwy atak DoS, który usunie Firefoksa po kilku minutach. Jest to jeszcze gorsze w 64-bitowej wersji Firefoksa (na przykład w systemie x86-64 Linux): przeglądarka może przydzielić praktycznie nieograniczoną ilość pamięci, potencjalnie blokując maszynę z powodu zamiany, dopóki nie wykryje tego zabójca OOM, lub w systemach, w których mają podobną funkcjonalność, całkowicie zawieszają komputer. To naprawdę musi być załatane. – bwDraco

+0

@DragonLord Co za wstyd, naprawdę. Spodziewałbym się pewnych wewnętrznych limitów bezpieczeństwa dla liczby handlerów. Zastanawiam się, jak inne przeglądarki są sprawiedliwe. Jednakże, jeśli * kiedykolwiek * trafiłam na stronę, która to zrobiła, nigdy bym nie wróciła;) –

6

Monitorowanie czasu wykonania skryptu jest ładne i wszystko, ale nie rozwiązuje problemu z pętlą modalną. Idąc do skrzynki alert, confirm lub prompt zatrzymuje zegar, czyniąc w ten sposób:

<script>while(true) alert('alert bomb');</script> 

trudno uciec, a to:

<body onbeforeunload="while(true) alert('alert bomb');"> 

skutecznie niemożliwe. (Miej pod ręką swojego Menedżera zadań).

Korzystanie z trudnych do uniknięcia modalnych pętli było ulubioną taktyką agresywnych stron instalacyjnych programów szpiegujących. ("Kliknij Tak, aby zainstalować VomitBar teraz lub zmień się z niekończącymi się skrzynkami alarmowymi ...")

+3

Chrome> Firefox na ten temat :); http://tinypic.com/r/54smer/5 – Matt

+1

Jedna z najbardziej irytujących rzeczy ... kiedykolwiek! –

+2

Chrome oferuje opcję zakończenia skryptu po pierwszym polu. –

2

Udało mi się wielokrotnie zawiesić Firefoksa, wykonując masowe wstawianie DOM około 10 000 elementów.

Zasadniczo użytkownik klika przycisk uruchamiający wywołanie jQuery AJAX. Wywołanie zwróci pełny plik HTML, który zostanie dołączony do konkretnego elementu div z jQuery.

<script> 
    $("div.content").empty(); 
    $("div.content").html(data); 
</script> 

Wtedy gdy dane dodano byłoby próbować zanalizować ten cały syf danych i dodać onClick i onHover wydarzenia w zasadzie każdy element w drzewie.

Zapewniam, że za każdym razem, gdy uruchomiłem tę funkcję, moja przeglądarka zawiesiła się. Przywołałoby to zwykłe "skrypt działa wolno, chcesz go anulować", ale nigdy nie mogłem go anulować i zawsze musiałem użyć CTRL + ALT + DEL.

Po prostu FYI, nigdy nie planowałem wprowadzenia elementu 10.000 elementu, to był błąd z mojej strony. Byłem kwerendy do bazy danych z JOIN i przeznaczone do wykonywania SELECT DISTINCT, a zamiast SELECT, więc zamiast zwracania 100 elementów, zwróciłem 10.000 ze względu na łączenie. Whoops.

Powiązane problemy