2010-11-10 7 views
3

Je me demandais quelles sont les failles de sécurité (le cas échéant) de l'utilisation de GWT avec SSL (en réalité TLS configuré sur le serveur JBoss web-app). J'en ai discuté avec un de mes amis, et il dit que même si j'active le protocole HTTPS, un utilisateur malveillant pourrait intercepter mon fichier .js et changer de code et se faire authentifier sur le serveur. Nous avons supposé qu'en dehors de SSL, nous n'envoyons jamais de mot de passe en clair sur le réseau (nous le hachissons en premier). Est-ce vraiment possible?GWT avec sécurité SSL

L'autre chose que je voudrais savoir est - comment le code Javascript (généré par GWT) déclenche-t-il des appels RPC? Nous avons utilisé Wireshark pour détecter les requêtes et les réponses du client sur le serveur Web SSL, et aucun des packages RPC ne circule. Tout ce que nous voyons sont ces paquets de protocole TLS, nous pouvons facilement les identifier en utilisant un filtre sur les adresses IP source et destination du client et du serveur web.

Répondre

4

Si vous envoyez également vos fichiers .html et .js via HTTPS, alors, d'une manière générale, personne ne pourra les manipuler pendant le transfert. Bien sûr, il y a quelques questions pratiques:

  • L'implémentation de TLS a-t-elle des bogues?
  • Y a-t-il des failles dans le protocole TLS?
  • Le navigateur ou l'ordinateur du client est-il compromis?
  • Le serveur est-il compromis?
  • ...

Supposons, ce n'est pas le cas. Mais alors il y a votre déclaration:

Nous avons supposé qu'en plus de SSL nous n'envoyons jamais de mot de passe en texte brut sur le fil (nous le hachageons en premier).

Donc, vous n'envoyez pas tout via SSL? Eh bien, les choses que vous n'envoyez pas via SSL peuvent être volées et manipulées pendant le transfert. Je suppose, ce que signifie votre ami, que le mot de passe haché peut être volé! Même si l'attaquant ne parvient pas à reconstruire le mot de passe en clair, il peut simplement utiliser le mot de passe haché, si votre serveur accepte le mot de passe haché.

Voir également ma réponse à GWT/Javascript client side password encryption.


A propos de votre deuxième question:

Nous avons utilisé Wireshark pour renifler les demandes et les réponses du client vers le serveur Web SSL, et il n'y a aucun des paquets RPC vont arround. Tout ce que nous voyons sont ces paquets de protocole TLS ...

Eh bien, je l'espère vraiment! Vos appels RPC sont la charge utile cryptée de ces paquets.

+0

Je ne sais pas vraiment pourquoi je m'attendais à des paquets RPC.Quand je travaillais avec du vrai RPC Java, je pouvais voir des paquets RPC traversant le réseau, mais cela ne faisait que partie de la charge utile du protocole HTTP. – Zec

+0

Je suis désolé de trier-de relancer ce fil. Mais je cours dans le même problème. Donc, si je veux la sécurité de mon client <-> communication du serveur - alors je dois passer à SSL, non? Mon application affiche un certain nombre de pages. Certains d'entre eux sont accessibles à tous, d'autres uniquement aux utilisateurs connectés (par exemple, la gestion des profils n'est disponible que pour les utilisateurs connectés). Alors, quelle est la meilleure pratique pour le faire? – Igor

0

Pour être complètement sûr de votre configuration SSL/TLS, je vous suggère d'utiliser un outil externe. . Jusqu'à présent, le plus précis pour moi était SSL/TLS Server Test. Là, vous pouvez voir comment votre configuration est conforme aux exigences PCI DSS, ou aux directives de HIPAA et NIST, qui sont des standards de l'industrie pour sécuriser SSL/TLS.