Si te encuentras con alguna parte que te causa duda puedes dejarnos un comentario y te ayudaremos rápidamente.
Solución:
sí – Las aplicaciones de servidor y de escritorio de Java son básicamente seguras.
Cuando ejecuta una aplicación de escritorio, Skype, Picassa, lo que sea, le da a ese software acceso completo a su computadora. Tienes que confiar en el software.
Por el contrario, cuando ejecuta un subprograma de Java en su navegador web, el subprograma se ejecuta en un entorno restringido llamado caja de arena. La caja de arena existe, por lo que no tiene que confiar en el subprograma de Java.
Java ha tenido muchas vulnerabilidades; casi todos son “fugas de caja de arena”. En otras palabras, si está ejecutando una versión antigua de Java, un subprograma malicioso puede salir de la caja de arena y tomar el control de su computadora.
No hay muchas tecnologías que sean compatibles con los entornos sandbox. De hecho, solo hay tres tecnologías comunes en las que la gente ejecuta rutinariamente software que no es de confianza: Java, JavaScript y Flash. Todos estos han tenido muchas vulnerabilidades de escape de sandbox, lo que demuestra la dificultad de escribir una sandbox segura.
Cuando ejecuta Java en su escritorio o en un servidor, confía en el código Java que está ejecutando, por lo que no depende de la zona de pruebas. En ese contexto, la principal preocupación es si los datos que no son de confianza pueden interferir con la aplicación. Por ejemplo, si está hablando con alguien por Skype, ¿podría enviarle un mensaje malicioso que Skype maneja mal y le permite tomar el control de su computadora? (Solo estoy usando Skype como ejemplo aquí).
Ha habido muy pocos casos en los que errores en el tiempo de ejecución de Java permitirían piratear una aplicación de escritorio o servidor. Normalmente, esto ocurre debido a errores en el código de la aplicación, no a Java en sí.
Pero, ¿el JRE es seguro sin el complemento del navegador? ¿Son las aplicaciones de servidor, móviles y de escritorio Java tan vulnerables como el complemento de Java?
El JRE no es tan seguro incluso si no tomamos en consideración el complemento de Java. Para darte una pista, aquí encontrarás una larga lista de vulnerabilidades de seguridad, incluidas las críticas, descubiertas durante este año que afectan a JRE en sus diferentes versiones.
Y los mecanismos de espacio aislado que encontramos en la JVM (y en otros lugares) no son tan perfectos, a veces se pasan por alto:
Aunque Oracle es consciente de que las vulnerabilidades de Java también se pueden explotar en las implementaciones de servidores al proporcionar entradas maliciosas a las API en componentes vulnerables, su mensaje generalmente ha sido que la mayoría de las vulnerabilidades de Java solo afectan el complemento del navegador de Java o que los escenarios de explotación de Java Las fallas en los servidores son improbables, dijo Gowdiak el martes por correo electrónico.
“Intentamos informar a los usuarios de que las afirmaciones de Oracle eran incorrectas con respecto al impacto de las vulnerabilidades de Java SE”, Dijo Gowdiak. “Demostramos que los errores evaluados por Oracle que afectan solo al complemento de Java también pueden afectar a los servidores”.
Fuente: Investigadores: Defecto grave en Java Runtime Environment para escritorios y servidores
Si bien Java RE no siempre es tan seguro como se anuncia, las alternativas son aún peores. Otras tecnologías como C ++ ni siquiera intentan ofrecer sandboxing y permiten que un programa haga lo que quiera. Cuando ejecuta un programa local en su máquina, debe asumir que le permite hacer lo que quiera. No importa si está implementado en C, Python, Java o lo que sea.
Aquí puedes ver las comentarios y valoraciones de los lectores
Eres capaz de avalar nuestra faena poniendo un comentario y dejando una puntuación te damos las gracias.