Jennifer Null es la demostración de cómo tu nombre puede convertirse en tu peor pesadilla en internet

Todavía usan impresora fiscal? No hacen boletas electrónicas?

Por mala fortuna los drop table no suelen tener ni commit ni rollback. O sea que si ese fuera el apellido de la Jennifer, sería peor que un suicidio, muerte súbita.

Oh, yes. Little bobby tables, we call him.

https://xkcd.com/327/

Es lo mismo que digo con esos que dicen que la ram está para usarse XD

Exacto.

Hay ataques de inyección de software que en el lugar d ela contraseña tantean cosas como operadores OR, etc y la aplicación se lo transmite literalmente a un query que al ver la frase "..... OR true), Zás, deja pasar. Y todo porquer la aplicación no lo ha impedido.

Por desgracia, lo único importante es que sea barato, que esté lo antes posible y sea bonito.

¿Seguridad? irrelevante. Igual que la performance, el consumo de hardware, ... irrelevantes ...

Hecho de menos esos tiempos en que lanzabas pruebas cabronas a cada campo y contabas el tiempo de carga de cada pantalla, superar los 500ms significaba que esa pantalla era basura y se tenía que rehacer, ahora te dicen que usa muchos microservicios y que por eso tarda, que es lo que hay.

The capital i makes the trick.

Ya veo por dónde va la cosa. ¿Los de Apple en su nuevo OS usarán iNull?

Ahora rápidamente se me ocurre, en el parseo de cadenas para evitar la inyección sql, en dicho parseo también deben considerarse cadenas como null y todas sus variantes de mayúsculas y minúsculas, porque nadie se llama null... o wait

Pero se supone que NULL no es lo mismo que 'NULL' no? vamos, lo que dice nuevocharrua, lo primero es un NULL, lo segundo una cadena de caracteres que pone 'NULL'. No creo que se lie el SQL con eso, a ver si puedo probarlo por simple curiosidad.

Ese texto 'NULL' puede quedar inyectado en un query dinámico y misteriosamente se refiere al valor nulo, y ahí algunos listos comienzan a apoderarse de una base de datos porque unos tontos no lo han previsto.

No lo recuerdo muy bien y me puedo equivocar perfectamente, pero creo recordar que SQL Server, cuando tenia que representar un NULL, lo que devolvia era una string con 'NULL'. Es decir, que va a devolver lo mismo si tu introduces la cadena 'NULL' que si el valor es el propio NULL.
Asi que, el SQL no es el que se lia, el que lo hará seguramente sea el front end cuando "pase los datos por la criba".

Pues te equivocas, si te refieres a MS-SQLServer, nunca va a retornar un "Null" para referirte a NULL.
Depende de que tecnología uses para hacer la consulta, retorna el null de dicha tecnología, o en su defecto la constante DBNULL.
De verdad no se me ocurre que tan mal programado tiene que estar algo para que confunda el string "Null" con NULL.

La verdad es que hasta es difícil replicar un error como este xD.

Lo único que se me ocurre, es que algunos programadores novatos, son tan inseguros en su código que agregan comparaciones como esta:

if $input == NULL || $input == "NULL" || $input == "null"

Simplemente porque dentro de su inseguridad (y pereza), se quedan con la duda de que la primera comparación va a funcionar o no.

Esto es especialmente común en lenguajes como PHP, donde puedes poner constantes que no existen y él interprete las tomara como strings.

Entonces tu puedes tener en tu programa algo como

if ($input == NUL)

(Notese que escribí NUL en vez de NULL intencionalmente).

Y el programa seguirá corriendo, solo mostrando un warning (que en versiones más viejas solo era un NOTICE) y si a eso le sumas que muchas servidores y gente tiene desactivado los warnings solo porque le la pereza corregirlos pues muchos novatos pueden terminan dudando si NULL realmente representa un valor nulo, o solo esta siendo tomando como un string más y terminan agregando todo tipo de comparaciones sin sentido.

es lo más probable, que sea el front-end el que esté programado para, recibiendo "null" desde la BD, decir que ese apellido no existe.

Máxime que suelen ser muy frecuentemente que los front end inyecten directamente la consulta a la base de datos.

pero un string con el valor "Null" no es lo mismo que el valor NULL. No tiene sentido....

Lo mismo pense, vaya que no especificamente por esto, pero desde hace mas de una decada que la manera en la que se ensenan los lenguajes usa practicas que tapan este tipo de agujeros para evitar la inyeccion de protocolos no deseados en las bases de datos. Vamos, que es impensable que esto pueda ocurrir a dia de hoy, simplemente las versiones de este siglo de los lenguajes evitan este tipo de confusiones en la maquina.

A mí me pasa lo mismo, tengo una ñ en el apellido y la solución (que han puesto otros) es el símbolo #, y al final solo una n. Anglosajones.

ORACLE y SQL Sever, los que más conozco, desde muchos años atrás soportan codificación UNICODE. Porque si nos asustamos por nuestra "ñ" que sería de los apellidos en Chino Mandarín (Dejo fuera a las direcciones de correo que parece que sólo usan la parte tradicional del ASCII de 7 bits, no las extensiones.)

Lo único que se requiere es que los charset y cualquier tipo de codificación sea compatible en todas las capas, y si no lo son, a preparar una capa de traducción.

Con los lenguajes modernos, mucha gente se ha acostumbrado a uso intensivo de programación con el ratón, y en lugar de prevenir con código, esperar al run time error y pasarle la patata caliente al usuario, para que descubra nuestros errores y entonces a revisar toca. Eso sí, el usuario debe hacer antes un cursito de cómo reportar adecuadamente los errores, para que vayamos directo al punto.

Para “tratar” de evitar las intrusiones o problemas de seguridad de cualquier tipo, considera que todos los datos que te envíen al servidor, son datos malintencionados. Dicho esto, quitar, borrar o detectar un “Null” no es para nada mala programación (todo lo contrario), dado que TODOS los datos que llegan al servidor son texto plano, un Null (se pasa como cadena), y “Null” son lo mismo de origen y Solo se distinguen en el parseo.

En este caso la chica tiene que cambiarse el apellido tan molón que tiene (que considere drop, select o update, para ir a la última XD), o seguirse aguantando.

Si el código que recibe el nombre o la contraseña se pasa sin análisis semántico directamente a una consulta dinámica para validar la integridad, ten por seguro que se pueden hacer destrozos en la base de datos.

Busca en San Google algo así como "ejemplos de inyección de código en bases de datos" y te quedarás aterrado. Luego busca "Inyección de HTML en paginas WEB" y el terror se convertirá en paranoia.

Cualquier malandrín que explote estas inyecciones que no han sido contempladas por la programación o que la programación sea muy simple, y el malandrín se apodera de la base de datos completa y si el sitio es del estilo "Web Forms" (ASP.NET no MVC, JSF, ...) mal programado, también se puede apoderar del sitio y hacer destrozos inventando datos o robando datos o consiguiendo que metan a la cárcel a las personas de contabilidad.