Sean R. Quinn srquinn21

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 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 suggest looking into JSON Web Tokens (JWT)

	#==========================================================
	# Environment/Configuration
	#==========================================================

	# For project consistency, its better to depend on npm binaries loaded locally than
	# globally, so we add .node_modules/.bin to the path for shorthand references. This
	# means you should add any binaries you need to "devDependencies" in package.json.
	export PATH := ./node_modules/.bin/:$(PATH)

	# Pull in the name and version from package.json. The name will default to "app" if not set.

	server {
	listen 443;
	server_name git.eatabrick.org;

	error_log /var/log/nginx/git.error.log;
	access_log /var/log/nginx/git.access.log;

	# ssl because cox sucks
	ssl on;
	ssl_certificate /etc/nginx/ssl/git.eatabrick.org;