Guia de de Buenas Prácticas de Desarrollo para Minimizar Falsos Positivos en el WAF
(Versión Ampliada)

1. Principios Fundamentales

​

• Validación en Origen: La primera y más importante línea de defensa debe ser la validación y sanitización de datos en el servidor de la aplicación. El WAF es una capa de defensa adicional, no un reemplazo de un código seguro.

• Claridad en los Datos: Mientras más predecible y estructurado sea el tráfico hacia su aplicación, más fácil será para el WAF distinguir entre el tráfico legítimo y el malicioso.

​

2. Recomendaciones por Categoría de Entrada

A. Manejo de Entradas de Texto (Campos de Formulario, Comentarios,Búsquedas)

​

• Defina Esquemas Estrictos:

  • Longitud: Establezca longitudes máximas y mínimas razonables para todos los campos.

  • Caracteres Permitidos: Utilice "listas blancas" (allow lists). Por ejemplo:

 

• Nombres: [a-zA-ZáéíóúñÑ\s]

• Email: Valide con una expresión regular estándar y permita solo los caracteres necesarios.

• Números de Teléfono: Permita solo dígitos, +, (, ), y -.

• Evite caracteres especiales innecesarios como <> / ' " \ ; a menos que sean absolutamente necesarios.

​​

• Codificación de Salida:

Asegúrese de que toda la salida generada con datos de usuario esté correctamente codificada para el contexto en el que se muestra (HTML, SQL, JavaScript, etc.). Esto previene XSS y hace que las entradas legítimas que contengan caracteres especiales sean menos sospechosas.

B. Manejo de Parámetros URL y Query Strings - ¡CRÍTICO!

​

• Estructura Predecible: Los parámetros deben tener nombres y tipos de valor consistentes.

 

• Ejemplo BUENO: ?

  • id=123&category=books (siempre números e IDs alfanuméricos).

• Ejemplo PROBLEMÁTICO: ?param=1&data=<script>alert('xss')</script>

​​

• Tipado Fuerte: Asegúrese de que los parámetros numéricos (id, page, user_id) sean convertidos a tipos numéricos en el backend antes de su uso. Rechace cualquier entrada que no sea numérica.

​​

• NUNCA Pasar Rutas de Archivo o Directorios vía GET:

  • MAL: https://api.ejemplo.com/read?file=../../../etc/passwd

  • MAL: https://app.ejemplo.com/load?template=/templates/default.html

  • PROBLEMA: El WAF detectará patrones como ../ (Path Traversal) y bloqueará la solicitud por ser un intento de acceso a archivos sensibles.

​

• SOLUCIÓN:

  • Use identificadores o claves en lugar de rutas completas: ?file_id=12345

  • Si debe usar rutas, valídelas estrictamente en el backend contra una lista blanca de rutas permitidas.

  • Considere usar POST en lugar de GET para este tipo de operaciones.

​

C. Manejo de Cabeceras HTTP (Headers)

​

• No Modificar Cabeceras Estándar de Manera Inusual: Evite inyectar datos no confiables en cabeceras como User-Agent o Referer. El WAF espera un comportamiento específico en estas cabeceras.

• Cabeceras Personalizadas: Si utiliza cabeceras personalizadas (ej. X-API-Key, X-Request-ID).

  • Content-Type Adecuados:

    • MAL: Enviar Content-Type: text/html cuando el cuerpo es JSON.

    •  MAL: Enviar Content-Type: application/json cuando el cuerpo es XML.

    • PROBLEMA: El WAF analiza el contenido basándose en el Content-
      Type declarado. Si no coincide, puede no detectar un ataque real o
      bloquear una solicitud legítima por malinterpretación.

      • SOLUCIÓN: Siempre configure los Content-Type correctos:
         application/json para JSON
         application/xml o text/xml para XML
         application/x-www-form-urlencoded para formularios HTML estándar
         multipart/form-data para formularios con subida de archivos

​​​

​

D. Manejo de Datos JSON y APIs RESTful

