Ppt Teórico 2

Desarrollo de software seguro

Qué es programar? trasmitir órdenes a un dispositivo, a través de un lenguaje.

Cómo se programa? A través de algoritmos.

*El método es lo que te convierte en programador, el lenguaje es una practica.*

Qué es un Algoritmo? Conjunto ORDENADO y FINITO de operaciones que permite llegar a la solución de un PROBLEMA; series de pasos pensados con el fin de generar un conjunto de instrucciones para hacer un programa.

*El diagrama de flujo, es una manera de pensar un programa.*

*Parámetro = variable = constante*

Variable: es un espacio en memoria, asociado a un nombre lógico y a un valor, con un tipo de dato particular. El valor de una variable varía durante la ejecución de un algoritmo. Características: Declaración (lo nombro) y Asignación con el signo = (le doy el valor).

En PHP todas las variables tienen un signo peso $ adelante y no es necesario declarar el tipo de variable.

Tipos de variables : String (cadena de caracteres), Integer (número entero), Float (numero con decimales), Boolean (V o F), Array (arreglos), Objeto (variable tipo objeto), NULL (variable sin valor aun asignado).

Operadores: son los símbolos que nos permiten expresar las operaciones entre los datos. Toman unos valores de entrada, los relaciona entre sí y muestran un resultado.

· Operadores Aritméticos/matemáticos (+ - * / %modulo, **exponenciación).

· Operadores de asignación (= += -= *= /= %= .=concatenación y asignación).

• Operadores de comparación:

== Comprueba si son iguales;

!= Comprueba si son distintos;

=== Comprueba si son iguales y de exactamente el mismo tipo;

!== Comprueba si son distintos o de distinto tipo;

<> Diferente (igual a !=);

< Menor que, comprueba si un valor es menor que otro;

> Menor que;

<= Menor igual;

>= Mayor igual;

Estructuras de control : permiten controlar y modificar el flujo de ejecución de las instrucciones de un programa.

●Ejecutar un grupo de sentencias de acuerdo a una condición. If: Se evalúa una expresión en base a su valor booleano (true o false); solo si la expresión es true se ejecutará. If… Else: solo si la expresión es falsa se ejecutará Else.

●Ejecutar un grupo de sentencias mientras se cumpla una condición. While: la expresión se evalúa como true, entra en el bucle y repite hasta que sea false. Do… While: la expresión es evaluada al final de cada iteración. Eso garantiza al menos una ejecución.

●Ejecutar un grupo de sentencias un número determinado de veces. For: está compuesta por tres expresiones. La primera expresión establece un valor inicial de una variable. La segunda expresión contiene la condición a evaluar sobre la variable de control. Si se evalúa como true el bucle continúa, se ejecutan las sentencias contenidas y se evalúa la tercera expresión. Si se evalúa como false el bucle se interrumpe. La tercera expresión efectúa un cambio en la variable de control.

HTML: no es un lenguaje de programación, es de Marcado. Permite armar la estructura de un documento mediante etiquetas (son elementos que encierran los contenidos para que se vean de determinada manera, ej <p>; </p>). Es interpretado por los navegadores web.

Formulario HTML: <formname="formulario"action="action.php"method="get">

name= nombre con el que se identifica al form

action= destino de los datos enviados a través del form

method= método http para el envío de los datos del formulario

index.php: <input type="text" name="txtNombre">

Action, es un atributo donde se alojan los datos ingresados en el formulario. Es necesario un archivo destino con el nombre action.php: $_GET ['txtNombre'];

Variables superglobales: predefinidas y disponibles en todos los ámbitos, ej: $_GET, $_POST, $_COOKIE, $_SESSION, todos son arrays asociativos.

GET y POST: Es la manera en como viajan los datos , son dos variables/métodos q se comunican con los formularios de las páginas web y tienen que ver con el usuario; formas de envío de datos en un formulario.

Diferencias:

· GET pasa directamente por la URL, la dirección web, en forma de parámetros. Los datos los puede ver cualquiera, ej: www.unisanisidro.edu.ar/action.php?nombre=pedro&apellidos1= gomez

· POST, del protocolo HTTP, viaja en el cuerpo del mensaje, la información viaja de forma codificada. Su uso es una buena práctica, que permite la confidencialidad de la información para la ciberseguridad.

*Integridad, Confidencial y la disponibilidad de la información.*

Qué es un Lenguaje de Programación? Es un lenguaje formal con reglas específicas que comprenden las computadoras. Un programa da órdenes a una computadora.

