Prólogo
Hola a todos Tengo 20 años Hasta hace poco, estudié en el Liceo y me estaba preparando para ingresar a una universidad médica, y ahora soy un desarrollador completo en una empresa estadounidense. De hecho, estoy muy contento de no haber tenido éxito con la medicina: la programación era mi pasatiempo y ahora puedo hacerlo todo el tiempo. Ahora preferiría no escribir sobre el éxito en TI. Ahora mismo quiero hablar sobre cómo leí un par de libros sobre vulnerabilidades (para proteger mis proyectos) y logré poner en práctica este conocimiento.
Descargo de responsabilidad
Todos los materiales, capturas de pantalla, así como enlaces a recursos de terceros, se publican con fines educativos. El autor no es responsable por su uso por otros visitantes al Habr. La compañía fue notificada por adelantado de 48 horas sobre la vulnerabilidad y recibió suficientes datos para solucionarla.
Como empezó todo
Fue un día muy ordinario. Completé varias tareas en el trabajo y preparé una taza de café. Al mismo tiempo, decidí leer
un artículo sobre la implementación de la aplicación en AWS, que una vez volví a publicar en VK (por cierto, nunca leí el artículo). La columna a la derecha del artículo muestra varios otros artículos y un
banner de socio para el proveedor de alojamiento .
No recuerdo qué me hizo exactamente ir al sitio, pero durante la transición noté una característica interesante: el enlace conduce a la página de registro e inmediatamente llenó un campo: un código promocional.
Si comparamos el código promocional, que se encuentra en el campo de entrada y en la barra de direcciones, vemos que coinciden completamente.
¿Qué podemos hacer al respecto?
Es común tratar de cambiar. Si el código promocional se compara con el valor en la base de datos, con una alta probabilidad obtendremos un error. Pero al cambiar la entrada, no hay ninguna solicitud al servidor y resulta que la entrada se verifica solo cuando hace clic en el botón de registro.
Creo que aquí ya puedes hacer algo más interesante: cambiar nuestro código promocional directamente en la barra de direcciones y ver qué sucede. Si no tienen un código promocional específicamente para el Habr que adiviné de inmediato,
así como cien juegos de caracteres diferentes , definitivamente podemos cambiar los valores del campo de entrada usando el enlace de dirección.
El siguiente paso es mirar el código HTML. RMB en el campo de entrada -> Ver código de artículo.
Aquí puede ver de inmediato que estamos cambiando el valor del campo de entrada. Intentemos salir y agregar, por ejemplo, un enlace. Para hacer esto, solo necesitamos cambiar el enlace y podemos cambiar el contenido de la página:
Resultado: acabamos de encontrar una vulnerabilidad xss en el sitio del proveedor de alojamiento.
Entonces, ¿qué sigue?
Creo que vale la pena ir más profundo. El enlace es de alguna manera superficial y no interesante. Queremos contarles todo esto a los propietarios del servicio e, idealmente, obtener una recompensa (la empresa, por cierto, no tiene una recompensa por errores, lo que significa que todo esto no se paga, pero aún no lo sabía). Intentemos colocar el bloque, estabilizarlo e insertar la imagen. ¿Qué se necesita para esto? De todos modos, cambie la URL.
Creo que describir html y css no vale la pena, así que solo pongo aquí lo que sucedió. Habr bloquea una parte de las etiquetas, descarta otras, no puedo poner el código de enlace aquí.
Publicaré un enlace aquí. No sé si ella trabaja en este momento, pero cuando publicó la publicación, trabajó. Quién lo necesita: saca el enlace y analiza.Remuneración
No piense que upCloud se negó por completo a pagar. En cambio, ofrecieron sus servicios de forma gratuita. Pero rechacé este tipo de pago, ya que no estoy interesado en alquilar un servidor ahora.
¿Cómo se puede explotar esta vulnerabilidad?
Aquí todo es simple: puede comenzar recolectando datos de todos los nuevos usuarios y terminar con sitios de phishing y usar el alojamiento de otra persona como propio. Puede reemplazar todos los enlaces de la página con los suyos o reemplazar el formulario con usuarios. Es suficiente enviarlos como referencias. Y, por supuesto, puede sustituir una solicitud al servidor desde el formulario para que no verifique el código promocional (al registrarse, el código promocional se verifica y la respuesta se devuelve al cliente con un error, pero todo esto se resuelve habilitando zhs).
Lo que los desarrolladores olvidaron hacer:
Es simple: validar la entrada del usuario. SQL-Inj no funciona allí: el servicio se bloquea en WordPress y, a su vez, procesa las líneas entrantes.
Por lo tanto, podemos:
- Verifique el código promocional con la base cuando renderice la página
Es lento y no está justificado. No hay carga adicional en la base de datos, y no tiene sentido si todavía se verifica durante el registro.
- Conduzca el código promocional durante la temporada regular
/ ^ [A-Z0-9] + $ / - es suficiente para validar valores y proteger contra vulnerabilidades. Y funciona más rápido que consultar la base de datos, y el efecto no es peor: se elimina XSS.
Conclusión
Los propietarios del servicio fueron notificados 48 horas + 2 días antes de que estaba negociando por correo electrónico y LinkedIn con aquellos que al menos de alguna manera se relacionaron con el desarrollo. Todas las conversaciones llegaron a: "Díganos cómo lo hizo, pero, por supuesto, no pagaremos las vulnerabilidades". También agregaré que de la misma manera que el sitio acepta scripts js de terceros: tanto a través de una fuente de terceros como mediante la escritura directa de código, sin embargo, en el segundo caso, Google Chrome detecta automáticamente xss y presenta una página de error en lugar de una página de servicio.
Espero que cada programador valide todos los datos de entrada y no se olvide de la cadena de consulta. Y también estoy seguro de que el artículo ayudará a alguien a notar de antemano + solucionar este problema en casa.
Muchas gracias por su atención