• Esquemas de Validación: Utilice esquemas JSON (como JSON Schema)para validar la estructura, tipos y formatos de todas las solicitudes entrantes a su API.

• Tipado de Datos: Asegúrese de que los campos en el JSON sean del tipo correcto (ej. &quot;price&quot;: 19.99 es un número, no una cadena &quot;19.99&quot;).

• Evite la Serialización de Código: No envíe código ejecutable (como

funciones JavaScript) dentro de los objetos JSON.

E. Subida de Archivos (Uploads)

• Restricciones Estrictas:

  • Tipo MIME: Valide el tipo MIME real del archivo en el servidor, no solo la extensión.

  • Extensiones Permitidas: Defina una lista blanca de extensiones permitidas (ej. .pdf, .jpg, .png).

  • Tamaño Máximo: Establezca un límite de tamaño para evitar la saturación y el abuso.

​​

• Almacenamiento Seguro: Almacene los archivos subidos fuera del directorio raíz web y sirvalos a través de un controlador o una URL que no permita la ejecución directa.

​

3. Comportamientos de la Aplicación que Generan Falsos Positivos (¡Evítelos!)
Estas son las "cosas raras" que más activan reglas del WAF:

• Contenido que Parece Código en Campos de Texto:

  • Escribir 1 OR 1=1 en un campo de búsqueda (se parece a SQL Injection).

  • Escribir <script>console.log(´test´)</script>  en un campo de nombre o comentario (se parece a XSS).

  • Solución: Eduque a sus usuarios finales o utilice una sanitización más agresiva en el backend para estos casos.

 

• Actividad de Web Scraping o Bots Legítimos:

  • Si su aplicación es scrapeada por un socio o un bot interno (ej. para iindexación), su patrón de tráfico (muchas solicitudes rápidas, parámetros repetitivos) puede disparar reglas de protección contra bots (DDoS, Anti-Scraping).

  • Solución: Proporciónenos las IPs o los User-Agent de estos bots para que los coloquemos en una lista blanca.

 

• Parámetros de URL con Contenido Complejo:

  • Enviar un objeto JSON serializado o un fragmento de HTML dentro de un parámetro de consulta (ej. ?config={"name":"test", "role", "admin"}). Esto es muy sospechoso para un WAF.

  • SOLUCIÓN: Utilice el cuerpo de una solicitud POST para enviar datos complejos.

​​

• Uso de Caracteres de Escape y Codificación:

  • Enviar caracteres como \x00, \n, \t o cadenas URL-encoded (%20, %27) en contextos donde no son necesarios.

  • PROBLEMA: El WAF puede interpretarlos como intentos de evasión de filtros.

  • SOLUCIÓN: Evite el uso innecesario de caracteres de escape. Si son necesarios, notifíquenoslo para ajustar las reglas.

• Uso de Herramientas de Desarrollo y Debugging:

  • Los parámetros de debug como ?debug=true o herramientas que inyectan cabeceras específicas (como algunas extensiones de navegador) pueden ser bloqueadas.

  • Solución: Asegúrese de que estas funcionalidades estén desactivadas en entornos de producción.

​

4. Checklist de Lanzamiento (Go-Live) para Desarrollo
Antes de desplegar una nueva funcionalidad o aplicación detrás del WAF, su
equipo debe verificar:

1. ¿Se validan y sanitizan todas las entradas del usuario en el backend?
2. ¿Los tipos de datos (números, cadenas, booleanos) se manejan correctamente?
3. ¿Las APIs utilizan esquemas de validación para las solicitudes entrantes?
4. ¿Se han eliminado los parámetros de debug y las funciones de testing?
5. ¿Se evita el paso de rutas de archivo mediante parámetros GET?
6. ¿Se configuran los Content-Type HTTP correctos para cada tipo de payload?
7. ¿Se ha probado la aplicación en un entorno de &quot;staging&quot; con el WAF en modo de detección/log para identificar posibles falsos positivos? (Este es el paso más crucial).

​

5. Flujo de Trabajo Recomendado con Nuestro Servicio WAF Core

