srquinn21 · August 28, 2020 02:04 · Jan 31, 2018 · Jan 31, 2018 · Jan 31, 2018 · Jan 31, 2018
diff --git a/README.markdown b/README.markdown
@@ -6,4 +6,4 @@ https://www.notsosecure.com/how-cross-site-websocket-hijacking-could-lead-to-ful
 
 **TL;DR**: Websockets, by spec, do not respect the browser's Same Origin Policy enforced for CORs and XHR requests. This means that a connection made in one browser tab can be hijacked in another browser tab similar to a typical XSS attack. In order to protect our services, we need to make sure that the Origin header matches the application's server name.
 
-I've provided a nginx.conf file below that demonstrates how to check the Origin header. In addition to this config update, you'll also want to be sure to use a session token during your websocket handshake that is verified on the server for each connection.
+I've provided a nginx.conf file below that demonstrates how to check the Origin header. In addition to this config update, you'll also want to be sure to use a session token during your websocket handshake that is verified on the server for each connection. I suggest looking into JSON Web Tokens (JWT)
diff --git a/README.markdown b/README.markdown
@@ -4,4 +4,6 @@ While researching possible Websocket vulnerabilities, I came across the "Cross S
 http://www.christian-schneider.net/CrossSiteWebSocketHijacking.html  
 https://www.notsosecure.com/how-cross-site-websocket-hijacking-could-lead-to-full-session-compromise/
 
-TL;DR: Websockets, by spec, do not respect the browser's Same Origin Policy enforced for CORs and XHR requests. This means that a connection made in one browser tab can be hijacked in another browser tab similar to a typical XSS attack. In order to protect our services, we need to make sure that the Origin header matches the application's hostname.
+**TL;DR**: Websockets, by spec, do not respect the browser's Same Origin Policy enforced for CORs and XHR requests. This means that a connection made in one browser tab can be hijacked in another browser tab similar to a typical XSS attack. In order to protect our services, we need to make sure that the Origin header matches the application's server name.
+
+I've provided a nginx.conf file below that demonstrates how to check the Origin header. In addition to this config update, you'll also want to be sure to use a session token during your websocket handshake that is verified on the server for each connection.
diff --git a/README.markdown b/README.markdown
@@ -1,7 +1,7 @@
 ### Notes
 While researching possible Websocket vulnerabilities, I came across the "Cross Site WebSocket Hijacking" attack as documented here:
 
-http://www.christian-schneider.net/CrossSiteWebSocketHijacking.html
+http://www.christian-schneider.net/CrossSiteWebSocketHijacking.html  
 https://www.notsosecure.com/how-cross-site-websocket-hijacking-could-lead-to-full-session-compromise/
 
 TL;DR: Websockets, by spec, do not respect the browser's Same Origin Policy enforced for CORs and XHR requests. This means that a connection made in one browser tab can be hijacked in another browser tab similar to a typical XSS attack. In order to protect our services, we need to make sure that the Origin header matches the application's hostname.
diff --git a/README.md → README.markdown b/README.md → README.markdown
@@ -1,4 +1,4 @@
-###Notes
+### Notes
 While researching possible Websocket vulnerabilities, I came across the "Cross Site WebSocket Hijacking" attack as documented here:
 
 http://www.christian-schneider.net/CrossSiteWebSocketHijacking.html

diff --git a/README.md b/README.md
@@ -0,0 +1,7 @@
+###Notes
+While researching possible Websocket vulnerabilities, I came across the "Cross Site WebSocket Hijacking" attack as documented here:
+
+http://www.christian-schneider.net/CrossSiteWebSocketHijacking.html
+https://www.notsosecure.com/how-cross-site-websocket-hijacking-could-lead-to-full-session-compromise/
+
+TL;DR: Websockets, by spec, do not respect the browser's Same Origin Policy enforced for CORs and XHR requests. This means that a connection made in one browser tab can be hijacked in another browser tab similar to a typical XSS attack. In order to protect our services, we need to make sure that the Origin header matches the application's hostname.
diff --git a/conf → nginx.conf b/conf → nginx.conf
diff --git a/conf b/conf
@@ -0,0 +1,22 @@
+# DENY all requests by default (PoLP)
+set $websocket_same_origin_policy "DENY";
+# ALLOW non-browser clients
+if ($http_origin = "") {
+    set $websocket_same_origin_policy "ALLOW";
+}
+# ALLOW browsers with matching Origin header and ServerName
+# (only browsers reliably set a truthful Origin header)
+if ($http_origin = $scheme://$server_name) {
+    set $websocket_same_origin_policy "ALLOW";
+}
+
+location /ws {
+    # DENY any request that violates the Same Origin Policy
+    if ($websocket_same_origin_policy != "ALLOW") {
+        return 403;
+    }
+    proxy_http_version 1.1;
+    proxy_set_header   Upgrade $http_upgrade;
+    proxy_set_header   Connection "upgrade";
+    proxy_pass         http://localhost:3030;
+}
No results found