Consultar el bono COVID-19 DE 380 SOLES



En esta página, podrás averiguar si te corresponde el apoyo monetario de 380 soles destinado a los hogares en condición de pobreza o pobreza extrema, de acuerdo al Sistema de Focalización de Hogares, que se encuentren en los ámbitos geográficos con mayor riesgo sanitario. Solo necesitarás colocar tu DNI. 


Tomar en cuenta que al acercarte al banco, deberás presentar tu DNI; de lo contrario, no podrás cobrar el bono. En caso tengas alguna pregunta adicional, puedes comunicarte a la línea telefónica 101 o al correo consultas@midis.gob.pe.

CONSULTA DE RETIRO DE AFP

Mediante el D.U. N° 034-2020, el gobierno dispuso que los afiliados al Sistema Privado de Pensiones (SPP) puedan realizar un retiro extraordinario de hasta S/2,000 de su fondo para afrontar la pandemia del COVID-19. Los afiliados que pueden acceder a este beneficio, son aquel
los que, al 31 de marzo de 2020, no registran aportes obligatorios en sus fondos en los últimos seis meses.logo-asociacion-afp







Los ataques de inyección SQL

Los ataques de inyección SQL son muy conocidos y temidos por tener un impacto tremendo en la seguridad de una aplicación, además de ser la vulnerabilidad más común, según el Top Ten de OWASP. Cuando pensamos en una inyección SQL, enseguida la relacionamos con fuga de información o robo de credenciales, porque el ataque más usual es volcar tablas de la base de datos que utiliza la aplicación vulnerable.



En este post voy a hablaros de otro método para aprovechar una vulnerabilidad de inyección SQL: saltarse un formulario de login, pudiendo autenticarse sin conocer credenciales.



 Partamos de un ejemplo típico: un formulario con un campo de usuario y otro de contraseña. La aplicación hará una consulta a la base de datos muy parecida al código a continuación:

 Código: [...] $usuario=$_POST['usuario']; $pass=$_POST['password']; $query="SELECT * FROM users WHERE usuario = '$usuario' AND password = '$pass'"; [...] Si se introduce como usuario pepe y contraseña patata1, la query resultante sería: Código: SELECT * FROM users WHERE usuario = 'pepe' AND password = 'patata1'

 La forma inicial de conocer si un formulario es vulnerable a inyección SQL es añadiendo una comilla en algún campo, para que la sentencia resultante esté mal formada.

 Así pues, si el usuario es pep’e, la query sería: Código: SELECT * FROM users WHERE usuario = 'pep'e' AND password = 'patata1' El texto resaltado se queda fuera del campo usuario, y formaría parte de la lógica de la sentencia SQL. Como no tiene sentido lo que se ha quedado fuera, lo más probable es que la aplicación muestre un error de sentencia SQL mal formada. Si no apareciera error, igualmente sería vulnerable pero estaríamos hablando de un ataque de inyección ciega, pero esto sería adentrarme en otro berenjenal así que lo dejaremos para otro post ;-)

Entonces, ya que hemos descubierto como inyectar código que forme parte de la sentencia SQL ¿qué ocurriría si usamos como usuario y contraseña asdf’ OR ‘a’='a? Veámoslo:

Código: SELECT * FROM users WHERE usuario = 'asdf' OR 'a'='a' AND password = 'asdf' OR 'a'='a' Fijaos que la segunda a no se le pone una segunda comilla, para poder cerrar la cadena con la comilla original y producir una sentencia SQL bien formada.


 Si se introdujera, se juntarían dos comillas y daría un error de sintaxis. Se estaría inyectando entonces una condición booleana siempre verdadera, para que aunque se introduzcan unas credenciales incorrectas, el resultado final sea siempre verdadero.

Voy a describir el esquema lógico para que se entienda mejor (los AND tienen preferencia sobre los OR):

1. usuario = ‘asdf’ OR ‘a’='a’ AND password = ‘asdf’ OR ‘a’='a’

