En el \u00faltimo mes he estado inmenso en un proyecto de un sitio de publicaci\u00f3n en el que uno de los factores m\u00e1s 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\u00f3digo malicioso, m\u00e1s all\u00e1 de que nos pongan una imagen en la home de nuestra web. Cosa que ni al cliente le gusta ver que la inversi\u00f3n 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.
\nSharePoint 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.<\/p>\n
Para evitar que nos hackeen nuestros desarrollos m\u00e1s que seguir alguna t\u00e9cnica de programaci\u00f3n, es pensar una vez como si fueramos a ser hackers no a creernos en la bondad de todos los visitantes de la p\u00e1gina.<\/p>\n
\u00bfComo se hace esto?<\/strong> Una t\u00e9cnica (no digo que la mejor) es pasarle los datos a esta p\u00e1gina mediante querystring. Una vez estamos en el load de esta p\u00e1gina ya tenemos la opci\u00f3n de leer estos param\u00e9tros y entonces hacer la b\u00fasqueda de la consulta. Hasta este punto todo esta claro no? Pero que ocurre si con estos param\u00e9tros de entrada nosotros construimos un HTML que se va a mostrar en la cabecera de la p\u00e1gina. Pues tenemos dos opciones:<\/p>\n Veis las dos opciones igual de seguras? Si la respuesta es que s\u00ed, que sois demasiados confiados y pensais en la buena voluntad de todos los visitantes de la p\u00e1gina. \u00a0Que puede ocurrir pues que en el par\u00e1metro de la QueryString en lugar de poner un string os inyecten una sentencia JavaScript y puedan reemplazar cualquier elemeno de la p\u00e1gina. Dejo la curiosidad del lector el verificar algunas webs que no cumplen con estos requisitos.<\/p>\n Otro de los aspectos donde quiz\u00e1s tambi\u00e9n pecamos de ingenuos en nuestros desarrollos, es a la hora de coger cualquier informaci\u00f3n del contexto en el que nos encontramos. Un ejemplo practico por ejemplo es un WebPart en el que queremos compartir la informaci\u00f3n de esta p\u00e1gina 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:<\/p>\n \u00bfQue opci\u00f3n elegiria\u00eds?<\/strong><\/p>\n Si escogemos la primera opci\u00f3n la url del contexto no tiene necesariamente el porque ser la url de la p\u00e1gina en la que nos encontramos sino que a esta url le podemos a\u00f1adir diverso c\u00f3digo malicioso y si nuestro webpart genera el html en base a este valor pues ya tenemos el c\u00f3digo 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\u00f3digo malicioso. Muchos estar\u00e9is pensando que seria necesario hacer una consulta CAML para saber esta informaci\u00f3n, con el siguiente c\u00f3digo no hace falta esto y tampoco penalizamos el rendimiento de nuestra aplicaci\u00f3n:<\/p>\n 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\u00f3n. El claro ejemplo es el WebPart de b\u00fasqueda, si nosotros lo a\u00f1adimos 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\u00f3nimo no debe ni de saber que existe. En anteriores versiones esta tarea era cuesti\u00f3n de ir haciendo restricciones en las b\u00fasquedas, en la versi\u00f3n 2013 en lugar de ir eliminando en la Administraci\u00f3n 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\u00edo 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\u00f3n que no deseemos para esta tarea recomiendo encarecidamente leeros este post\u00a0<\/a><\/p>\n Y para la gente de sistemas que puede hacer?<\/strong><\/p>\n Esta claro que SharePoint en los sitios abiertos tiene un mont\u00f3n de puertas abiertas y que se deben de cerrar una vez el sitio esta puesto en producci\u00f3n. SharePoint tiene multitud de url que la gente que trabaja (y los que no) saben como intentar acceder a la configuraci\u00f3n de los mismos. Para ello es muy importante adem\u00e1s 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\u00f3n debe de tener activada la caracter\u00edstica de\u00a0ViewPagesLockDown\u00a0<\/strong>esto lo que hace es que todas las url internas de sharepoint no puedan acceder desde fuera. Si quere\u00eds saber un poco m\u00e1s sobre este tema es de obligatoria lectura este post<\/a> del maestro Luis Ruiz (MVP ASP.NET)<\/a><\/p>\n Hemos visto con tan solo unas peque\u00f1as pautas como dotar a nuestros desarrollos de unas nociones m\u00ednimas de seguridad. Esta claro que no somos especialistas en evitar todos los agujeros de seguridad. La intenci\u00f3n 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\u00e1s bonito del mundo si quiz\u00e1s solo este online 5 minutos. Por lo que es conveniente no descuidar estos aspectos y prestarle un m\u00ednimo de atenci\u00f3n para prevenir en nuestros desarrollos cualquier ataque.<\/p>\n<\/span>","protected":false},"excerpt":{"rendered":" En el \u00faltimo mes he estado inmenso en un proyecto de un sitio de publicaci\u00f3n en el que uno de los factores m\u00e1s importantes era el tema de la seguridad. Cuando hablo de aspectos de seguridad me refiero a evitar … Continue reading
\n Pues en primer lugar protegiendo todos los par\u00e1metros de entrada de la aplicaci\u00f3n. Por ejemplo tenemos un formulario para buscar elementos en una lista y queremos pas\u00e1rselos a un WebPart que hemos implementado el resultado de esta en otra p\u00e1gina.<\/p>\n\n
\r\nPage.Request['variable']\r\n<\/pre>\n
\r\nHttpUtility.HtmlAttributeEncode(Page.Request['variable'])\r\n<\/pre>\n<\/li>\n<\/ol>\n
\n
\r\nstring urlshare =SPContext.Current.Site.Url+ SPContext.Current.ListItemServerRelativeUrl;\r\n<\/pre>\n
Conclusi\u00f3n<\/h2>\n