1. Fase de Desarrollo: Siga las buenas prácticas de esta guía.
2. Fase ´Detect: Nosotros configuraremos el WAF en modo "Detección" o "Registro" para su entorno de staging. Esto no bloqueará nada, pero generará registros de todo lo que hubiera sido bloqueado.
3. Revisión de Logs: Juntos, revisaremos los registros del WAF durante las pruebas de su aplicación. Usted identificará las solicitudes legítimas que están siendo marcadas (falsos positivos).
4. Ajuste Fino: Nosotros crearemos exclusiones (whitelists) o reglas personalizadas para esos falsos positivos específicos (ej. "desactivar la regla 941110 para el parámetro search_query en la URL /api/search").
5. Pase a Producción: Una vez que los falsos positivos se hayan minimizado, cambiaremos el WAF a modo "Protección" o "Bloqueo" para su entorno de producción.

Al seguir estas recomendaciones, sus desarrolladores se convertirán en sus mejores aliados para que el WAF sea una herramienta de seguridad eficaz y silenciosa, no una fuente constante de problemas y tickets de soporte.

 

hemos tenido algunos con los archivos y content type, pasan el binario en texto etc

​

¡Ahí está el problema! Esos casos son clásicos y generan muchos dolores de cabeza. Vamos a profundizar en esos puntos específicos:

​

Problemas Específicos con Archivos y Content-Type - Guía de Corrección

�� PROBLEMA CRÍTICO: Pasar Binarios como Texto
Lo que está pasando:

• Los desarrolladores envían archivos binarios (images, PDFs, documentos)

pero los codifican en texto (Base64, HEX, etc.) y los mandan como
parámetros o en JSON