2. FALSE OR TRUE AND FALSE OR TRUE
3. FALSE OR FALSE OR TRUE 4. TRUE La sentencia final sería: Código: SELECT * FROM users WHERE TRUE Es decir, se van a recuperar todos los usuarios de la tabla users. Lo más probable es que la aplicación seleccione la primera fila de la tabla para autenticarse, que por regla general suele ser el usuario administrador, por ser el primero que se dio de alta en la aplicación. Este escenario es una prueba de concepto muy común, pero en la práctica no suele ser tan directo. Esto es debido a que la contraseña se almacena hasheada en la base de datos, por lo que el campo password se hashea antes de entrar en la sentencia SQL. Si se repitiera el ataque, resultaría la siguiente sentencia SQL: Código: md5(asdf' OR 'a'='a) = 28248f883bd3e12dce1f60842a8dea39; SELECT * FROM users WHERE usuario = 'asdf' OR 'a'='a' AND password = '28248f883bd3e12dce1f60842a8dea39'

1. usuario = ‘asdf’ OR ‘a’='a’ AND password = ’28248f883bd3e12dce1f60842a8dea39′ 2. FALSE OR TRUE AND FALSE

3. FALSE OR FALSE

4. FALSE La sentencia SQL se queda en: Código: SELECT * FROM users WHERE FALSE Por lo que la autenticación no se produciría. Sin embargo, se puede atacar de otra manera, añadiendo un carácter de terminación de sentencia al campo de usuario. En SQL, los caracteres “–” o “#” hacen que el resto de query se ignore. Si se añade en el campo usuario asdf’ OR ‘a’='a’# y lo que sea en el campo password, se ejecutaría: Código: SELECT * FROM users WHERE usuario = 'asdf' OR 'a'='a'#' AND password = '28248f883bd3e12dce1f60842a8dea39' Lo marcado en naranja se ignoraría, y quedaría: Código: SELECT * FROM users WHERE usuario = 'asdf' OR 'a'='a'# Como podréis deducir, el resultado lógico resultante es TRUE, y la autenticación será exitosa.

Si se conoce un nombre de usuario válido, el ataque es más sencillo todavía puesto que no sería necesario inyectar una condición válida de tipo algo=algo: Código: SELECT * FROM users WHERE usuario = 'admin'# Código: SELECT * FROM users WHERE usuario = 'asdf' OR a=a OR 'a'='a' AND password = '28248f883bd3e12dce1f60842a8dea39' Vamos a poner la secuencia lógica para que se vea más claro: 1. usuario = ‘asdf’ OR a=a OR ‘a’='a’ AND password = ’28248f883bd3e12dce1fa39′

2. FALSE OR TRUE OR TRUE AND FALSE

3. FALSE OR TRUE OR FALSE 4. TRUE De nuevo la aplicación se autenticaría con el primer usuario de la tabla. Fuente: google.com

Manual para el Diseño de Redes (Lan)

1 - Análisis para el Diseño de una Red de Área Local

Topología:

Es simplemente visualizar el sistema de comunicación en una red es conveniente utilizar el concepto de topología, o estructura física de la red. Las topologías describen la red físicamente y también nos dan información acerca de el método de acceso que se usa (Ethernet, Token Ring, etc.). Entre las topologías conocidas tenemos.

Bus:

En una red en bus, cada nodo supervisa la actividad de la línea. Los mensajes son detectados por todos los nodos, aunque aceptados sólo por el nodo o los nodos hacia los que van dirigidos. Como una red en bus se basa en una "autopista" de datos común, un nodo averiado sencillamente deja de comunicarse; esto no interrumpe la operación, como podría ocurrir en una red en anillo

Anillo:

Se integra a la Red en forma de anillo o circulo. Este tipo de Red es de poco uso ya que depende solo de la principal, en caso de fallas todas las estaciones sufrirían.

Estrella:

