gsingh2011
2014-05-09 22:39:24 UTC
Bardzo podoba mi się język programowania Java, ale ciągle słyszę o tym, jak niebezpieczny jest on. Wyszukiwanie w Google „niezabezpieczona java” lub „luki w zabezpieczeniach java” powoduje wyświetlenie wielu artykułów omawiających, dlaczego należy odinstalować lub wyłączyć Javę, aby chronić swój komputer. Java często publikuje ogromną liczbę poprawek bezpieczeństwa naraz, a mimo to wciąż pozostaje mnóstwo luk do załatania.
Rozumiem, że zawsze będą błędy w oprogramowaniu, ale ilość luk w zabezpieczeniach Java nie wydaje się normalne (czy sobie to wyobrażam?). Jeszcze bardziej zagmatwane jest to, że jeśli istnieje jedna decyzja architektoniczna, która tworzy te luki, dlaczego nie zmienić tego projektu? Istnieje mnóstwo innych języków programowania, które nie mają tego problemu, więc musi istnieć lepszy sposób na zrobienie tego, co Java robi źle. Dlaczego więc Java jest nadal tak niepewna?
Uważam, że to naprawdę niesprawiedliwe, że niektórzy ludzie twierdzą, że java byłaby „niepewna”, ponieważ jej koncepcja piaskownicy ma kilka wad, podczas gdy większość innych technologii nie ma nawet piaskownicy i pozwala programom robić praktycznie wszystko, co chcą na maszynie, na której działają. Krytyka jest uzasadniona tylko w naprawdę wąskim przypadku użycia apletów uruchamianych w przeglądarce internetowej, gdzie alternatywy, takie jak Flash, mają równie złe wyniki w zakresie bezpieczeństwa.
Twoje pytanie jest podobne do pytania „Dlaczego samochody nadal mają problemy z silnikiem?”. (A dla tych, którzy przychodzą pod kątem „C (++) tego nie ma!”, Dodaj „Mój rower nigdy ich nie ma!”)
Ponieważ był prześladowany jako dziecko.
Java ma stosunkowo * niewiele * luk w zabezpieczeniach dla pełnoprawnego języka programowania, który może działać w przeglądarce (większość innych języków obsługujących przeglądarkę nie jest w stanie wykonywać pewnych czynności). - Luki, o których ostatnio słyszałeś, to całkowicie złośliwe aplikacje (czytaj Aplety), które znajdują sposób na wydostanie się z piaskownicy i wykonanie dowolnego kodu w systemie. Może istnieć argument, że aplety są częścią javy, którą należy zaprzestać, jednak wiele technologii nadal na nich opiera się (konsole IMPI, witryny banków itp.).
@Philipp: Nie sądzę, żeby to było niesprawiedliwe. Jeśli język jest promowany jako piaskownica, ale jego piaskownica ma historię dziesiątek do setek krytycznych luk każdego roku, jest całkowicie sprawiedliwe, aby potępić go jako niepewny. Bezpieczeństwo nie jest sprawą absolutną, ale kwestią przestrzegania opublikowanej umowy. Być może nie jest sprawiedliwe porównywanie Javy i C ++, ale z pewnością porównywanie Javy i Lua. Jeśli się nie mylę, ten ostatni nie przeszedł nawet jednocyfrowych wartości luk w zabezpieczeniach przed ucieczką w piaskownicy.
@R .. Sandboxing dotyczy tylko bardzo wąskiego kontekstu, a są to aplety Java w przeglądarkach internetowych. Jeśli chcesz powiedzieć, że są one niepewne, całkowicie się zgadzam. Ale jak można wywnioskować z tego pytania, wiele osób rozszerza tę krytykę ogólnie na Javę, która obejmuje przypadki użycia, w których problemy z piaskownicą apletów nie mają w ogóle znaczenia.
@R .. Porównanie Javy do Lua również nie jest sprawiedliwe, ponieważ Java jest językiem ogólnego przeznaczenia z [ogromną biblioteką standardową, która zawiera wszystko oprócz zlewu kuchennego] (http://docs.oracle.com/javase/8 /docs/api/allclasses-noframe.html), podczas gdy Lua ma [bardzo małą standardową bibliotekę] (http://www.lua.org/manual/5.2/) i ma być osadzona w aplikacji hosta, która dodaje domenę -specyficzne powiązania skryptów z lua, które mogą być bezpieczne lub nie.
Moim zdaniem jest to całkowicie sprawiedliwe, ponieważ ogromna standardowa biblioteka * zaimplementowana poza piaskownicą * zasadniczo wyklucza możliwość zaoferowania bezpiecznego środowiska piaskownicy. Jest to jedna z rzeczy, w których Java bardzo się pomyliła, a Lua miała rację.
Zgadzam się, że „Java the language” zyskuje wiele negatywnego rozgłosu, ponieważ „Java the sandbox” jest tak zepsuta. To, czy jest to „sprawiedliwe”, czy nie, jest kwestią oceny, ale jest to konsekwencja decyzji marketingowej o ścisłym połączeniu tych dwóch. W większości systemów samo zainstalowanie Javy (w jakimkolwiek celu) powoduje również zainstalowanie komponentów przeglądarki, które narażają system na krytyczne zdalne luki w zabezpieczeniach, jeśli używana jest przeglądarka, więc można śmiało powiedzieć, że wystarczy zainstalować Javę, chyba że zszedłeś z drogi, aby zablokować jego użycie w przeglądarce, jest problemem bezpieczeństwa.
@R .. Firma, dla której pracowałem, używała LotusNotes wyłącznie dlatego, że niewielu ludzi z niego korzystało, więc luki w zabezpieczeniach, które z pewnością miały (jak wszystko), pozostały niewykryte. Obawiam się, że java jest po przeciwnej stronie. Każda wada, którą ma **, zostanie ** odkryta, nie oznacza, że inne rzadziej używane rzeczy są bezpieczniejsze, po prostu mniej osób próbuje je złamać
@R .. „z pewnością porównywanie Javy i Lua jest uczciwe. Jeśli się nie mylę, ta ostatnia nawet nie przeszła jednocyfrowych liczb dotyczących luk w zabezpieczeniach przed ucieczką z piaskownicy”. Zgodnie z tym argumentem, naprawdę wszyscy powinniśmy używać PostScript, ponieważ ma on jeszcze mniej takich luk. (PostScript _does_ w rzeczywistości oferuje sandboxing i jeśli poprawnie skonfigurowany może pozwolić na bezkarne wykonanie wrogiego kodu, FYI) (Jeśli nie rozumiesz tego, co mówię, to znaczy, że Java ma więcej _wykrytych_ luk w zabezpieczeniach, ponieważ Java jest używana _ daleko częściej_ niż Lua.)
W rzeczywistości PostScript ma w przeszłości sporo luk w zabezpieczeniach, zwłaszcza jeśli weźmie się pod uwagę środowisko, w którym ma być używany. Każdy język zgodny z Turingiem jest luką DoS w kontekście tego, do czego przeznaczony jest PostScript (dokumenty), zwłaszcza gdy jesteś uruchamianie go na mikrokontrolerach 1MHz wewnątrz drukarek.
Jeśli chodzi o Javę i Lua, nie ma znaczenia, jak często są używane. To kwestia projektu. Lua ma niewielką liczbę potencjalnych awarii (jeden z nich był idiotyczny: pozwolenie kodowi Lua na przesłanie kodu bajtowego bezpośrednio do maszyny wirtualnej). Java ma astronomiczną liczbę.
Oczywiście dla hakerów (białych kapeluszy) badanie wulnów języka Java jest bardziej interesujące niż w innych językach, podobnie jak w przypadku innych systemów operacyjnych Windows.
Może mógłbyś wyjaśnić, jaki jest kontekst twojego oświadczenia. Wygląda na to, że stwierdzasz, że uważasz, iż kod Java może wymagać naprawy, a opiekunowie oprogramowania nie wykonują wystarczająco dobrej pracy? Każda aplikacja będzie miała własny odpowiedni typ kodu do zaimplementowania, więc należy unikać polegania na jednym zestawie praktyk kodowania. Założę się, że aplikacje Java po stronie klienta przejdą przez Flash i wkrótce wymrą.
Hah, porozmawiajmy o niesprawiedliwości: rozwijamy [przeglądarkę w Javie] (https://github.com/UprootLabs/gngr) i ludzie mylą ją z apletami lub kojarzą ją z Javą, którą mylą z apletami lub kojarzą piaskownica menedżera bezpieczeństwa z bardziej szczegółową piaskownicą apletów ... i tak dalej.