Clasificación de lenguajes - Nivel de Abstracción:

Cuanto más bajo nivel, está más cerca del lenguaje humano.

Cuanto más cercano sea del hardware, es más de bajo nivel.

• Lenguaje de alto nivel: ej PHP.

o El mayor parecido al lenguaje humano, lenguaje natural.

o Interprete: no genera código de máquina, lo va leyendo y ejecutando, se interpreta directamente en el código fuente.

· Lenguaje de medio-alto nivel: ej C.

o Mayor nivel abstracción, con características de bajo nivel.

o Se envía a un COMPILADOR que lo convierte a lenguaje de máquina. Atado a una arquitectura. Traduce a lenguaje de maquina lo que se programa en lenguajes de alto nivel.

• Lenguaje de bajo nivel:

o Lenguaje ensamblador, es una traducción del vinario a uno más parecido al humano.

o Lenguaje de maquina: entiende el lenguaje vinario (0 y 1).

· Hardware: parte física de la computadora, microprocesador.

Paradigma: son los principios fundamentales, las buenas prácticas. Estilos de paradigmas:

· Programación imperativa (clásico), se le da todas las órdenes detalladas, es el cómo. Ej Programación estructurada; Programación procedimental; Programación modular. Pascal y C, así como de todos los lenguajes ensambladores

· Programación declarativa, se busca la descripción del resultado final, con un grado de abstracción más alto, es el qué. Ej Programación lógica; Programación funcional.

¿Qué es un ambiente? conjunto de herramientas físicas y/o lógicas que permiten la ejecución de programas, es el entorno donde se desarrolla un programa.

IDE: Es un entono de programación integrado.

PHP: Lenguaje de programación de código abierto, de alto nivel, es interpretado y corre del lado del servidor; son siglas página web personal. Permite la creación de páginas web dinámicas. Se necesita un servidor web (XAMPP) que sea capaz de interpretar este lenguaje de programación y un intérprete que identifica los pasajes de un archivo que contienen código PHP.

Web dinámica: permite tener una base de datos y un programa que consulta la BD y genera una lista. Permite dar herramientas al usuario para que el mismo mantenga la web/BD.

Script: es un programa informático en general de pequeñas dimensiones que no se compila en código binario previamente

Ppt Teórico 3

$_COOKIE: un fragmento de información que un navegador web almacena en el disco dura del visitante de la página web. Es un archivo que guarda información desde el lado del navegador (lado del cliente), contiene información de la página web y el usuario. Es accesible desde una variable PHP.

$_SESSION: residen en el servidor pero se accede desde una cookie; se genera un número de 32 dígitos, que el navegador guarda en una cookie. Es un número de referencia de la sesión que la variable guarda en el servidor. Es más difícil de acceder a la información.

Dev: las personas encargadas del desarrollo de los programas son los programadores.

Ops: las personas encargadas de la administración de los ambientes son los de Operaciones de IT.

DevOps: desarrollo ágil, metodología ágil que fue necesaria por las presiones del mercado. El ciclo de desarrollo este compenetrado con el ciclo de operaciones.

En el pasado, un equipo de seguridad independiente añadía la seguridad al software al final del ciclo de desarrollo (casi como una elección hecha a último momento), y otro equipo independiente de control de calidad (QA) la probaba. Esto era manejable cuando las actualizaciones de software se publicaban una o dos veces al año.

DevSepOps: Desarrollo, Seguridad y Operaciones. Seguridad por diseño, incluye las buenas prácticas de seguridad.

¿Qué es? DevSecOps integra la seguridad de la aplicación y la infraestructura sin problemas en los procesos y herramientas de Agile y DevOps. Aborda los problemas de seguridad a medida que surgen, cuando son más fáciles, más rápidos y menos costosos de arreglar (y antes de que se pongan en producción). Además, DevSecOps hace de la aplicación y la seguridad de la infraestructura una responsabilidad compartida de los equipos de desarrollo, seguridad y operaciones de TI, en lugar de la exclusiva responsabilidad de un silo de seguridad. Permite "software, más seguro, antes", el lema de DevSecOps, automatizando la entrega de software seguro sin frenar el ciclo de desarrollo de software.

Permite planificar a futuro:

· la trazabilidad, permite realizar un seguimiento;

· la auditabillidad, es importante para garantizar la conformidad de los

• controles de seguridad;

· la visibilidad, es tener un sistema de supervisión sólido para medir la pulsación del funcionamiento, enviar alertas, aumentar el reconocimiento de los cambios y los ciberataques a medida que se producen y proporcionar responsabilidad durante todo el ciclo de vida del proyecto.

