112 lines
7.4 KiB
Markdown
112 lines
7.4 KiB
Markdown
## Context
|
||
|
||
`website_sale_aplicoop` expone el portal de compra colaborativa (Eskaera) a usuarios de portal, y
|
||
la API externa de Odoo (XML-RPC/JSON-RPC) es accesible aunque el puerto de la BD esté firewallado.
|
||
La recon del código confirmó cinco hallazgos (H1–H5) y varios puntos de config de infra. Producción
|
||
corre tras nginx/traefik con TLS; el `docker-compose.yml` del repo es lab/dev y no refleja prod.
|
||
|
||
Los controladores de eskaera ya usan `sudo()` para sus escrituras y ya disponen de gatekeepers de
|
||
pertenencia (`_validate_user_group_access`, `_get_consumer_group_for_user` en
|
||
`controllers/website_sale_validators.py`); el problema es que las ACL/record rules son demasiado
|
||
permisivas y que algunos endpoints no invocan esos gatekeepers.
|
||
|
||
## Goals / Non-Goals
|
||
|
||
**Goals:**
|
||
- Cerrar H1–H5 con mínimo cambio de comportamiento observable para el usuario legítimo, respaldado
|
||
por tests que impidan regresión.
|
||
- Entregar un proceso de auditoría repetible (checklist, runbook, scripts, findings register).
|
||
- Documentar y aplicar hardening de infra (odoo.conf, proxy, fail2ban, secretos/BD).
|
||
|
||
**Non-Goals:**
|
||
- No se corrigen hallazgos nuevos de la auditoría activa en este change (se registran).
|
||
- No se toca `ocb/` ni addons OCA originales.
|
||
- No se rediseña la UX del portal; los cambios de endpoint son de transporte/seguridad.
|
||
|
||
## Decisions
|
||
|
||
**D1 — ACL de `group.order`/`group.order.slot` (H1): reemplazar la fila de `group_id` vacío por
|
||
ACLs explícitas de mínimo privilegio.** La fila vacía concede write+create a todos. Se sustituye
|
||
por: lectura interna (`base.group_user`, `1,0,0,0`, que empareja con la record rule interna ya
|
||
existente), lectura de portal explícita donde haga falta, y escritura solo para
|
||
`group_group_order_manager`. Alternativa descartada: añadir record rules que bloqueen write/create a
|
||
portal — más frágil que quitar el permiso en la ACL, porque una ACL permisiva sin regla restrictiva
|
||
ya abre el acceso. Verificar si el portal lee `group.order.slot` por ACL o por `sudo()` en el
|
||
controlador; si es por `sudo()`, no añadir ACL de portal para el slot.
|
||
|
||
**D2 — `product.supplierinfo` (H2): acotar el acceso, no eliminarlo.** El portal SÍ usa
|
||
`supplierinfo`: la web pinta el **origen** del producto y el **proveedor principal** a partir de él
|
||
(vía `product.seller_ids`), además de que el pricing se computa server-side en
|
||
`controllers/website_sale_pricing.py` vía `sudo()`. Por tanto no se puede quitar la ACL de portal
|
||
sin romper ese render. Dos opciones, en orden de preferencia:
|
||
- **(preferida) Preparar origen + proveedor principal en el controlador** vía `sudo()` y pasarlos ya
|
||
resueltos a la plantilla (alineado con la regla del repo "sin lógica en QWeb"). Entonces el portal
|
||
deja de necesitar ACL directa sobre `product.supplierinfo` → se elimina la ACL de portal (fila 6) y
|
||
la record rule `rule_product_supplierinfo_portal_read`. Es lo más seguro: no expone ningún coste.
|
||
- **(fallback) Acotar la record rule** para que el portal solo lea `supplierinfo` de los productos de
|
||
los grupos a los que pertenece, sustituyendo `domain=[(1,'=',1)]` por un dominio filtrado, y sin
|
||
exponer campos de coste/precio (restringir con `groups=` en el campo o exponer campo derivado).
|
||
|
||
El punto clave: hay que verificar en las plantillas/controladores qué campos de `supplierinfo` se
|
||
leen realmente (origen, nombre del proveedor) antes de elegir; el objetivo es no exponer
|
||
`price`/coste de todos los proveedores a cualquier usuario de portal.
|
||
|
||
**D3 — CSRF (H3): convertir a `type="json"`.** Los endpoints de estado (`save-order`, `confirm`,
|
||
`clear-cart`, `save-cart`) pasan de `type="http"` + `csrf=False` a `type="json"`. Un `type="json"`
|
||
exige `Content-Type: application/json`, que un formulario HTML cross-site no puede fijar, de modo
|
||
que neutraliza el CSRF por formulario sin gestionar tokens manualmente. Plantilla de referencia:
|
||
`confirm_order_from_portal` (ya `type="json"`). Implica ajustar el JS (solo transporte: fetch con
|
||
envelope JSON-RPC y lectura de `result`) y el Python (devolver `dict` en vez de `Response`).
|
||
Alternativa descartada: mantener `type="http"` y validar token CSRF — más código y más fácil de
|
||
olvidar en endpoints futuros.
|
||
|
||
**D4 — Autorización horizontal (H4): invocar los gatekeepers existentes.** En cada endpoint que hace
|
||
`group.order.sudo().browse(order_id)` y solo comprueba `exists()`/`state`, añadir la comprobación de
|
||
pertenencia tras ese check. Usar `_get_consumer_group_for_user` (devuelve `False`) en los que deban
|
||
retornar vacío/redirect silencioso (`load_eskaera_page`, `load_products_ajax`) y
|
||
`_validate_user_group_access` (lanza) en los que deban fallar duro. Mantener el bypass para usuarios
|
||
internos (`current_user.share == False`) igual que `eskaera_shop`.
|
||
|
||
**D5 — Plantilla (H5): salida JSON segura.** Sustituir `t-raw` en `<script>` de
|
||
`load_from_history_templates.xml` por `<script type="application/json">` leído por el JS, evitando
|
||
inyección raw en contexto de script.
|
||
|
||
**D6 — Proceso de auditoría: docs + scripts parametrizados.** Checklist, runbook y findings register
|
||
en `docs/`; scripts en `scripts/security/` que toman URL y credenciales por parámetro/env (sin
|
||
secretos versionados) y son no destructivos. El harness de fuerza bruta y el fuzzing corren contra
|
||
staging o en ventana, nunca contra cuentas reales.
|
||
|
||
**D7 — Hardening de infra: requisitos documentados + cambio versionable puntual.** La config de
|
||
`odoo.conf`, nginx/traefik y fail2ban vive en el servidor (no versionable aquí); se documenta como
|
||
requisitos verificables en el checklist. El único cambio versionable de este bloque es añadir
|
||
`groups_id` a la server action de mandatos SEPA en `account_banking_mandate_batch`.
|
||
|
||
## Risks / Trade-offs
|
||
|
||
- [Convertir endpoints a `type="json"` rompe el carrito/checkout] → Tests de endpoint + verificación
|
||
end-to-end del flujo de portal antes de mergear; cambios de JS limitados a transporte.
|
||
- [Recortar `supplierinfo` rompe la visualización de precios] → Confirmar que el pricing se computa
|
||
vía `sudo()`; test que verifica que el shop sigue mostrando precios.
|
||
- [Endurecer ACL bloquea a un usuario interno legítimo que dependía del permiso global] → La record
|
||
rule interna de lectura ya existe; el test cubre lectura interna y escritura de manager.
|
||
- [Auditoría activa afecta a producción] → Snapshot previo, staging preferente, ventana de
|
||
mantenimiento, cuentas de test dedicadas, monitorización en vivo.
|
||
- [`proxy_mode=True` mal configurado falsea la IP de origen] → Verificar cabeceras `X-Forwarded-For`
|
||
en nginx y comprobar en la Fase 1 que fail2ban ve la IP real de Kali.
|
||
|
||
## Migration Plan
|
||
|
||
1. Rama aparte para los fixes de código; la auditoría activa se ejecuta contra staging.
|
||
2. Aplicar D1–D5 en `website_sale_aplicoop` + tests; bump de `__manifest__.py`.
|
||
3. Actualizar el addon: `docker-compose run odoo odoo -d odoo --stop-after-init -u website_sale_aplicoop`.
|
||
Rollback: revertir la rama y re-actualizar el addon (las ACL/record rules se recargan al -u).
|
||
4. Aplicar D7 (config de servidor) en ventana; rollback = restaurar los ficheros de config previos y
|
||
recargar servicios.
|
||
|
||
## Open Questions
|
||
|
||
- ¿El portal lee `group.order.slot` y `product.supplierinfo` directamente en algún punto, o todo va
|
||
por `sudo()`? Resolver leyendo los controladores antes de eliminar ACLs (afecta a D1/D2).
|
||
- ¿Se usa traefik o nginx en prod? Ajusta la sintaxis de rate-limit/cabeceras del runbook (no el
|
||
requisito).
|
||
- ¿Externalizar secretos a `.env`/secrets del orquestador en este change o en uno posterior de infra?
|