Return
Rédigé le 2023-11-13 08:47
Nous avons reçu des requêtes quant à notre solution TiedApp concernant l’intégration des solutions telles que SharePoint/OneDrive, Google Docs, et autres solutions de stockage cloud. Ayant sondé le marché, nous nous sommes rendu compte que les solutions cloud les plus utilisées par les entreprises sont celles mises à disposition par Microsoft.
En surface, toutes les solutions cloud sont extraordinaires. Nous le pensons sincèrement. D’ailleurs, l’ensemble des fournisseurs de solutions cloud proposent des outils d’authentification forte (authentification à deux facteurs ou 2FA). Cependant, comme toute technologie créée par les humains, des failles sont possibles. Nous le savons et l’avons déjà entendu à plusieurs reprises : « le diable se cache dans les détails ». De ce fait, il était impossible pour nous de ne pas regarder dans le détail le fonctionnement des solutions de Microsoft afin d’assurer la sécurité intégrale des données des utilisateurs. Voici ce que nous avons découvert.
Pour intégrer les solutions Microsoft Graph, il est prérequis de créer un compte Azure, puis de s’inscrire au programme Microsoft Partner. Une fois ces étapes réalisées, nous avons commencé l’intégration des fonctionnalités Microsoft Graph dans une application test (lien en fin d’article). Durant l’intégration des fonctionnalités, nous avons constaté que les réponses aux requêtes liées au « DriveItem » obtenu après la connexion contiennent un élément répertorié sous « microsoft.graph.downloadUrl ». Ce lien est généré par les serveurs et a une durée de validité légèrement plus longue que le jeton d’accès de connexion de l’utilisateur. Nous avons pu déterminer que le lien était valable au moins 4 (quatre) heures après son émission.
Nous avons constaté que le downloadurl pouvait être utilisé pour télécharger la donnée qui y est liée sans avoir besoin d’authentifier l’utilisateur au préalable. Nous reviendrons sur ce point avec des vidéos démonstratives.
Afin de rester du côté de la force (hackers éthiques), nous avons décidé de signaler ce que nous avons découvert à Microsoft. N’étant pas au fait de la meilleure procédure, nous avons tout d’abord consulté la communauté StackOverflow (https://stackoverflow.com/questions/77360523/how-to-report-a-plausible-data-leak-related-to-microsoft-graph/77364255#77364255). Puis nous avons fini par signaler le problème identifié le dimanche 29/10/2023.
A la suite de ce mail automatique, nous avons été conviés à ne pas rendre le problème public durant 2 semaines tout au plus.
Quelques jours après avoir revu le signalement, nous avons reçu une réponse tout à fait surprenante car sujette à quelques questions. Si leur équipe a plausiblement résolu (clôturé) le problème en date du 7 novembre 2023, premièrement la nécessité de garder le signalement privé est réputée caduque, et deuxièmement il nous semblait nécessaire de vérifier si le problème avait bel et bien été résolu ou simplement rejeté. D’où la publication de l’ensemble de nos interactions dans cet article.La réponse de l’équipe en charge de vérifier le signalement nous semble très ambiguë. La partie de leur réponse surlignée, « Nous avons déterminé que ce comportement est considéré comme étant intentionnel et non comme un problème. » nous a certainement surpris, mais surtout, nous interroge sur le message direct sinon caché. Voici deux façons d’interpréter ce message :
1. Ce n’est pas un problème généré par Microsoft mais par vous.
2. Nous ne considérons pas que ce soit un problème car nous avons designé nos solutions pour fonctionner ainsi.
En considérant attentivement la première option, nous avons donc décidé de réaliser un premier test directement depuis le site de Microsoft grâce aux outils fournis pour les développeurs et intégrateurs (les liens en fin d’article). Dans cette vidéo, il est aisé de constater que le « downloadurl » mentionné dans le signalement est utilisable depuis leur site internet, qui n’a rien à voir avec la solution applicative que nous avons développée pour montrer la problématique.
De ce fait, si le problème signalé ne vient pas de nous, pouvons-nous considérer que Microsoft, malgré ce signalement, a choisi d’ignorer le problème ?
Pour ceux qui n’auront pas eu la patience de regarder la vidéo jusqu’à la fin, voici en détail le problème que nous avons identifié :
1. Après la connexion à votre compte, il est possible de télécharger la liste du contenu de votre OneDrive ou SharePoint (https://learn.microsoft.com/fr-fr/graph/api/driveitem-list-children?view=graph-rest-1.0&tabs=http).
2. Le contenu reçu via une requête HTTPS contient notamment le « downloadurl ».
3. Le « downloadurl » ne nécessite aucune forme d’authentification pour accéder au fichier car même en navigation privée on peut télécharger le fichier.
4. Plus tard, nous découvrirons que ce même « downloadurl » peut être stocké dans un fichier texte.
5. En complément du point précédent, il est important de noter que le lien peut être stocké n’importe où, par n’importe quel moyen.
6. Durant la période que nous avons mesurée de 4 (quatre) heures environ après authentification, en utilisant même le 2FA, le lien permet à quiconque de télécharger la donnée sans aucunes restrictions. C’est à se demander à quoi servent les fonctionnalités dites sécurisées de partage de document à des personnes ou à des groupes.
7. Le lien peut être envoyé par mail, posté sur un serveur, utilisé pour télécharger tous les fichiers de votre SharePoint/OneDrive et est utilisable depuis n’importe quel appareil dans le monde. Et tout ceci, sans votre autorisation ni consentement.
8. Et si par malheur l’intégrateur décide de passer du côté obscur de la force, il pourrait même créer un code qui scannerait dès votre authentification tous les « downloadurl » de tous les fichiers de votre SharePoint/OneDrive. Pour quelle raison ? Cela n’a aucune importance, car si la possibilité de le faire est maintenue par Microsoft, pourquoi s’en priverait-il ?
Pour revenir à la réponse de l’équipe MSRC, nous nous sommes donc de nouveau interrogés. Est-ce un comportement qui est designé intentionnellement ? Si non, pourquoi ignorer le signalement et feindre que le problème est créé artificiellement par nous ? Et si c’est le cas, comment se fait-il qu’il n’ait pas été résolu alors que l’équipe MSRC prétend que si ?
Pour démonter dans un environnement de production que le problème persiste, nous nous sommes munis du logiciel Fiddler qui permet de scanner les requêtes du réseau. Nous avons ainsi pu démontrer que le problème persiste et se manifeste de la même façon dont il a été signalé originellement à Microsoft, tout comme exposé dans le README.md du projet GitHub (lien en fin d’article)..png)
.png)
.png)
.png)
Le test via le logiciel Fiddler a déterminé que le problème est bel et bien présent et que rien n’a été résolu. Pour déchiffrer les requêtes reçues en HTTPS, le logiciel Fiddler nécessite l’activation d’une fonctionnalité (lien en fin d’article). D’où notre intégration. N’étant pas experts en sécurité réseau, nous nous sommes posé la question suivante :
Si un logiciel légitime comme Fiddler est capable de déchiffrer toutes les requêtes HTTPS, combien de fois un malware sur un ordinateur infecté, designé pour l’occasion, permettrait de le faire ? Et si ce malware existe, qu’advient-il des downloadurl récupérés ?
Nous avons affirmé précédemment que la récolte du downloadurl entraine un risque de téléchargement de vos données sans votre consentement. Afin de montrer que le problème persiste, nous avons décidé de faire d’autres tests sur l’utilisation de cette information sensible.
Le but du test de la vidéo ci-dessous est de démontrer comment la transmission du downloadurl et la récupération du même lien permet de le télécharger, depuis n’importe quel appareil, sans que les fonctionnalités d’authentification, simple ou à double facteur, ne soit nécessaires. UN RISQUE BEAUCOUP TROP IMPORTANT POUR ÊTRE IGNORÉ SELON NOUS. Nous nous sommes donc demandé comment notre signalement a pu être rejeté du revers de la main sans aucune considération malgré le message souligné dans l’image ci-après.
.png)
Aussi surprenant que ce soit, lorsqu’on essaye d’utiliser le downloadurl 4 (quatre) heures environ après l’authentification, on obtient finalement la réponse qu’on aurait dû obtenir à chaque fois qu’on l’a utilisé sans utiliser le jeton d’accès et sur l’ensemble des appareils utilisés lors de nos tests. C’est à se demander si l’authentification par mot de passe et par Microsoft Authenticator (2FA) ne sont que vaines illusions de sécurité au regard de tout ce qui a été exposé jusqu’à présent.
Il est toujours plus facile d’accuser plus faible ou moins important que soi. Ce ne sont pas des paroles en l’air, c’est simplement un fait. La réponse de l’équipe MSRC nous laisse à penser que Microsoft pourrait être amené à rejeter la faute d’une plausible fuite d’information sur les intégrateurs, car ceux-ci n’ont pas suivi le protocole qu’il fallait.
D’où la nécessité de s’interroger sur le point de vue. Le problème lié à une plausible fuite de données est-il de la responsabilité de l’intégrateur ? Est-il de la responsabilité de Microsoft ? Si l’intégrateur choisit un protocole conformément à un tutoriel et que ce tutoriel intègre lui-même une faille de sécurité, que l’intégrateur a signalée mais le problème n’a pas été résolu, en cas de faille, qui doit porter la responsabilité ? Et ceci est la raison pour laquelle…
Depuis très longtemps, notre solution TiedApp (anciennement appelée ACM Pro), permet d’assurer la sécurité de vos données. Nous ne vous demandons pas de nous croire sur parole, mais de tester nos solutions par vous-mêmes après avoir regardé la vidéo ci-dessous. Dans cette vidéo, nous avons utilisé la même méthode de scan du réseau via le logiciel Fiddler pour récupérer la réponse de la requête de téléchargement des données. Notre protocole assure la sécurité de vos données sur plusieurs aspects :
1. L’authentification au Serveur TiedApp est confirmée via le jeton d’accès de la session de l’utilisateur par le protocole SignalR (merci à Microsoft pour cet outil extraordinaire). Sans cette validation, aucune requête ne peut être déclenchée dans notre application.
2. Les fichiers envoyés et téléchargés sont protégés par une clé de chiffrement unique à chaque application. Il est donc extrêmement difficile de les exploiter même si la requête est scannée par des malwares ou logiciels tels que Fiddler.
Nous l’avons entendu très souvent avant d’accepter de commencer l’intégration des outils Microsoft : « Microsoft est très orgueilleux de la sécurité de ses systèmes ». Cet argument est légitime. Oui, nous le pensons aussi. Sur de nombreux aspects, ils font partie du podium en termes de sécurité. Ceci est vrai si on ignore que le diable se cache dans les détails et que certains détails sont amers à considérer car ne flattent pas l’orgueil. Mais ce n’est pas à nous d’en juger. C’est à Microsoft qui a reçu cette publication en priorité le 08/11/2023 via le même canal de communication avec l’équipe MSRC avant que l’article ne soit publié sur notre site..png)
.png)
C’est également à vous de juger si nous avons tort de penser que le problème n’a pas été résolu, mais qu’il a plutôt été détourné en pointant du doigt tous les intégrateurs comme nous.
La grande question est de savoir si le marché de la revente de données s’applique également aux données d’entreprises ? Si oui, est-ce la raison pour laquelle une telle faille est ignorée par Microsoft ? Existe-t-il un marché de revente de données d’entreprises ? S’agit d’une forme d’espionnage encore ignorée de tous qui consiste à utiliser toutes les données stockées sur le cloud, y compris par les entreprises ? Si oui, dans quel but ?
En supposant que le problème tel que présenté soit résolu dans le futur, ne serions-nous pas appelés à penser qu’il a juste été déplacé ailleurs ?
Seul l’avenir nous le dira.
1. Lien de l’application test envoyé à Microsoft pour signaler ce que nous considérons comme "faille" (Essayez l’application par vous-même) https://github.com/flaubertlekhem/MyOndriveConnect
2. Daté du 10/27/2023, tutoriel fourni par Microsoft "Obtenir une ressource driveItem" https://learn.microsoft.com/fr-fr/graph/api/driveitem-get?view=graph-rest-1.0&tabs=http
3. Daté du 30/10/2023, tutoriel fourni par Microsoft "Télécharger le contenu d’une ressource DriveItem" https://learn.microsoft.com/fr-fr/graph/api/driveitem-get-content?view=graph-rest-1.0&tabs=http
4. Tutoriel fourni par Telerik Fiddler "Configure Fiddler Classic to Decrypt HTTPS Traffic" https://docs.telerik.com/fiddler/configure-fiddler/tasks/decrypthttps
Tentez par vous-même de déchiffrer les bites retournées dans le fichier texte que vous pouvez télécharger via ce lien ci-après:
Click to download: FileByte of data download from our server - Try to open it.txt
Découvrez l’historique des mises à jour de l’application TiedApp ici https://tiedapp.com/TiedAppversions
Nous avons mis à jour les conditions d’utilisation de nos solutions. Consultez les ici https://tiedapp.com/Footer/TermsOfUse
Return
Rédigé le 2023-11-13 08:47
Nous avons reçu des requêtes quant à notre solution TiedApp concernant l’intégration des solutions telles que SharePoint/OneDrive, Google Docs, et autres solutions de stockage cloud. Ayant sondé le marché, nous nous sommes rendu compte que les solutions cloud les plus utilisées par les entreprises sont celles mises à disposition par Microsoft.
En surface, toutes les solutions cloud sont extraordinaires. Nous le pensons sincèrement. D’ailleurs, l’ensemble des fournisseurs de solutions cloud proposent des outils d’authentification forte (authentification à deux facteurs ou 2FA). Cependant, comme toute technologie créée par les humains, des failles sont possibles. Nous le savons et l’avons déjà entendu à plusieurs reprises : « le diable se cache dans les détails ». De ce fait, il était impossible pour nous de ne pas regarder dans le détail le fonctionnement des solutions de Microsoft afin d’assurer la sécurité intégrale des données des utilisateurs. Voici ce que nous avons découvert.
Pour intégrer les solutions Microsoft Graph, il est prérequis de créer un compte Azure, puis de s’inscrire au programme Microsoft Partner. Une fois ces étapes réalisées, nous avons commencé l’intégration des fonctionnalités Microsoft Graph dans une application test (lien en fin d’article). Durant l’intégration des fonctionnalités, nous avons constaté que les réponses aux requêtes liées au « DriveItem » obtenu après la connexion contiennent un élément répertorié sous « microsoft.graph.downloadUrl ». Ce lien est généré par les serveurs et a une durée de validité légèrement plus longue que le jeton d’accès de connexion de l’utilisateur. Nous avons pu déterminer que le lien était valable au moins 4 (quatre) heures après son émission.
Nous avons constaté que le downloadurl pouvait être utilisé pour télécharger la donnée qui y est liée sans avoir besoin d’authentifier l’utilisateur au préalable. Nous reviendrons sur ce point avec des vidéos démonstratives.
Afin de rester du côté de la force (hackers éthiques), nous avons décidé de signaler ce que nous avons découvert à Microsoft. N’étant pas au fait de la meilleure procédure, nous avons tout d’abord consulté la communauté StackOverflow (https://stackoverflow.com/questions/77360523/how-to-report-a-plausible-data-leak-related-to-microsoft-graph/77364255#77364255). Puis nous avons fini par signaler le problème identifié le dimanche 29/10/2023.
A la suite de ce mail automatique, nous avons été conviés à ne pas rendre le problème public durant 2 semaines tout au plus.
Quelques jours après avoir revu le signalement, nous avons reçu une réponse tout à fait surprenante car sujette à quelques questions. Si leur équipe a plausiblement résolu (clôturé) le problème en date du 7 novembre 2023, premièrement la nécessité de garder le signalement privé est réputée caduque, et deuxièmement il nous semblait nécessaire de vérifier si le problème avait bel et bien été résolu ou simplement rejeté. D’où la publication de l’ensemble de nos interactions dans cet article.La réponse de l’équipe en charge de vérifier le signalement nous semble très ambiguë. La partie de leur réponse surlignée, « Nous avons déterminé que ce comportement est considéré comme étant intentionnel et non comme un problème. » nous a certainement surpris, mais surtout, nous interroge sur le message direct sinon caché. Voici deux façons d’interpréter ce message :1. Ce n’est pas un problème généré par Microsoft mais par vous.
2. Nous ne considérons pas que ce soit un problème car nous avons designé nos solutions pour fonctionner ainsi.
En considérant attentivement la première option, nous avons donc décidé de réaliser un premier test directement depuis le site de Microsoft grâce aux outils fournis pour les développeurs et intégrateurs (les liens en fin d’article). Dans cette vidéo, il est aisé de constater que le « downloadurl » mentionné dans le signalement est utilisable depuis leur site internet, qui n’a rien à voir avec la solution applicative que nous avons développée pour montrer la problématique.
De ce fait, si le problème signalé ne vient pas de nous, pouvons-nous considérer que Microsoft, malgré ce signalement, a choisi d’ignorer le problème ?
Pour ceux qui n’auront pas eu la patience de regarder la vidéo jusqu’à la fin, voici en détail le problème que nous avons identifié :
1. Après la connexion à votre compte, il est possible de télécharger la liste du contenu de votre OneDrive ou SharePoint (https://learn.microsoft.com/fr-fr/graph/api/driveitem-list-children?view=graph-rest-1.0&tabs=http).
2. Le contenu reçu via une requête HTTPS contient notamment le « downloadurl ».
3. Le « downloadurl » ne nécessite aucune forme d’authentification pour accéder au fichier car même en navigation privée on peut télécharger le fichier.
4. Plus tard, nous découvrirons que ce même « downloadurl » peut être stocké dans un fichier texte.
5. En complément du point précédent, il est important de noter que le lien peut être stocké n’importe où, par n’importe quel moyen.
6. Durant la période que nous avons mesurée de 4 (quatre) heures environ après authentification, en utilisant même le 2FA, le lien permet à quiconque de télécharger la donnée sans aucunes restrictions. C’est à se demander à quoi servent les fonctionnalités dites sécurisées de partage de document à des personnes ou à des groupes.
7. Le lien peut être envoyé par mail, posté sur un serveur, utilisé pour télécharger tous les fichiers de votre SharePoint/OneDrive et est utilisable depuis n’importe quel appareil dans le monde. Et tout ceci, sans votre autorisation ni consentement.
8. Et si par malheur l’intégrateur décide de passer du côté obscur de la force, il pourrait même créer un code qui scannerait dès votre authentification tous les « downloadurl » de tous les fichiers de votre SharePoint/OneDrive. Pour quelle raison ? Cela n’a aucune importance, car si la possibilité de le faire est maintenue par Microsoft, pourquoi s’en priverait-il ?
Pour revenir à la réponse de l’équipe MSRC, nous nous sommes donc de nouveau interrogés. Est-ce un comportement qui est designé intentionnellement ? Si non, pourquoi ignorer le signalement et feindre que le problème est créé artificiellement par nous ? Et si c’est le cas, comment se fait-il qu’il n’ait pas été résolu alors que l’équipe MSRC prétend que si ?
Pour démonter dans un environnement de production que le problème persiste, nous nous sommes munis du logiciel Fiddler qui permet de scanner les requêtes du réseau. Nous avons ainsi pu démontrer que le problème persiste et se manifeste de la même façon dont il a été signalé originellement à Microsoft, tout comme exposé dans le README.md du projet GitHub (lien en fin d’article).
Le test via le logiciel Fiddler a déterminé que le problème est bel et bien présent et que rien n’a été résolu. Pour déchiffrer les requêtes reçues en HTTPS, le logiciel Fiddler nécessite l’activation d’une fonctionnalité (lien en fin d’article). D’où notre intégration. N’étant pas experts en sécurité réseau, nous nous sommes posé la question suivante :Si un logiciel légitime comme Fiddler est capable de déchiffrer toutes les requêtes HTTPS, combien de fois un malware sur un ordinateur infecté, designé pour l’occasion, permettrait de le faire ? Et si ce malware existe, qu’advient-il des downloadurl récupérés ?
Nous avons affirmé précédemment que la récolte du downloadurl entraine un risque de téléchargement de vos données sans votre consentement. Afin de montrer que le problème persiste, nous avons décidé de faire d’autres tests sur l’utilisation de cette information sensible.
Le but du test de la vidéo ci-dessous est de démontrer comment la transmission du downloadurl et la récupération du même lien permet de le télécharger, depuis n’importe quel appareil, sans que les fonctionnalités d’authentification, simple ou à double facteur, ne soit nécessaires. UN RISQUE BEAUCOUP TROP IMPORTANT POUR ÊTRE IGNORÉ SELON NOUS. Nous nous sommes donc demandé comment notre signalement a pu être rejeté du revers de la main sans aucune considération malgré le message souligné dans l’image ci-après.
Aussi surprenant que ce soit, lorsqu’on essaye d’utiliser le downloadurl 4 (quatre) heures environ après l’authentification, on obtient finalement la réponse qu’on aurait dû obtenir à chaque fois qu’on l’a utilisé sans utiliser le jeton d’accès et sur l’ensemble des appareils utilisés lors de nos tests. C’est à se demander si l’authentification par mot de passe et par Microsoft Authenticator (2FA) ne sont que vaines illusions de sécurité au regard de tout ce qui a été exposé jusqu’à présent.Il est toujours plus facile d’accuser plus faible ou moins important que soi. Ce ne sont pas des paroles en l’air, c’est simplement un fait. La réponse de l’équipe MSRC nous laisse à penser que Microsoft pourrait être amené à rejeter la faute d’une plausible fuite d’information sur les intégrateurs, car ceux-ci n’ont pas suivi le protocole qu’il fallait.
D’où la nécessité de s’interroger sur le point de vue. Le problème lié à une plausible fuite de données est-il de la responsabilité de l’intégrateur ? Est-il de la responsabilité de Microsoft ? Si l’intégrateur choisit un protocole conformément à un tutoriel et que ce tutoriel intègre lui-même une faille de sécurité, que l’intégrateur a signalée mais le problème n’a pas été résolu, en cas de faille, qui doit porter la responsabilité ? Et ceci est la raison pour laquelle…
Depuis très longtemps, notre solution TiedApp (anciennement appelée ACM Pro), permet d’assurer la sécurité de vos données. Nous ne vous demandons pas de nous croire sur parole, mais de tester nos solutions par vous-mêmes après avoir regardé la vidéo ci-dessous. Dans cette vidéo, nous avons utilisé la même méthode de scan du réseau via le logiciel Fiddler pour récupérer la réponse de la requête de téléchargement des données. Notre protocole assure la sécurité de vos données sur plusieurs aspects :
1. L’authentification au Serveur TiedApp est confirmée via le jeton d’accès de la session de l’utilisateur par le protocole SignalR (merci à Microsoft pour cet outil extraordinaire). Sans cette validation, aucune requête ne peut être déclenchée dans notre application.
2. Les fichiers envoyés et téléchargés sont protégés par une clé de chiffrement unique à chaque application. Il est donc extrêmement difficile de les exploiter même si la requête est scannée par des malwares ou logiciels tels que Fiddler.
Nous l’avons entendu très souvent avant d’accepter de commencer l’intégration des outils Microsoft : « Microsoft est très orgueilleux de la sécurité de ses systèmes ». Cet argument est légitime. Oui, nous le pensons aussi. Sur de nombreux aspects, ils font partie du podium en termes de sécurité. Ceci est vrai si on ignore que le diable se cache dans les détails et que certains détails sont amers à considérer car ne flattent pas l’orgueil. Mais ce n’est pas à nous d’en juger. C’est à Microsoft qui a reçu cette publication en priorité le 08/11/2023 via le même canal de communication avec l’équipe MSRC avant que l’article ne soit publié sur notre site.
C’est également à vous de juger si nous avons tort de penser que le problème n’a pas été résolu, mais qu’il a plutôt été détourné en pointant du doigt tous les intégrateurs comme nous.La grande question est de savoir si le marché de la revente de données s’applique également aux données d’entreprises ? Si oui, est-ce la raison pour laquelle une telle faille est ignorée par Microsoft ? Existe-t-il un marché de revente de données d’entreprises ? S’agit d’une forme d’espionnage encore ignorée de tous qui consiste à utiliser toutes les données stockées sur le cloud, y compris par les entreprises ? Si oui, dans quel but ?
En supposant que le problème tel que présenté soit résolu dans le futur, ne serions-nous pas appelés à penser qu’il a juste été déplacé ailleurs ?
Seul l’avenir nous le dira.
1. Lien de l’application test envoyé à Microsoft pour signaler ce que nous considérons comme "faille" (Essayez l’application par vous-même) https://github.com/flaubertlekhem/MyOndriveConnect
2. Daté du 10/27/2023, tutoriel fourni par Microsoft "Obtenir une ressource driveItem" https://learn.microsoft.com/fr-fr/graph/api/driveitem-get?view=graph-rest-1.0&tabs=http
3. Daté du 30/10/2023, tutoriel fourni par Microsoft "Télécharger le contenu d’une ressource DriveItem" https://learn.microsoft.com/fr-fr/graph/api/driveitem-get-content?view=graph-rest-1.0&tabs=http
4. Tutoriel fourni par Telerik Fiddler "Configure Fiddler Classic to Decrypt HTTPS Traffic" https://docs.telerik.com/fiddler/configure-fiddler/tasks/decrypthttps
Tentez par vous-même de déchiffrer les bites retournées dans le fichier texte que vous pouvez télécharger via ce lien ci-après:
Click to download: FileByte of data download from our server - Try to open it.txt
Découvrez l’historique des mises à jour de l’application TiedApp ici https://tiedapp.com/TiedAppversions
Nous avons mis à jour les conditions d’utilisation de nos solutions. Consultez les ici https://tiedapp.com/Footer/TermsOfUse
Return