I was surprised to find that I had already done like 99% of the work to prevent SQL injection attacks, but still need to cover my last base. Explanation as follows:
Flow of data when joining a meeting:
- User provides meeting ID(!) and their name
- Internal websocket hub is looked up using supplied meeting ID
- User is joined to the meeting hub and a websocket connection is established
- The current contents of the database are fetched and returned to the users using the supplied meeting ID(!!)
The fix is fairly simple, surprisingly. I just need to use the hub struct found by the supplied meeting ID (https://github.com/mpuckett159/stack-web-app/blob/master/wshandler/client.go#L257) to provide back the hubId property of the hub struct (https://github.com/mpuckett159/stack-web-app/blob/master/wshandler/client.go#L290) and that will prevent any user input from ever reaching the tableId part of the sql query, thus preventing any potential SQL injections on my side of the code. So the code change will just be:
stackUsers, err := db.ShowCurrentStack(hub.hubId) at https://github.com/mpuckett159/stack-web-app/blob/master/wshandler/client.go#L290
I was surprised to find that I had already done like 99% of the work to prevent SQL injection attacks, but still need to cover my last base. Explanation as follows:
Flow of data when joining a meeting:
The fix is fairly simple, surprisingly. I just need to use the hub struct found by the supplied meeting ID (https://github.com/mpuckett159/stack-web-app/blob/master/wshandler/client.go#L257) to provide back the hubId property of the hub struct (https://github.com/mpuckett159/stack-web-app/blob/master/wshandler/client.go#L290) and that will prevent any user input from ever reaching the tableId part of the sql query, thus preventing any potential SQL injections on my side of the code. So the code change will just be:
stackUsers, err := db.ShowCurrentStack(hub.hubId)at https://github.com/mpuckett159/stack-web-app/blob/master/wshandler/client.go#L290