Español | Deutsch | English

Diez reglas de oro para las verificaciones de autorización de ABAP

junio 7, 2016 | De Virtual Forge GmbH

Según el benchmark de aplicaciones empresariales de Virtual Forge y el estándar BIZEC APP/11, las verificaciones de autorización insuficientes son el fallo de seguridad más común en el código ABAP de cliente. En este blog facilitamos ideas para evitarlo

POR ANDREAS WIEGENSTEIN, VIRTUAL FORGE15_Ten_GoldenRules_Key-ea701a481.jpg

La seguridad de las aplicaciones continúa siendo un tema nuevo a la vez que misterioso para la mayoría de los desarrolladores de ABAP. Aunque Virtual Forge ha ofrecido numerosas charlas sobre la seguridad de SAP en conferencias (primera charla sobre seguridad de SAP con motivo de SAP TechEd en San Diego en 2004) y ha escrito un libro de referencia acerca de la programación ABAP segura («Sichere ABAP Programmierung», SAP Press, 2009), la mayoría de los desarrolladores de ABAP continúan desconociendo los riesgos comunes relacionados con la programación ABAP. No es de extrañar, puesto que prácticamente no ha habido ningún tipo de documentación útil sobre fallos de seguridad como la inyección de código SQL, la inyección de comandos de ABAP, Directory Traversal y Cross-Site Scripting en los lugares en los que suelen buscar los desarrolladores de SAP. Suponiendo que encuentren tiempo para buscar, desde luego. La disponibilidad de la documentación ha mejorado bastante. Este año (2013), SAP también ha empezado a publicar en su blog sobre las prácticas recomendadas en seguridad de código que ya describimos nosotros hace años en nuestro libro. A pesar del ligero retraso, esto resulta positivo para mejorar la concienciación en torno al tema en la comunidad de clientes de SAP.

Diez reglas de oro para las verificaciones de autorización de ABAP: seguridad de SAP, conformidad y calidad.

En el pasado, los roles y las autorizaciones eran sinónimos de seguridad en SAP. Cuando se hablaba con los desarrolladores de ABAP sobre la seguridad de ABAP, acostumbraban a concluir diciendo: nos referimos a las autorizaciones. Porque SAP es seguro y protege de forma mágica cualquier código del cliente. Afortunadamente, la mayoría de las empresas y de los desarrolladores de hoy día saben más que antes. Hemos de agradecer a los investigadores en seguridad de SAP las charlas que han ofrecido sobre seguridad técnica, lo que ha logrado que el público en general sea cada vez más consciente.

Pero aunque la mayoría de los desarrolladores de ABAP ya conocían hace años la importancia de las verificaciones de autorización, los fallos de autorización continúan siendo el riesgo de seguridad más común del código ABAP en la actualidad. Por eso es importante centrarse en este tema.

Puesto que sigue sin haber una documentación exhaustiva sobre el porqué, el cuándo y el cómo escribir verificaciones de autorización, publicamos una versión resumida de nuestras directrices internas sobre la seguridad de ABAP, a fin de crear conciencia y convertir el universo SAP en algo un poco más seguro.

Las reglas de oro de Virtual Forge para la codificación de las verificaciones de autorización en ABAP.

I. Realizar verificaciones de autorización
Por muy evidente que parezca, el primer paso para aplicar las autorizaciones es codificar la verificación de autorización. Puesto que SAP utiliza un modelo de autorización explícita, todas las verificaciones de autorización deben codificarse para poder ser ejecutadass. Si no hay ninguna verificación de autorización en el código, el sistema SAP no verificará autorización alguna (excepto en unos pocos casos). Las cifras en nuestros parámetros de referencia de aplicaciones empresariales son claras: la falta de verificaciones de autorización continúa siendo el fallo de seguridad más común relacionado con las autorizaciones en el código del cliente. También es bastante común en el sistema estándar de SAP (solo hay que echar un vistazo a las notas de seguridad de cualquiera de los días de aplicación de parches de SAP en 2013).

Recomendación general:

  • Consulte con el departamento comercial si se precisan autorizaciones (y cuáles) para ejecutar la lógica empresarial que usted proporciona
  • Como alternativa, analice código parecido a su proceso empresarial para las verificaciones de autorización.
  • Si se requieren verificaciones de autorización para la lógica empresarial del cliente, añádalas al código.