Una red en estrella consta de varios nodos conectados a una computadora central (HUB), en una configuración con forma de estrella. Los mensajes de cada nodo individual pasan directamente a la computadora central, que determinará, en su caso, hacia dónde debe encaminarlos s de fácil instalación y si alguna de las instalaciones fallas las demás no serán afectadas ya que tiene un limitante.

Posibles problemas que presenta una Red a raíz de una mala configuración en los Equipos establecidos.

Perdida de las Datos:

La pérdida de datos es producida por algún virus o por otro tipo de incidencia, los mas comunes son mal manejo por parte del usuario o personas inescrupulosas que acceden al sistema o mediante Internet, estos puede incidentes pueden evitarse de tal manera que en las estaciones de trabajo se instalan códigos para que así tengan acceso solo personal autorizado, en cuanto a Internet hay muchos software en el mercado mejor conocidos como Muros de fuego, que sirve para detener a los intrusos.

Caídas Continuas de la Red:

La caída continua en una Red se debe en la mayoría de los casos a una mala conexión Servidor > Concentrador o la conexión existente con el proveedor de Internet.

En el procesamiento de la información es muy lento:

Cuando el procesamiento de información de una Red es muy lento tenemos que tomar en cuenta el tipo de Equipos que elegimos, (Servidor, Cableado, Concentrador, Estaciones de Trabajo y otros, ya que si tomamos una decisión errónea perderemos tanto tiempo como dinero.

2 - Protocolos a usar

TCP/IP:

Se refiere a los dos protocolos que trabajan juntos para transmitir datos: el Protocolo de Control de Transmisión (TCP) y el Protocolo Internet (IP). Cuando envías información a través de una Intranet, los datos se fragmentan en pequeños paquetes. Los paquetes llegan a su destino, se vuelven a fusionar en su forma original. El Protocolo de Control de Transmisión divide los datos en paquetes y los reagrupa cuando se reciben. El Protocolo Internet maneja el encaminamiento de los datos y asegura que se envían al destino exacto.

Norma EIA/TIA 568:

ANSI/TIA/EIA-568-A (Alambrado de Telecomunicaciones para Edificios Comerciales)

Este estándar define un sistema genérico de alambrado de telecomunicaciones para edificios comerciales que puedan soportar un ambiente de productos y proveedores múltiples.

El propósito de este estándar es permitir el diseño e instalación del cableado de telecomunicaciones contando con poca información acerca de los productos de telecomunicaciones que posteriormente se instalarán. La instalación de los sistemas de cableado durante el proceso de instalación y/o remodelación son significativamente más baratos e implican menos interrupciones que después de ocupado el edificio.

El propósito de esta norma es permitir la planeación e instalación de cableado de edificios comerciales con muy poco conocimiento de los productos de telecomunicaciones que serán instalados con posterioridad. La instalación de sistemas de cableado durante la construcción o renovación de edificios es significativamente menos costosa y desorganizadora que cuando el edificio está ocupado.

Alcance

La norma EIA/TIA 568A específica los requerimientos mínimos para el cableado de establecimientos comerciales de oficinas. Se hacen recomendaciones para:

Las topología
La distancia máxima de los cables
El rendimiento de los componentes
Las tomas y los conectores de telecomunicaciones
Se pretende que el cableado de telecomunicaciones especificado soporte varios tipos de edificios y aplicaciones de usuario. Se asume que los edificios tienen las siguientes características:

Una distancia entre ellos de hasta 3 Km.
Un espacio de oficinas de hasta 1,000,000 m2
Una población de hasta 50,000 usuarios individuales
Las aplicaciones que emplean los sistemas de cableado de telecomunicaciones incluyen, pero no están limitadas a:

Voz , Datos, Texto, Video, Imágenes
La vida útil de los sistemas de cableado de telecomunicaciones especificados por esta norma debe ser mayor de 10 años.

Las normas EIA/TIA es una de las mejores Normas por sus Antecedentes que son: Vos, Dato, video, Control y CCTV