+
+![](\"/miImagen.gif\")
https://es.wikipedia.org/wiki/Anexo:Cabeceras_HTTP HTTP define una serie predefinida de métodos de petición (algunas veces referido como \"verbos\") que pueden utilizarse. El protocolo tiene flexibilidad para ir añadiendo nuevos métodos y para así añadir nuevas funcionalidades. Cada método indica la acción que desea que se efectúe sobre el recurso identificado. Lo que este recurso representa depende de la aplicación del servidor. Por ejemplo, el recurso puede corresponderse con un archivo que reside en el servidor. https://en.wikipedia.org/wiki/HTTP#Request_methods El código de respuesta, estado o retorno es un número que indica que ha pasado con la petición. El resto del contenido de la respuesta dependerá del valor de este código. El sistema es flexible y de hecho la lista de códigos ha ido aumentando para así adaptarse a los cambios e identificar nuevas situaciones. Cada código tiene un significado concreto. Sin embargo el número de los códigos están elegidos de tal forma que según si pertenece a una centena u otra se pueda identificar el tipo de respuesta que ha dado el servidor: Códigos con formato 1xx: Respuestas informativas. Indica que la petición ha sido recibida y se está procesando. Códigos con formato 2xx: Respuestas correctas. Indica que la petición ha sido procesada correctamente. Códigos con formato 3xx: Respuestas de redirección. Indica que el cliente necesita realizar más acciones para finalizar la petición. Códigos con formato 4xx: Errores causados por el cliente. Indica que ha habido un error en el procesado de la petición a causa de que el cliente ha hecho algo mal. Códigos con formato 5xx: Errores causados por el servidor. Indica que ha habido un error en el procesado de la petición a causa de un fallo en el servidor. Enlaces https://es.wikipedia.org/wiki/Anexo:C%C3%B3digos_de_estado_HTTP https://en.wikipedia.org/wiki/List_of_HTTP_status_codes En el año 2000, un nuevo formato para usar HTTP fue diseñado: REST (del inglés: 'Representational State Transfer'). Las acciones de la nueva API, no estaban supeditadas a nuevos métodos HTTP, unicamente al acceso a URIs especificas con métodos HTTP/1.1). Esto permitió que cualquier aplicación Web dispusiera de una API, para permitir la recuperación y modificación de datos, sin tener que actualizar servidores o navegadores; todo lo que se necesitaba era incluido en los archivos servidos por los sitios Web. La contrapartida del modelo REST está en que cada sitio Web define su propia versión no estándar de API RESTful y tiene un control total sobre ella; al contrario del formato *DAV donde clientes y servidores eran interoperables. La arquitectura REST empezó a ser muy común a partir del año 2010. |== | Cabecera | Descripción | Ejemplo | Content-Type | Define el tipo de contenido que se envía en la petición | application/json | Accept | Define el tipo de contenido que se aceptará en la respuesta | application/json |https://developer.mozilla.org/es/docs/Web/HTTP/Headers/Authorization[Authorization]|Permite enviar tokens de autorización.| Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l |== |== | Método | Uso recomendado | Códigos de Estado Comunes | GET | Obtener información | 200, 404, 403 | POST | Permite crear recursos | 201, 202, 404, 403 | PUT | Permite actualizar recursos en su totalidad | 200, 404, 403 | PATCH | Permite actualizar un campo dentro de un recurso | 200, 404, 403 | DELETE | Permite eliminar un recurso | 200, 404, 403 |== Nota: No se recomienda el código de estado 204 (No content) debido a que no entrega ninguna respuesta (body) al cliente. Es mejor siempre devolver un cuerpo con información relacionada a la operación. https://developer.mozilla.org/es/docs/Web/HTTP/Basics_of_HTTP/Evolution_of_HTTP https://apisyouwonthate.com/books/ https://www.rfc-editor.org/rfc/rfc9110.html#section-9.3 JSON API es una convención (no un estándar) para expresar datos de APIs en formato JSON o json api. Es decir, es un JavaScript Object Notation en una Interfaz de Programación en Aplicaciones. También puedes pensar en JSON API como un formato que trabaja con HTTP. https://jsonapi.org/ https://keepcoding.io/blog/json-api-que-es-para-que-sirve/ La especificación OpenAPI es un lenguaje de especificación para API HTTP que proporciona un medio estandarizado para definir su API ante otros. Puede descubrir rápidamente cómo funciona una API, configurar la infraestructura, generar código de cliente y crear casos de prueba para sus API. Obtenga más información sobre cómo puede obtener el control de sus API ahora, comprender el ciclo de vida completo de las API y comunicarse con las comunidades de desarrolladores dentro y fuera de su organización. https://www.openapis.org/ SOAP es una tecnología antigua que requiere un contrato de comunicación estricto entre sistemas. Con el tiempo, se han agregado nuevos estándares de servicios web para adaptarse a los cambios tecnológicos, pero generan gastos generales adicionales. REST se desarrolló después de SOAP y soluciona de forma inherente muchas de sus deficiencias. Los servicios web REST también se denominan servicios web RESTful. https://aws.amazon.com/es/compare/the-difference-between-soap-rest/ GraphQL es un lenguaje de consulta para API y un tiempo de ejecución para completar esas consultas con sus datos existentes. GraphQL proporciona una descripción completa y comprensible de los datos de su API, brinda a los clientes el poder de solicitar exactamente lo que necesitan y nada más, facilita la evolución de las API con el tiempo y habilita potentes herramientas para desarrolladores. { hero { name friends { name homeWorld { name climate } species { name lifespan origin { name } } } } } https://graphql.org/ gRPC es un marco moderno de llamada a procedimiento remoto (RPC) de código abierto y alto rendimiento que puede ejecutarse en cualquier entorno. Puede conectar de manera eficiente servicios dentro y entre centros de datos con soporte conectable para equilibrio de carga, rastreo, verificación de estado y autenticación. También es aplicable en la última milla de la informática distribuida para conectar dispositivos, aplicaciones móviles y navegadores a servicios backend. https://grpc.io/ Existen diversos formatos y estándares para compartir datos y configurar los productos de software. Normalmente son formatos de texto plano (pueden ser leidos por un humano) y también hay en formato binario (pueden ser leidos solo por un computador), entre los más populares están JSON, XML, YAML y TOML. Siempre que desee enviar alguna estructura de datos o un objeto a través de redes informáticas, digamos Internet, debe convertirlo en un formato especial para leerlo y almacenarlo. El proceso se conoce comúnmente como serialización y es de enorme importancia en la web. Un ejemplo de uso común de serialización es al leer datos de bases de datos y transferirlos a través de la web. Algunas formaciones de serialización incluyen JSON y XML. JSON (JavaScript Object Notation - Notación de Objetos de JavaScript) es un formato ligero de intercambio de datos. Leerlo y escribirlo es simple para humanos, mientras que para las máquinas es simple interpretarlo y generarlo. Está basado en un subconjunto del Lenguaje de Programación JavaScript, Standard ECMA-262 3rd Edition - Diciembre 1999. JSON es un formato de texto que es completamente independiente del lenguaje pero utiliza convenciones que son ampliamente conocidos por los programadores de la familia de lenguajes C, incluyendo C, C++, C#, Java, JavaScript, Perl, Python, y muchos otros. Estas propiedades hacen que JSON sea un lenguaje ideal para el intercambio de datos. Ejemplo { \"squadName\": \"Super hero squad\", \"homeTown\": \"Metro City\", \"formed\": 2016, \"secretBase\": \"Super tower\", \"active\": true, \"members\": [ { \"name\": \"Molecule Man\", \"age\": 29, \"secretIdentity\": \"Dan Jukes\", \"powers\": [\"Radiation resistance\", \"Turning tiny\", \"Radiation blast\"] }, { \"name\": \"Madame Uppercut\", \"age\": 39, \"secretIdentity\": \"Jane Wilson\", \"powers\": [ \"Million tonne punch\", \"Damage resistance\", \"Superhuman reflexes\" ] }, { \"name\": \"Eternal Flame\", \"age\": 1000000, \"secretIdentity\": \"Unknown\", \"powers\": [ \"Immortality\", \"Heat Immunity\", \"Inferno\", \"Teleportation\", \"Interdimensional travel\" ] } ] } https://developer.mozilla.org/es/docs/Learn/JavaScript/Objects/JSON https://www.ecma-international.org/publications-and-standards/standards/ecma-404/ https://www.json.org/json-es.html El lenguaje de marcado extensible (XML) permite definir y almacenar datos de forma compartible. XML admite el intercambio de información entre sistemas de computación, como sitios web, bases de datos y aplicaciones de terceros. Las reglas predefinidas facilitan la transmisión de datos como archivos XML a través de cualquier red, ya que el destinatario puede usar esas reglas para leer los datos de forma precisa y eficiente. Ejemplo Criptografía
+La criptografía juega un papel fundamental en la seguridad de aplicaciones web y móviles. +Permite transmitir información de forma que solo pueda ser vista y comprendida +por el emisor y el receptor designado, ayudando a que terceros no puedan visualizar +o adulterar el contenido original.
+Hash
+El hash es una forma de codificar un dato para detectar cualquier cambio de forma sencilla. +El menor cambio mostrará una secuencia de caracteres totalmente distinta. +El hash tiene la característica que es solo de una vía, un contenido no puede volver a +su versión original si pasa por una función de hash.
+Los hash son usados, por ejemplo, por las criptomonedas +al momento de verificar los bloques utilizando técnicas +como el Árbol de Merkle.
+También son usados para verificar si un archivo ha sido descargado +correctamente y no ha sido adulterado al verificar su hash.
+MD5
+MD5 es un hash creado en 1991 que fue muy popular +en las aplicaciones webs de los 90s y principios del 2000. Hoy en día no es recomendado +para nada más que verificar la integridad de datos. Ya que con el avance tecnológico +el poder de cómputo avanza hasta lograr quebrar este algoritmo, provocando que pueda +ser descubierto el dato original (usando tablas de palabras) o existan colisiones, +es decir dos o más datos con el mismo hash.
+Bcrypt
+Bcrypt es un hash originado en 1999, recomendado para ocultar contraseñas en las bases de datos. +Tiene la característica de ser resistente a ataques de tablas de palabras (rainbow tables) y fuerza bruta, por lo que no se ve afectado +por el aumento del poder de cómputo en el tiempo.
+Base64
+Base64 es una forma de codificar binario en texto plano. Sirve por ejemplo para incrustrar imágenes en sitios web +dentro del mismo archivo html.
+<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABgAAAAYCAYAAADgdz34AAAABHNCSVQICAgIfAhkiAAAAAlwSFlzAAAApgAAAKYB3X3/OAAAABl0RVh0U29mdHdhcmUAd3d3Lmlua3NjYXBlLm9yZ5vuPBoAAANCSURBVEiJtZZPbBtFFMZ/M7ubXdtdb1xSFyeilBapySVU8h8OoFaooFSqiihIVIpQBKci6KEg9Q6H9kovIHoCIVQJJCKE1ENFjnAgcaSGC6rEnxBwA04Tx43t2FnvDAfjkNibxgHxnWb2e/u992bee7tCa00YFsffekFY+nUzFtjW0LrvjRXrCDIAaPLlW0nHL0SsZtVoaF98mLrx3pdhOqLtYPHChahZcYYO7KvPFxvRl5XPp1sN3adWiD1ZAqD6XYK1b/dvE5IWryTt2udLFedwc1+9kLp+vbbpoDh+6TklxBeAi9TL0taeWpdmZzQDry0AcO+jQ12RyohqqoYoo8RDwJrU+qXkjWtfi8Xxt58BdQuwQs9qC/afLwCw8tnQbqYAPsgxE1S6F3EAIXux2oQFKm0ihMsOF71dHYx+f3NND68ghCu1YIoePPQN1pGRABkJ6Bus96CutRZMydTl+TvuiRW1m3n0eDl0vRPcEysqdXn+jsQPsrHMquGeXEaY4Yk4wxWcY5V/9scqOMOVUFthatyTy8QyqwZ+kDURKoMWxNKr2EeqVKcTNOajqKoBgOE28U4tdQl5p5bwCw7BWquaZSzAPlwjlithJtp3pTImSqQRrb2Z8PHGigD4RZuNX6JYj6wj7O4TFLbCO/Mn/m8R+h6rYSUb3ekokRY6f/YukArN979jcW+V/S8g0eT/N3VN3kTqWbQ428m9/8k0P/1aIhF36PccEl6EhOcAUCrXKZXXWS3XKd2vc/TRBG9O5ELC17MmWubD2nKhUKZa26Ba2+D3P+4/MNCFwg59oWVeYhkzgN/JDR8deKBoD7Y+ljEjGZ0sosXVTvbc6RHirr2reNy1OXd6pJsQ+gqjk8VWFYmHrwBzW/n+uMPFiRwHB2I7ih8ciHFxIkd/3Omk5tCDV1t+2nNu5sxxpDFNx+huNhVT3/zMDz8usXC3ddaHBj1GHj/As08fwTS7Kt1HBTmyN29vdwAw+/wbwLVOJ3uAD1wi/dUH7Qei66PfyuRj4Ik9is+hglfbkbfR3cnZm7chlUWLdwmprtCohX4HUtlOcQjLYCu+fzGJH2QRKvP3UNz8bWk1qMxjGTOMThZ3kvgLI5AzFfo379UAAAAASUVORK5CYII="
+>Hay que tener en cuenta de que algunos caracteres de Base64 no son compatibles con las URL,
+por lo que se debe ver una variante que no tenga los caracteres como / si se usará para enviar
+datos por url (URL Safe Base64).
HMAC
+HMAC son las siglas de Código de Autenticación de Mensajes basado en Hash +(por sus siglas en inglés, Hash-based Message Authentication Code). Se trata de un método de +seguridad que utiliza una función hash criptográfica y una clave secreta compartida para verificar +la integridad y la autenticidad de un mensaje. Esto significa que garantiza que el mensaje +no ha sido alterado durante la transmisión y que proviene de la fuente esperada.
+Diffie-Hellman
+El intercambio de claves Diffie-Hellman es un protocolo criptográfico que permite a dos +partes crear de forma segura una clave secreta compartida sobre un canal público e inseguro, +sin que esa clave viaje nunca por la red. Este método se basa en la matemática de las funciones de un solo sentido y es fundamental +para el cifrado de comunicaciones, ya que las claves resultantes se usan para asegurar la +comunicación posterior.
+Es muy común verlo utilizado para verificar conexiones ssh y generar llaves únicas +para las criptomonedas.
+
+----
+
+Hay que tener en cuenta de que algunos caracteres de Base64 no son compatibles con las URL,
+por lo que se debe ver una variante que no tenga los caracteres como `/` si se usará para enviar
+datos por url (URL Safe Base64).
+
+== HMAC
+
+https://en.wikipedia.org/wiki/HMAC[HMAC] son las siglas de Código de Autenticación de Mensajes basado en Hash
+(por sus siglas en inglés, Hash-based Message Authentication Code). Se trata de un método de
+seguridad que utiliza una función hash criptográfica y una clave secreta compartida para verificar
+la integridad y la autenticidad de un mensaje. Esto significa que garantiza que el mensaje
+no ha sido alterado durante la transmisión y que proviene de la fuente esperada.
+
+== Diffie-Hellman
+
+El intercambio de claves https://es.wikipedia.org/wiki/Intercambio_de_claves_de_Diffie-Hellman[Diffie-Hellman] es un protocolo criptográfico que permite a dos
+partes crear de forma segura una clave secreta compartida sobre un canal público e inseguro,
+sin que esa clave viaje nunca por la red. Este método se basa en la matemática de las funciones de un solo sentido y es fundamental
+para el cifrado de comunicaciones, ya que las claves resultantes se usan para asegurar la
+comunicación posterior.
+
+Es muy común verlo utilizado para verificar conexiones ssh y generar llaves únicas
+para las criptomonedas.
diff --git a/modules/security/pages/security.adoc b/modules/security/pages/security.adoc
new file mode 100644
index 0000000..faf8f04
--- /dev/null
+++ b/modules/security/pages/security.adoc
@@ -0,0 +1,167 @@
+= Seguridad de las Aplicaciones
+
+En el ciclo de desarrollo se debe resolver tempranamente los requerimientos de seguridad, regulaciones, cumplimiento y riesgos asociados.
+Por lo que se deben considerar en las primeras etapas de planificación del proyecto. Es adecuado seguir las recomendaciones
+de seguridad de la última versión del https://owasp.org/Top10/[Owasp Top 10].
+
+**Beneficios de considerar**
+
+- Reducir la probabilidad de una falla de seguridad y sus consecuencias, como pérdida de reputación comercial o multas.
+- Evitar fisuras que permitan liberar información delicada que pueden costar millones de dólares por incidente.
+
+Para mayor información se recomiendan los siguientes recursos:
+
+- https://github.com/mirego/elixir-security-advisories
+- https://softwarepatternslexicon.com/patterns-elixir/23/2/
+- https://hacksplaining.com/lessons
+- https://www.manning.com/books/grokking-web-application-security
+
+== Actores
+
+Entre los actores de la seguridad se encuentran principalmente tres y se diferencian
+con un "color de sombrero".
+
+=== Black Hat Hackers
+
+Los hackers de sobrero negro. Son los actores maliosos, también conocidos como crackers.
+Trabajan para fines no éticos y crean virus, troyanos, backdoors, keyloggers, entre otras
+herramientas para obtener beneficios económicos o mandar mensajes políticos. Son los criminales
+de la ciber seguridad. Algunos contratados por organizaciones criminales e individuos de baja fibra moral.
+
+=== Grey Hat Hackers
+
+Los hackers de sombrero gris son aquellos que intentan vulnerar los sistemas pero sin el conocimiento
+de las organizaciones, aunque pueden ofrecerlo sus descubrimientos a la organización o al mejor postor.
+Están en una zona gris donde depende de la moralidad de la persona en qué área moverse. Podrían
+ser actores contratados por el gobierno para realizar ataques de ciber guerra.
+
+=== White Hat Hackers
+
+Los hackers de sombrero blanco. Son investigadores de la ciber seguridad contratados por las empresas
+para intentar vulnerar a los sistemas antes de que los actores maliciosos
+descubran vulnerabilidades. Utilizan las mismas herramientas y metodologías
+de los atacantes, pero siempre en pos de mejorar la seguridad de la organización
+para la cual trabajan.
+
+
+== Problemas de Seguridad Comunes
+
+La seguridad es un tema amplio, por lo que se mostrará solo un pequeño punteo
+de los problemas más comunes que pueden aparecer en aplicaciones web y móviles.
+Se recomienda la lectura de libros especializados en el tema, como Grokking Web Application Security
+para profundizar.
+
+=== XSS
+
+Los ataques de Cross Site Scripting (XSS) consisten en lograr subir un script ejecutable
+como _Javascript_ o _PHP_ al sitio web, debido a que los formularios no son adecuadamente protegidos,
+validados ni verificados en el frontend o en el backend. Por lo que un atacante puede subir código ejecutable que permita
+obtener acceso a datos valiosos como las contraseñas, cookies o incluso acceso al servidor
+al instalar puertas traseras (backdoors) dentro del código ejecutable.
+
+=== SQLInjections
+
+Los ataques de SQLInjections son similares a los XSS, pero están más orientados a ejecutar
+consultas SQL y realizar operaciones para obtener la base de datos o dañar la información
+almacenada.
+
+=== MITM
+
+El ataque Man in The Middle (Hombre en el medio). Consiste en escuchar las comunicaciones
+entre un dispositivo y el internet. Esto es posible con que el dispositivo se conecte a una red
+no segura o que este utilizando un proxy que desvié las comunicaciones al computador de un tercero
+antes de llegar a internet. Normalmente las comunicaciones deben estar encriptadas con SSL pero
+no todos los sitios web y aplicaciones están correctamente configuradas.
+
+++++
+
+++++
+
+En las aplicaciones móviles para proteger de un MITM se utiliza la técnica de fijación de SSL o SSL Pinning
+el cual consiste en tener un certificado de SSL almacenado en la aplicación, por lo que siempre se podrá verificar
+la autenticidad de un certificado y no podrá ser adulterado por un proxy atacante.
+
+++++
+
+++++
+
+=== Dependency Chain Abuse
+
+El envenenamiento de las dependencias o abuso de la cadena de dependencias, consiste en que las dependencias de una aplicación son adulteradas por un tercero en la fuente
+original. Por lo que es un ataque masivo a todas las aplicaciones que utilicen la dependencia.
+
+Esto ocurre por problemas de seguridad en el origen de las dependencias o por que los autores originales
+de la misma fueron atacados para robar sus contraseñas o dispositivos.
+
+Para evitar estos ataques se debe estar pendiente de cualquier vulnerabilidad
+en los canales oficiales y seguir las recomendaciones de seguridad del framework
+usado.
+
+https://owasp.org/www-project-top-10-ci-cd-security-risks/CICD-SEC-03-Dependency-Chain-Abuse[Más Info].
+
+=== Phishing
+
+Es el envío de emails o links que simulan ser una página oficial como un banco
+o tienda. Solicita a la persona datos privados usando formularios adulterados
+con urls sospechosas similares a una página oficial.
+
+++++
+
+++++
+
+==== Developer Phishing
+
+Hay una nueva modalidad de ataque a los desarrolladores, sobre todo los que buscan trabajo
+de enviar un proyecto para ser mejorado dentro del contexto de reclutamiento para una posición de trabajo.
+Este proyecto tiene dependencias o código malicioso que puede robar contraseñas u otras cosas
+importantes, como acceso a código de proyectos empresariales.
+
+Se recomienda siempre utilizar una máquina virtual con Linux (recomendanción Debian)
+antes de ejecutar cualquier código para un tercero, sobre todo
+para cuando se tenga estos procesos de reclutamiento. Desconfiar
+si el reclutador es de países sospechosos o insiste en ejecutar el código antes de
+comenzar cualquier formalidad en el proceso de reclutamiento.
+
+=== CSRF
+
+Cross Site Request Forgery (Falsificación de Peticiones de Sitio Cruzado)
+Los formularios pueden ser incrustrados en otras páginas que simulan ser la original.
+Si el sitio no protege sus formularios contra este ataque puede hacer que sus usuarios
+sean víctima de ataques _MITM_ o clonación de datos, también el sitio puede ser
+sobrepasado con envíos masivos de peticiones (DDoS) o utilización de recursos para envío de SPAM
+y otras prácticas nocivas.
+
+Los stacks tecnológicos actuales proveen protección contra este ataque al generar un token
+único que se incrusta en el formulario. Este token solo puede ser validado por el backend,
+por lo que un atacante no podrá adulterar el formulario.
+
+El siguiente es un ejemplo utilizando el framework https://processwire.com/api/ref/session/c-s-r-f/[ProcessWire] de PHP.
+
+.frontend
+[source, php]
+----
+// Incluir en los campos del formulario
+
+----
+
+.backend
+[source, php]
+----
+// verificar si el token es válido
+if($session->CSRF->hasValidToken()) {
+ // se puede continuar
+} else {
+ // el formulario es sospechoso
+ throw new WireException('CSRF check failed!');
+}
+----
+
+=== Social Engineering
+
+Es la práctica de convencer a personas para que liberen información privada
+a través de engaños o manipulación emocional. Es una técnica usada normalmente
+por estafadores de teléfono para acceder a dineros o claves de tarjeta de crédito.
+
+++++
+
+++++