Bonjour à tous. Je souhaiterai empêcher de sniffer les requetes http de mon appli. Ces "sniffs" sont réalisés à l'aide d'outils d'interception de packets (wireshark , httpdebuggerpro ...) Y a t-il une possibilité? Merci d'avance pour toute idée pouvant me mettre sur la voie.
I don't think if it has a relation with windev, but you do the following steps to prevent a sniffer : Encrypt everything you send or receive using antivirus Scan your networks for any issues or dangers Use only trusted wifi networks
Bonjour, HTTPS pour commencer. En fait, la meilleure protection contre ce type d’attaque est d’utiliser un protocole de communication sécurisé. Après, pour les bases de donnes ça dépend de type de connexion ODBC, OLE DB, HFSQL SQLServer, MYSQL ... Pour MYSQL par exemple "pour certains accès comme la supervision, le management à distance en CLI, les sauvegardes ou la réplication, il est fortement conseillé de mettre en place un accès chiffré vers le port 3306." Regarde par Bonjour visiteur, Merci de vous Inscrire ou de vous connectez pour voir les liens! Dans mon cas j'utilise un VPS que j'ai installé et configuré moi-même de A à Z. Si c'est pas le cas alors tu dois vérifier les protocoles de sécurité installés sur le serveur au près de ton fournisseur. Bon Dev.
Merci channibal pour ces infos. Je tiens à préciser que mon appli réalise des http requetes sur plusieurs sites internet pour récupérer des infos. Ces sites ne m'appartiennent pas et la concurrence lance juste un sniffer sur mon appli pour retrouver les urls que j'attaque. Je remarque sur certaines appli que dès que je mets un sniffer, l'appli ne répond plus ou tout simplement je ne vois rien dans le sniffer. Merci encore pour l'intérêt.
Dans ce cas je crois que tu devrais travailler sur 2 niveaux: 1 - Les requêtes HTTP lancées par l'application. Les protocoles et les paquets doivent donc être sécurisés et cryptés, ce qui devrait être réalisable dans ton application, c'est évident. 2 - Le réseau ou les réseaux A ce niveau c'est plus compliqué de mettre en place une stratégie de sécurisation. On ne maitrise pas à 100% la sécurité du réseau (ou des réseaux) sur lequel l'appli est lancée et les paquets transitent, le risque reste présent et permanent, mais il y a toujours des solutions surement. Sinon, ce que je te suggère fortement, c'est la solution de passer par le biais d'un Webservices de type REST. Il y a du boulot a faire mais c'est très intéressant si tu utilisera ton propre serveur (un VPS par exemple) pour déployer le webservice. Dans ce cas c'est ton serveur (webservice) qui va communiquer, dans les 2 sens, avec les sites tierces. Et là je m'inspire de la solution de Fabrice Harari. Et de son explication aussi. Regarde le projet WXReplication qui utilise un Webservice pour réaliser plusieurs taches, il énumère plusieurs types de sécurisation sur plusieurs niveaux. Pour CHAQUE communication entre client et webservice: - Le client prépare le paquet à envoyer (une chaîne pas XML, mais ça pourrait être du xml sans rien changer) - le client encrypte la chaine - le client envoie la chaine au webservice - le webservice recoit la chaine - le webservice décrypte la chaine - le webservice traite la chaine et ca repart dans l'autre sens... Ca, c'est un premier niveau de sécurité, au niveau du contenu Ensuite, il y a la sécurité de la session, pour éviter des attaques de type "Man in the Middle"... - Au début de chaque session, le client envoi une demande de connexion (encryptée, comme tous les autres paquets) - Cette demande contient un identifiant unique (un GUID dans le cas évoqué), en plus des identifiants du clients lui même - le serveur vérifie d'abord que l'identifiant unique n'a jamais été utilisé auparavant, ce qui empêche tout hackeur de simplement renvoyer le même paquet. - Il vérifie ensuite les identifiants utilisateur (est-ce qu'il a le droit de se connecter) - Le serveur répond en fonction de tout ça avec un "Connexion établie ou refusée" (ça aussi encrypté, bien sur) - Ensuite, pendant toute la durée de la session, chaque paquet envoyé par le client contient en plus un numéro de paquet (1 est la demande de connexion, puis 2,3,4...) et le serveur vérifie que la séquence est correcte. - A la fin, le client fait une demande de déconnexion (et dans tous les cas le serveur gère un time out) Bien sur, ce système est bon pour une utilisation INTERNE (cad où TU écris le client ET le webservice)... Si tu dois fournir toutes ces infos (mode d'encryption, clé, etc) à des gens externes pour qu'ils utilisent ton webservice, le problème se présente différemment, et c'est encore pire si c'est un webservice PUBLIC... Bon Dev.
Mon vieux ..... Bonjour visiteur, Merci de vous Inscrire ou de vous connectez pour voir les liens! tu serais pas été prof par hasard Merci énormément pour toutes ces pistes.
Bonjour visiteur, Merci de vous Inscrire ou de vous connectez pour voir les liens! Mon vieux ..... Bonjour visiteur, Merci de vous Inscrire ou de vous connectez pour voir les liens! tu serais pas été prof par hasard Merci énormément pour toutes ces pistes.Cliquez pour agrandir...