Pourquoi n'est-il pas de même de la politique d'origine pour les WebSockets? Pourquoi je peux me connecter ws://localhost?

Je voudrais utiliser les WebSockets pour la communication inter-processus pour mon application (Démon<->WebGUI et le Démon<->FatClient, etc.). Pendant le test, j'ai essayé de la connexion à mon localement web serveur socket (ws://localhost:1234) via le JavaScript client WebSocket sur websocket.org (http://www.websocket.org/echo.html).

Ma question maintenant est:

Pourquoi est-ce possible? N'est-il pas de la croix-origine de la politique mise en œuvre dans les navigateurs (ici: FF29 sur Linux)?

Je demande car si websocket.org était mal, il pourrait essayer de communiquer avec mon local WS serveur et de rediriger tous les messages qu'il reçoit à partir de localhost vers un autre serveur:

Local Serveur WebSocket Navigateur Mal De Serveur Web 
en ws://localhost:1234 à http://evil.tld 
| | | 
| |------[OBTENIR /]--------->| 
| |<-----[HTML+EvilJS]----| 
|<------[se connecter ws://..]----| | 
|<----[de communication]-->| | 
| |----[le mal de l'avant]---->| 
| | |

Je n'ai pas testé l'ensemble de cas d'utilisation, mais le connecter à ws://localhost de la JS livrés par websocket.org certainement œuvres.

websocket.org ne doit pas être mal, Web sockets peut être 😉

InformationsquelleAutor binwiederhier | 2014-05-15

39

oberstet répondu à la question. Merci!!!! Malheureusement je ne peux pas le marquer comme "correct", parce que c'était un commentaire. Le navigateur envoie à "l'origine" de l'en-tête qui peut être vérifiée par l'application.

En Java [1]:
```
@Override 
public void onOpen(WebSocket clientSocket, ClientHandshake poignée de main) { 
Chaîne clientOrigin = poignée de main.getFieldValue("origine"); 

si (clientOrigin == null || !clientOrigin.equals(WEBSOCKET_ALLOWED_ORIGIN_HEADER)) { 
enregistreur.log(Level.AVERTISSEMENT: "le Client n'a pas envoyé origine exacte de l'en-tête:" + clientOrigin); 

clientSocket.close(); 
retour; 
} 

//... 
}
```
[1] à l'aide de https://github.com/TooTallNate/Java-WebSocket
- OWASP mentionne la vérification de l'Origine (et potentiellement le Referer) de la tête dans leur CSRF feuille de triche comme la première étape et la plus importante, mais ils recommandent également d'aller plus loin et de mettre en œuvre une CSRF défense spécifiques. Dans le cas des WebSockets, c'est peut-être en ajoutant un XSRF antiforgery jeton pour le WS URI comme un paramètre de requête et de la validation côté serveur après l'origine de la vérifier.
InformationsquelleAutor binwiederhier
37

Pour répondre au "Pourquoi?" de la partie, la raison pour laquelle les navigateurs ne pas appliquer la Même Politique d'Origine (dont la SCRO est une relaxation) pour les WebSockets, par opposition à des appels AJAX, c'est parce que les WebSockets ont été introduites après la valeur de la croix-origine des demandes a été établi, et parce qu'ils ne sont pas soumis aux SOP, pour commencer, la raison historique de la SCRO côté client vérifie ne s'applique pas.

Pour l'AJAX, dans les jours d'une couverture Unique de la Politique d'Origine, les serveurs ne s'attendait authentifié navigateur envoie une requête à partir d'un domaine différent¹, et donc n'a pas besoin de nous assurer que la demande venait d'un emplacement de confiance². Plus tard, les distractions comme la SCRO a avoir côté client vérifications pour éviter les exposer les applications existantes de l'abus en cas de violation de cette hypothèse (en fait un Attaque CSRF).

Si le site Web ont été inventés aujourd'hui, sachant ce que nous savons maintenant, ni SOP, ni de la SCRO serait requis pour l'AJAX et il est possible que la validation est à gauche sur le serveur.

WebSockets, étant une technologie plus récente, sont conçus pour soutenir les scénarios de domaine de l'aller. Quiconque écrit le serveur de la logique devrait être conscient de la possibilité de la croix-origine des demandes et d'effectuer le processus de validation, sans la nécessité pour la main lourde côté navigateur précautions à la SCRO.

¹ C'est une simplification. Cross-origin me demande des ressources (y compris les <img>, <lien> et <script> balises) et la soumission d'un formulaire POST demandes ont toujours été autorisés en tant que caractéristique fondamentale du Web. De nos jours, la croix-origine des appels AJAX dont les demandes ont les mêmes propriétés sont également autorisées et connu sous le nom simple croix-de l'origine des demandes. Toutefois, l'accès aux données renvoyées de ces demandes dans le code n'est pas autorisé, sauf si explicitement autorisé par le serveur de la SCRO en-têtes. Aussi, il est de ces "simples" POST demandes qui sont la raison principale pourquoi l'anti-CSRF les jetons sont nécessaires pour les serveurs, afin de se protéger contre les sites web malveillants.

² En fait, un moyen sécurisé de vérifier la source de la demande n'était pas encore disponibles depuis le Referer en-tête peut être usurpée par exemple à l'aide d'un ouvert de redirection de la vulnérabilité. Cela montre aussi comment mal CSRF vulnérabilités ont été compris à l'époque.
- Ce n'est en effet répondre à la question, donc +1. Mais, pour l'anecdote, je suis en total désaccord avec ce raisonnement. Je prédis que, par suite de cette décision de conception, un nombre important de sites qui utilisent les WebSockets ne pourront pas valider le Origin en-tête et de fuite privé de l'utilisateur des données de sites tiers comme un résultat. Les Clients de vérifier les Access-Control-Allow-Origin en-tête, comme ils le font avant de permettre JS accès pour les réponses à toutes les autres croix-origine de la requête HTTP sur le web, aurait été une façon simple d'éviter toute cette classe d'attaque (Cross-Site WebSocket Détournement). Trop tard maintenant.
- Je suis plutôt d'accord, la modification de conception est essentiellement à déplacer à partir d'une liste blanche d'une approche fondée sur une liste noire, qui est risqué. Juste point de.
InformationsquelleAutor staafl
17

WebSockets peut traverser domaine de la communication, et ils ne sont pas limités par la SOP (Même Origine).

Le même problème de sécurité que vous décrivez peut se faire sans les WebSockets.

Le mal JS pouvez:
- Créer un script/balise image avec une URL vers le mal.tld et de mettre les données dans la chaîne de requête.
- Créer une balise de formulaire, mettre les données dans les champs, et d'invoquer le "soumettre" l'action du formulaire, faire un HTTP POST, qui peut être de la croix de domaine. AJAX est limitée par la SOP, mais c'est normal l'adresse HTTP POST n'est pas. De vérifier la XSRF web de problème de sécurité.
Si quelque chose injecte javascript dans votre page, ou vous obtenir code javascript malveillant, votre sécurité est déjà cassé.
- Je ne suis pas inquiet du mal JS. Je sais que c'est toujours possible. Ce que je suis vraiment inquiète, c'est le navigateur-breakout: Tout site web peut maintenant communiquer avec un en local lié WS prise et de voler des données, à partir de là.
- SOP/SCRO ne s'applique pas aux WebSocket, mais les navigateurs envoyer un origin en-tête qui contient le nom d'hôte du serveur qui a servi le code HTML avec le JS qui a ouvert la connexion WebSocket. Un serveur WebSocket peut alors restreindre l'accès par la vérification de origin.
InformationsquelleAutor vtortola

Vous devez vous connecter pour publier un commentaire.