¿Qué hace que los hackers sean mejores que los programadores comunes y corrientes?
Supongamos que el jefe nos da una tarea hoy, pidiéndonos determinar si una IP está en línea. Podemos usar Python para escribir el código IP de ping importost=input ('Ingrese la IP a detectar:') result=os.popen ('ping-C 1-t1%s'% (host)). Leer() si 'ttl' es resultado: Imprimir ('Ip en línea') en caso contrario: Imprimir ('Ip fuera de línea').
Ahora, como revisor de código, no piensas en la estructura general del código ni en por qué el programador que escribió este código utilizó Ping o Popen. ¿Crees que hay algo malo en eso? Si no, considere dos preguntas: ¿Cuál es la naturaleza del bourbon? Si no conoce o no ha utilizado Popen, no lo busque y adivine qué hace esta función. En este programa, ¿cuál es el comando que Popen quiere ejecutar? Dado que el usuario ingresa la variable del host en la declaración ejecutada después de popen, ¿puede un usuario malintencionado ingresar un localhost && whoami? De esta forma, el código ejecutado por popen se convierte en ping -c 1 -t 1 localhost && whoami. Tenga en cuenta que incluso si los resultados de la ejecución no se imprimen directamente en el ejemplo anterior, la falta de impresión no significa que el código no se esté ejecutando. Por ejemplo, si ingreso host directamente como localhost && whoami, el resultado de salida aún muestra que la IP existe, pero esto no significa que el comando whoami no se esté ejecutando. Aún podemos crear un Shell inverso. Para verificar el resultado, dejamos que el resultado se imprima en el código.
Esta técnica se llama inyección de comandos. Si el programador promedio no encontrara este problema, no tocaría esta tecnología. Cuando vean el código vulnerable anterior, pensarán que no hay ningún problema. En el mejor de los casos, les parece un poco desagradable, pero los pocos que pueden reflexionar sobre la brecha de seguridad son una minoría. Esto suena como una técnica simple, mucho más simple que los levantamientos en reversa y con potencia. Pero esta tecnología es muy creativa y tiene un límite inferior y un límite superior. Por ejemplo, ahora sabemos que existe el problema anterior, por lo que está bien filtrar algunas palabras clave en la etapa de entrada. En esta pregunta, queremos que el usuario ingrese una dirección IP, por lo que debemos filtrar el espacio directamente. Las direcciones IP normales no tienen espacios.
Creo que es fuerte tanto en la sensibilidad a la vulnerabilidad como en la creatividad. Se necesita mucho tiempo para aumentar la sensibilidad a las vulnerabilidades en CVE, foros de hackers, etc., mientras que la creatividad sólo puede mejorarse con talento y suerte. Se podría pensar que hay muchas maneras de evitar este ejemplo. En primer lugar, admito que este ejemplo es temporal, lo cual es malo, pero tenga en cuenta que mi ejemplo es muy simple e inmaduro. En el verdadero campo de batalla rojo y azul, tomando la inyección SQL como ejemplo, después de tantos años, ¿podemos evitarla por completo? Recuerdo la base de datos de recopilación expuesta en la web oscura a principios de este año, 1000 gramos de varias bases de datos de inyecciones, que involucran a varios foros de todo el mundo, e incluso algunos bancos, algunas oficinas de población y algunas agencias gubernamentales. Las ideas de código son limitadas, pero la creatividad es ilimitada.