Revisando código heredado: ¿por dónde empezar con el top 10 de OWASP?

Para la búsqueda manual, buscar patrones de texto ayuda muchísimo: 1) Llamadas a la base de datos donde se concatenan variables directo en la consulta, 2) Claves secretas dejadas en el código sin cifrar, 3) Estructuras en bloques de captura de errores que devuelven información sensible del sistema al cliente. Buscar estos patrones lleva un par de horas.

Cuando asumimos un portal de escala similar, encontramos 5 fallos de autorización distintos en dos días con revisión manual. Los escáneres automáticos no vieron ninguno porque solo un humano leyendo la lógica de negocio entiende qué datos debe ver cada usuario.

Primero hagan una auditoría de dependencias de las librerías de terceros. Corran los comandos de auditoría de seguridad integrados en su gestor de paquetes y actualicen los paquetes con vulnerabilidades conocidas. Casi siempre los agujeros más grandes que dejan las agencias vienen de librerías viejas.

Es muy difícil que dos devs que no escribieron el código aseguren la arquitectura de otro solo mirando la lista OWASP. Si tienen poco tiempo, concéntrense solo en los permisos de acceso y las consultas a la base de datos, no pierdan tiempo en otros detalles criptográficos complejos.

miren sobre todo si cambiando los id en la url pueden entrar a los pedidos de otro las agencias suelen olvidarse esos controles de permisos en el backend

edit: he corregido unas erratas.

Al firmar contratos con clientes corporativos de logística, es habitual que soliciten un informe de auditoría de seguridad independiente. La revisión interna que hagan refuerza el sistema, pero legalmente no reemplaza un informe de auditoría externa.

¿Su sistema tiene una arquitectura multitenant? Es decir, ¿todos los clientes de logística comparten la misma base de datos? Si es así, el punto más crítico de la revisión debe ser el mecanismo de aislamiento que impide que un cliente acceda a las tablas de otra empresa.

Aunque parezca intimidante para equipos pequeños, avanzar paso a paso usando la guía OWASP como lista de verificación le da al equipo una visión de ingeniería increíble. A medida que detecten fallos de lógica de negocio, la arquitectura del software se volverá mucho más robusta.

El camino que parece barato suele salir caro a la larga. Que la copia de seguridad sea accesible en la misma red y con la misma identidad la convierte en parte del objetivo.

Tema muy oportuno. Si no lo pones por escrito desde el principio, luego surgen discusiones.

Si tenéis dudas, escribid, os responderé en la medida de lo posible.

Estoy de acuerdo a medias, en parte no. La mayor parte de la pérdida de tiempo se acumula en los trabajos pendientes de aprobación.

Permíteme resumir lo que se ha dicho hasta ahora. El error cometido por revision de codigo owasp top 10 suele ser reversible, pero caro.

Lo dejo como nota, por si sirve.

Hay algo que no entiendo. Si el camino de la notificación es largo la notificación no llega; una notificación que no llega significa un incidente detectado tarde.

Que todo el mundo haga algo no significa que sea lo correcto. Ánimo.

Aquí hay una trampa, no puedo dejar de mencionarla. La gente no defiende el proceso, defiende la costumbre. La resistencia viene de ahí.

Comprobado por experiencia.

Hablaré desde el otro lado, yo estoy en el lado del proveedor. No confíes en una sola medida; ve capa por capa.

Intentar hacerlo solo es la vía más cara. Yo seguiría por ese camino.

guardado.

Es correcto en general pero falta un detalle. bueno antes de decidir, mirad qué datos tenéis en la mano.

Si escribís el resultado aquí también servirá de ayuda a otros.

Exactamente así. Lo que más tiempo nos hacía perder era no saber quién tomaba las decisiones.

Intentar hacerlo solo es la vía más cara.