Seguridad en los sistemas web

SEGURIDAD
EN LAS APLICACIONES WEB.

SEGURIDAD
La seguridad de las aplicaciones web es una
rama de la Seguridad Informática que se
encarga específicamente de la seguridad de
sitios web, aplicaciones web y servicios web.
Las aplicaciones, comúnmente son
desarrolladas usando lenguajes de
programación tales como PHP, JavaScript,
Python, Ruby, ASP.NET, JSP, entre otros.

SEGURIDAD
En un alto nivel, la seguridad de aplicaciones
web se basa en los principios de la seguridad
de cualquier aplicación informática pero
aplicada específicamente a la World Wide
Web.
Debido al descuido en las buenas prácticas
de programación relacionadas con la
seguridad, muchos sistemas son vulnerables
a los ataques, incluyendo inyección SQL.

SEGURIDAD
La base de datos y la aplicación deben estar
protegidas para evitar daños a causa de
estas instrucciones maliciosas. Es necesario
comprender cómo se estructuran estas
instrucciones. Un sistema de web puede leer
la entrada del usuario de varias maneras
diferentes, basado en el entorno que se ha
desarrollado la aplicación.

SEGURIDAD
En la mayoría de los casos, el SQLIA (Ataque
de inyección SQL) viene en los envíos de
formularios que se envían al sistema web a
través de HTTP GET o POST. Los sistemas
web acceden a los datos de entrada del
usuario y logran acceder a cualquier otra
variable de entorno.

SEGURIDAD
Al introducir los códigos por el formulario, el
atacante tiene acceso a la zona restringida
de la página como un administrador
(normalmente el usuario administrador –
administrator - es el primer usuario de la
tabla de usuarios de la base de datos del sitio
y tiene todos los permisos). Al acceder al
sistema como administrador, tiene acceso a
los datos confidenciales, por lo que puede
utilizar estos datos de la manera que desee.

SEGURIDAD
Si el ataque es por URL el atacante utiliza
códigos maliciosos en la URL de acceso al
sistema para encontrar la información
contenida en la base de datos, por lo tanto, la
consecución de ambos descubren los datos
sensibles de los usuarios, así como tablas o
la destrucción de datos importantes.

AMENAZAS DE SEGURIDAD
Con la aparición de la Web 2.0, el
intercambio de información a través de redes
sociales y el crecimiento de los negocios en
la adopción de la Web como un medio para
hacer negocios y ofrecer servicios, los sitios
web son constantemente atacados.

La mayoría de los ataques a aplicaciones
web ocurren a través de:
 Cross-site scripting (XSS).
 Inyección SQL.
 Phishing.
Estos ataques logran su cometido debido a
una codificación deficiente y la falta de
desinfección de las entradas y salidas de la
aplicación web.

 Inyección SQL.
 Phishing
aplicación web.
Tipo de vulnerabilidad informática o agujero
de seguridad, que permitir a una tercera
persona inyectar en páginas web visitadas
por el usuario código JavaScript o en otro
lenguaje similar como VBScript.

 Inyección SQL.
 Phishing
aplicación web.
Existe en aplicaciones que presente
información en un navegador web u otro
contenedor de páginas web. Pueden ser sitios
web en línea o aplicaciones locales vulnerables
a XSS, incluso el mismo navegador.

 Inyección SQL.
 Phishing
aplicación web.
Usualmente causada al no validar
correctamente los datos de entrada que son
usados en cierta aplicación, o no sanear la
salida adecuadamente para su presentación
como página web.

 Inyección SQL.
 Phishing.
aplicación web.
 Directa (o Persistente): Consiste en
insertar código HTML peligroso en
sitios que lo permitan; incluyendo
etiquetas como <script> o <iframe>.

 Inyección SQL.
 Phishing
aplicación web.
 Indirecta (o Reflejada): Modifica valores que la
aplicación usa para pasar variables entre dos
páginas, sin usar sesiones y sucede por un
mensaje o ruta en la URL del navegador, en
una cookie, o cualquier cabecera HTTP (a
veces navegadores y aplicaciones web,
podría extenderse al DOM del navegador).

Cross-site scripting (XSS).
Un framework no actualizado, permite a los
atacantes explotar las vulnerabilidades de la
aplicación.
Otro ejemplo es cuando los datos y los
componentes estándar necesarios para la
instalación de una aplicación, base de datos
o componente son instalados
automáticamente y no son eliminados.

Un atacante podrá descubrir las páginas de
administración en el servidor y autenticarse
utilizando el usuario y contraseña estándar
de la instalación y tomar el control sobre la
aplicación o servidor.
cuando un listado de directorios no fuera
desactivado. Un atacante, podrá listar los
directorios de la aplicación y encontrar otras
vulnerabilidades.

Si el módulo de PHP está configurado para
mostrar errores, entregaría información
valiosas al atacante como el servidor y el
usuario:
Warning mysql_connetc()[function.mysql-
connect]: Access denied for user
'usuari'@'192.168.0.82'
(using password: YES) in
/www/html/web/admin.php on line 70

Si la directiva register_globals es on
(habilitada) la variable $autoriza podría ser
manipulada fácilmente. Si modifica el valor
en off, el código funcionaria correctamente
(libre de la vulnerabilidad). Otra forma sería
inicializar la variable antes de su uso, en este
caso el código funcionaría sin importar el
estado de register_globals.

 Otro caso es copiar en el value de una
etiqueta <input>. Por ejemplo en los
buscadores en sitios web, al realizar una
búsqueda a través de ellos, lo habitual es
que el término introducido se copie dentro
del campo del buscador.
 Otras veces puede copiar código dentro de
los comentarios HTML, comúnmente en
páginas mal programadas que dejan
mensajes dentro del código fuente HTML:
";alert("¡Hola Mundo!");//

 Para determinar si un campo, ya sea un
parámetro desde la URL o un campo de
texto donde sea posible escribir, es
vulnerable a XSS introduzca una serie de
caracteres para comprobar si existe algún
filtro anti-XSS. Los caracteres a introducir
serían:

 Comilla simple (‘)
 Comilla doble (“)
 Símbolo de mayor que (>)
 Símbolo de menor que (<)
 Barra (/)
 Espacio ( )

Si puede introducir estos caracteres existe un
alto porcentaje de posibilidades de encontrar
algún fallo de XSS. Sin embargo no se puede
asegurar su existencia de forma totalmente
definitiva, siempre existe la posibilidad de
encontrar algún otro tipo de filtro que impida
introducir palabras clave como script, onload
o javascript.

Se declara una variable d que contiene los
valores &to, &enviar y &mensaje, que son las
variables que se envían en la aplicación cuando
manda un mensaje. Detalle importante a
observar es el contenido de la variable &mensaje,
document.cookie, un objeto del DOM de la
página que contiene todas las cookies asociadas
al dominio actual.

Se codifica un if...else, que asegura la creación
de un objeto de tipo XMLHttpRequest tanto en
navegadores Internet Explorer como Firefox o
similares. Este objeto es el usado para realizar
las peticiones AJAX.
Con open() se establece las condiciones que se a
utilizarán para enviar el formulario. Será enviado
por POST a la url func/send.php. Mediante true
se indica que la petición será realizada de
manera asíncrona, esto es, el navegador no se
quedará “congelado” mientras se envía el
mensaje.

El llamado a la función setRequestHeader() se
usan para establecer cabeceras HTTP que hagan
que el servidor web entienda que lo que se está
enviando es un formulario, aunque el usuario no
lo haya rellenado.
Se invoca send() pasándole como parámetro la
variable d. Con esto el navegador realiza las
acciones definidas anteriormente y, si todo ha
salido bien, el usuario afectado “enviará” su
cookie de sesión.

 Inyección SQL.
 Phishing.
aplicación web.
Método de infiltración
de código intruso que
usa una vulnerabilidad
informática presente
en una aplicación en
el nivel de validación
de las entradas para
realizar operaciones
sobre una base de
datos.

 Inyección SQL.
 Phishing.
aplicación web.
Su origen radica en la
incorrecta comprobación
o filtrado de las variables
usadas en un programa
que contiene, o bien
genera, código SQL.

 Inyección SQL.
 Phishing.
aplicación web.
Ocurre cuando se
inserta o "inyecta"
código SQL invasor
dentro del código SQL
programado, para
alterar el funcionamiento
normal del programa y
lograr así que se ejecute
la porción de código
"invasor" incrustado, en
la base de datos.

 Inyección SQL.
 Phishing.
