Clases

1. confidencial
Visión de Ciberseguridad

2. confidencial
- Politicas de Backup
- SQLInjection
- Cross-Site Scripting (XSS)
- Dudas y consultas
Agenda

3. confidencial
Políticas de Backup
Las copias de seguridad son parte esencial de la plataforma tecnológica y logística de un
negocio, debe formar parte del plan de continuidad de negocio, ser un respaldo oportuno en
momentos inesperados.
La forma en que se realiza el proceso de copias de seguridad requiere solidez y esto se
consolida mediante una política de backup precisa, clara y adaptada a la empresa.
Estas políticas determinan:
● de qué forma se iniciará el proceso
● qué hardware, software y factor humano intervendrá
● donde se almacenarán los datos
● cómo funcionará el plan de recuperación de datos

4. confidencial
Las políticas de backup deben considerar algunos factores y aspectos, por ejemplo :
● Ámbito de aplicación / Criticidad de los sistemas
○ Tipos de datos
○ Niveles de Seguridad
● Frecuencias de las copias
● Soporte de copias de seguridad
● Tipos de Backup
● Plan de recuperación de datos
Políticas de Backup

5. confidencial
La frecuencia de los backups será determinada por los factores anteriormente
mencionados .
Utilizando los mismos podemos establecer escalas de valores y de esta forma
determinar la frecuencia a realizar el backup.
● Criticidad del activo - 1 (bajo) - 5 (alto)
● Tipo de activo - VM , BD, Files , Mails.
Políticas de Backup -Frecuencias

6. confidencial
Existe una gran cantidad de tipos de copias de seguridad, que se diferencian por su manera
de copiar los datos, velocidad y requerimientos de espacio.
Los principales tipos de copias de seguridad son:
● Completa. Se realiza una copia de seguridad de todos los archivos y carpetas
seleccionados. Cuando se ejecutan copias posteriores, nuevamente se hace una
copia de seguridad de todo el listado de archivos. La restauración de una copia de
seguridad completa es rápida. Sin embargo, cada ejecución es lenta y ocupa más
espacio con respecto a las otras tipologías.
● Incremental. Primero se realiza una copia de seguridad completa y las siguientes
copias incluyen únicamente los cambios realizados desde la última copia de
seguridad. Es mucho más rápida que una copia de seguridad completa y requiere
menos espacio, pero la restauración es más lenta que con una copia de seguridad
completa o diferencial.
Políticas de Backup- Tipos

7. confidencial
● Diferencial. Se realiza una copia de seguridad de todos los cambios realizados desde
la última copia de seguridad completa. Es mucho más rápida y requiere menos
espacio de almacenamiento que una copia de seguridad completa, pero más que una
copia de seguridad incremental. Las restauraciones son más lentas que con una copia
de seguridad completa, pero más rápidas que con copias de seguridad incrementales.
● Protección de datos continua (CDP). Permite una mayor cantidad de puntos de
restauración con respecto a los demás tipos de copias de seguridad.
Politicas de Backup- Tipos

8. confidencial
La mayor diferencia entre estas dos variedades de copia de seguridad es la cantidad de
información digital de la que hay que hacer una copia de seguridad, que puede calcularse en
función de la copia de seguridad completa o de la copia de seguridad anterior.
Si, por ejemplo, se hacen dos copias de seguridad incrementales sin que se modifique ningún
archivo, no habrá datos visibles en la segunda copia de seguridad.
Además, si se realizan dos copias de seguridad diferenciales de los mismos datos, ambas
serán idénticas. Igualmente, en caso de siniestro, las copias de seguridad diferenciales
permiten restaurar todos los datos en un tiempo relativamente corto, mientras que las copias
de seguridad incrementales requieren desde la última copia de seguridad hasta la primera
para restaurar completamente toda la información.
Diferencia entre Incremental y Diferencial

9. confidencial
Políticas de Backup- Tipos

10. confidencial
SQLInjection
Los ataques de inyección 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.

11. confidencial
SQLInjection

12. confidencial
Scripting entre sitios (XSS)
XSS ocurre cuando un atacante es capaz de inyectar un script, normalmente Javascript, en el
output de una aplicación web de forma que se ejecuta en el navegador del cliente. Los
ataques se producen principalmente por validar incorrectamente datos de usuario, y se suelen
inyectar mediante un formulario web o mediante un enlace alterado.

13. confidencial
Scripting entre sitios (XSS)
Las vulnerabilidades de scripting entre sitios 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.

14. confidencial
Scripting entre sitios (XSS)
XSS se puede utilizar de varias maneras para causar problemas graves. El uso tradicional de
XSS permite a un atacante robar las cookies de sesión, lo que le permite fingir ser el usuario
(víctima). Pero no se trata sólo de robar cookies; los atacantes pueden utilizar XSS para
propagar malware, desfigurar sitios web, crear problemas en las redes sociales, falsificar
credenciales y, junto con las técnicas de ingeniería social, perpetrar ataques más dañinos.
En resumen, el atacante consigue cargar código de script malicioso en el sitio web, que
posteriormente será servido a los usuarios y ejecutado en su navegador.

