sqlmap - ¿Evidencia de que SharePoint no tiene vulnerabilidades de inyección SQL?

sql injection ejemplos reales

Question

Mi compañía tiene el requisito de que todos los sitios de producción pasen un escaneo de seguridad de AppScan. A veces, cuando escaneamos una instalación de SharePoint, el software detecta una vulnerabilidad de inyección SQL oculta. Estoy bastante seguro de que esto es un falso positivo: AppScan probablemente esté interpretando alguna otra actividad en la respuesta HTTP como éxito de la inyección ciega. Pero es difícil probar que este es el caso.

Sospecho que SharePoint, tanto MOSS 07 como WSS 3.0, usa procedimientos almacenados exclusivamente detrás de escena. ¿Alguien sabe si existe alguna documentación de Microsoft para este efecto y, además, si alguno de los procedimientos almacenados usa SQL generado dinámicamente? Si todo fuera una mejora, y ninguno de ellos dinámico, tendríamos bastante buena evidencia de que SharePoint no tiene vulnerabilidad de inyección SQL.

Answer 1

Gracias. Miré el generador de perfiles y encontré algunas cosas: parece que SharePoint solo está ejecutando procedimientos almacenados. Hay bits ocasionales de SQL puro, pero estos parecen estar limitados a "exec sp_oledb_ro_usrname" y "select collationname (...)", que parecen ser algo profundamente interno, y posiblemente no se ejecutan como SQL en todos, pero solo están saliendo en el perfilador de esa manera ...?

SharePoint ocasionalmente utiliza sp_executesql, pero esta es una llamada parametrizada y, por lo tanto, probablemente esté a salvo de la inyección.

Answer 2

No son todos los procesos almacenados. En particular, cosas como las listas cruzadas se unen en horrendo sintaxis. Por ejemplo, mire la ventana Traza de SQL de este artículo . Además, dado que tanto los controles de usuario como las llamadas API pueden ser escritos por los desarrolladores, no hay garantía de que no esté sujeto a la Inyección SQL si está utilizando módulos personalizados.

Creo que SharePoint siempre usa, como mínimo, parámetros nombrados. Sin embargo, su mejor opción podría ser ejecutar un rastreo SQL y comparar los resultados. Además, si usted es un cliente lo suficientemente grande, puede intentar llamar a su evangelista local de MSFT (o publicar una pregunta en connect.microsoft.com ) y ver si puede obtener una respuesta.

Answer 3

Hay una cantidad de vectores de inyección SQL ciegos relativamente nuevos que se basan en el retraso de respuesta, por ejemplo, usando WAITFOR DELAY . Al menos sqlmap y BurpSuite los usan (y probablemente otros también).

Sin embargo, estos vectores son propensos a falsos positivos, porque el desencadenante es, bueno, el retraso de la respuesta HTTP, que también puede ocurrir por otros miles de motivos si está escaneando a través de Internet. Si obtuvieras estos a través de LAN, sería más sospechoso, pero aún investigar otras posibles causas de retraso en el lado del servidor. Solo si obtienes la demora de manera consistente en una cantidad de pruebas independientes, probablemente estés lidiando con una vulnerabilidad.

También tenga en cuenta que SharePoint a menudo desencadena vulnerabilidades antiguas de FrontPage en muchos escáneres vuln, que también son falsos positivos. Para obtener más detalles, consulte este artículo "Extensiones de servidor de SharePoint y FrontPage en los resultados del escáner de seguridad" .