{"id":8082,"date":"2015-07-01T22:58:31","date_gmt":"2015-07-01T20:58:31","guid":{"rendered":"http:\/\/www.palentino.es\/blog\/?p=8082"},"modified":"2015-07-01T23:27:26","modified_gmt":"2015-07-01T21:27:26","slug":"aspectos-interesantes-sobre-la-seguridad-web","status":"publish","type":"post","link":"https:\/\/www.palentino.es\/blog\/aspectos-interesantes-sobre-la-seguridad-web\/","title":{"rendered":"Aspectos interesantes sobre la Seguridad Web. #monografia"},"content":{"rendered":"<div id=\"palen-1803058826\" class=\"palen-antes-del-contenido palen-entity-placement\"><div class=\"palen-adlabel\">Anuncios<\/div><script async src=\"\/\/pagead2.googlesyndication.com\/pagead\/js\/adsbygoogle.js?client=ca-pub-2815317153396146\" crossorigin=\"anonymous\"><\/script><ins class=\"adsbygoogle\" style=\"display:inline-block;width:300px;height:250px;\" \ndata-ad-client=\"ca-pub-2815317153396146\" \ndata-ad-slot=\"4593837716\"><\/ins> \n<script> \n(adsbygoogle = window.adsbygoogle || []).push({}); \n<\/script>\n<\/div><p><strong>Monograf\u00eda sobre los principios de seguridad web.<\/strong><\/p>\n<p style=\"text-align: justify;\">La <strong>seguridad web pasiva<\/strong> son aquellas medidas para crear nuestra aplicaci\u00f3n <strong>sin necesidad<\/strong> de<strong> intervenci\u00f3n humana.<\/strong> Debe ser segura por defecto. Cualquier estado de error no debe proporcionar inseguridad. Deberemos tener cuanto menos puntos de entrada mejor, minimizando oportunidades de acceso o ataque.<\/p>\n<p style=\"text-align: justify;\">La <strong>seguridad activa web<\/strong> son acciones <strong>manuales<\/strong> para aumentar la seguridad del sistema. Por ejemplo, una revisi\u00f3n buscando brechas de seguridad. Se podr\u00e1n comprobar las vulnerabilidades y crear auditorias. La realizaci\u00f3n de copias de seguridad es vital para poder recuperar datos.<\/p>\n<p style=\"text-align: justify;\">Intentaremos mantener siempre el principio de <strong>simpleza<\/strong> en el desarrollo web. Existen multitud de elementos a comprobar porque existen multitud de elementos de ataque.<\/p>\n<p style=\"text-align: justify;\">El principio de <strong>Pareto<\/strong> o la regla del<strong> 80-20<\/strong> aplicada a seguridad web, indica que no todos los ataques tienen el mismo tipo de distribuci\u00f3n.<br \/>\n<strong>Con el 20% de la prevenci\u00f3n se puede detener el 80% de los posibles ataques.<\/strong><\/p>\n<p><!--more--><\/p>\n<p>La seguridad web <strong>evoluciona<\/strong> en el tiempo. <strong>Todos los d\u00edas surgen ataques y nuevas maneras de acceder de forma no autorizada<\/strong>. Tendremos que estar <strong>actualizados<\/strong> e informados constantemente. Deberemos restringir el n\u00famero de accesos abiertos en el servidor para disminuir las probabilidades de que nuestra web o desarrollo sea atacado.<\/p>\n<p>Atendiendo a los lugares de acceso, existen <strong>3 puntos posibles<\/strong> de ataque.<\/p>\n<ul>\n<li>Desde el propio lugar de acceso.<strong> El cliente<\/strong>. Cada copia que se env\u00eda a un navegador web, es una posibilidad de entrada. Es la aplicaci\u00f3n HTML que ha sido descargada del servidor al navegador. Esta aplicaci\u00f3n representa muchas oportunidades de entrada. Por ejemplo los formularios y las <strong>URLs<\/strong> son sistemas muy empleados de ataque. Las <strong>cookies<\/strong> puede ser le\u00eddas. La propia l\u00f3gica de aplicaci\u00f3n puede ser atacada. Javascript es un lenguaje visto, puede ser ofuscado, pero es un lenguaje analizado.<\/li>\n<li>El servidor posee m\u00e1s control. Puede disponer de m\u00faltiples servicios y puertos abiertos. El servidor FTP, Telnet, Terminal Server, SSH, VNC, el servidor de base de datos, etc. Necesitaremos <strong>restringir el n\u00famero mayor posibles de accesos a estos servicios<\/strong>.<\/li>\n<li>La red existente entre el cliente y el servidor. Esta red posee m\u00faltiples nodos intermediarios. Pueden existir <strong>sniffers<\/strong> o software de escucha. Es por ello que es preciso encriptar la informaci\u00f3n.<\/li>\n<\/ul>\n<p><strong>La seguridad web total no existe.<\/strong> Pero aunque sea un requisito muy l\u00edcito establecido por un cliente en una memoria de proyecto, la seguridad total s\u00f3lo existe en <strong>teor\u00eda<\/strong>. Es un ideal. Imposible de cumplir en su totalidad. No obstante es un objetivo que \u201cintentaremos cumplir\u201d.<\/p>\n<p><strong>Similar al SEO, nadie puede garantizar al 100% el SERP de una p\u00e1gina.<\/strong><\/p>\n<p>Existen una serie de consejos o pr\u00e1cticas para asegurar la aplicaci\u00f3n.<\/p>\n<p>Una de las m\u00e1s importantes es cerrar las puertas no necesarias. Intentar cerrar servicios o partes donde se puede acceder al interior. Cerrando puertos, cerrando servicios web, actualizando el sistema, m\u00f3dulos, plugins, el sistema operativo, la versi\u00f3n del servidor web, servidor SQL, etc. Es preciso intentar disponer de la mayor parte de servicios actualizados.<\/p>\n<p>Esto suele ser un gran problema para algunos desarrolladores, porque precisar\u00e1n la reprogramaci\u00f3n de ciertas partes del programa. No todas las actualizaciones permiten que nuestro software siga funcionando correctamente.<\/p>\n<p>La seguridad en el cliente, depender\u00e1 tambi\u00e9n de que sus contrase\u00f1as o accesos sean complejos, se cambien de forma peri\u00f3dica, etc.<\/p>\n<p>Si como programadores <strong>ofuscamos<\/strong> el c\u00f3digo del lado del servidor, y el m\u00e1s inseguro del lado cliente, estaremos yendo en contra de los programadores al no permitir la <strong>reutilizaci\u00f3n<\/strong>, entendimiento y <strong>refactorizaci\u00f3n<\/strong>. Por lo tanto muchas veces tendremos que <strong>elegir entre ambos criterios dependiendo de la seguridad de la aplicaci\u00f3n<\/strong>. Este criterio depender\u00e1 de la aplicaci\u00f3n y de la situaci\u00f3n.<\/p>\n<p><strong>INPUTS y OUTPUTS de informaci\u00f3n web.<\/strong><\/p>\n<p>Las entradas son partes de un sistema en las que un usuario puede introducir informaci\u00f3n. <strong>Ser\u00e1n usaras mayormente para realizar ataques<\/strong>.<\/p>\n<p>Por ejemplo, los formularios web, encuestas, registros, etc, son elementos de ataque de entrada.<\/p>\n<p>Mediante los <strong>OUTPUTS<\/strong> el programa se comunica con los usuarios. Esto nos permitir\u00e1 mostrar informaci\u00f3n, por ejemplo mediante inyecciones URL \u00f3 SQL.<\/p>\n<p>Las entradas permiten adaptar el comportamiento de la aplicaci\u00f3n web. Pero como he comentado, las entradas tienen sus peligros. El contenido de una entrada pasa desde el lado humano hacia el interior del programa. El contenido de un formulario puede ser tratado por el programa o por la base. Posibilitaran realizar inyecciones que alteren la base de datos o el programa.<\/p>\n<p>Por lo que es necesario realizar <strong>validaciones<\/strong> en las entradas de los formularios, el HTML debe ser tratado y preprocesado. Podremos <strong>escapar<\/strong> cadenas para evitar insertar instrucciones de c\u00f3digo.<\/p>\n<p>Las salidas son partes donde el programa devuelve informaci\u00f3n en pantalla o consola del navegador. La informaci\u00f3n puede contener mensajes del sistema o mensajes de depuraci\u00f3n. Un atacante puede<strong> aprovechar estos mensajes para sacar conclusiones y usarlos en nuestra contra<\/strong>.<\/p>\n<p><strong>Blacklist y Whitelist<\/strong><\/p>\n<p>Un Blacklist es una lista negra de elementos. Elementos prohibidos del sistema. Podremos acceder a esta lista para comprobar que no existe c\u00f3digo fuente no permitido. Las cadenas de entrada se pasar\u00e1n a trav\u00e9s de esta matriz para comprobar su validez.<\/p>\n<p>De forma contraria existe la lista de elementos permitidos. Estas listas por ejemplo nos posibilitan tener todas las palabras reservadas por ejemplo DDL o DML de SQL. En otros casos tambi\u00e9n pueden existir diccionarios.<\/p>\n<p>En estas listas tambi\u00e9n pueden existir usuarios para acceder o denegar sus accesos. En definitiva son t\u00e9cnicas para aumentar o blindar la seguridad web.<\/p>\n<p><strong>Registro de eventos en nuestra aplicaci\u00f3n.<\/strong><\/p>\n<p>Es un sistema de seguridad indirecto. Permite que la aplicaci\u00f3n almacene datos de sus estado (puede ser una base de datos). Puede ser recuperada en caso de fallo, para averiguar las causas del mismo. Este tipo de eventos los tendremos que almacenar nosotros en la l\u00f3gica de nuestra aplicaci\u00f3n. Podemos almacenar la IP del usuario, la hora, fecha, navegador con el que ha conectado, el tiempo de ejecuci\u00f3n, p\u00e1gina accedida, etc.<\/p>\n<p>Registro de eventos en el servidor.\u00a0Dependiendo del servidor que empleemos depender\u00e1 el almac\u00e9n. Si empleamos IIS o Apache, SQL Server o Mysql, PHP o ASP.NET, el tipo de conexi\u00f3n FTP o SFTP. El servidor se podr\u00e1 encargar de almacenar estados, IPs, usuarios, puertos remotos, etc.<\/p>\n<h3><span style=\"color: #800000;\"><strong>Tipos de ataques m\u00e1s comunes en la web.<\/strong><\/span><\/h3>\n<p>Existen multitud de ellos, cada uno de ellos aprovecha una debilidad. Cada vez surgen nuevas v\u00edas. Vamos a ver las m\u00e1s comunes, s\u00f3lo los m\u00e1s comunes.<\/p>\n<p><strong>Ataque XSS<\/strong><\/p>\n<p>Cross Site Scripting. Para evitar confundirlo con la tecnolog\u00eda CSS.<\/p>\n<p>Su funcionamiento <strong>inyecta<\/strong> c\u00f3digo no deseado en el lenguaje <strong>Javascript<\/strong>. Puede encontranrse tambi\u00e9n en el lado del servidor. Ejecuta partes no autorizadas o el nuevo c\u00f3digo inyectado.<\/p>\n<p><a href=\"https:\/\/es.wikipedia.org\/wiki\/Cross-site_scripting\" target=\"_blank\">https:\/\/es.wikipedia.org\/wiki\/Cross-site_scripting<\/a><\/p>\n<p><strong>Inyecci\u00f3n SQL<\/strong><\/p>\n<p><a href=\"https:\/\/es.wikipedia.org\/wiki\/Inyecci%C3%B3n_SQL\" target=\"_blank\">https:\/\/es.wikipedia.org\/wiki\/Inyecci%C3%B3n_SQL<\/a><\/p>\n<p>Insertaremos una sentencia SQL en una entrada. Ser\u00e1 necesario escapar el comando con el que estamos trabajando.<\/p>\n<p>La Inyecci\u00f3n SQL es un tipo de vulnerabilidad, \u00a0m\u00e9todo de infiltraci\u00f3n, que incrusta c\u00f3digo SQL intruso.<\/p>\n<p>Se dice que existe o se produjo una\u00a0inyecci\u00f3n SQL\u00a0cuando, de alguna manera, se inserta o &#8220;inyecta&#8221; c\u00f3digo SQL invasor dentro del c\u00f3digo SQL programado, a fin de alterar el funcionamiento normal del programa y lograr as\u00ed que se ejecute la porci\u00f3n de c\u00f3digo &#8220;invasor&#8221; incrustado, en la\u00a0base de datos.<\/p>\n<p><strong>Ataque por fuerza bruta<\/strong><\/p>\n<p>Este tipo de ataques consiste en probar m\u00faltiples combinaciones en una entrada, con el prop\u00f3sito de averiguar la contrase\u00f1a de acceso.<\/p>\n<p><a href=\"https:\/\/es.wikipedia.org\/wiki\/Ataque_de_fuerza_bruta\" target=\"_blank\">https:\/\/es.wikipedia.org\/wiki\/Ataque_de_fuerza_bruta<\/a><\/p>\n<p><strong>Ataque con cookies.<\/strong><\/p>\n<p>Son peque\u00f1os paquetes de informaci\u00f3n persistente que residen en el navegador. Existen cookies por sesi\u00f3n y otras permanentes de aplicaci\u00f3n con una fecha de caducidad m\u00e1s larga que se quedan en el navegador aunque se finalice la navegaci\u00f3n.<\/p>\n<p>Una cookie puede almacenar gustos, datos de usuario, para personalizar la experiencia de usuario. Recordemos la publicidad que nos suele aparecer cuando navegamos.<\/p>\n<p>El peligro de las cookies es que son f\u00e1cilmente manipulables. Se puede leer, escribir, etc.<\/p>\n<p>Ocurren en el lado del cliente, donde no tenemos ning\u00fan control. Debemos evitar usar las cookies para almacenar informaci\u00f3n sensible.<\/p>\n<p><a href=\"https:\/\/es.wikipedia.org\/wiki\/Cookie_(inform%C3%A1tica)\" target=\"_blank\">https:\/\/es.wikipedia.org\/wiki\/Cookie_(inform%C3%A1tica)<\/a><\/p>\n<p><strong>Manipulaci\u00f3n de la URL.<\/strong><\/p>\n<p>Muchas aplicaciones pasan par\u00e1metros mediante la URL por el protocolo HTTP mediante GET. Los par\u00e1metros GET son f\u00e1cilmente editables. Al modificarlos podemos cambiar el comportamiento de la aplicaci\u00f3n.<\/p>\n<p><strong>Fallas en CMS como wordpress, drupal, joombla y en sus plugins.<\/strong><\/p>\n<p>Muchos desarrollos web se basan en estas aplicaciones. Poseen fallos de seguridad que afectan a millones\u00a0de webs. No solamente estos CMS sino sus extensiones o <strong>plugins<\/strong> que aportan funcionalidad extra.<\/p>\n<p>Como medida adicional es altamente aconsejable el cifrado de datos y la encriptaci\u00f3n. Puesto que los datos viajan del cliente hacia el servidor.<\/p>\n<p>Al margen de las vulnerabilidades web, existen varias formas de codificaci\u00f3n. Existen varios mecanismos para ello y evitar que sean interpretados los datos al ser capturados.<\/p>\n<p>Mediante el cifrado ocultamos el contenido del mensaje. Mediante un algoritmo de cifrado se cifran los datos usando una clave. Pero al estar cifrados un atacante no \u201cpodr\u00eda interpretarlos\u201d. En destino se aplica el algoritmo inverso y se obtiene el mensaje original. La clave de cifrado debe ser guardada en secreto. Esta clave debe tener un nivel de fuerza alta, para evitar que sea dif\u00edcil de descifrar. El acto de cifrado consume recursos de sistema. El cifrado va en contra de la eficiencia en los recursos hardware. La seguridad en determinadas ocasiones va en contra de la eficiencia. Es necesario buscar el equilibrio.<\/p>\n<p><strong>Por ejemplo en php:<\/strong><\/p>\n<p><span style=\"color: #808080;\">$mensaje=Base64_encode(\u201cEl mensaje\u201d) \/\/ Codificamos<\/span><\/p>\n<p><span style=\"color: #808080;\">Base64_decode($mensaje) \/\/ Decodificamos<\/span><\/p>\n<p>La encriptaci\u00f3n o hashing mediante un algoritmo de hash o encriptaci\u00f3n, toma los datos originales y los cifra, obteniendo una cadena indescifrable. En destino se recibe el mensaje encriptado, se obtiene un valor a comparar, se encripta dicho valor y se comparan las cadenas.<\/p>\n<p>El uso t\u00edpico de este cifrado sin retorno es codificar informaci\u00f3n como contrase\u00f1as, se compara el hash de la contrase\u00f1a.<strong> Es el motivo por el cual ninguna web actual te da la contrase\u00f1a si la has olvidado<\/strong>. En muchos lenguajes podemos realizarlo con la funci\u00f3n <strong>MD5<\/strong>. Es un algoritmo que devuelve el mismo resultado.<\/p>\n<p>Por ejemplo, la base de datos almacenar\u00eda la contrase\u00f1a cifrada en MD5 y se compara.<\/p>\n<p><span style=\"color: #808080;\">If (md5($contrasena) == \u201cCadena de hash\u201d)<\/span><\/p>\n<p><span style=\"color: #808080;\">\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Echo \u201cexiste coincidencia\u201d<\/span><\/p>\n<p>Gracias a esto, si un atacante accede a las password, no le servir\u00eda de nada porque se encuentran codificadas.<\/p>\n<p>La seguridad web se ve afectada por la seguridad de los servidores. Independientemente de que sean Windows, Linux o Mac, deben ser actualizados peri\u00f3dicamente. Pero ojo, el comportamiento web de un sistema puede variar al ser actualizado. Por lo tanto, las actualizaciones del sistema se gana en seguridad, pero ciertas partes pueden dejar de funcionar.<\/p>\n<p>Esto es aplicable a actualizaciones de los CMS. Si actualizamos el wordpress, puede que un determinado tema o plugin deje de funcionar. Es por ello, que actualmente, existen 2 versiones en los temas, una padre y otra hija. Las modificaciones se realizan en la hija, para que cuando se actualice la parent no se pierdan las modificaciones de la child.<\/p>\n<p>El software que corre el los servidores tambi\u00e9n debe ser actualizados. Las aplicaciones instaladas pueden ser la pila<\/p>\n<p><strong> LAMP<\/strong><\/p>\n<p>Linux, Apache, MySQL y PHP. Estos 3 elementos deben ser actualizados y modificados. Suele ser el m\u00e1s extendido a nivel mundial.<\/p>\n<p>Otras alternativas son <strong>Windows + .NET y servidor SQL Server<\/strong>.<\/p>\n<p>Una tercera configuraci\u00f3n es <strong>Linux + J2EE, servidor Linux o Windows + Apache Tomcat<\/strong> y bases de datos como Oracle, MySQL, PostgreSQL, etc<\/p>\n<p>Muchos administradores gestionan sus servidores con paneles de control administrables como <strong>CPANEL<\/strong>, <strong>Plesk<\/strong>, etc. Gracias a estos, se puede configurar \u201cf\u00e1cilmente\u201d aspectos de la m\u00e1quina y ganar tiempo. Pero ojo, tambi\u00e9n tienen sus vulnerabilidades y necesitan ser actualizados.<\/p>\n<p>Otro ejemplo de seguridad aplicado a servidores, es el relacionado con los servidores de datos. Muchas veces, tendremos abierto el puerto externo para conectar con la base, siendo <strong>innecesario<\/strong> ya que lo podremos realizar en <strong>localhost<\/strong>.<\/p>\n<div id=\"palen-575073360\" class=\"palen-despues-del-contenido palen-entity-placement\"><div class=\"palen-adlabel\">Anuncios<\/div><script async src=\"\/\/pagead2.googlesyndication.com\/pagead\/js\/adsbygoogle.js?client=ca-pub-2815317153396146\" crossorigin=\"anonymous\"><\/script><ins class=\"adsbygoogle\" style=\"display:block;\" data-ad-client=\"ca-pub-2815317153396146\" \ndata-ad-slot=\"\" \ndata-ad-format=\"auto\" data-full-width-responsive=\"true\"><\/ins>\n<script> \n(adsbygoogle = window.adsbygoogle || []).push({}); \n<\/script>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>Monograf\u00eda sobre los principios de seguridad web. La seguridad web pasiva son aquellas medidas para crear nuestra aplicaci\u00f3n sin necesidad de intervenci\u00f3n humana. Debe ser segura por defecto. Cualquier estado de error no debe proporcionar inseguridad. Deberemos tener cuanto menos puntos de entrada mejor, minimizando oportunidades de acceso o ataque. La seguridad activa web son acciones manuales para aumentar la seguridad del sistema. Por ejemplo, una revisi\u00f3n buscando brechas de seguridad. Se podr\u00e1n comprobar las vulnerabilidades y crear auditorias. La realizaci\u00f3n de copias de seguridad es vital para poder recuperar datos. Intentaremos mantener siempre el principio de simpleza en el desarrollo web. Existen multitud de elementos a comprobar porque existen multitud de elementos de ataque. El principio de Pareto o la regla del 80-20 aplicada a seguridad web, indica que no todos los ataques tienen el mismo tipo de distribuci\u00f3n. Con el 20% de la prevenci\u00f3n se puede detener el 80% de los posibles ataques.<\/p>\n","protected":false},"author":1,"featured_media":5050,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"advanced_seo_description":"","jetpack_seo_html_title":"","jetpack_seo_noindex":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_feature_clip_id":0,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2},"jetpack_post_was_ever_published":false},"categories":[50,24],"tags":[645],"class_list":["post-8082","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-seguridad","category-web","tag-seguridad-web"],"views":2764,"jetpack_publicize_connections":[],"jetpack_featured_media_url":"https:\/\/www.palentino.es\/blog\/wp-content\/uploads\/2013\/06\/Seguridad.jpg","jetpack_shortlink":"https:\/\/wp.me\/p2ECph-26m","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/www.palentino.es\/blog\/wp-json\/wp\/v2\/posts\/8082","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.palentino.es\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.palentino.es\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.palentino.es\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.palentino.es\/blog\/wp-json\/wp\/v2\/comments?post=8082"}],"version-history":[{"count":8,"href":"https:\/\/www.palentino.es\/blog\/wp-json\/wp\/v2\/posts\/8082\/revisions"}],"predecessor-version":[{"id":8090,"href":"https:\/\/www.palentino.es\/blog\/wp-json\/wp\/v2\/posts\/8082\/revisions\/8090"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.palentino.es\/blog\/wp-json\/wp\/v2\/media\/5050"}],"wp:attachment":[{"href":"https:\/\/www.palentino.es\/blog\/wp-json\/wp\/v2\/media?parent=8082"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.palentino.es\/blog\/wp-json\/wp\/v2\/categories?post=8082"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.palentino.es\/blog\/wp-json\/wp\/v2\/tags?post=8082"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}