![]() Sending DDP WebSocket Traffic to Burp Suite Tampering with his can force a fallback to XHR. tamper with JavaScript code or other requests: When looking at the JavaScript code, a lot of the times a check can be identified, for example websocket=true or something similar.This will trick the client into believing that the WebSocket connection is not supported and force it to fall back to XHR. Using Burp, you can use a match and replace rule in the proxy settings to change the response to a HTTP 500. The server will respond with an “HTTP/1.1 101 Switching Protocols” header. tamper with the WebSocket upgrade response: When initializing a WebSocket connection, the browser will send an upgrade request.disable WebSockets in the browser: never seemed to work in my case, despite changing multiple settings in the about:config in both FireFox and Chrome.Testing for fallback is pretty easy, the following methods can be used: If a fallback is supported, it makes life easier since we can just run active scanner, do all authorization and business logic tests via XHR which is easy to do with Burp. Burp extensions also cannot easily access WebSocket traffic, so writing a custom extension to deal with this is not an option.Ī lot of applications that use WebSockets allow a fallback to XMLHttpRequest (XHR) when WebSockets are not supported. We can view, intercept and modify the WebSocket messages in Burp, but we cannot use modules like Repeater, Intruder or Active Scanner. Meteor applications use Distributed Data Protocol ( DDP) over a WebSocket connection. To test this yourself, the example Meteor application “Todos” can be downloaded here. ![]() This can also be applied to other protocols that run over WebSockets. The following post will cover some techniques to test Meteor applications with Burp Suite.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |