Blog

VULNERABILIDADES DE APLICACIONES WEB: LA IMPORTANCIA DE CONOCER EL FUNCIONAMIENTO DEL NAVEGADOR

14.01.2018 23:44
A medida que los programadores previenen mejor las inyecciones de HTML, los hackers buscan lugares menos obvios donde inyectar código, por ejemplo entre las etiquetas <title></title> de la parte superior del archivo .html, delimitada por las etiquetas <head></head> .
 
Vemaos el siguiente ejemplo:
 
El archivo adelante.html es el siguiente:
 
<html><head></head>
<body>
<body>
   <form method="get" action="atras.php">
        Ingrese el término a buscar: <input type="text" name="buscar">
        <input type="submit" name="subir_btn" value="Enviar" />
   </form>
</body>
</html>
 
siendo atras.php
 
<html>
<head>
<title><?php echo $_GET['buscar']; ?></title>
</head>
<body>
Búsqueda: <?php echo strip_tags($_GET['buscar']); ?>
</body>
</html>
 
Veremos que si ingresamos un término en "adelante.html", el mismo se verá reflejado en el cuerpo de "atras.php" como también en su título. 
Si en la casilla de búsqueda "adelante.html" ingresamos los siguiente:
 
"</title></h1>Esto está siendo inyectado en el cuerpo del archivo</h1>", veremos que efectivamente aparecerá en el cuerpo del archivo. ¿Por qué? Al cerrar el título con la etiqueta </title> y al añadir <h1>texto</h1> estaremos incrustando código HTML malformado entre las etiquetas <head></head>. Entre las mismas sólo son aceptadas las siguientes etiquetas: <title>; <base>; <link>; <style>; <meta>; <script>: <noscript>; <command> y sus respectivas etiquetas de cierre. El navegador intentará subsanar la malformación de código imprimiendo todo en el cuerpo del mensaje, que es donde aparecerá la inyección HTML.
 
Hemos probado el ataque en tres navegadores diferentes y funcionó igual en todos. Claro que se podría inyectar código desde el título al cuerpo del mensaje incluso sin la característica del navegador mencionada pero quisimos resaltar la importancia de conocer todo el entorno de la aplicación web, no sólo la aplicación propiamente dicha.
 
El ataque se previene usando strip_tags() también en el título, no solo en el cuerpo del archivo.
 

¿INSENSATEZ O PERVERSIDAD? EL REINO UNIDO BASARÁ SU DEFENSA EN CUATRO SSBN

14.01.2018 23:35
En artículos muy recientes hemos escrito sobre el desatino que significababa para la defensa del Reino Unido de Gran Bretaña seguir avanzando con el programa de los submarinos SSBN Dreadnought, reemplazantes de la Clase Vanguard. También informábamos que los británicos no descartan emplear el segundo portaaviones Clase Queen Elizabeth como fuente de repuestos para su buque gemelo. De hecho en la Royal Navy la canibalización se volvió una práctica usual y creciente. Además se convirtió en una suerte de metáfora de la realidad de la Marina Real británica. Se quita de una lado para tapar agujeros en otro lado a un costo muy superior al que tendría el reemplazo con piezas surgidas de una producción para la Defensa planificada.
 
Los rumores de nuevos recortes en las fuerzas armadas británicas no son algo totalmente nuevo ni inesperado, pero los últimos que circulan alarman a los especialistas del Reino Unido. Al parecer existen diferentes proyectos para tapar el rojo fiscal del área de Defensa y los más drásticos estarían previendo una reducción temeraria del Ejército Británico. Algunos hablan de llevarlo a una cifra de apenas 50.000 efectivos. También prevén la reducción en el número de marinos e infantes de marina e incluso de miembros de la Real Fuerza Aérea. Se habla de fusión de Royal Marines con unidades de paracaidistas del ejército. Al parecer hasta nos quedamos cortos cuando informamos que la Royal Navy se desharía de hasta nueve buques. Buscando confirmar los rumores mencionados hemos logrado dar con declaraciones de parlamentarios británicos que permiten suponer que son ciertos.
 
En tiempos normales eso podría ser visto como un hecho positivo. La vieja Inglaterra colonialista (todavía tiene en su poder enclaves coloniales como el de Malvinas) estaría reduciendo sus fuerzas a un nivel de disuación creíble. El problema son la situación mundial y el tipo de reducción. Recortar indiscriminadamente fuerzas convencionales para concentrar el esfuerzo financiero en cuatro SSBN seguramente no significa una contribución a la paz mundial. Con Corea del Norte haciendo amenazas a diestra y siniestra, con el fortalecimiento chino tanto en lo económico como en lo militar, con Rusia mostrando su propia vieja garra imperialista, con el avance del terrorismo internacional (surgido muchas veces de grupos inicialmente finaciados por países occidentales), con el surgimiento de nuevas potencias militares como lo son, por ejemplo, India y Paquistán, lo que están haciendo los británicos oscila entre lo insensato, lo perverso y lo demencial. 
 
Artículos relacionados:
 

LA EMPRESA: LAS QUEJAS DE LOS CLIENTES SON UNA OPORTUNIDAD DE MEJORAR

12.01.2018 19:40
En algún momento todo negocio que brinda algún tipo de servicio o realiza ventas de productos, recibe quejas de manera verbal o escrita por parte de sus clientes, ya sea porque estos productos no llenaron sus expectativas o porque buscan mejores experiencias de atención.
 
Saber escuchar, analizar y manejar estas situaciones se convierte en oportunidades para las empresas, porque les hacen notar en qué están fallando y cómo pueden mejorar; asimismo, una solución inmediata y que agrade al cliente reafirma  y mejora su relación con la empresa.
 
Por otro lado también es bueno estar atento a estas quejas y reclamaciones, porque un cliente insatisfecho no sólo hace su queja de manera formal y escrita, sino que utiliza la tecnología  de manera masiva mediante la web y puede crear una mala reputación y afectando de manera directa al negocio.
 
La comunicación personalizada con estos clientes insatisfechos, ofreciendo disculpas y soluciones, nos permite medir y resolver el grado del problema.
 
Como dijimos anteriormente, estás quejas son oportunidades para corregir y mejorar, por lo tanto si se detectan y se aplican las medidas correctivas el negocio está en proceso de crecimiento. Además mejorar nos hace sentir que realmente estamos prestando un servicio, no sólo vendiendo un producto.
 
Artículos relacionados:
 

VULNERABILIDADES DE APLICACIONES WEB: FUNCIONALIDADES OLVIDADAS Y FUNCIONALIDADES OCULTAS

12.01.2018 09:19
En el presente capítulo nuevamente alteraremos un poco la taxonomía clásica de las vulnerabilidades de las aplicaciones web, simplemente para fusionar dos en una.
 
Supongamos que tenemos el archivo adelante.html con el siguiente código:
 
<html>
<body>
<h1>Bienvenido</h1>
<form action="atras.php" method="get"><br>
<input type="text" name="usuario"><br>
<input type="password" name="clave"><br>
<input type="submit"><br>
</form>
</body>
</html>
 
siendo atras.php:
 
<?php
error_reporting(0);
$debugger = $_GET['debugger'];
if (isset($debugger)) { 
    header("Location:debugger.php");
    exit;
} elseif (($_GET['usuario'] == "Juan") && ($_GET['clave'] == "clave12345")) {
    echo "Bienvenido a nuestro sitio";
} else {
    header("Location:principal.htm");
}
/* ¡Cuidado, el código fue simplificado para facilitar su comprensión. No use combinaciones usuario/contraseña incrustadas en el programa, mucho menos en texto plano! */
?>
 
y debugger.php:
 
<?php
echo "Bienvenido al debugger";
$archivo = $_GET['archivo'];
echo file_get_contents($archivo);
?>
 
Vemos que por olvido o intencionalmente el programador dejó en la aplicación una porción de código por medio de la cual puede acceder a una página desde cual puede ver el contenido de diferentes archivos sin necesidad de autenticarse:
 
https://127.0.0.1/codigo-olvidado/atras.php?debugger=1
 
Si un usuario malicioso la encuentra y sabe explotarla tendrá una especie de puerta trasera que le permitirá planear ataques con mayor facilidad.
 
Las funcionalidades olvidadas (a menudo llamadas "sobrantes") u ocultas pueden tener un matiz totalmente diferente a la del ejemplo presentado arriba. Pueden contener una sorpresa del estilo "huevo de Pascua", un juego o código lisa y llanamente malicioso. Sean maliciosas o no y por razones que exceden el alcance de este artículo, las mismas constituyen un problema de seguridad.
 

VULNERABILIDADES DE APLICACIONES WEB: PRESENCIA DE DIRECCIONES DE CORREO ELECTRÓNICO EN EL SITIO WEB

11.01.2018 17:33
La presencia de direcciones de correo electrónico en una página web puede considerarse una vulnerabilidad y habitualmente el riesgo que constituye se clasifica como leve. 
 
Las direcciones de correo electrónico pueden ser usadas para el envío de spam; para hacer inteligencia previa en preparación de un ataque, en especial para todo tipo de ataques de phishing y para intentar ataques por diccionario y/o fuerza bruta contra la propia casilla de correo.
 
Como el lector habrá podido observar, en nuestra página hay una dirección de correo electrónico que es el medio por el cual nuestro lectores pueden contactarnos, por lo que álguien podría decir que deberíamos predicar con el ejemplo. El hecho es que si en lugar de una dirección de correo electrónico habilitáramos una sección de comentarios, los mismos serían publicados automáticamente, con lo que no podríamos evitar el spam. Lo ideal sería tener una sección de comentarios donde cada uno pudiera ser aprobado antes de ser publicado en la página, lo cual de momento está fuera de nuestro alcance. Por mucho que se diga lo contrario, frecuentemente los comentarios terminan siendo filtrados manualmente.
 
Por lo expuesto en el párrafo de arriba terminamos optando por la dirección de correo electrónico, el cual es revisado y abierto personalmente por el autor del presente artículo. Debemos admitir que el spam ("correo basura") es mucho como también son unos cuantos los mensajes de phishing. Bloqueamos sistemáticamente ese tipo de mensajes y el número de direcciones bloqueadas es importante. Cada administrador deberá implementar la forma más conveniente y segura de manejar los mensajes de los lectores de acuerdo a su entorno de trabajo. El spam en los comentarios es muy molesto y desluce la página. En GEOESTRATEGIA hemos optado por una única dirección de correo electrónico. Eso sí, nuestra contraseña es larga y compleja.
 
Para quien guste comunicarse con nosotros nuestra dirección de contacto es: luis_lavric@hotmail.com
 
 
 

LOS BRITÁNICOS PODRÍAN USAR EL PORTAAVIONES HMS PRINCE OF WALES COMO FUENTE DE REPUESTOS

11.01.2018 17:12
Quien sostenga que el problema de la canibalización dentro de la Royal Navy es una cuestión sin importancia se equivoca. La misma alcanza a naves de superficie, submarinos y aeronaves.
 
Damos un ejemplo que grafica a las claras la gravedad de los hechos: la construcción del tercer submarino Clase Astute, el HMS Artful, se vio retrasada por 42 días porque otros submarinos fueron dotados de partes clave del mismo. No estamos hablando del último submarino de la clase, estamos refiriéndonos al tercero. La clase Astue ya acumula tantas demoras que el hecho de que en su momento se haya perdido un mes y medio por una cuestión de canibalización convierte al episodio en uno de gravedad, en especial teniendo en cuenta el estado del Servicio Silencioso británico.
 
El golpe de gracia lo dio lo declarado ayer por el Secretario Permanente del Ministerio de Defensa británico, Stephen Lovegrove, quien dijo que no descartaría la idea de que el equipamiento del portaaviones HMS Prince of Wales sea reubicado en el portaaviones HMS Queen Elizabeth. Lovengrove hizo la afirmación en respuesta al parlamentario por Portsmouth South, Stephen Morgan, quien exigió respuestas sobre la eventual canibalización naval del segundo portaaviones de la clase. 
 
Morgan exresó hoy en su cuenta de Facebook que ha "presionado a los funcionarios del gobierno sobre los nuevos portaaviones y otros buques complejos" inquiriendo sobre "qué será necesario para mantenerlos en servicio y asegurar el mantenimiento y apoyo que necesitarán". El parlamentario quiere asegurarse "que la Royal Navy y otras fuerzas tengan el apoyo para planificar adecuadamente" cualquier efecto de eventuales canibalizaciones en el largo plazo. Con eso está admitiendo de que el hecho es prácticamente inevitable y que sólo busca minimizar los daños. 
 
Lo curioso es que el mayor porcentaje de canibalización no se da en los buques más antiguos de la Marina Real sino en los destructores Type 45 y en los submarinos Clase Astute. La línea logística de la Royal Navy deja mucho que desear y eso afectaría seriamente su capacidad de respuesta en caso de un conflicto de importante.
 
Artículo relacionado:
 

VULNERABILIDADES DE APLICACIONES WEB: ALMACENAMIENTO CRIPTOGRÁFICO INSEGURO

11.01.2018 07:04
Cuando hablamos de almacenamiento criptográfico inseguro más que de una vulnerabilidad hablamos de una categoría de vulnerabilidades que engrupa toda una serie de ellas. La falta de encriptamiento de información sensible, el uso de un método criptográfico débil o inadecuado, el uso de un algoritmo criptográfico riesgoso y la falta de uso de sal o semilla (salt) para la generación de hashes son algunas de las vulnerabilidades puntuales englobadas en esta categoría.
 
Todos los años millones y millones de combinaciones de usuario/contraseña, grandes cantidades de información financiera, médica y de otro tipo son robados de diferentes bases de datos y sorprendentemente muchas veces todo eso está guardado en texto plano o débilmente encriptado. Los datos de tarjetas de crédito se venden en los circuitos criminales a valores irrisoriamente bajos. No obstante los hechos descriptos, al año siguiente la historia se repite.
 
Si almacenamos información sensible en nuestro servidor web debemos hacernos algunas preguntas:
 
- ¿Es necesario almacenar esa información?
- ¿Es necesario almacenarla en el servidor?
- ¿Es necesario almacenarla en el servidor en un directorio accesible a todos los que usan la aplicación? (con eso también nos referimos a información guardada bajo la protección de contraseñas. La más de las veces será sólo cuestión de tiempo para el hacker burlar esa protección).
- ¿Está encriptada?
- ¿Está encriptada con un algoritmo criptográfico seguro?
- Si hemos convertido datos en hashes, ¿hemos agregado la sal antes de encriptar? 
- ¿La sal agregada es la misma para cada dato encriptado?
- Aún cuando la sal agregada no fuera la misma, ¿se puede deducir o averiguar con qué patrón varía? Lo ideal es que sea generada "al azar", con una entropía tal que no permita deducirla con facilidad. 
 
Hemos hecho sólo algunas de las preguntas más elementales que hay que hacerse, de acuerdo al tipo de información almacenada y al lugar y forma de almacenamiento cada uno deberá hacerse otras más. La seguridad física del lugar de almacenamiento no puede ser una cuestión anecdótica. Protegemos nuestras casa con cerraduras, rejas metálicas, alarmas, perros, cámaras de seguridad, etc. ¿Por qué no protegemos mejor los datos? Hace tiempo que proteger la información, propia o ajena, dejó de ser un lujo, se ha convertido en una necesidad imperiosa. 
 

LA EMPRESA: PARA SER UN BUEN LÍDER HAY QUE SABER ESCUCHAR

10.01.2018 19:50
Además de fomentar la buena comunicación en una organización es muy importante saber escuchar a los propios colaboradores y prestarles atención. De esta manera se entenderán mejor el entorno y los acontecimientos que tienen lugar en la empresa y por ende se podrá ofrecer soluciones a problemas, se podrá negociar, mediar y propiciar un mejor ambiente de trabajo.
 
Un buen jefe debe estar atento a lo que sucede dentro de su área y prestar atención. Después de tomar conocimiento de las distintas dificultades debe analizar y ver la solución que se le puede dar a cada tema, esto le permitirá entender mejor su entorno y conocer a su personal. Así propiciará que su área se desarrolle mejor y que mejore el funcionamiento de la empresa.
 
También es muy importante saber escuchar a los clientes cuando manifiestan quejas y comentarios sobre productos y servicios que la firma ofrece. En Perú, donde funciona nuestra empresa, por normas de Indecopi (Instituto Nacional de Defensa de la Competencia y de la Protección de la Propiedad Intelectual) se debe responder y dar solución en plazos determinados. Si vemos estas quejas desde el ángulo del cliente podemos ver en qué podemos y debemos mejorar, entonces, si somos positivos y respondemos activamente, creamos soluciones en beneficio de la empresa.
 
Artículos relacionados:
 

UN GENERAL DE LA FUERZA AÉREA ES EL NUEVO MINISTRO DE DEFENSA DE PERÚ

10.01.2018 10:28
El Teniente General en retiro de la Fuerza Aérea del Perú Jorge Kisic Wagner juró ayer como nuevo ministro de Defensa del país andino. Lo hizo en reemplazo del sociólogo y político Jorge Nieto Montesinos quien renunció a su cargo después que el presidente Pedro Pablo Kuczynski indultara al ex presidente Alberto Fujimori.
 
Kisic es un hombre profesionalmente muy bien preparado y con una vasta experiencia que sirve de aval al cargo que acaba de asumir. Fue Comandante de Operaciones de la FAP en el año 2001; jefe del Estado Mayor General de la Fuerza Aérea entre el 2001 y el 2002; asesor de la Dirección General de Aeronáutica Civil en el año 2010 e Inspector General del Ministerio de Defensa de Perú en el 2011. Es graduado del Programa de Alta Dirección de la Universidad de Piura, institución académica que participa de diferentes proyectos de modernización de equipos militares.
 
El flamante ministro también ocupó un par de agregadurías militares, fue Comandante del Grupo de Fuerzas Especiales de la FAP, Director de la Escuela Superior de Guerra Aérea y Presidente de la Federación Peruana Aerodeportiva. 
 
Según consta en el sitio oficial del Ministerio de Defensa peruano, "el nuevo titular del sector Defensa fue nombrado en el cargo mediante Resolución Suprema N° 012-2018-PCM, que lleva las rúbricas del jefe de Estado y de la presidenta del Consejo de Ministros, Mercedes Aráoz Fernández."
 

VULNERABILIDADES DE APLICACIONES WEB: REFERENCIA INSEGURA Y DIRECTA DE UN OBJETO

10.01.2018 07:57
Conocida en inglés como Insecure Direct Object Reference, esta vulnerabilidad fue muy común en algún momento y aún siendo menos usual hoy en día, todavía es posible encontrarla. Su taxonomía exacta es difícil de establecer porque tiene variaciones de acuerdo a quien la describe pero la defeniremos como aquella en la cual los mecanismos de autorización del sistema permiten que un usuario obtenga acceso a datos o registros de otro usuario al modificar el valor clave que identifica los suyos. Facilitaremos la comprensión con un ejemplo muy elemental:
 
https://entidad-financiera/estado-cuenta?cliente=79915
 
Como los mecanismos de autorización son permisivos, el cliente 79915 (número que se va asignando por orden de alta en la institución) podrá ver el estado de cuenta de cualquier otro cliente simplemente cambiando el número de cliente. Para el registrado inmediatamente antes que él, la consulta será:
 
https://entidad-financiera/estado-cuenta?cliente=79914
 
En otro caso la cosulta podrá ser 
 
https://mutual/cuentas/ver/147725
 
y un atacante intentaría algo como:
 
https://mutual/cuentas/actualizar/147725
 
El segundo ejemplo podría ser más peligroso que el primero, podría permitir algo más que simplemente ver los datos. 
 
Para prevenir este tipo de ataques implemente de un control de acceso. El usuario tiene que estar autorizado para ver su información y sólo la suya. Como medida adicional asegúrese de que la clave que se utiliza en la búsqueda de un registro no sea controlable externamente por el usuario. Además esa clave debería ser aleatoria, no un nombre o un número entero. Si se opta por una clave no aleatoria la misma al menos debería ser encriptada para dificultar la obtención de otros valores válidos, aunque esto último es menos seguro que la clave aletoria. Incluso las claves "aleatorias" suelen tener una entropía tan baja que en determinados casos pueden ser descubiertas con relativa facilidad.
 
<< 117 | 118 | 119 | 120 | 121 >>