aplicación web.
try
{$dbh = new PDO($dsn, $user,
$password);}
catch (PDOException $y)
{$log = $y->getMessage();
/* grabar el log */}
$login = $_POST['login'];
$contrasenia = $_POST['contrasenia'];
$sth = $dbh->prepare("SELECT * FROM
usuarios “ . "WHERE login = login AND
contrasenia = :contrasenia");
$sth->bindParam(':login', $login);
$sth->bindParam(':contasenia',
$contrasenia);
$sth->ejecute();
if( $sth->rowCount() )
echo "resultado: true";
else
echo "resultado: false";

 Inyección SQL.
 Phishing.
aplicación web.
$login = $_POST['login'];
$contrasenia=$_POST[‘contrasenia’];
$query = array();
$query[] = "CALL testarLogin(@valor,
" $login."', " $contrasenia."')";
$query[] = "SELECT @valor";
$mysqli->query($query[0]);
$res = $mysqli->query($query[1]);
$valor = $res->fetch_object();
$nombre = "@valor";
if( $valor->$nombre )
echo "resultado: true";
else
echo "resultado: false";
$mysqli->close();
?>

 Inyección SQL.
Una aplicación cifra los datos de las tarjetas
de créditos en una base de datos para
prevenir que los mismos sean expuestos a
usuarios finales. Sin embargo, la base de
datos está configurada para descifrar
automáticamente consultas en las columnas
de tarjetas de crédito, permitiendo que un
fallo de inyección por SQL pueda listar todas
las tarjetas de crédito en claro.

 Inyección SQL.
El sistema debería haber sido configurado
para permitir que sólo las aplicaciones de
back-end pudieran descifrar esos datos y no
las aplicaciones web de front-end.

 Inyección SQL.
En una aplicación web PHP, la transferencia
por GET pasa parámetros vía url:
http://www.dominio.com/[nombre_pagina].
php?[nombre_variable]=[valor]
Después del “ ?” hay una variable con su
valor, que fue consultado en la base de
datos, está explícito en la URL, entonces,
podría retornar datos de la base de datos con
la agrupación de comandos SQL.

 Inyección SQL.
Consultar los detalles de un producto desde:
http://www.dominio.com/detalles.php?pro
ducto_id = 158
Éste probablemente tendrá un código PHP
que recibirá un valor en una variable:
$id = $_GET[“ id” ];
Ese valor sería pasado a otra variable que
contenga el código que será responsable de
la consulta SQL, como por ejemplo:

 Inyección SQL.
$query = mysql_query(?SELECT * FROM
producto WHERE producto_id = “ $id’” );
$query recibe la ejecución de la consulta en
el MYSQL, la cual selecciona todos los
registros de la tabla producto con producto_id
igual al valor de $id. Consulta que se ejecuta
explícitamente en el código, exponiendo la
vulnerabilidad del sistema y arriesgando la
base de datos.

 Inyección SQL.
http://www.dominio.com/detalles.php?product
o_id = 1’
Si se insertan ‘(comillas simples) al final de la
url y la página retornar un error diciendo: “
You have an error on your SQL syntax ;
check the manual that corresponds to your
MYSQL server version for the’”, significa que
es vulnerable.

 Inyección SQL.
Considerando la url anterior, se agrupará un
comando para la verificación de la cantidad
de columnas existentes en la tabla. Con
ORDER BY, es posible especificar cualquier
número de columnas
http://www.dominio.com/detalles.php?product
o_id = 1’ ORDER BY 1,2,3,4 (...).

 Inyección SQL.
Probando desde 1 hasta n, cuando en “ n”
sucede un error, se obtiene la información n-
1 que se refiere al número de columnas de la
tabla consultada, en el caso que el número
sea 5, si sucede el error, el valor
correspondiente al número de columnas que
pueden ser usadas por los demás comandos
será 4.

 Inyección SQL.
Con la función UNION los ataques son lo
suficientemente eficaces para retornar datos,
es posible entonces retornar el conjunto de
registros de la base de datos con:
ducto_id =1 UNION ALL SELECT 1,2,3,4

 Inyección SQL.
