¿WP es vulnerable al actualizar complementos o temas?

4

Una vez, tuve el problema de que, de alguna manera, alguien podía cambiar los archivos de mi sitio web sin las credenciales de FTP o SSH. Probablemente ingresó a través de WP (probablemente no fue un 'él', sino un 'it', un bot), dijimos después de la investigación.

De todos modos, desde entonces estoy usando el complemento WordPress File Monitor , que me envía por correo cuando se encuentran los archivos. cambiado Ahora, cuando actualizo los complementos o temas, primero realizo un escaneo con el monitor de archivos, luego actualizo y luego escaneo nuevamente. El monitor emite una alerta debido a la actualización y la elimino porque "es debido a la actualización".

Ahora me pregunto, si WP es especialmente vulnerable al actualizar (por ejemplo, si es posible que la actualización no provenga de los servidores WP sino de un pirata informático), entonces Con esto abro una fuga en la seguridad de mi sitio.
Por otro lado, si los complementos / temas actualizados funcionan (lo que siempre verifico), y solo se modifican los archivos de los complementos (que también verifico siempre), entonces, en mi opinión, no es tan probable que alguien hackeado mi sitio durante la actualización.

¿Estoy haciendo lo correcto aquí, o debo verificar mejor después de actualizar?

    
pregunta Keelan 04.04.2014 - 10:37

2 respuestas

3

Lo que estás haciendo en este momento está bien, pero hay maneras mucho mejores de hacerlo.

El problema del ataque del hombre en el centro aquí es que insertarse entre wordpress.org y un servidor en un centro de datos no es una tarea fácil, por lo que este escenario es muy improbable.

However

Si abandona el actualizador integrado y, en cambio, confía en los repositorios de git para desplegar sus datos, puede garantizar al 100% que sus complementos y temas son seguros, incluso si ocurre un ataque en el centro .

Esto se debe a la fiabilidad que promete git. Un repositorio de git tiene un hash SHA-1 que representa su historial VCS, y cualquier intento de "entrometerse" o manipular un repositorio de git para agregar código invalidará ese hash, causando que git se oponga. Debido a esto, siempre que el hash sea bueno, puede bajar los cambios de código desde cualquier lugar, sin importar lo poco confiable que sea la garantía criptográfica.

Aquí está Linus Torvalds hablando de confianza y confiabilidad en Git mucho mejor de lo que podría explicar:

enlace

Una vez que se haya movido a una configuración de versión controlada, puede configurar su carpeta wp-content, etc. para que lea solo para los servidores Apache / WWW / Nginx. Si un repositorio que no es de git está dañado o en peligro, simplemente puede volver a verificar el repositorio en su lugar y deshacer el daño.

Las herramientas de aprovisionamiento / implementación, como Composer, también serían útiles aquí.

Tenga en cuenta que si bien Git evitaría que un hombre en el ataque central resalte las inconsistencias de los datos y proporcione evidencia de manipulación, solo garantizará que tenga la copia correcta de la fuente. No evita que el desarrollador original tenga una crisis nerviosa y ponga un comando DROP ALL TABLES en su complemento. Para eso tenemos pruebas en entornos limitados, revisiones de revisión / códigos y foros de soporte.

    
respondido por el Tom J Nowell 04.04.2014 - 11:36
1

Su actualización es tan segura como un punto más débil en su cadena de actualización. Dado que la actualización se realiza a través de HTTPS, ya que un ataque MITM 3.7 contra wordpress.org será tan difícil que no vale la pena dedicar tiempo a considerar la posibilidad de protegerse contra él, ya que cualquier persona con los recursos para hacerlo podrá hacerlo de una forma u otra.

Los puntos más problemáticos son en realidad las cuentas en wordpress.org y su cuenta en su servidor. Puede proteger su servidor pero no puede protegerse contra el pirateo de las cuentas de wordpress.org y la inserción de códigos maliciosos en los complementos y temas que utilice.

La única forma de estar totalmente seguro de con qué actualizar el sitio es mediante la carga manual de los archivos en el servidor después de haberlos comprobado.

Nota al margen: si los archivos en su servidor se modificaron sin acceso ftp o ssh, entonces su servidor no es lo suficientemente seguro y probablemente no esté aislando a Apache como un usuario diferente y establezca los permisos correctos en sus directorios.

    
respondido por el Mark Kaplun 04.04.2014 - 12:07

Lea otras preguntas en las etiquetas