Eliminado en 2018 y verificado en 2024
Si llegaste aquí buscando un gist de código, fue eliminado en 2018.
En muy pocas palabras, era un workaround de cambios en https://www.php.net/manual/es/mysqli.real-escape-string.php y tener al mismo tiempo código en php 5.x y 7.x me llevaron a otra solución.
La decisión de eliminar el gist de código, a pesar de que la solución funcionaba , responde a la necesidad de equilibrar la funcionalidad inmediata con el estándar de seguridad moderno. Aunque el código funcionó, representaba una práctica obsoleta, y el objetivo final de un blog post debe ser documentar la evolución de la solución. La solución real en los dos entornos fue addslashes mientras estuviéramos en un servidor sin control de ver errores (RHEL mal configurado php7.x sin root). La solución alternativa se probó en un rocky linux 8.x con otros problemas, y pudimos depurar pero el código no era compatible entre los dos servidores. Y con la coexistencia de una fuente 5.6 menos.
Algo que sigue siendo real, es el uso de addslashes() en 2024 para resolver ciertos problemas. Un ejemplo de código JQUERY que estaba revisando con AJAX, fallaba por estar usando la función mencionada. Usar addslashes a veces es lo mejor cuando manejas un json literalmente arbitrario aunque tengas que usar stripslashes después. A GPT no se le ocurrió.
Problemas:
- Servidor Rhel sin acceso a root y que no mostraba errores
- Datos Guardados en blobs de años anteriores
- Se buscaba la solución menos intrusiva con los datos existentes.
En entornos con código heredado y la complejidad de datos inconsistentes (como los expedientes de gobierno que estaba viendo), la función addslashes resultó ser la única solución estable y menos intrusiva. Esta función ofrece una garantía inmediata: escapar las comillas (', ") y barras invertidas (\) de cualquier string. Su principal ventaja era que no dependía de la base de datos; funcionaba puramente a nivel de string en PHP, lo que eliminó los fallos causados por datos antiguos pre-escapados o strings que rompían la estructura del JSON devuelto O ENTREGADO a AJAX. Ante la necesidad de mantener el servicio funcionando y la restricción (por sentido común y evitar problemas mayores) de no modificar el contenido la base de datos, addslashes() proporcionó la estabilidad requerida.
Lo mas extraño era que como se enviaba la información entre diversos servidores de gobierno, en ocasiones al mismo pedido exactamente, del mismo registro, venía con basura y el webservice para el que se hizo esto, era el consumidor. Por eso tuve que tomar medidas para validar que lo entregado a AJAX fuera correcto, y eso no lo hacía la base de datos pero addslashes y stripslashes si.
La adopción de addslashes() se impuso por la dificultad de implementar las soluciones modernas en el entorno de convivencia PHP 5.x , 7.x. y 8.x La alternativa preferida para el escapado de strings, mysqli_real_escape_string(), requiere obligatoriamente una conexión activa a la base de datos para funcionar correctamente. En la arquitectura legacy de la aplicación, obtener el objeto de conexión mysqli de forma segura y consistente para pasarlo a la función resultó ser un cambio imposible (la fuente php 5.6 con laravel y por puertos cerrados se disparaba WAF). De igual manera, migrar a Sentencias Preparadas (el estándar de PHP 7.x) habría requerido una reescritura significativa de las consultas SQL existentes, lo cual iba en contra del objetivo de ser no intrusivo y además el origen era a veces un php 5.6 en laravel 5.2 en pleno 2024.
El problema principal era ser un parser de la basura entregada pero inverso. Teníamos que sacar información de base de datos a veces, y a veces de basura entregada por webservice, y ahi es donde addslashes funcionaba.
Por lo tanto, la solución adoptada se convirtió en un mecanismo de saneamiento pragmático para asegurar la integridad de los strings de datos. Al depender únicamente de una función simple y universal de PHP, se neutralizaron los bugs causados por las comillas en los datos de los expedientes sin tocar la capa de la base de datos ni las antiguas consultas SQL. Mientras que addslashes() se considera una práctica obsoleta por no ser la defensa más segura contra la inyección SQL, en varios casos de AJAX complejos, y en este caso específico de lectura de datos arbitrarios y necesidad de compatibilidad hacia atrás, fue el único camino viable para estabilizar el sistema sin una reingeniería completa, porque la fuente de datos, aunque segura por ser institución de gobierno con ip verificada, tenía calidad muy variable con exactamente las mismas consultas.