Nueva vulnerabilidad Cross-Site Scripting afecta a Servipag.com

Muchas vulnerabilidades han afectado ya a este portal de pagos, las cuales han sido corregidas proactiva y reactivamente. Tambien ha dado que hablar el alto estandar de seguridad que dicen tener. Por ejemplo, se dieron a conocer vulnerabilidades Cross-Site Scripting en dos oportunidades y tambien una falla de seguridad categorizada como “Local File Include”.

Posteriormente se demostró que Servipag estaba exponiendo los datos de los usuarios que usaban el portal para realizar pagos, mediante el acceso sin restriccion a los comprobantes de pagos. Solo bastaba con modificar en la URL el “id” correspondiente al comprobante.

Actualmente el portal continua con algunos problemas de seguridad, he descubierto un nuevo Cross-Site Scripting que podría ser utilizado por un atacante para robar información o suplantar identidad (phishing).

La vulnerabilidad existe gracias a que no se está filtrando las variables que se entregan por URL, permitiendo modificar/incrustar codigo para que sea ejecutado en el navegador del usuario.

Al ingresar a https://www.servipag.com/Portal-De-Pagos-En-Linea/Home/SvpCom?select=2, vemos que el comportamiento del sitio es “seleccionar la segunda pestaña”, cuando modificamos el valor de la variale select por 1 o por 3, seleccionará la pestaña 1 o 3, segun corresponda.

Lo gracioso es que en el código fuente, crea una función JavaScript cuyo nombre es el valor que entreguemos mediante esa variable, por ejemplo, probaremos “select=funcionPrueba” y vemos que en el codigo fuente aparece:

Por lo tanto, si entregamos el valor “2(); alert(/XSS/);//“, completará el código de la siguiente forma:

Provocando que el navegador ejecute la función “alert()”.

El atacante podría manipular el codigo javasciprt e incrustar código malicioso que, por ejemplo, redireccione al usuario a otro sitio, modificar los atributos de los formularios para que los datos sean enviados a un servidor externo, etc.

La vulnerabilidad ya se encuentra solucionada.

Link: Vulnerabilidades reportadas y corregidas en Servipag.com

3 comentarios

  1. Lo rescatable es la disposición de Servipag a reparar los problemas.

  2. y esto señores demuestra que no importa la pasta que te gastes en un waf f5 u otro, se debe realizar desarrollo seguro

  3. Si el QA en Servipag no considera scanning automatico o algun analisis de seguridad se le seguiran “pasando” yayitas continuamente.
    No se puede confiar ciegamente en que .NET tiene todo seguro o algun super framework js-based. Ese es el error muchas veces, confiar en la seguridad del framework.
    Coincido contigo jo3h, Servipag se hace cargo rapidamente de estos temas, y justamente la disminución de parametros GET es consecuencia del hallazgo grave del año pasado. Bien por Servipag en ese sentido.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Esto sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.