Proposal — Auditoría de seguridad y hardening (Odoo 18.0)

Why

Detectamos ataques automatizados cada vez más sofisticados que la heurística de fail2ban no frena, y somos responsables de la seguridad de nuestra infra y la de nuestros clientes. Necesitamos (a) un proceso de auditoría reproducible tipo "checklist de prevuelo" para verificar la resiliencia ante fuerza bruta, acceso indebido a datos vía API y vectores inadvertidos; y (b) corregir cinco hallazgos ya confirmados leyendo el propio código de website_sale_aplicoop.

Objetivo

Dejar la infra Odoo con una postura de seguridad auditable y repetible, y cerrar los hallazgos H1–H5 con tests que impidan su regresión.

Alcance

Solo nuestra infra (autorización directa, sin terceros). Producción está tras nginx/traefik con TLS.
Auditoría activa autorizada (fuerza bruta controlada contra cuenta de test y fuzzing de endpoints) desde la máquina Kali de la red y desde localhost vía SSH, preferentemente contra un clon de staging o en ventana de mantenimiento con snapshot previo.
Remediación de los hallazgos confirmados en website_sale_aplicoop (+ groups_id en la server action de mandatos SEPA de account_banking_mandate_batch).

No-objetivos

No se audita ni escanea infra de terceros ni hosting ajeno.
No se corrige aquí ningún hallazgo nuevo que surja durante la auditoría activa: se registra en el findings register y se aborda en un change posterior (salvo severidad crítica, que se escalará).
No se modifica ocb/ ni los addons OCA originales.

What Changes

Proceso de auditoría: se añaden entregables de documentación (docs/SECURITY_AUDIT_CHECKLIST.md, docs/SECURITY_AUDIT_RUNBOOK.md, docs/SECURITY_FINDINGS.md) y scripts no destructivos en scripts/security/ (probe de ACL vía API, probe de IDOR, harness de fuerza bruta, PoC de CSRF, recon web) parametrizados con cuentas de test.
Fix H1 (Alta) — ACL con group_id vacío que concede write+create global sobre group.order y group.order.slot: se reemplaza por ACLs de mínimo privilegio (lectura interna/portal explícitas; escritura solo manager). Los writes de los controladores usan sudo() y no dependen de estas ACLs.
Fix H2 (Alta) — record rule de product.supplierinfo con domain=[(1,'=',1)] que expone todos los precios de proveedor al portal. El portal usa supplierinfo para pintar el origen del producto y el proveedor principal en la web, así que no se elimina sin más: o se preparan esos valores server-side (vía sudo() en el controlador, según la regla "sin lógica en QWeb") o se acota el dominio a los productos accesibles por el usuario, sin exponer campos de coste/precio.
Fix H3 (Media) — endpoints de cambio de estado con csrf=False: se convierten a type="json" (bloquea el POST de formulario cross-site), tomando como plantilla confirm_order_from_portal.
Fix H4 (Media) — endpoints de lectura/ajax que solo comprueban exists()+state: se añade comprobación de pertenencia al grupo reutilizando _validate_user_group_access / _get_consumer_group_for_user.
Fix H5 (Baja) — t-raw inyectado en <script>: se sustituye por un patrón de salida seguro.
Hardening de config: admin_passwd, list_db=False, proxy_mode=True, password de BD fuerte, rate-limit/cabeceras en nginx, jails de fail2ban (web + API). Documentado como requisitos; los cambios de infra no versionable se ejecutan en el servidor, los versionables (groups_id en la server action) en el repo.

Capabilities

New Capabilities

eskaera-access-control: cómo website_sale_aplicoop restringe acceso a datos y acciones — ACL de mínimo privilegio, alcance de product.supplierinfo, autorización por pertenencia al grupo de consumo en todos los endpoints, protección CSRF en endpoints de estado, y escapado de salida en plantillas. Cubre H1–H5.
security-audit-process: proceso repetible de auditoría — reglas de compromiso/autorización, checklist de prevuelo, runbook de auditoría activa, scripts de prueba y registro de hallazgos.
infra-hardening: requisitos de endurecimiento de producción — odoo.conf, reverse proxy (nginx/traefik) con TLS/rate-limit/cabeceras, fail2ban (web + API), y gestión de secretos/BD.

Modified Capabilities

(ninguna — no existen specs previas en openspec/specs/)

Impact

Addons afectados: website_sale_aplicoop (security CSV + record rules, controladores, plantilla, tests, bump de __manifest__.py); account_banking_mandate_batch (groups_id en la server action).
Addons NO afectados: ocb/, los addons OCA originales, y el resto de custom (solo se auditan; cualquier hallazgo se registra, no se modifica en este change).
Nuevas rutas en el repo: docs/SECURITY_*, scripts/security/.
Impacto UI/website/QWeb: al convertir endpoints a type="json" hay que ajustar el transporte en el JS de website_sale_aplicoop (solo transporte, sin lógica). La plantilla load_from_history_templates.xml cambia su forma de inyectar JSON. Sin cambios visibles de UX.
Infra (no versionable): odoo.conf, config de nginx/traefik y fail2ban en el servidor de prod.

Riesgos

La auditoría activa (fuerza bruta/fuzzing) puede degradar o afectar a producción: mitigado con clon de staging o ventana de mantenimiento, snapshot previo y cuentas de test dedicadas (nunca contra cuentas reales, por riesgo de lockout/DoS de usuarios legítimos).
Convertir endpoints a type="json" cambia el contrato de request/response: riesgo de regresión en el carrito/checkout del portal; mitigado con tests y verificación end-to-end.
Recortar el acceso a product.supplierinfo podría romper la visualización de precios si algún punto del portal dependía de la ACL abierta: verificar que el pricing se computa vía sudo().

Criterios de aceptación

Los probes odoo_acl_probe.py e idor_probe.py deniegan tras los fixes lo que permitían antes (write/create de group.order, lectura de supplierinfo ajeno, datos de grupos ajenos).
El PoC de CSRF funciona antes del fix y falla después.
El harness de fuerza bruta acaba con la IP de Kali baneada por fail2ban en /web/login y en la ruta API.
Tests de website_sale_aplicoop en verde: docker-compose run odoo odoo -d odoo --test-enable --stop-after-init -u website_sale_aplicoop.
El checklist de prevuelo cubre los tres frentes + infra, con criterio pass/fail por ítem, y el findings register queda con H1–H5 en estado resuelto/verificado.

6.5 KiB Raw Blame History Unescape Escape