Etapas de DevSecOps:

· Planifica, es la menos automatizada e incluye la colaboración, discusión, revisión y estrategia de análisis de seguridad. Los equipos deben realizar un análisis de seguridad y crear un plan que detalle dónde, cómo y cuándo se realizarán las pruebas de seguridad. Herramientas de planificación populares: IriusRisk, Jira Software, Slack, etc.

· Código, las prácticas de seguridad más importantes son el análisis de código estático, las revisiones de código y los hooks previos a la confirmación. Herramientas de código de seguridad: Gerrit, Phabricator, SpotBugs, PMD, CheckStyle y Find Security Bugs, etc.

· Compilación, (comienza cuando los desarrolladores confirman el código en el repositorio fuente). Las herramientas se centran en el análisis de seguridad automatizado con respecto al artefacto de salida de la compilación. Los desarrolladores instalan y compilan con regularidad dependencias de código de terceros, que pueden proceder de una fuente desconocida o que no es de confianza. Las dependencias de código externo pueden incluir vulnerabilidades de seguridad y exploits de forma accidental o malintencionada. Herramientas para ejecutar análisis de fase de compilación: OWASP, Dependency-Check, SonarQube, SourceClear, Retire.js, Checkmarx y Snyk.

· Prueba, utiliza herramientas de pruebas dinámicas de seguridad de las aplicaciones (DAST) para detectar flujos de aplicaciones en tiempo real, como autenticación de usuarios, autorización, SQL Injection y puntos de conexión relacionados con API. Las DAST centradas en la seguridad analizan una aplicación con respecto a una lista de problemas conocidos de alta gravedad, como los que figuran en la lista de las 10 principales vulnerabilidades de OWASP. Herramientas: BDD Automated, Security Tests, JBroFuzz, Boofuzz, OWASP ZAP, Arachni, IBM AppScan, GAUNTLT y SECApps Suite.

Ppt Teórico 4

Política de Desarrollo Seguro: Generar un estándar de buenas políticas de desarrollo dentro de la organización; generar una cultura que favorezca el desarrollo seguro de software. El activo más importe que tiene una organización es la información.

Para generar una cultura de software seguro primero hay que sentar las bases sobre cómo se van a incorporar los procesos y procedimientos a la metodología de trabajo actual. Las campañas de concientización al usuario y la capacitación de empleado son claves para la seguridad.

¿Qué debe contener la política de desarrollo seguro?

· Definir quiénes serán los responsables de diseñar, aprobar y actualizar la política de desarrollo seguro. Quienes son los actores.

· Determinar las áreas o personas que serán impactadas para que tengan un claro conocimiento de sus compromisos y responsabilidades en sus tareas diarias.

Comité de seguridad de la información: tiene la función de monitorear, implementar e informar sobre aspectos de seguridad dentro de la empresa.

Área TI: responsables de cumplir con las disposiciones y requerimientos de seguridad dispuestos en la presente política.

Control de AMBIENTES: Contar con repositorios en los cuales se restrinja su acceso

• Desarrollo: donde los programadores desarrollan los programas, solo para pruebas de desarrollo;

• Pre Producción: donde se ejecutan pruebas funcionales y de seguridad sobre los programas, acceso semi restringido;

• Producción: donde el programa está siendo utilizado plenamente por usuarios finales para el fin que fue creado, acceso restringido.

Tipos de prueba de software:

· Test unitario: son a bajo nivel (cercanas al código fuente de nuestra aplicación). Este tipo de testing consiste en probar de forma individual las funciones y/ométodos (de las clases, componentes y/o módulos que son usados pornuestro software).

· Test de Integración: verifican que los diferentes módulos y/o servicios usados por nuestra aplicación funcionen en armonía cuando trabajan en conjunto.

· Test Funcional: verifican la salida (resultado) de una acción, sin prestar atención a los estados intermedios del sistema mientras se lleva a cabo la ejecución.

· Diferencia entre "integration tests" (puede simplemente verificar que las consultas a una base de datos se ejecuten correctamente) y "functional tests" (esperaría mostrar un valor específico aun usuario, en concordancia a lo definido por los requerimientos del producto).

· Test de Humo: verifican la funcionalidad básica de una aplicación, su objetivo es asegurar que las características más importantes del sistema funcionan como seespera. Verifican que a funcionalidad principal del sitio opera como es debido.