15. confidencial
Scripting entre sitios (XSS)

16. confidencial
Supongamos por ejemplo el siguiente formulario:
En el formulario hay una input text para datos de entrada y un botón de enviar. Una vez que el formulario sea enviado,
enviará los datos a post.php para procesarlos. Supongamos que lo único que se hará con los datos en post.php será
mostrarlos con un echo:
Sin ningún tipo de filtrado, el atacante puede enviar el siguiente script a través del formulario,
lo que generará un popup en el browser con el mensaje "Hacked".
El script anterior tan sólo envía un mensaje de alerta, pero con Javascript ya hemos visto que se pueden hacer
multitud de cosas que pueden dañar al usuario, especialmente relacionadas con el robo de cookies y sesiones.
Scripting entre sitios (XSS) - Ejemplo

17. confidencial
Scripting entre sitios (XSS) - Tipos de Ataques
Los ataques Cross-Site Scripting pueden agruparse en dos grandes categorías,
dependiendo de cómo envían el código malicioso:
● non-persistent XSS
● persistent XSS

18. confidencial
Scripting entre sitios (XSS) - Tipos de Ataques
non-persistent XSS
Los ataques non-persistent XSS o reflected XSS no almacenan el código malicioso en el
servidor sino que lo pasan y presentan directamente a la víctima. Es el método más popular de
ataque XSS. El ataque se lanza desde una fuente externa, mediante email o un sitio de
terceros.
persistent XSS
El código malicioso ya ha superado la barrera del proceso de validación y está
almacenado en un almacén de datos. Puede ser un comentario, un archivo log, un mensaje
de notificación, o cualquier otro tipo de sección del sitio web que solicita algún input al
usuario. Cuando esta información en particular se presenta en el sitio web, el código malicioso
se ejecuta.

19. confidencial
Scripting entre sitios (XSS) - Prevención
La regla o política más básica que ha de tenerse siempre en cuenta es simple: NUNCA
confíes de datos que vienen de usuarios o de cualquier otra fuente externa. Cualquier
dato debe ser validado o escapado para su output.
Las medidas a tomas se dividen en 3 :
● Data validation
● Data Sanitization
● Output escaping

20. confidencial
Scripting entre sitios (XSS) - Prevención
Data Validation
La validación de datos es el proceso de asegurarse
que tu aplicación analiza el tipo de datos correctos. Si tu script espera un integer de un input,
cualquier otro tipo de dato debe de rechazarse. Cada dato debe ser validado cuando se recibe
para asegurarse que es del tipo correcto, y rechazado si no pasa ese proceso de validación.

21. confidencial
Scripting entre sitios (XSS) - Prevención
Data Sanitization
La sanitización de datos se centra en manipular los
datos para asegurarse que son seguros, eliminando cualquier parte indeseable y
normalizándolos en la forma correcta. Por ejemplo, si se espera un texto string de los usuarios,
se debe evitar cualquier tipo de markup HTML
El método strip_tags eliminará todas las etiquetas html y php de una cadena de texto.
Le pasamos por parámetro la cadena y devuelve la misma cadena sin etiquetas, es decir, en
texto plano.

22. confidencial
Scripting entre sitios (XSS) - Prevención
Output Escaping
Para proteger la integridad de los datos que se
devuelven, el output data, se debe escapar cualquier dato que se devuelve al usuario. Esto
evita que el navegador malinterprete alguna secuencia especial de caracteres:
Esta función devuelve una cadena con dichas conversiones realizadas.
Esta función es útil para evitar que el texto entrado por el usuario contenga marcas HTML

23. confidencial
Scripting entre sitios (XSS) - Ejemplo de
Prevención
Mezclando un poco las tres formas de prevenir ataques XSS, vamos a ver un sencillo
sistema de comentarios:

24. confidencial
Scripting entre sitios (XSS) - Ejemplo de
Prevención
Primero nos aseguramos de que no se guardan comentarios vacíos. Después se sanitizan
los datos eliminando cualquier posible etiqueta HTML que pudiera contener. Finalmente, los
comentarios se devuelven filtrados. La función _striptags hace que no sea posible insertar
enlaces en los comentarios, ya que éstos utilizan una etiqueta que será eliminada. Para que
puedan insertarse se puede utilizar htmlentities o htmlspecialchars en su lugar.
Hay que tener en cuenta que ninguna solución es fiable al 100%, y que es conveniente estar
al tanto de novedades respecto a los ataques Cross-Site Scripting ya que van
evolucionando a medida que lo hacen las plataformas que los facilitan (navegadores,
HTML...).

25. confidencial