Le protocole HTTP fait fonctionner l’essentiel du Web. C’est le protocole de communication qui prend en charge la majeure partie du trafic Internet. De nouvelles méthodes d’optimisation réseau des communications Internet voient le jour, qu’elles soient chiffrées, encodées ou transmises en clair via UDP ou TCP. Parmi elles figure la possibilité de regrouper plusieurs requêtes HTTP en une seule. Ce regroupement permet de réduire la surcharge liée à la charge utile ainsi que le temps d’aller-retour (RTT) d’une nouvelle requête, ce qui représente un gain de temps et d’argent.
Le regroupement de plusieurs requêtes HTTP sert principalement à rassembler différents appels d’API de transfert d’état représentationnel (REST) provenant de divers protocoles et fournisseurs, notamment l’Open Data Protocol (OData). Norme ouverte permettant de créer et d’utiliser facilement des API REST interopérables et interrogeables, le protocole OData a été développé par Microsoft en 2007 et est utilisé et exploité dans des applications de Microsoft, SAP et d’autres fournisseurs.
Dans le cadre de la spécification OData, plusieurs appels d’API REST via HTTP peuvent être regroupés en une seule requête HTTP, ce qui permet d’économiser un temps réseau précieux et coûteux et à l’application de mieux utiliser la bande passante allouée.
Lorsqu’on cherche à sécuriser des applications qui regroupent des requêtes HTTP par lots, l’application des signatures d’attaque pose problème.
Il existe trois types différents de signatures d’attaque, selon la partie de la requête à laquelle elles s’appliquent :
- Signatures d’en-têtes
- Signatures d’URL
- Signatures de charge utile
Voici un exemple d’une telle requête :
La première requête contient d’autres requêtes HTTP, notamment leurs en-têtes et leurs URL.
Cependant, lorsqu’un pare-feu d’application web (WAF) traite une requête HTTP dont la charge utile contient plusieurs requêtes regroupées, il considère l’ensemble de ces requêtes comme une seule charge utile. Il utilise donc uniquement les signatures liées à la charge utile, ce qui peut entraîner des faux positifs et laisser certaines attaques passer inaperçues.
Dans F5 Advanced WAF v16.1, F5 a ajouté l’analyse native et la prise en charge des requêtes HTTP groupées. Advanced WAF peut ainsi distinguer chaque requête HTTP individuellement, plutôt que de les traiter collectivement comme un lot, et donc appliquer les signatures appropriées aux parties concernées de chaque requête.
F5 Advanced WAF protège l’ensemble du trafic OData ou de tout autre trafic utilisant des requêtes HTTP par lots, sans risque de ne pas détecter certaines attaques ni de générer de nombreux faux positifs.
SAP s’appuie sur le protocole OData pour communiquer et interagir avec toute application, tout logiciel ou tout appareil qui ne fait pas partie de son offre. OData reposant sur HTTPS, n’importe quel langage de programmation — et, de fait, n’importe quel développeur — peut utiliser un message OData et communiquer avec celui-ci. Toute solution ne faisant pas partie de l’offre SAP peut ainsi se connecter à SAP via HTTPS, l’interface OData reposant sur XML ou JSON.
SAP Fiori fournit des outils qui permettent aux concepteurs et aux développeurs de créer et d’optimiser des applications mobiles natives et des applications Web offrant une expérience utilisateur cohérente et innovante sur toutes les plateformes. SAP Fiori offre une expérience utilisateur moderne sur tous les appareils et pour chaque utilisateur. SAP Fiori permet aux utilisateurs de travailler simplement et efficacement où qu’ils se trouvent. OData permet d’intégrer des applications non-SAP dans un environnement créé avec SAP Fiori et d’assurer leur interopérabilité.
Si l’interopérabilité et la facilité des communications sont essentielles, la sécurité l’est tout autant, en particulier pour les déploiements SAP Fiori accessibles depuis Internet et qui utilisent des applications analytiques ou effectuent des recherches sur Internet.
Dans un article de blog publié par SAP, intitulé « Considérations et recommandations pour les applications Fiori accessibles depuis Internet », il est indiqué qu’un WAF « doit être placé devant SAP Web Dispatcher afin de surveiller et de contrôler toutes les requêtes HTTP entrantes », et qu’il doit être déployé « entre un réseau interne de confiance et l’Internet non fiable ». L’article précise également que, parmi les fonctions de sécurité offertes par un WAF, celui-ci doit bloquer les attaques par déni de service distribué (DDoS), notamment « afin qu’elles ne puissent pas atteindre votre système SAP S/4HANA ».
La prise en charge du protocole OData par F5 Advanced WAF permet aux clients de protéger les applications SAP plus efficacement tout en réduisant les faux positifs.
Pour plus d’informations sur les solutions F5 pour SAP Fiori et S/4 HANA, veuillez consulter les ressources suivantes :
Rapide et sécurisée : migration de SAP vers le cloud (F5.com)
Atténuation des cyberattaques actives visant les applications SAP critiques | DevCentral (f5.com)
Pour plus d’informations sur SAP Fiori et sur l’utilisation d’un WAF afin de garantir la sécurité et de réduire les faux positifs liés à SAP Fiori ainsi qu’à son utilisation d’OData et des requêtes HTTP par lots, vous pouvez consulter les ressources suivantes : Considérations et recommandations relatives aux applications Fiori accessibles depuis Internet | SAP Blogs
Déploiement sur l’intranet ou sur Internet | Portail d’aide SAP
Contenu associé
OData – Tout ce que vous devez savoir : partie 1 | Blogs SAP
OData – Tout ce que vous devez savoir : partie 2 | Blogs SAP
OData – Tout ce que vous devez savoir : partie 3 | Blogs SAP
À propos de l’auteur
Articles de blog associés
F5 NGINXaaS pour Google Cloud : des applications résilientes et évolutives
Découvrez comment NGINXaaS s’intègre à Google Cloud pour renforcer les performances et la sécurité, et préparer vos applications critiques à un avenir propulsé par l’IA.
L’intégration de F5 Web Application Firewall (WAF) à AWS est disponible dès aujourd’hui
En faisant appel à un partenaire de déploiement AWS WAF tel que F5, vous pouvez renforcer la sécurité de vos applications web grâce à des règles personnalisées qui bloquent les schémas d’attaque courants, comme les injections SQL ou les attaques par scripts intersites (XSS).
Appliquer le principe de Peter Parker à l’inspection TLS
« Un grand pouvoir implique de grandes responsabilités. » Si l’on en trouve des échos chez Voltaire et Churchill, cette citation est surtout connue grâce aux bandes dessinées Spider-Man, où elle est attribuée à l’oncle Ben. Bien entendu, si cette phrase est si répandue dans la culture populaire, c’est notamment parce qu’elle peut s’appliquer à une multitude de situations et de sujets, y compris à l’inspection TLS.
Le NetOps a besoin de défenseurs, pas d’adversaires
Il est important de reconnaître que les équipes NetOps ne sont pas toujours celles qui font obstacle au déploiement de la dernière nouveauté, application ou service. Les freins à la rapidité sont souvent dus au fait que les organisations n’adoptent pas tous les principes du DevOps lorsqu’elles cherchent à transformer leurs opérations informatiques.
Mise à jour des services applicatifs : sécurité, rapidité et visiteurs suspects
Il est de nouveau temps de nous pencher sur les services applicatifs que les entreprises utilisent réellement pour rendre leurs applications plus rapides et plus sûres. On constate notamment une hausse du recours aux services de protection contre les bots, ainsi que la progression lente mais régulière de HTTP/2. Bien qu’il ne s’agisse pas d’une application…
Les templates prennent le contrôle du cloud
Les modèles s’imposent dans le cloud. Lisez le blog de F5 pour découvrir comment l’infrastructure en tant que code et les API déclaratives automatisent la mise à disposition des applications.