Interface d’administration, back-office, tableau de bord (dashboard), panneau administrateur… plusieurs noms pour la même chose : l’endroit où les organisations gèrent leurs données, supervisent leur activité sur une plateforme web, répondent aux demandes de leurs clients, activent les comptes utilisateurs, configurent des articles pour une plateforme e-commerce…

Lorsque l’on pense à la sécurité des plateformes web, le back-office n’est pas forcément la priorité, pour plusieurs raisons. L’accès à ce type d’application est normalement restreint, aux services internes de l’organisation, et parfois à des tiers, supposés de confiance.

Naturellement, la priorité est donnée aux applications exposées au public, aussi connu en tant que « applications côté client » : site internet pour les clients, APIs, services web… tout ce qui est directement exposé. Ces « applications » ont la surface d’attaque la plus grande et de nombreuses fonctions avec un grand nombre d’éléments variés potentiellement vulnérables.

Quels sont les risques d’un back-office ?

Les attaques directes, depuis l’extérieur

Bien évidemment, un back-office peut être attaqué de front. Attaquer la fonction d’authentification est l’attaque la plus directe et évidente. Mais si la porte est robuste, qu’en est-il si la partie la plus faible est le mur ? Avoir accès à un élément interne d’un back office est parfois plus facile que l’on pense, même sans être identifié.

Les attaques directes, depuis l’interne

Les utilisateurs d’un back-office sont censés être digne de confiance. Mais le sont-ils ? Si plusieurs niveaux de droits (privilèges) ont été implémentés, cela peut valoir la peine de les tester. Pourquoi sinon mettre en place différents types de comptes et de droits ?

Des utilisateurs légitimes ont de nombreuses raisons potentielles de devenir « malveillant » à certains moments :

• Pour éviter une procédure qu’ils ne comprennent pas et qu’ils savent qu’ils peuvent court-circuiter, en utilisant une fonction à laquelle ils ne sont pas supposés avoir accès, mais à laquelle ils ont en fait accès…
• Pour avoir accès aux données d’un autre utilisateur, qui seront super utiles…

Pensez simplement à n’importe quel back-office que vous connaissez, visualisez les limites auxquelles les utilisateurs font face, et ensuite pensez à « les règles sont faites pour être brisées ».

Attaque indirecte, généralement depuis l’extérieur

Abordons maintenant les attaques indirectes. Les attaques de front ne sont simplement pas assez « marrantes » pour les hackers.

Supposons que la porte du back-office est solide comme le roc, les murs sont durs comme de la pierre, et les utilisateurs légitimes sont vraiment sympa et suivent les règles. Le monde parfait.

Les attaquants jouent avec le front-office (les applications utilisateurs standards) et injectent du contenu malicieux dans le site web, par le biais de n’importe quel champ ou envoi de donnée disponible pour eux. Avec un peu de magie (non pas vraiment), ce contenu malicieux qu’ils injectent apparait dans le back-office, où un administrateur travaille au même moment. Pas pour dire « bonjour », mais pour manipuler le serveur web, et avec un peu de chance voler leur « session » dans l’interface d’administration.

Parlant de manière imagée, cette attaque est un peu comme un colis piégé envoyé dans un bureau sécurisé avec un micro ou pire…

Ce scénario n’est pas de la théorie, nous trouvons et exploitons régulièrement ce type de vulnérabilité durant des évaluations de sécurité sur des plateformes web. Des exemples réels sont la prise d’une application de chatbot, qui rendait accessible de manière non-sécurisée les questions des utilisateurs dans le panneau d’administration, et la prise d’un site e-commerce qui avait un listing non-sécurisé de consommateurs, dans le back-office là aussi.

Au-delà du simple back-office

Les fonctions d’administration sont souvent liées à des services tiers, pour injecter des données live d’une plateforme web directement dans un autre système commercial. Par exemple, c’est une pratique courante de connecter un outil CRM à un site web, pour suivre les informations essentielles et optimiser les processus.

Si ce n’est pas configuré correctement, ce type d’interconnexion peut compromettre des systèmes plus grands. Ce type de vulnérabilité nous permet de prendre le contrôle de systèmes tiers critiques, par des attaques du front office d’un site web.

Tester des back-offices

Tester la fiabilité d’un back-office est par conséquent une exigence pour les organisations qui souhaitent sécuriser la totalité de leur plateforme.

Tester la totalité du back-office devrait être envisagé, mais avec des contraintes budgétaires strictes, limiter l’étendue des tests aux fonctions liées au front-office peut être une alternative.