ASP.NET-Nivel de confianza=¿completo?
security sharepoint (5)
Recientemente me uní a una empresa y al analizar su entorno noté que SharePoint web.config tenía el nivel de confianza establecido en Completo. Sé que esta es una práctica absolutamente terrible y esperaba que la comunidad de stackoverflow pudiera ayudarme a delinear los defectos en esta decisión.
Oh, parece que esta decisión se tomó para permitir a los desarrolladores implementar dlls en la carpeta Bin sin crear políticas CAS. Suspiro.
Solo quiero aclarar y empeorar las cosas, también estamos implementando código de terceros para esta aplicación web.
¿Defectos? Muchos. Pero lo más condenable es la utilidad CAS:
"... permite el acceso completo a los recursos de su computadora, como el sistema de archivos o el acceso a la red, lo que potencialmente funciona fuera del control del sistema de seguridad".
Esto significa que el código otorgado Full Trust puede ejecutar cualquier otro código (administrado o no) en el sistema, puede realizar llamadas a través de la red a cualquier máquina, puede hacer cualquier cosa en el sistema de archivos (incluso cambiar permisos en archivos restringidos, incluso archivos OS) )
La mayoría de los programadores web dirían "eso no es un problema, es solo mi código", lo cual está bien ... hasta que aparezca un error de seguridad en su código que permita a un atacante usarlo para hacer cosas desagradables. Entonces, Full Trust previamente otorgado se vuelve bastante desafortunado.
Honestamente, he encontrado que compartir es demasiado restrictivo.
Eche un vistazo a la siguiente página para ver lo que puede y no puede hacerse en función de los niveles de confianza http://msdn.microsoft.com/en-us/library/ms916855.aspx
Un problema con el que me encontré inmediatamente fue que no pude usar el bloque de aplicación de almacenamiento en caché. Estábamos usando este bloque de aplicaciones en lugar del almacenamiento en caché de ASP.NET porque habíamos usado un patrón de MVP y podríamos abrir una aplicación de formularios para ganar.
Otro problema es el no reflejo, esto provocó que la página Acerca de fallara porque el número de versión se extrae de los metadatos del ensamblaje.
Creo que la mejor solución es no usar Sharepoint como un host de aplicaciones. Solo usaría SharePoint como servidor de aplicaciones si la cantidad de codificación era tan pequeña que no afectara el nivel de confianza y sería menos trabajo luego de configurar una nueva aplicación. Si está haciendo algún tipo de codificación que está empezando a golpear las paredes del nivel de confianza, mueva su aplicación a un entorno ASP.NET adecuado. Pero ese soy solo yo, y soy parcial. Tal vez deberías intentar apuntar a un compromiso de nivel medio de confianza.
Si están ignorando las políticas de CAS, podría ser una venta difícil conseguir que lo vuelvan a llamar, ya que hace su trabajo un poco más difícil (o, al menos, un poco menos indulgente). Cambiar las prácticas de seguridad siempre es difícil, como cuando tuve que convencer a mi jefe de que usar las cuentas SA en la cadena de conexión SQL de nuestras aplicaciones web era una mala idea, pero aguanta.
Full Trust permite que la aplicación escale al control de cualquier recurso en la computadora. Si bien debe tener una falla de seguridad en su aplicación para permitir esto, y probablemente afirmarán que han evitado cualquier escalada a través de una programación astuta, recuérdeles que, en caso de que algo suceda, ¿no preferirían el la aplicación web no tiene el control de toda la computadora? Quiero decir, solo por si acaso?
EDITAR: Estaba un poco entusiasta con mi idioma aquí. La confianza total permitiría a la aplicación controlar lo que quiera, pero solo si el proceso del grupo de aplicaciones tiene suficientes derechos para hacerlo. Por lo tanto, si se está ejecutando como un usuario limitado sin derechos en el servidor, a excepción de lo que la aplicación necesita, entonces supongo que esencialmente no hay riesgo de "plena confianza". La realidad es que el propietario del grupo de aplicaciones probablemente tenga una serie de derechos que no le gustaría tener en su aplicación (y en algunos casos, muchos, muchos más), por lo que es mucho más seguro limitar la seguridad de la aplicación y otorgar derechos adicionales a la aplicación. Gracias por la corrección, Barry.
Todd,
El libro, " Programación de Microsoft ASP.Net 3.5 ", de Dino Espisito brinda algunos razonamientos razonables para no permitir la plena confianza en las aplicaciones ASP.Net.
Entre otras razones, Dino afirma que las aplicaciones web expuestas a Internet son "uno de los entornos más hostiles para la seguridad informática que puedas imaginar". Y:
una aplicación completamente confiable y públicamente expuesta es una plataforma potencial para que los hackers lancen ataques. Cuanto menos se confíe en una aplicación, más segura será esa aplicación.
Me sorprende que la comunidad de no describió mejor el problema con Full Trust. Esperaba lo mismo, así que no tuve que buscar en mi pila de libros para encontrar la respuesta, vago.
Utilizo plena confianza en mis máquinas de desarrollo ... para poder implementar en el BIN al construir un nuevo código. Confío en mi propio código y lo ejecuto en el GAC en producción porque crear políticas de CAS es un problema.
La cosa de los terceros me preocuparía ... sin embargo:
La mayoría de las soluciones de terceros que se encuentran en la web también se implementan en el GAC (asumiendo por las mismas razones). Esto les otorga todos los derechos independientemente del nivel de confianza. Siente que tiene más que ver con si confías en los terceros o no ... ¿y realmente confías en tus propios desarrolladores?
¿Qué haría un hacker? El escenario en el que un hacker arroja un dll malvado en su carpeta BIN no lo veo como muy realista ... independientemente de si puede hacerlo, probablemente también pueda cambiar el nivel de confianza.