• Ejemplo MAL: {"imagen":/9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAA..."} en un JSON

• Ejemplo MAL: ?pdf=%2550%2544%2546%252D... en URL parameters

​​​

Por qué el WAF lo bloquea:
1. Análisis de contenido incorrecto: El WAF analiza el contenido como texto
y detecta patrones sospechosos

2. Patrones de evasión: La codificación Base64/HEX se usa para evadir
firmas de seguridad
3. Consumo excesivo de recursos: Analizar grandes cadenas de texto
consume mucha CPU

SOLUCIONES PARA ARCHIVOS:
✅ OPCIÓN 1: Uso Correcto de Multipart/Form-Data
http
POST /upload HTTP/1.1
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary

------WebKitFormBoundary
Content-Disposition: form-data; name="archivo"; filename="documento.pd";
Content-Type: application/pdf

 

[binary data here]

------WebKitFormBoundary--

✅ OPCIÓN 2: Subida Directa Binaria
http
POST /upload HTTP/1.1
Content-Type: application/pdf
Content-Length: 12345

[binary data here]

✅ OPCIÓN 3: Si DEBEN usar Base64 (no recomendado)

​

Notificar al equipo de seguridad para crear exclusiones específicas
Validar estrictamente el tipo de archivo antes de decodificar
Limitar el tamaño máximo de la cadena Base64

​

�� PROBLEMA: Content-Type Incorrectos para Binarios
Casos comunes problemáticos:

• Content-Type: text/plain para imágenes PNG

• Content-Type: application/json para PDFs

• Content-Type: text/html para documentos Word

​

Consecuencias:

• El WAF analiza el PDF como si fuera texto y detecta &quot;falsos patrones

maliciosos&quot;

• Bloqueo de archivos legítimos

• Problemas de renderizado en el navegador

​

SOLUCIONES PARA CONTENT-TYPE:
Tabla de Content-Type Correctos:

​​

​​

​

​

​
​

​​

​​

​​

​​

​​

​​

​​

​​

​​

​​

​​

​

​

​

​

​

Checklist Específico para Manejo de Archivos:
ANTES de implementar:

• ¿Estamos usando multipart/form-data para formularios con archivos?

• ¿El Content-Type coincide con el tipo real del archivo?

• ¿Validamos el magic number (firma binaria) del archivo en el backend?

• ¿Evitamos completamente el paso de archivos binarios codificados en

texto?

• ¿Probamos la subida con el WAF en modo detección?

​​

VALIDACIÓN EN BACKEND (Crítico):

 

python
# Ejemplo de validación robusta
def validar_archivo(archivo):
      # Verificar magic numbers
      signature = archivo.read(4)
      if signature != b'%PDF'
            raise ValueError("No es un PDF válido")

      # Verificar tipo MIME real
      mime_type = magic.from_buffer(archivo.read(1024), mime=True)
      if mime_type != application/pdf:
           raise ValueError("Tipo MIME incorrecto")

 

Flujo de Corrección Inmediata:
1. IDENTIFICAR endpoints problemáticos que envían binarios como texto
2. MIGRAR a multipart/form-data o subida binaria directa
3. VALIDAR Content-Type real del archivo en servidor

4. PROBAR en staging con WAF en modo registro
5. IMPLEMENTAR en producción una vez verificados

Comunicación para sus Desarrolladores:

"Para archivos: siempre usen multipart/form-data. Nunca pasen binarios
codificados en texto através de JSON o parámetros. El WAF interpretará esto
como un intento de evasión y bloqueará la solicitud."

¿Te ayudaría si preparo ejemplos de código específicos para los lenguajes que
usan tus desarrolladores (Node.js, Python, PHP, etc.)?
dame todas laas buenas practicas juntas

Guía Completa de Buenas Prácticas para WAF Core -

Resumen Ejecutivo

�� PRINCIPIOS FUNDAMENTALES

1. Validación en Origen

• Primera línea de defensa: Validación y sanitización en el servidor de la

aplicación

• WAF es capa adicional: No reemplaza código seguro

• Validar todo: Entradas, salidas, parámetros, headers

 

2. Claridad en los Datos

• Tráfico predecible: Más fácil para el WAF distinguir legítimo vs malicioso

• Estructuras consistentes: Mismos formatos, mismos comportamientos

• ​

�� COMPORTAMIENTOS CRÍTICOS A EVITAR

1. Archivos y Content-Type

• ❌ NO: Pasar binarios como texto (Base64 en JSON/parámetros)

• ❌ NO: Content-Type incorrectos (text/plain para PDFs)

• ❌ NO: Rutas de archivo en parámetros GET

• ✅ SÍ: Usar multipart/form-data para subidas

• ✅ SÍ: Content-Type específicos y correctos

• ✅ SÍ: Validar magic numbers en backend

​​

2. Parámetros y URLs

• ❌ NO: ?file=../../../etc/passwd

• ❌ NO: ?data=&lt;script&gt;alert()&lt;/script&gt;

• ❌ NO: Parámetros debug en producción (?debug=true)

• ✅ SÍ: IDs en lugar de rutas (?file_id=123)

• ✅ SÍ: Validación estricta de tipos

• ✅ SÍ: POST para datos complejos

​​

3. Codificación y Caracteres

• ❌ NO: Caracteres de escape innecesarios (\x00, \n, \t)

• ❌ NO: Codificación múltiple o innecesaria

• ❌ NO: Caracteres especiales sin validación (&lt; &gt; / &#39; &quot; \ ;)

• ✅ SÍ: Listas blancas de caracteres permitidos

• ✅ SÍ: Codificación contextual apropiada

​

✅ BUENAS PRÁCTICAS POR CATEGORÍA

 

A. ENTRADAS DE TEXTO (Formularios, Búsquedas, Comentarios)

 

• Longitudes definidas: Mínimas y máximas razonables

• Listas blancas: Solo caracteres necesarios

• Ejemplos:

                   Nombres: [a-zA-ZáéíóúñÑ\s]
                   Email: Expresión regular estricta
                   Teléfonos: Solo dígitos y +()-

 

B. PARÁMETROS URL

• Estructura predecible: ?id=123&amp;category=books

• Tipado fuerte: Convertir a números/booleanos en backend

• Nunca rutas: Usar IDs, no rutas de archivo

 

C. CABECERAS HTTP

• Headers estándar: No modificar User-Agent, Referer

• Headers personalizados: Notificar para whitelist

• Content-Type correcto:

• JSON: application/json

• XML: application/xml

• Formularios: application/x-www-form-urlencoded

• Archivos: multipart/form-data

​​

D. APIs RESTful/JSON

• Esquemas de validación: JSON Schema para todas las requests

• Tipado estricto: "price" 19.99 (número, no string)

• Sin código ejecutable: No serializar funciones

 

E. SUBIDA DE ARCHIVOS

• Restricciones estrictas:

  • Tipos MIME reales (no solo extensiones)

  • Listas blancas de extensiones

  • amaños máximos definidos

​​

• Almacenamiento seguro: Fuera del webroot

• Nunca binarios en texto: Base64 solo si es absolutamente necesario

​​

F. MANEJO DE ERRORES

• Sin información sensible: No mostrar stack traces

• Mensajes genéricos: Mismo formato en éxito/error

• Logging seguro: Sin datos sensibles en logs

​​

�� CONTENT-TYPE CORRECTOS - TABLA RÁPIDA

 

 

 

 

 

 

 

 

 

​

​

​

​

​

​

​

​

​

 

​

​

​

​​

​

​

​

​

​

​

​

 

�� CASOS QUE GENERAN FALSOS POSITIVOS
1. Contenido que Parece Código

• 1 OR 1=1 en búsquedas → Parece SQL Injection

• <script>console.log()</script> en comentarios → Parece XSS

• Solución: Sanitización agresiva o educación usuarios

​​

2. Actividad de Bots Legítimos

• Web scraping de socios

• Indexación interna

• Solución: Whitelist de IPs/User-Agents

 

3. Parámetros con Contenido Complejo

• JSON en query strings: ?config={&quot;role&quot;:&quot;admin&quot;}

• HTML en parámetros

• Solución: Usar POST para datos complejos

​​

4. Herramientas de Desarrollo

• Parámetros debug (?debug=true)

• Headers de testing

• Solución: Desactivar en producción

​

�� CHECKLIST DE LANZAMIENTO
Antes de Deploy en Producción:

• Validación backend: Todas las entradas validadas/sanitizadas

• Tipado fuerte: Parámetros convertidos a tipos correctos

• Esquemas API: Validación JSON Schema implementada

• Sin debug: Parámetros/funciones testing eliminados

• Sin rutas en GET: IDs en lugar de rutas de archivo

• Content-Type correctos: Específicos y apropiados

• Archivos correctos: multipart/form-data, no binarios en texto

• Testing WAF: Pruebas en staging con modo detección

​

Validación Específica Archivos:

• Multipart/form-data para formularios con archivos

• Content-Type coincide con tipo real

• Magic numbers validados en backend

• Sin binarios codificados en texto/JSON

• Testing completo con WAF en modo detección

​

�� FLUJO DE TRABAJO WAF RECOMENDADO
1. Fase Desarrollo

• Seguir buenas prácticas desde el inicio

• Code review enfocado en seguridad

​

2. Fase Staging

​

• WAF en modo "Detección/Registro"

• Identificar falsos positivos

• Pruebas exhaustivas de todas las funcionalidades

​

3. Revisión de Logs

​

• Análisis conjunto de registros WAF

• Identificación de solicitudes legítimas bloqueadas

​

4. Ajuste Fino

​

 

• Creación de exclusiones (whitelists) específicas

• Reglas personalizadas para casos particulares

• Documentación de exclusiones

 

5. Producción

 

• WAF en modo &quot;Protección/Bloqueo&quot;

• Monitoreo continuo

• Revisión periódica de logs

 

�� REGLA DE ORO

​

"Si parece un ataque, será bloqueado. Hagan que su tráfico legítimo no se
parezca a un ataque"

Entradas predecibles = Menos falsos positivos
Estructuras consistentes = Mejor protección
Validación en origen = WAF más efectivo

​

¿Listos para implementar? Esta guía cubre el 95% de los casos de falsos
positivos. Siguiendo estas prácticas, el WAF será una capa de seguridad
transparente y efectiva.