Recomendación especial:

  • No confíe en las autorizaciones S_RFC. Solo determinan *si* un módulo de funciones puede invocarse de forma remota. No están relacionadas de ningún modo con la lógica empresarial específica de su código del cliente. No querrá que los usuarios con autorizaciones S_RFC * puedan de emitir órdenes de compra ni de subir el sueldo de alguien. A los auditores tampoco les gustaría...
  • No confíe en los grupos de autorización asignados a los informes. Suelen ser genéricos, ya que un mismo grupo de autorización se usa en varios programas. Además, no están necesariamente relacionados con la lógica empresarial específica de su código de cliente.
  • Verifique siempre las autorizaciones iniciales (con el módulo de funciones AUTHORITY_CHECK_TCODE) cuando utilice CALL TRANSACTION, puesto que el kernel no efectúa ninguna verificación de autorización inicial explícita.
  1. Realizar verificaciones de autorización según las funciones estándar de SAP

Asegúrese de aplicar las autorizaciones utilizando únicamente el comando AUTHORITY-CHECK de ABAP o ejecutando las API que utilicen el comando AUTHORITY-CHECK de ABAP. Solo las verificaciones que se basen en AUTHORITY-CHECK aparecerán en el trace de autorizaciones y serán aceptadas por los auditores. La omisión de esta regla puede provocar un cambio radical en su carrera profesional.

Una mala práctica común es basar las autorizaciones en nombres de usuario o en entradas de tabla. Hemos visto que esto ocurría en el código de «las 4 grandes» empresas de auditoría.

Recomendación general:

  • Utilice siempre funciones basadas en el comando AUTHORITY-CHECK de ABAP para realizar las verificaciones de autorización.

III. Verificar el resultado de una verificación de autorización
Cuando se ejecuta instrucción AUTHORITY-CHECK de ABAP, el kernel de SAP verifica si el usuario, que tiene iniciada la sesión, dispone de la autorización necesaria. Asimismo, el kernel escribe una entrada en el trace de autorizaciones (transacción ST01) si este está activo. Si el usuario dispone de la autorización necesaria, la variable global sy-subrc se establece en cero. Por lo tanto, es importante verificar el estado de sy-subrc inmediatamente después de AUTHORITY-CHECK. De lo contrario, aparecerá una entrada en el trace de autorizaciones que sugiere una verificación reál, cuando en realidad esa verificación ni tan siquiera se ha aplicado.

Recomendación general:

  • Verifique siempre el resultado de sy-subrc tras haber ejecutado AUTHORITY-CHECK. sy-subrc con un valor cero significa una autorización suficiente.
  • Debido a que otros comandos ABAP también modifican la variable sy-subrc, asegúrese de efectuar la verificación de sy-subrc *inmediatamente* después del comando AUTHORITY-CHECK.
  1. Realizar verificaciones de autorización para el usuario con sesión iniciada
    El comando AUTHORITY-CHECK también puede utilizarse técnicamente para verificar si cualquiera de los usuarios (que no tenga la sesión iniciada) dispone de alguna autorización. Ello se lleva a cabo con la adición opcional de FOR USER. No obstante, esta práctica casi nunca es útil en los programas de cliente y debe evitarse.

Recomendación general:

  • Verifique únicamente la autorización del usuario con sesión iniciada (no utilizando el parámetro opcional FOR USER).
  1. Utilizar siempre las API en lugar de AUTHORITY-CHECK si existen
    Hay varias API de SAP para las verificaciones de autorización. Siempre que sepa que SAP proporciona una API (que se publica para clientes), utilice esa API en lugar de la verificación de autorización. Dichas API suelen realizar otras verificaciones importantes adicionales y SAP es quien se encarga de su mantenimiento en caso de que cambien los requisitos de este tipo de verificación de autorización.

Recomendación general:

  • Utilice siempre las funciones de API especializadas para las verificaciones de autorización en lugar de AUTHORITY-CHECK.

Recomendación específica:

  • Utilice AUTHORITY_CHECK_TCODE en lugar de S_TCODE
  • Utilice AUTHORITY_CHECK_DATASET en lugar de S_DATASET y S_PATH
  1. Declarar todos los campos del objeto de autorización
    Por desgracia, desde un punto de vista técnico, se pueden omitir campos (importantes) al realizar las verificaciones de autorización. En ese caso, la verificación de autorización se lleva a cabo, pero su alcance es limitado. Cuando codifique inicialmente las verificaciones de autorización, utilice el botón de patrón (“pattern”) de SAP. El patrón incluye de forma automática todos los campos del objeto de autorización. Sin embargo, los desarrolladores necesitan omitir a veces determinados campos de una verificación de autorización. Si fuera el caso, declare el campo, pero márquelo como DUMMY. ¿Por qué es más conveniente? Su intención queda clara si alguna otra persona lee el código. Si falta un campo, podría pensarse que olvidó declararlo. Si utiliza DUMMY, los demás saben que el campo no se ha considerado de forma intencionada.

