Research Academy
My account Customers About Blog Careers Legal Contact Resellers

Burp Suite User Forum

Create new post

Understanding sockjs path in Target / Site Map for Vulnerability Scan

John | Last updated: Jan 05, 2018 10:32PM UTC

Hi, I'm running a Meteor application and can see paths that I've created in my application's router code show up as expected under my website's domain in the `Target -> Site Map` tool within Burp Suite. However, I'm also seeing a folder/path called "sockjs" in the site map tool under my website's domain, which tends to have multiple numbered subfoldered. Each of these containing more subfolders, each of which hold a websocket document. I understand that my application uses websockets. However, I don't understand websockets well enough to comprehend the "what/why/where" of these "sockjs" paths and I don't understand if this "sockjs" directory/path is relevant for vulnerability/penetration testing (my ultimately goal) or if it can simply be ignored during my testing. I've noticed that if I do an "active scan" on this "sockjs" folder/path, that several issues come up, some of which are critical e.g. Cross-origin resource sharing: arbitrary origin trusted. However, I do not see these issues come up if I actively scan the other other paths in the application's domain. Thanks!

PortSwigger Agent | Last updated: Jan 08, 2018 08:23AM UTC

Hi John, Thanks for your message. When a WebSocket connection is opened, the client starts by making an HTTP request with special headers, including "Upgrade: websocket" What you are seeing is that path that Meteor is using to make that initial request. Those paths are relevant to a pen test, although they're likely to reflect issues in Meteor itself, rather than application code. I suspect that the CORS vulnerability is a false positive, but you would need to investigate to confirm that. Please let us know if you need any further assistance.

You must be an existing, logged-in customer to reply to a thread. Please email us for additional support.