· Prueba de aceptación de usuario: pruebas formales, ejecutadas para verificar si un sistema satisface sus requerimientos de negocio, requieren que el software se encuentre en funcionamiento, y se centran en replicar el comportamiento de los usuarios.

Vigencia y Versionado: mantener Versiones actualizadas del software, asegura un buen soporte, y una gestión eficiente de parches.

Algo común es realizar el manejo de versiones mediante 3 números: X.Y.Z y cada uno indica una cosa diferente:

•El primero (X) se le conoce como versión mayor y nos indica la versión principal del software. Ejemplo: 1.0.0, 3.0.0

•El segundo (Y) se le conoce como versión menor y nos indica nuevas funcionalidades. Ejemplo: 1.2.0, 3.3.0

•El tercero (Z) se le conoce como revisión y nos indica que se hizo una revisión del código por algún fallo. Ejemplo: 1.2.2, 3.3.4

Versiones por estabilidad: el usuario prueba el software e indica los errores.

· Alpha es una versión inestable que es muy probable que tenga muchas opciones que mejorar.

· Beta una versión más estable que Alpha en la que contamos con el producto en su totalidad, y se desea realizar pruebas de rendimiento, usabilidad y funcionamiento de algunos módulos para ver cómo funciona bajo un ambiente no tan controlado.

OWASP:

¿Qué es el OWASP top 10? es un informe que se actualiza con regularidad y en el que se exponen los problemas de seguridad de las aplicaciones web, centrándose en los 10 riesgos más importantes. Es elaborado por un equipo de expertos en seguridad y es considerado como un "documento de concientización" para minimizar o mitigar los riesgos de seguridad.

1. Inyección: estos ataques ocurren cuando se envían datos que no son de confianza a un intérprete de código a través de la entrada de un formulario o algún otro envío de datos a una aplicación web. Por ejemplo, un atacante podría introducir código de base de datos SQL en un formulario que espera un nombre de usuario en texto plano. Si la entrada del formulario no está asegurada de forma adecuada, se acabaría ejecutando el código SQL. Esto se conoce como un ataque de inyección de código SQL.

Los ataques de inyección pueden evitarse al validar o sanear los datos enviados por el usuario. (La validación significa rechazar los datos que tienen un aspecto sospechoso, mientras que la sanitización hace referencia a la limpieza de las partes de aspecto sospechoso de los datos). Además, el administrador de la base de datos puede establecer controles para minimizar la cantidad de información que puede sacar a la luz un ataque de inyección.

2. Autenticación rota (Broken Auth): es un ataque por fuga de datos. Las vulnerabilidades en los sistemas de autenticación (login) pueden dar a los atacantes acceso a las cuentas de los usuarios e incluso la capacidad de poner en riesgo todo un sistema mediante el uso de una cuenta de administrador. Por ejemplo, un atacante puede coger una lista con miles de combinaciones conocidas de nombres de usuarios y contraseñas conseguidas durante una fuga de datos, y utilizar un script para probar todas esas combinaciones en un sistema de inicio de sesión para ver si funciona alguna.

Algunas estrategias para mitigar las vulnerabilidades de autenticación son pedir la autenticación en dos fases (2FA), así como limitar o retrasar los intentos repetidos de inicio de sesión mediante el uso de la limitación de velocidad.

3. Exposición de datos confidenciales: un ataque por guardar información sensible y que no es realmente necesario guardar . Si las aplicaciones web no protegen los datos confidenciales, como la información financiera y las contraseñas, los atacantes pueden acceder a esos datos y venderlos o utilizarlos con fines maliciosos. Un método popular para robar información confidencial es el uso de un ataque en ruta.

El riesgo de exposición de datos puede minimizarse al encriptar todos los datos confidenciales, y al desactivar el almacenamiento en caché* de cualquier información confidencial. Además, los desarrolladores de aplicaciones web deben asegurarse de que no están almacenando innecesariamente ningún dato confidencial .

4. Entidades XML externas (XXE, es un formato de archivo tipo texto plano): Este es un ataque contra una aplicación web que analiza la entrada XML*. Esta entrada puede hacer referencia a una entidad externa, que intenta aprovecharse de una vulnerabilidad en el analizador. En este contexto, una "entidad externa" hace referencia a una unidad de almacenamiento, como un disco duro. A un analizador XML se le puede engañar para que envíe datos a una entidad externa no autorizada, que a su vez puede pasar datos confidenciales directamente a un atacante.

La mejor manera de prevenir los ataques XEE es hacer que las aplicaciones web acepten un tipo de dato menos complejo, como JSON**, o al menos parchear los analizadores XML y desactivar el uso de entidades externas en una aplicación XML.