Recomendación general:

  • Asegúrese siempre de especificar todos los campos del objeto de autorización que verifique.
  • Si hay campos que no desea verificar, márquelos como DUMMY para que sus intenciones sean explícitas.

VII. No utilizar valores DUMMY en campos importantes
Hay varios campos en los objetos de autorización que no deben marcarse como DUMMY (es decir, omitirse) en las verificaciones. ACTVT es un ejemplo de estas características. La actividad determina qué acción (p. ej., leer, cambiar, eliminar, etc.) se va a llevar a cabo. Si este campo se marca como DUMMY, los usuarios con permiso de lectura pueden verse en la situación de que podrían cambiar o eliminar objetos, en función de lo que haga realmente el código empresarial.

Recomendación general:

  • No utilice valores DUMMY en campos de autorización importantes como 'ACTVT'

VIII. No programar verificaciones de autorización con privilegios
A veces el «*» de los campos de autorización confunde a los desarrolladores porque su uso no es precisamente intuitivo. Para algunos, el siguiente código parece verificar si el usuario está autorizado a leer el informe especificado en la variable lv_prog, sin importar en qué paquete resida.

AUTHORITY-CHECK OBJECT 'S_DEVELOP'

  ID 'DEVCLASS' FIELD '*'
  ID 'OBJTYPE'  FIELD 'PROG'
  ID 'OBJNAME'  FIELD lv_prog
  ID 'P_GROUP'  DUMMY " Field not required in this context
  ID 'ACTVT'    FIELD '03'.

IF sy-subrc = 0.
  READ REPORT lv_prog INTO lt_code.
ENDIF.

Sin embargo, el valor «*» no significa que «la autorización se concede si el usuario tiene algún paquete asignado al campo DEVCLASS en su rol». Significa que «la autorización se concede si el usuario tiene asignado '*' al campo DEVCLASS en su rol», es decir, el usuario necesita el privilegio para acceder a todos los paquetes.

¿Cuál es el problema al respecto? Es sencillo: este tipo de codificación obliga a los administradores (de roles) a asignar a todos los usuarios que ejecuten este programa un privilegio «*» para las autorizaciones (de lectura) de S_DEVELOP. Ello resulta en privilegios innecesarios. Por lo tanto, considere siempre cuidadosamente qué valores utilizará en los campos de autorización.

Recomendación general:

  • Evite los valores «*» en los campos de autorización, ya que obligan a los administradores a otorgar a los usuarios unos privilegios innecesariamente altos
  1. Realizar verificaciones de autorización pronto en la lógica empresarial
    Esta práctica no es necesariamente una práctica recomendada relacionada con la seguridad. Sin embargo, ayuda a proporcionar una mayor facilidad de uso y a evitar cálculos innecesarios. Si para ejecutar una determinada lógica empresarial se requiere autorización, deberá verificarse de inmediato. Si los usuarios han de realizar varios pasos de un proceso solamente para averiguar que no están autorizados a pulsar el último botón, el equipo de desarrollo seguramente recibirá carbón para Reyes.

Recomendación general:

  • Si se requiere una verificación de autorización para una determinada lógica empresarial, dicha verificación debe realizarse lo antes posible
  1. Realizar verificaciones de autorización para evitar volcados.
    Algunos comandos ABAP incorporan una verificación de autorización implícita que realiza el kernel cuando se ejecutan. Dos ejemplos son OPEN DATASET y CALL 'SYSTEM'. Mientras que desde la perspectiva de la seguridad se trata de algo positivo, resulta negativo desde el punto de vista de la potencia, ya que el kernel vuelca si el usuario no dispone de la autorización adecuada.

Recomendación específica:

  • Asegúrese de probar siempre las autorizaciones de S_DATASET y S_PATH antes de abrir un fichero del lado servidor.

¿Por qué no recomendamos las verificaciones de S_C_FUNC antes de CALL 'SYSTEM'? Porque el uso de CALL 'SYSTEM' conduce al lado oscuro. No queremos animar a los desarrolladores a seguir ese camino...

Resumen
Siga las reglas de oro de Virtual Forge para codificar las verificaciones de autorización en ABAP. Las verificaciones de autorización adecuadas son una parte importante de la estrategia de seguridad de su empresa, ya que están en el ámbito de todas las actividades de auditoría basadas en el estándar de seguridad BIZEC APP/11.

Ya no hay excusas que justifiquen la falta de VERIFICACIONES DE AUTORIZACIÓN, ni que estas estén rotas o incompletas.
¡Conviértase en un Jedi de ABAP, nunca en un Sith!