Share
Uno de los aspectos más interesantes del desarrollo web moderno es el potencial que viene con la creación de aplicaciones específicamente para navegadores web (o para ejecutar "en la nube").
Originalmente, Java estaba destinada a ser la solución de "una sola escritura y de ejecución en cualquier lugar", pero parece que la web se ha convertido en el medio perfecto para eso. Quien lo hubiera pensado, ¿verdad??
Pero junto con los diversos navegadores que tenemos disponibles, las tecnologías que podemos aprovechar y, simplemente, las ordenado cosas que podemos hacer, todavía hay un punto débil en el desarrollo de aplicaciones web: secuencias de comandos entre sitios.
Y considerando que WordPress es una aplicación web en la que muchos de nosotros creamos para divertirnos, obtener ganancias o para ganarse la vida, es un tema que no debemos evitar. especialmente Si queremos tener los productos más robustos posibles..
En esta serie de dos partes, vamos a echar un vistazo a las secuencias de comandos entre sitios De Verdad Es, sus peligros, cómo afecta el desarrollo de WordPress y luego los pasos prácticos que podemos tomar para probar nuestros temas y complementos..
Los scripts de sitios cruzados, generalmente abreviados como XSS, se definen en Wikipedia de la siguiente manera:
XSS permite a los atacantes inyectar secuencias de comandos del lado del cliente en las páginas web que ven otros usuarios. Los atacantes pueden utilizar una vulnerabilidad de secuencias de comandos entre sitios para omitir los controles de acceso, como la misma política de origen..
Creo que esa definición funciona bien si está familiarizado con las vulnerabilidades, la misma política de origen y lo que constituye exactamente una inyección de un script del lado del cliente, pero para muchos, eso simplemente no es suficiente.
Una vista conceptual de cómo los datos viajan del cliente al servidor. Así que echemos un vistazo a los scripts entre sitios desde cero antes de continuar..
Los scripts del lado del cliente son básicamente cualquier código que se ejecuta en el lado del cliente de un sitio web o aplicación web. Podría decirse que los scripts del lado del cliente más populares son las funciones de JavaScript. En contraste, PHP sería considerado un script del lado del servidor.
Otra forma de verlo es esta: los scripts del lado del cliente se envían desde el servidor a la computadora del visitante cuando se carga la página web. La secuencia de comandos luego se ejecuta. A veces hace algo simple como animar un menú..
Otras veces, puede hacer algo más avanzado como hacer una llamada asíncrona al servidor, recuperar algunos datos en función de la ubicación de los usuarios y adaptar la información que ven..
Aunque es posible que esté utilizando la información de ubicación proporcionada por el navegador, sigue siendo seguro ya que el navegador mantiene los datos y la información se recupera en función de la información disponible públicamente..
Quizás un nombre mejor para "Inyección de guiones" es "inyección de código".
En este caso, un atacante busca literalmente algún tipo de elemento de entrada en su sitio, que puede ser un campo de búsqueda, un campo de contacto, un campo de nombre o alguna Otro tipo de elemento que envía datos a un servidor. Esto normalmente se hace mediante el uso de un script, a veces es JavaScript malicioso, pero los atacantes puede tener éxito en la inserción de comandos PHP o MySQL, también.
Finalmente, se le conoce como inyección porque si el atacante tiene éxito, entonces están literalmente inyectando su código en tu solicitud.
El concepto de una política del mismo origen es simple: es una política que los exploradores aplican que básicamente permite que los scripts del lado del cliente, como JavaScript, realicen solicitudes a otras páginas y scripts del lado del servidor. en el mismo servidor (o, el mismo origen), pero no a otros dominios o sitios.
Por ejemplo, puede configurar una función de JavaScript para realizar una llamada desde tutsplus.com a wordpress.com, recuperar datos y luego mostrarlos en tutsplus.com. Eso violaría la política del mismo origen..
Ahora, para aclarar, esto no quiere decir que sea no poder ser hecho A través de la combinación de funciones creativas del lado del cliente y llamadas del lado del servidor, las cosas puede lograrse, pero los navegadores hacen lo mejor que pueden para evitar que los scripts del lado del cliente realicen esto.
En este punto, las implicaciones deben ser bastante claras. Las vulnerabilidades de los scripts entre sitios pueden dar a los visitantes malintencionados el control sobre nuestros sitios y aplicaciones web de formas que finalmente no podamos controlar..
Por ejemplo, pueden ir desde relativamente menores hasta mucho más importantes:
Todo esto depende de las características que ofrezca el sitio y de la seguridad del sitio..
Cualquiera que sea el caso, la seguridad de la aplicación web es algo que está aquí para quedarse. De acuerdo, creo que todos deberíamos especializarnos en nuestros campos respectivos, y que los especialistas en seguridad son personas a quienes debemos consultar antes de lanzar una aplicación web que pueda contener información confidencial, pero eso no significa que no podamos familiarizarnos. Con algunas estrategias básicas para nuestras propias pruebas..
Antes de ver la practicidad de implementar técnicas seguras con XSS en nuestros esfuerzos de desarrollo, es importante que notemos por qué, como desarrolladores de WordPress, deberíamos preocuparnos por esto..
Considera esto: WordPress es una aplicación web de pila completa. Consiste en una base de datos, una capa de aplicación y una capa de presentación, todas las cuales son extensibles por otros desarrolladores.
La pila de WordPress Esto significa que WordPress en sí está sujeto a muchas de las mismas amenazas de seguridad que cualquier otra aplicación web, pero aquellos que construyen para WordPress también lo están.
Incluso si WordPress era altamente resistente a cualquier ataque XSS, eso no significa que las herramientas de terceros, como complementos o temas, cosechen esos beneficios automáticamente.
Después de todo, están construidos por desarrolladores externos que pueden no estar siguiendo las mejores prácticas al escribir código defensivo.
Todas las funciones de WordPress a un lado y en el nivel más básico, si su trabajo acepta cualquier entrada del usuario de alguna manera, entonces es posible que esté abriendo la puerta para un exploit XSS.
Incluso me atrevería a decir que si está buscando aprovechar algunas de las API principales de WordPress para aceptar entradas y almacenar datos, entonces no está completamente seguro..
Después de todo, WordPress podría tener exploits que aún no se han descubierto.
Entonces, esto plantea la pregunta: si realmente nos importa el trabajo que estamos haciendo y queremos construir algo significativamente más seguro, entonces hay una serie de cosas que podemos hacer.
Primero, debemos asegurarnos de que estamos usando las funciones de API adecuadas para manejar los campos de entrada, los atributos, la validación y el saneamiento. Algunas de estas funciones proporcionan características específicas para:
De hecho, el artículo del Codex ofrece funciones detalladas sobre:
Recomiendo leer el artículo en su totalidad..
En segundo lugar, podemos ejecutar nuestro tema o complemento a través de una batería de pruebas XSS que se utilizan para descubrir cualquier vulnerabilidad que no hayamos podido detectar. Pero cubriremos esto en el próximo artículo..
Para resumir, las secuencias de comandos entre sitios se refieren a la capacidad de los usuarios malintencionados para insertar su propio código malicioso en nuestro sitio web, aplicación web, tema o complemento, en un intento de obtener el control de algunos aspectos, o de todos los aspectos, del sitio web.
El potencial de las vulnerabilidades varía de una aplicación a otra, pero teniendo en cuenta que nuestra área de especialidad es con WordPress, nos centraremos en las estrategias para explotar la prueba de nuestro trabajo en el próximo artículo..
Accentsconagua