La lógica del negocio está condicionada por su diseño inicial, por lo que la seguridad en la lógica de negocio debe tenerse en cuenta desde el mismo instante en el que se diseña dicha plataforma. Un buen punto de partida podría ser un diseño por capas, confiando a cada capa una única misión y minimizando la exposición de la plataforma.
Figura 1. Diseño en tres capas
Cada vez son más las empresas que, sensibilizadas por la seguridad, adquieren una posición robusta frente a vulnerabilidades tecnológicas. No obstante, todavía es muy frecuente que éstas presenten vulnerabilidades asociadas a la lógica del negocio, y más específicamente en el marco de autorización.
Resulta fundamental disponer de un marco de autenticación robusto, pero en servicios de acceso masivo, no supone un beneficio definitivo. Algunos ejemplos de servicios de acceso masivo podrían ser:
Venta de productos por Internet
Gestión bancaria (banca online)
Servicios de la Administración Pública
Ocio (p.e. redes sociales)
En estos casos, la diferencia entre estar autenticado o no es tan leve como la de rellenar un formulario de registro o crearse una cuenta bancaria para posteriormente solicitar un acceso a servicios de banca online. Definitivamente, para muchos servicios, disponer de una serie de controles en el marco de autenticación no frenará a un atacante suficientemente motivado. Dada la facilidad de acceder a la zona autenticada de un servicio, sólo nos queda confiar en la robustez del marco de autorización.
Sorprende ver que en muchos casos no se le da, al marco de autorización, el peso que éste merece, revelándose vulnerabilidades tan obvias que sólo pueden llevar a dos conclusiones claras:
Que existe un exceso de confianza en el marco de autenticación (cuando en absoluto es la panacea), y no siempre se le da la misma importancia al marco de autorización.
Que todas las revisiones de seguridad, que se hayan podido realizar en el pasado, sólo se han focalizado en revelar vulnerabilidades tecnológicas, y en absoluto se han focalizado en revelar las carencias de seguridad sobre la lógica de negocio.
Representando esto mediante un ejemplo ficticio y sencillo (para facilitar su comprensión), estaríamos hablando de algo similar a lo siguiente:
Supongamos que bancaonline.com me permite hacer una transferencia de Z Euros, desde mi cuenta X hasta mi otra cuenta Y, mediante la siguiente URL:
https://www.bancaonline.com/hacer_transferencia?cuenta_origen=X&cuenta_destino=Y&importe=Z
A priori podría parecer algo normal, incluso corriente. Lamentablemente es más común de lo que muchos quisieran, puesto que desde un punto de vista de seguridad, de normal no tiene nada. ¿Acaso mi banco no sabe cuál es mi número de cuenta X? ¿Qué necesidad existe de que mi número de cuenta X sea pasada como parámetro? La solución es sencilla:
La seguridad del servicio no ha sido tenida suficientemente en cuenta desde su diseño.
En el ejemplo anterior, el servicio está exponiéndose a la posibilidad de que un usuario malintencionado cambie el parámetro cuenta_origen=X, cuando realmente no hay necesidad de ello porque realmente, el banco, conoce muy bien cuál es el número de mi cuenta bancaria.
Desde un punto de vista de revisión de seguridad, independientemente de analizar las vulnerabilidades técnicas, no siempre se analiza con la suficiente profundidad las posibles vulnerabilidades en la lógica del negocio, ya que algo tan sencillo como manipular cuenta_origen por otro número de cuenta, expedido por la misma entidad bancaria, podría ser suficiente como para poner a prueba los controles de seguridad existente en el marco de autorización. En el caso en que dichos controles en el marco de autorización sean insuficientes, y confíen en los parámetros manipulables (como en nuestro ejemplo: cuenta_origen=X) más allá que en la información interna que bancaonline.com sabe sobre mis cuentas, significaría la posibilidad de defraudar las cantidades económicas que el atacante defina, con independencia del daño reputacional que pudiera derivarse de la repercusión mediática de hechos similares.
Resulta obvio que el anterior ejemplo no es más que una idealización de la realidad, y que muchas empresas tienen controles adicionales para suplir deficiencias en el diseño (como pueda ser la utilización una capa de cifrado antes de transmitir ciertos parámetros), pero es que la realidad es caprichosa y, en ocasiones, supera a la ficción.