5. Pérdida de control de acceso: El Control de acceso hace referencia un sistema que controla el acceso a la información o a la funcionalidad. Por ejemplo, una aplicación web podría permitir que un usuario cambiara la cuenta con la que ha iniciado sesión con solo cambiar parte de una url, sin ninguna otra verificación.

Los controles de acceso pueden asegurarse utilizando tokens de autorización y establezca controles estrictos sobre los mismos.

6. Mala configuración de seguridad: La desconfiguración de la seguridad es la vulnerabilidad más común de la lista, y suele ser el resultado de usar configuraciones por defecto o de mostrar errores excesivamente detallados.

Esto se puede mitigar mediante la eliminación cualquier función no utilizada en el código y al asegurarse de que los mensajes de error sean más generales.

7. Scripting entre sitios (XSS): se producen cuando las aplicaciones web permiten que los usuarios añadan código personalizado en una url o en un sitio web que será visto por otros usuarios. Esta vulnerabilidad puede ser explotada para ejecutar código JavaScript malicioso en el navegador de la víctima. Por ejemplo, un atacante podría enviar un correo electrónico a una víctima que parece que viene de un banco de confianza, con un enlace al sitio web de dicho banco. Este enlace podría tener algún código JavaScript malicioso etiquetado al final de la url. Si el sitio del banco no está debidamente protegido contra el scripting entre sitios, ese código malicioso se ejecutará en el navegador de la víctima cuando se haga clic en el enlace.

Las estrategias de mitigación para el scripting entre sitios incluyen evitar las solicitudes HTTP que no sean de confianza, así como validar o sanear el contenido generado por el usuario . El uso de marcos de desarrollo web modernos, como ReactJS y Ruby on Rails, también ofrece cierta protección integrada contra el scripting entre sitios.

8. Deserialización no segura: Esta amenaza se dirige a las numerosas aplicaciones web que serializan y deserializan datos con frecuencia . La serialización implica tomar objetos del código de la aplicación y convertirlos en un formato que pueda ser utilizado con otro objetivo, como almacenar los datos en el disco o transmitirlos. La deserialización es justo lo contrario: convertir los datos serializados de nuevo en objetos que la aplicación pueda utilizar. La serialización es como meter los muebles en cajas antes de una mudanza, y la deserialización es como sacarlos de las cajas y volver a montarlos después de la mudanza. Un ataque de deserialización inseguro es como si la empresa de mudanzas manipulara el contenido de las cajas antes de desembalarlas.

Una explotación de deserialización insegura es el resultado de la deserialización de datos desde fuentes no confiables, y puede tener graves consecuencias, como los ataques DDoS y los ataques de ejecución remota de código . Aunque se pueden tomar medidas para intentar atrapar a los atacantes, como la supervisión de la deserialización y la implementación de comprobaciones de tipo , la única forma segura de protegerse antes los ataques es prohibir la deserialización de datos desde fuentes no fiables .

9. Uso de componentes con vulnerabilidades conocidas: Muchos desarrolladores web modernos utilizan componentes como bibliotecas y marcos en sus aplicaciones web . Estos componentes son piezas de software que ayudan a los desarrolladores a evitar el trabajo redundante y a ofrecer la funcionalidad necesaria; un ejemplo común son los marcos frontales como React y las bibliotecas más pequeñas que se utilizan para añadir iconos compartidos o pruebas a/b. Algunos atacantes buscan vulnerabilidades en estos componentes que luego pueden utilizar para orquestar ataques. Los desarrolladores de componentes suelen ofrecer parches de seguridad y actualizaciones para tapar las vulnerabilidades conocidas, pero los desarrolladores de aplicaciones web no siempre tienen las versiones parcheadas o más recientes de los componentes que se ejecutan en sus aplicaciones.

Para minimizar el riesgo los desarrolladores deben eliminar de sus proyectos los componentes que no utilicen, así como asegurarse de que reciben componentes de una fuente de confianza y de que estos estén actualizados.

10. Registro y Supervisión insuficientes: Muchas aplicaciones web no toman suficientes medidas para detectar las fugas de datos. Se suele tardar unos 200 días de media en detectar una fuga después de que esta se haya producido. Esto da a los atacantes mucho tiempo para causar daños antes de que haya una respuesta. OWASP recomienda que los desarrolladores web implementen planes de registro y supervisión, así como de respuesta a incidentes, para asegurarse de que están al tanto de los ataques a sus aplicaciones.