En el último mes he estado inmenso en un proyecto de un sitio de publicación en el que uno de los factores más importantes era el tema de la seguridad. Cuando hablo de aspectos de seguridad me refiero a evitar que en la Web cualquier entrada de datos entre nuestros desarrollos y el mundo exterior, evite que nos inyecten código malicioso, más allá de que nos pongan una imagen en la home de nuestra web. Cosa que ni al cliente le gusta ver que la inversión que acaba de realizar se la acaban de hackear, ni al desarrollador que lo implementa ver que todo el esfuerzo realizado no ha valido la pena.
SharePoint es un herramienta principalmente para el desarrollo de Intranets Corporativas, de hay que muchas veces cuando desarrollemos pasamos por alto diversas aspectos que son practicas muy sencillas, nada laboriosas y que tenemos que tener muy en cuenta.
Para evitar que nos hackeen nuestros desarrollos más que seguir alguna técnica de programación, es pensar una vez como si fueramos a ser hackers no a creernos en la bondad de todos los visitantes de la página.
¿Como se hace esto?
Pues en primer lugar protegiendo todos los parámetros de entrada de la aplicación. Por ejemplo tenemos un formulario para buscar elementos en una lista y queremos pasárselos a un WebPart que hemos implementado el resultado de esta en otra página.
Una técnica (no digo que la mejor) es pasarle los datos a esta página mediante querystring. Una vez estamos en el load de esta página ya tenemos la opción de leer estos paramétros y entonces hacer la búsqueda de la consulta. Hasta este punto todo esta claro no? Pero que ocurre si con estos paramétros de entrada nosotros construimos un HTML que se va a mostrar en la cabecera de la página. Pues tenemos dos opciones:
- Confiemos que a esta página siempre accederán haciendo uso de nuestro mecanismo y para ello obtenemos la QueryString de la siguiente forma:
- Que pensemos que quizas hay gente que tiene mucho tiempo libre y que quizas intentarán buscar resquicios en nuestros desarrollos para hacernos inyección de JavaScript y para ello siempre más vale prevenir que tener que sufrir y lo realizamos de la siguiente forma:
HttpUtility.HtmlAttributeEncode(Page.Request['variable'])
Page.Request['variable']
Veis las dos opciones igual de seguras? Si la respuesta es que sí, que sois demasiados confiados y pensais en la buena voluntad de todos los visitantes de la página. Que puede ocurrir pues que en el parámetro de la QueryString en lugar de poner un string os inyecten una sentencia JavaScript y puedan reemplazar cualquier elemeno de la página. Dejo la curiosidad del lector el verificar algunas webs que no cumplen con estos requisitos.
Otro de los aspectos donde quizás también pecamos de ingenuos en nuestros desarrollos, es a la hora de coger cualquier información del contexto en el que nos encontramos. Un ejemplo practico por ejemplo es un WebPart en el que queremos compartir la información de esta página en nuestras redes sociales preferidas, para ello esta claro que necesitamos la url en la que nos encontramos. Al igual que en el anterior caso tenemos dos opciones:
- Leer la url del Contexto
- Leer el item en el que estamos del SPContext.
¿Que opción elegiriaís?
Si escogemos la primera opción la url del contexto no tiene necesariamente el porque ser la url de la página en la que nos encontramos sino que a esta url le podemos añadir diverso código malicioso y si nuestro webpart genera el html en base a este valor pues ya tenemos el código malicioso dentro de nuestro desarrollo. Por el contrario si leemos el item del contexto en el que nos encontramos esto lo tenemos resuelto ya que en la base de datos tenemos la url tal y como nosotros la esperamos y de esta forma evitamos posibles inyecciones de código malicioso. Muchos estaréis pensando que seria necesario hacer una consulta CAML para saber esta información, con el siguiente código no hace falta esto y tampoco penalizamos el rendimiento de nuestra aplicación:
string urlshare =SPContext.Current.Site.Url+ SPContext.Current.ListItemServerRelativeUrl;
Otros aspectos que debemos de tener en cuanta para asegurarnos nuestra Web, es tener encuenta los WebParts que hay por defecto dentro de SharePoint y su configuración. El claro ejemplo es el WebPart de búsqueda, si nosotros lo añadimos a nuestra Web tal cual viene de serie, por defecto el buscador busca en todas las listas, elementos ocultos y diversos aspectos que un visitante anónimo no debe ni de saber que existe. En anteriores versiones esta tarea era cuestión de ir haciendo restricciones en las búsquedas, en la versión 2013 en lugar de ir eliminando en la Administración Central, el WebPart lo han mejorado para que desde el mismo podamos indicar todo lo que deseamos mostrar y lo que no. Pero como dice el tío de uno de mis superheroes preferidos todo poder llevar una gran responsabilidad. Y en este caso nuestro poder es configurar correctamente este buscador para evitar mostrar información que no deseemos para esta tarea recomiendo encarecidamente leeros este post
Y para la gente de sistemas que puede hacer?
Esta claro que SharePoint en los sitios abiertos tiene un montón de puertas abiertas y que se deben de cerrar una vez el sitio esta puesto en producción. SharePoint tiene multitud de url que la gente que trabaja (y los que no) saben como intentar acceder a la configuración de los mismos. Para ello es muy importante además de todas las reglas que se puedan poner en el IIS para evitar que la gente no deseable entre dentro de SharePoint. Todo sitio de producción debe de tener activada la característica de ViewPagesLockDown esto lo que hace es que todas las url internas de sharepoint no puedan acceder desde fuera. Si quereís saber un poco más sobre este tema es de obligatoria lectura este post del maestro Luis Ruiz (MVP ASP.NET)
Conclusión
Hemos visto con tan solo unas pequeñas pautas como dotar a nuestros desarrollos de unas nociones mínimas de seguridad. Esta claro que no somos especialistas en evitar todos los agujeros de seguridad. La intención de este post es sobre todo que cuando empecemos a desarrollar pensemos en que la seguridad es un elemento muy importante porque de que sirve hacer el desarrollo más bonito del mundo si quizás solo este online 5 minutos. Por lo que es conveniente no descuidar estos aspectos y prestarle un mínimo de atención para prevenir en nuestros desarrollos cualquier ataque.
¡Suscríbete a nuestras RRSS!
