Safe Mode Processing en SharePoint!

En este post vamos a hablar sobre un concepto importante en plataforma SharePoint: Safe Mode Processing. En lo que se refiere a páginas personalizadas en SharePoint, es importante entender que todas las páginas son procesadas en un modo especial conocido como modos seguro (safe mode). El principal motivo de este modo de procesamiento viene dado porque los usuarios estándar puedan modificar el contenido de las páginas de un sitio de SharePoint. De este modo un usuario (por ejemplo, un propietario) que no disponga de privilegios de administrador en la granja puede hacer modificaciones de páginas de un sitio. Sin embargo, en un escenario tipo large farm de SharePoint en el que un administrador de sitio intenta hacer un ataque contra el servidor web (IIS) mediante código C# utilizando para ello una página personalizada en la que ha añadido un bloque de código inline no tendrá éxito gracias a que este modo de procesamiento deshabilita cualquier código inline en páginas personalizadas.

Para demostrar lo anterior, vamos a crear una página personalizada en un sitio de SharePoint con el Safe Mode habilitado. Para crear está página, utilizaremos SharePoint Designer 2007:

  • Abrimos el menú Archivo y pulsamos Nuevo -> Aspx.

image

  • Por defecto, el markup que nos añade SharePoint Designer 2007 es el siguiente:

<%@ Page Language="C#" %>

<html dir="ltr">

 

<head runat="server">

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

<title>Sin título 1</title>

<meta name="Microsoft Theme" content="Lichen 1011, default">

</head>

 

<body>

 

<form id="form1" runat="server">

</form>

 

</body>

 

</html>

  • Modificamos el markup de la siguiente forma:

<%@ Page Language="C#" %>

<html dir="ltr">

<head runat="server">

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

<title></title>

<meta name="Microsoft Theme" content="Lichen 1011, default">

</head>

<body>

<form id="form1" runat="server">

                        <%Response.Write("Hola desde el lado del servidor");%>

</form>

</body>

</html>

  • Guardamos la página y la previsualizamos en el navegador. Como cabía esperar, la página no se muestra, y se visualiza el error ya conocido:
image image

Lo que está sucediendo es que SharePoint intenta procesar la página usando el safe mode. Como la página contiene código inline, rechaza su procesamiento y produce el error comentado.

  • Para solucionarlo, seguimos la mala práctica de permitir la ejecución de código inline modificando el archivo web.config (sección SafeMode):

    <SafeMode MaxControls="200" CallStack="false" DirectFileDependencies="10" TotalFileDependencies="50" AllowPageLevelTrace="false">

      <PageParserPaths>

                        <PageParserPath VirtualPath="/ERSDi/_catalogs/masterpage/default.Master" CompilationMode="Always" AllowServerSideScript="true" />

                        <PageParserPath VirtualPath="/Pagina_Codigo_Inline.aspx" CompilationMode="Always" AllowServerSideScript="true" />

      </PageParserPaths>

    </SafeMode>

  • Hacemos un iisreset y refrescamos la página. Ahora veremos que sí está plenamente operativo el código inline introducido.

image

Tal y como se comenta en [Inside Microsoft Windows SharePoint Services 3.0. Ted Pattison & Daniel Larson. Microsoft Press, Edición 2007], hay que tratar de evitar la introducción de código inline en las páginas que se ejecuten bajo el contexto de SharePoint. Esto es aún más importante cuando hablamos de una master page, puesto que constituye el esqueleto base de muchas de las páginas de un sitio de SharePoint determinado.

Finalmente, es importante destacar que aunque no es una buena práctica utilizar código inline en una página ejecutándose en el contexto de SharePoint, a veces es la única opción posible para situaciones en las que no exista otra alternativa posible. También es destacable que se puede permitir el código inline en todas las páginas de un aplicación web de SharePoint sin más que configurar el parámetro VirtualPath con el valor /*. Sin embargo, está práctica tiene que evitarse por dos factores principales (y que ya se han comentado):

  • Por seguridad, dado que estamos habilitando una puerta trasera a una aplicación web completa de SharePoint, es decir, a todas sus páginas. Esto nos expone a que cualquier usuario con conocimientos de personalización de páginas pueda fácilmente escribir código manejado que se ejecute en el servidor web.
  • Por escalabilidad, las páginas no-compiladas son mucho más escalables que aquellas que requieren compilación. Los problemas ocasionados se vuelven críticos en el caso de aplicaciones web que tengan que compilar y cargar miles de ensamblados para las páginas personalizadas que se hayan definido.

Y hasta aquí llega lo que os quería contar sobre Safe Mode Processing en SharePoint. Espero que el post te haya resultado interesante.