Por ello, @@version es capaz de informar
sobre la versión del sistema gestor de bases
de datos, para así usar la sintaxis correcta:
ducto_id =1 UNION ALL SELECT 1, 2, 3,
@@version

 Inyección SQL.
ducto_id =1 UNION ALL SELECT 1, 2, 3,
column_name from
information_schema.columns—
Lo anterior devolverá el nombre de las
columnas y tablas del esquema principal de
la base de datos.

 Inyección SQL.
Si los privilegios de usuario no están
configurados correctamente, el atacante
conseguirá retornar los nombre de tablas y
columnas y así hacer la selección de los
datos que necesitará para proseguir con la
inyección SQL.

 Inyección SQL.
Para que finalmente sean retornados los
datos necesarios para acceder al sistema y
también modificar la base de datos, el
atacante hará una nueva secuencia de
comandos, donde podrá obtener los nombres
de usuarios, contraseñas y datos de otras
tablas que componen el esquema que está
siendo atacado.

 Inyección SQL.
Para retornar los datos de la tabla usuario,
como ejemplo, utilizan los códigos siguientes,
y si logran tener éxito, el atacante conseguirá
manipular el sistema y la base de datos, con
libre acceso y más intenciones.

 http://www.dominio.com/detalles.php?pr
oducto_id =1 UNION ALL SELECT 1, 2, 3,
column_name from
information_schema.column WHERE
table_name=’usuario’—
concat(username,0x 8b,password)from
admin/*
oducto_id=1/**/union/**/all/**/select/**/0x
76,concat_ws(0x
8b,username,password),44/*-
column_name from
information_schema.column WHERE
table_name=’usuario’—
concat(username,0x 8b,password)from
admin/*
oducto_id=1/**/union/**/all/**/select/**/0x
76,concat_ws(0x
8b,username,password),44/*-

 Inyección SQL.
 Phishing.
aplicación web.
Conocido como suplantación
de identidad, es un modelo
de abuso informático que se
comete mediante el uso de
un tipo de ingeniería social,
caracterizado por intentar
adquirir información
confidencial de forma
fraudulenta.

Una página es vulnerable a XSS cuando
aquello que se le envía al servidor (un
comentario, un cambio en un perfil, una
búsqueda, etc.) se ve posteriormente
mostrado en la página de respuesta.

Esto es, cuando se escribe un comentario en
una página y puede leer posteriormente el
mensaje, modifica su perfil de usuario y el
resto de usuarios puede verlo o se realiza
una búsqueda y se muestra un mensaje: “No
se han encontrado resultados para <texto>”,
se está incluyendo dentro de la página el
mismo texto que nosotros hemos introducido.

Una vez detectada una zona de la aplicación
que al recibir texto procedente del usuario lo
muestra en la página, es el momento de
determinar si es posible utilizar esa zona
como punto de ataque de XSS.
Para ello es posible insertar un pequeño
código Javascript que muestra un mensaje
de alerta para descubrir rápidamente si se
está actuando en la línea correcta de ataque.

Determinados filtros Anti-XSS pueden
imposibilitar el uso de ciertos caracteres a la
hora de introducir el código Javascript. Por
ejemplo, las comillas dobles o los caracteres
de “mayor que” y “menor que” suelen estar
prohibidos.

Categorías para fallos de XSS:
 Permanentes: Su denominación se debe al
hecho de que queda almacenada en algún
lugar, habitualmente una base de datos
SQL, y se va a mostrar a cualquier usuario
que visite el sitio.
 No permanentes: se introduce como
<texto> el código Javascript. La diferencia
es que en esta ocasión los efectos de la
acción no son permanentes.

Un ataque de XSS puede tomar el control
sobre el navegador del usuario afectado y
realizar acciones en la aplicación web.
Si se ha logrado que un usuario
administrador ejecute un Javascript, las
posibilidades de actuación maliciosa son muy
superiores.
Sería posible borrar todas las noticias de una
página o generar una cuenta de
administrador con los datos encontrados.

Haciendo uso de las técnicas de phishing,
mediante Javascript, podría modificar el
comportamiento y la apariencia de una
página web.
Esto permite crear un formulario de login
falso o redirigir el submit de uno existente
hacia un dominio controlado por otro servidor.

Es posible realizar un ataque de
denegación de servicios distribuidos
(distributed dennial of services, DDoS).
Para ello se forzará mediante código
Javascript que los navegadores hagan uso
intensivo de recursos muy costosos en
ancho de banda o capacidad de
procesamiento de un servidor de forma
asíncrona.

Un gusano XSS es un código Javascript que se
propaga dentro un sitio web o entre páginas de
Internet aprovechando un fallo XSS en la
descripción personal de los usuarios de una
red social.
En esta situación un usuario malintencionado
podría crear código Javascript para copiar el
código del gusano al perfil del usuario que
visita otro perfil infectado y que adicionalmente
realizase algún tipo de modificación en los
perfiles afectados.

Las únicas limitaciones la constituye la
imposibilidad de ejecutar código fuera del
navegador, dado que el ambiente sobre el que
se ejecuta no permite el acceso a ficheros del
sistema, y a las propias funcionalidades que
ofrezca el sitio web objeto del posible ataque.

TECNOLOGÍA DE SEGURIDAD.
Mientras que la seguridad se basa
fundamentalmente en las personas y los
procesos, existen varias soluciones técnicas
a considerar cuando se diseña, construye y
prueban aplicaciones web seguras. A un alto
nivel incluyen:

Soluciones de alto nivel son:
 Black box.
 White box.
 Fuzzing.
 Escáner de seguridad de aplicaciones web
(escáner de vulnerabilidad.)
 Firewalls de aplicación web (WAF.)
 Cracking de contraseña.

 Black box.
 White box.
 Fuzzing.
Herramientas de pruebas:
 Escáneres de seguridad de
aplicaciones web.
 Escáneres de vulnerabilidad
 Software de prueba de
penetración.

 Black box.
 White box.
 Fuzzing.
Herramientas de pruebas:
 Analizadores estáticos
de código fuente.

 Black box.
 White box.
 Fuzzing.
Herramientas utilizadas
para pruebas de entrada.

Fuzzing es una técnica de pruebas de
software, a menudo automatizado o
semiautomatizado, que proporciona datos
inválidos, inesperados o aleatorios a las
entradas de un programa de ordenador.
Entonces se monitorean las excepciones
como caídas, aserciones de código erróneas,
o para encontrar potenciales filtraciones de
memoria.

DESARROLLO SEGURO.
El DBA es el responsable superior de
declarar las reglas dentro del SGBD. Este es
el responsable de conceder o eliminar
privilegios, crear o excluir usuarios, y atribuir
de un nivel de seguridad a los usuarios del
sistema, de acuerdo con la política de la
empresa.

DESARROLLO SEGURO.
El control de flujo de la información es un
mecanismo que previene que la información
fluyan por canales secretos y violen la
política de seguridad al alcanzar usuarios no
autorizados. Este regula la distribución o flujo
de información entre objetos accesibles.

DESARROLLO SEGURO.
Un flujo entre el objeto A y el objeto B sucede
cuando un programa lee valores de A y
escribe valores en B. Los controles de flujo
tienen la finalidad de verificar si las
informaciones contenidas en algunos objetos
no fluyen explícita o implícitamente hacia
objetos de menor protección.
De esa manera, un usuario no puede obtener
indirectamente en B aquello que este o esta
no pueda obtener directamente de A.

DESARROLLO SEGURO.
La codificación de datos es una medida de
control final, utilizada para proteger datos
sigilosos que se transmiten por medio de
algún tipo de red de comunicación. También
se puede usar para ofrecer protección
adicional para que partes confidenciales de
una base de datos no sean accedidas por
usuarios no autorizados.

DESARROLLO SEGURO.
Para eso, los datos están codificados a
través de algún algoritmo de codificación.
Así, un usuario no autorizado tendrá una
gran dificultad para descifrarlos, pero los
usuarios autorizados recibirán claves para
descifrar esos datos.
La criptografía permite disfrazar el mensaje
para que, aún con el desvío de la
transmisión, el mensaje no sea revelado.

DESARROLLO SEGURO.
Gestionar usuarios y al esquema de la base
de datos donde cada base de datos tiene una
lista de nombres de usuarios. Deben estar
implementados diferentes perfiles de usuario
para diferentes tareas en la base de datos,
con el enfoque que cada aplicación o usuario
tiene su necesidad de acceso. Puede
proteger los perfiles con contraseña, y
además usar cotas para restringir el espacio
en el disco que será utilizado por los usuarios
o aplicativos.

DESARROLLO SEGURO.
Método de acceso y seguridad multinivel,
donde el usuario no tiene un término medio.
Tiene o no privilegios. Normalmente usado
en BD que clasifican datos de usuarios,
donde es necesario un nivel más de
seguridad.
Se utiliza en sistemas gubernamentales,
militares o de inteligencia, así como
industriales y corporativas.

DESARROLLO SEGURO.
Acceso basado en roles, donde estos son
creados de acuerdo con los diferentes cargos
en una organización y los usuarios están
asociados a roles según sus
responsabilidades y cualificaciones.
Se pueden designar varios individuos a un
mismo rol. Los privilegios de seguridad
comunes a un rol se conceden a su nombre y
cualquier individuo designado para ese rol
automáticamente los tendrá. Los usuarios
pueden moverse fácilmente de un rol a otro.

DESARROLLO SEGURO.
Los usuarios pueden moverse fácilmente
entre roles. Los cambios en los entornos
computacionales, la instalación de sistemas y
eliminación de aplicaciones antiguas,
modifican sólo el conjunto de permisos
atribuidos a los diferentes roles, sin
afectarlos.
La separación de tareas es un requisito
importante. La exclusión mutua de roles es
un método que puede implementarse.

DESARROLLO SEGURO.
Control de acceso utilizando triggers para
crear mecanismos de seguridad más
complejos que pueden ser disparados cada
vez que se llama un evento o que pueden ser
disparados antes o después del comando
especificado con el objetivo de proveer
mayor rigor en el control de la seguridad.
Si el comando ejecutado por el usuario no es
validado por los Triggers, se activa un error
para impedir modificaciones indebidas.

DESARROLLO SEGURO.
SELECT * FROM Usuario WHERE
usu_usuario = '" $login."' AND
usu_contrasenia = '" $contrasenia."';
Cuando se utiliza la política de seguridad de
insertar todas las consultas en STORED
PROCEDURES, la ejecución se limitará al
objeto de la base de datos, es decir, no existe
una consulta directa a la base de datos por
parte del sistema.

DESARROLLO SEGURO.
El objeto STORED PROCEDURE crea un
filtro entre la consulta y la base de datos. En
la estructura del STORED PROCEDURE,
existe la consulta, pero la codificación de
esta no está explícita en el código del
sistema y, así, se realiza una llamada al
objeto pasando hacia este los valores de las
variables de entrada:

DESARROLLO SEGURO.
CALL
TCC_Usuario_SELECT('".$usuario."',"
$contrasenia."')
Usando este código, tanto los ataques vía
formularios de credenciales como también
vía URL quedarán prevenidos, protegiendo
así la base de datos y sus registros.

DESARROLLO SEGURO.
Con view es posible permitir acceso, conceder
privilegios, ocultar líneas y columnas de
información confidenciales o restringir en la
tabla original. Los privilegios y concesiones
están definidos en la vista y no afectan a la
tabla base, estando el acceso de los usuarios
delimitado por la vista, la cual se genera
creando un subconjunto de datos en la tabla
referenciada. La opción With Verification da
mayor seguridad porque no permite modificar la
tabla sin tener los privilegios dentro de la vista.

BIBLIOGRAFÍA.
Desarrollo seguro de
aplicaciones web.
Ariel Ayala Montes.
2014

Puede interesar que los elementos de
una lista estén ordenados: una vez
que finalizó la inscripción en un curso,
tener a los listados de los alumnos por
orden de llegada puede ser muy
incómodo, siempre será preferible
tenerlos ordenados por número para
realizar cualquier comprobación.
Se obtiene una referenc
<section> en el docum
contenido con un eleme
ahí, el usuario solo verá
la pantalla.
Se obtiene una ref
elemento <section> e
reemplaza su contenid
<p>. A partir de ahí, el
elemento <p> en la pan

Seguridad en los sistemas web

Más contenido relacionado

La actualidad más candente

Similar a Seguridad en los sistemas web

Más de Facultad de Ciencias y Sistemas

Último

Seguridad en los sistemas web