Pourquoi pas de support pour TCP Sockets en JavaScript
Je sais qu'il existe maintenant des WebSockets, mais quel est le problème avec la fourniture d'une API de socket pour permettre l'interaction avec les protocoles existants?
Je veux dire, après tout, je peux déjà utiliser un objet flash caché pour faire la même chose. Y a-t-il un vecteur d'attaque qui me manque?
... mais quel est le problème avec la fourniture d'une API socket pour permettre l'interaction avec les protocoles existants?
Ce n'est pas une restriction de la langue elle-même mais de son utilisation dans le bac à sable du navigateur. Imaginez simplement qu'un script quelque part sur Internet soit chargé dans le navigateur et puisse de l'intérieur du navigateur accéder à chaque ordinateur accessible par le navigateur avec des protocoles arbitraires. Vous pouvez facilement abuser de cela pour envoyer du spam via le serveur de messagerie interne d'une entreprise ou attaquer/abuser d'autres ressources internes et externes.
Ce qui signifie qu'il doit y avoir des restrictions en place et que les différents environnements de bac à sable pour les différentes exécutions de langue fournissent différents types de restrictions:
- Avec flash, l'hôte cible doit autoriser explicitement l'accès à en fournissant un fichier de stratégie de socket approprié. Ceci est similaire au mécanisme de HTML5 CORS .
- Non fiable Java sont limitées à la communication avec l'hôte fournissant l'applet.
- Et avec JavaScript dans le navigateur, vous pouvez parler à presque tous les sites, mais vous êtes limité par le protocole que vous pouvez utiliser, à savoir HTTP (restreint par CORS) et WebSockets.
Je ne sais pas quel accès API socket un objet Flash fournit, mais il y a de très bonnes raisons de ne pas autoriser les sockets simples TCP ou UDP (et encore moins tout autre type de) sockets en JavaScript.
Le plus important, probablement, est que vous fournissez essentiellement un moyen de contourner les pare-feu si vous le faites. Chaque service de votre machine qui écoute sur les sockets réseau de bouclage, normalement inaccessible par des attaquants externes, peut désormais être attaqué à partir du navigateur. Chaque machine de votre réseau, normalement isolée d'Internet par votre passerelle et votre pare-feu, est désormais accessible ou attaquable par le code Internet.
Il y a aussi d'autres raisons. L'analyse des ports et les attaques DDOS deviennent beaucoup plus faciles lorsque les navigateurs peuvent les faire sans un plugin ( oui, les navigateurs peuvent tenter de lancer DDOS sur des serveurs HTTP (S), mais ils pourraient être bien plus efficace avec des sockets de niveau inférieur ). Les vers de réseau (en particulier ceux auxquels seule une petite proportion de machines sont vulnérables) peuvent se propager beaucoup plus rapidement lorsque tous ceux qui consultent une annonce sur un site Web populaire commencent à envoyer des attaques, au lieu de ceux qui sont réellement infectés.
Les Websockets existent pour donner un moyen de faire une communication par socket avec des choses qui veulent explicitement communiquer avec un navigateur qui exécute du code non approuvé. Le serveur Internet typique est durci de la même manière et attend des clients malveillants de toutes natures. Le problème vient des services qui n'attendent pas du trafic malveillant, car ils ne sont accessibles que par des clients de confiance. Les prises contrôlées par JS briseraient totalement cela.