Sécurisation des requêtes HTTP par lots SAP Fiori (OData) avec F5 Advanced WAF

Le protocole HTTP gère, dans une large mesure, le Web. Il s’agit du protocole de communication qui gère la majeure partie du trafic Internet. De nouvelles méthodes d’optimisation des communications Internet apparaissent, qu’elles soient cryptées, codées ou en texte clair via UDP ou TCP. Parmi elles, la possibilité de regrouper plusieurs requêtes HTTP en une seule requête. Le regroupement de plusieurs requêtes HTTP permet de limiter la charge utile et le temps d'aller-retour (RTT) d'une nouvelle requête, ce qui signifie qu'il permet d'économiser du temps et de l'argent.

Le regroupement de plusieurs requêtes HTTP est principalement utilisé pour regrouper divers appels d'API de transfert d'état représentatif (REST) par plusieurs protocoles et fournisseurs, parmi lesquels le protocole Open Data Protocol (OData). Norme ouverte permettant de créer et d'utiliser de manière simple des API REST interopérables et interrogeables, le protocole OData a été développé par Microsoft en 2007 et est utilisé et exploité dans les 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 dans une seule requête HTTP, ce qui permet d'économiser un temps réseau précieux et coûteux et de permettre à l'application de mieux utiliser la bande passante allouée.

Lorsqu'on tente de sécuriser des applications qui traitent par lots des requêtes HTTP, un défi se pose avec l'application des signatures d'attaque.

Il existe trois types différents de signatures d'attaque, en fonction de la partie de la requête à laquelle elles se rapportent :

• Signatures d'en-têtes
• Signatures d'URL
• Signatures de charge utile

Voici un exemple d’une telle demande :

La première requête contient d’autres requêtes HTTP, y compris ses en-têtes et ses URL.

Mais, lorsqu'un pare-feu d'application Web (WAF) traite une requête HTTP avec plusieurs requêtes groupées dans le cadre de la charge utile, il considérera toutes les requêtes groupées comme une seule charge utile. Par conséquent, il n'utilisera que des signatures liées à la charge utile, ce qui peut conduire à des faux positifs et à des attaques non détectées.

Dans F5 Advanced WAF v16.1, F5 a ajouté une analyse native et la prise en charge des requêtes HTTP par lots. Cela permet à Advanced WAF de distinguer chaque requête HTTP individuellement – et non collectivement dans un lot – et donc d’exécuter les signatures appropriées sur les bonnes parties de chaque requête.

F5 Advanced WAF protège tout le trafic OData ou autre avec des requêtes HTTP par lots sans risque de manquer des attaques ou de produire de nombreux faux positifs.

SAP exploite le protocole OData pour communiquer et interagir avec n'importe quelle application, logiciel ou appareil qui n'est pas une offre SAP. Comme OData est basé sur HTTPS, n’importe quel langage de programmation – et d’ailleurs, n’importe quel développeur – peut utiliser et communiquer avec un message OData. Cela permet à toute offre qui n'est pas une offre SAP de se connecter à SAP via HTTPS, car l'interface avec OData est basée 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 et Web natives qui offrent une expérience utilisateur cohérente et innovante sur toutes les plateformes. SAP Fiori offre une expérience utilisateur moderne sur n’importe quel appareil et pour chaque utilisateur. SAP Fiori offre aux utilisateurs une expérience de travail simple et productive, où qu'ils se trouvent. OData permet aux applications non SAP d'être intégrées et interopérables dans un environnement créé par SAP Fiori.

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 qui sont connectés à Internet et consomment des applications analytiques ou qui utilisent la recherche sur Internet.

Dans un blog publié par SAP, « Considérations et recommandations pour les applications Fiori orientées Internet », il est indiqué qu'un WAF « doit être placé devant le répartiteur Web SAP, surveillant et contrôlant toutes les requêtes HTTP entrantes », et qu'un WAF doit être déployé « entre un réseau interne de confiance et l'Internet non fiable ». Le blog poursuit en soulignant que, parmi les capacités de sécurité disponibles dans un WAF, il devrait arrêter les attaques par déni de service distribué (DDoS), en particulier « 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 avec une efficacité supérieure et une réduction des faux positifs.

Pour plus d'informations sur les solutions F5 pour SAP Fiori et S/4 HANA, veuillez consulter les éléments suivants :

Rapide et sécurisé : Migration SAP vers le Cloud (F5.com)
Atténuation des cyberattaques actives sur les applications SAP critiques | DevCentral (f5.com)

Pour plus d'informations sur SAP Fiori et l'application d'un WAF pour garantir la sécurité et réduire les faux positifs associés à SAP Fiori et son utilisation des requêtes par lots OData et HTTP, vous pouvez consulter les éléments suivants : Considérations et recommandations pour les applications Fiori accessibles sur Internet | Blogs SAP
Déploiement sur l'intranet ou sur Internet | Portail d'aide SAP

Contenu connexe 

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