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

Question

Mi empresa exige que todos los sitios de producción pasen un análisis 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, utiliza procedimientos almacenados exclusivamente detrás de las escenas. ¿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

No son todos los procesos almacenados. En particular, cosas como las listas cruzadas se unen en horrendo sintaxis. Para ver un ejemplo, consulte la ventana de SQL Trace desde this article. Además, como los desarrolladores pueden escribir tanto los controles de usuario como las llamadas de API, no hay garantía de que no esté sujeto a la inyección de SQL si está utilizando módulos personalizados.

Supongo que SharePoint siempre usa, como mínimo, parámetros con nombre. 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 2

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 interno profundo, y posiblemente no se están ejecutando 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 3

Hay una serie de vectores de inyección SQL ciega 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).

Estos vectores, sin embargo, son propensos a falsos positivos, porque el desencadenador 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 antiguas vulnerabilidades de FrontPage en muchos escáneres vuln, que también son falsos positivos. Para más detalles, consulte este artículo "SharePoint and FrontPage Server Extensions in security scanner results".