Does anyone have a websocket connection working with an application proxy (e.g. burp or zap)?
For example, I have a working version of jWebSockets with works perfectly on my local machine.
However, when I intercept with Burp or Zap the connection times out and I get no server response back.
I have increased the timeout settings on the server side but this does not make a difference.
I have also tried using the invisible proxy option.
Thank you.
There are very few tools that support web sockets right now as its really a completely new protocol.
The current version of ZAP (1.4.1) wont, but the next major version will: http://code.google.com/p/zaproxy/wiki/GSoC2012_WebSockets
If you can build ZAP from the trunk then it will support web sockets - build instructions here: http://code.google.com/p/zaproxy/wiki/Building
It will allow you to view web socket traffic, intercept and change it and fuzz it to try and find vulnerabilities.
Let us know if you have any problems with it, eg via the ZAP developer group: http://groups.google.com/group/zaproxy-develop
Simon (ZAP Project Lead).
Update - Web Sockets support in ZAP is now available in the weekly cross-platform releases, which can be downloaded from http://code.google.com/p/zaproxy/downloads/list so you dont have to build it yourself
Related
I am trying to get Dialogflow SDK samples from Google's Dialogflow v2 Node.js SDK to work. I am using node.js v8.10.0, with dialogflow node.js SDK version 0.5.0. I am encountering this issue when trying to run the "Detect Intent" sample, from behind a corporate http/s proxy:
Auth error:Error: write EPROTO 140163148314432:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:../deps/openssl/openssl/ssl/s23_clnt.c:827
I came across this post here: https://medium.com/google-cloud/accessing-google-cloud-apis-though-a-proxy-fe46658b5f2a which seemed very java-oriented, but it suggested that the environment variable GRPC_PROXY_EXP be set in order to get the gRPC calls to work behind a proxy. I set the environment variable in the shell from which I was running node with export GRPC_PROXY_EXP="$https_proxy" and attempted to run the sample again, with the same issue. Note that my $http_proxy, $https_proxy variables are the same.
The same sample works from the same machine, when connected to a wifi network without the proxy; and a tcpdump packet analysis indicates that there are two TCP connections (distinct ports) in-use: one which works (and is opened first), and one which doesn't, and encounters the error with the proxy. The second connection immediately begins the CLIENT_HELLO TLS message, when it needs to first authenticate and send the HTTPS proxy the CONNECT message (as the first TCP connection does).
Am I missing something, or is this an issue with the dialogflow (google-gax / grpc) node library?
After some back-and-forth on a couple of Google node project issue discussion boards, the problem turned out to be that - when HTTPS over HTTP tunneling is used - the gtoken API's direct use of the axios npm package was only prepared to use HTTPS (consistent with the protocol in the URL).
To make a long story short; Dialogflow 0.8.2 contains the fix for this issue in that its transitive dependencies include a version of the gtoken package that uses gaxios instead of axios. gaxios is a package used elsewhere in the google-gax library to make HTTP/S connections (which is proxy aware, and handles the HTTPS over HTTP use-case).
I have a server that uses websockets. It is written in Go. For testing, I have another application written in Go. To test, I start the server, then run the test client. The test client creates websocket connections to the server and does things (basically impersonating user activity). Both the client and the server are using the gorilla/websockets library, and standard browsers also work fine with the server.
This was all working beautifully.
To support non-compliant browsers, I was asked to start using the SockJS Go server library. I did this and the new version works just fine when used from a browser by clients using the SockJS library.
Now for the problem. SockJS does not accept incoming websocket connections. Only connections from the SockJS client. So my testing application doesn't work, and I'm unable to test.
I could recover the old version of my connection code from git and make a separate connection type that uses gorilla/websockets and have my server listen on an additional port that only listens on localhost. This would allow me to test the functionality. The downside is that I have to maintain two versions of essentially the same code, and I wouldn't be testing the real user experience and possibly not find bugs until production.
Ideally the SockJS server, considering it still uses gorilla/websockets as a dependency would automatically accept proper websocket connections, but barring that it seems I'd need a SockJS client library in Go which, as far as I can tell, doesn't exist.
Does anyone have a solution for this? Thanks!
Need to be able to continuously receive calls when a Chrome webpage is open. How do I do that even for users who are inside a strict enterprise network?
WebSockets? (but there's the proxy problems that doesn't know what wss:// is)
HTTP? (but will I have to poll?)
Other?
Since you included the "vLine" tag, I'll reply with some information on how our WebRTC platform will behave in an enterprise network. vline.js will use a secure WebSocket by default if the browser supports it and fall back to HTTPS long polling. As described here, the secure WebSocket may work depending on the exact proxy configuration. Feel free to test it out by using GitTogether or creating your own vLine service for testing.
I'm trying to develop an extension that detects every connection made by the browser to figure out the URLs being accessed. I know that this is possible via writing an HTTP/SOCKS proxy and configuring the browser to flow traffic via that. However, that's kind of overkill for the application that I'm trying to develop and it's best done as a Firefox Add-on if that's possible. Any clues/pointers would be highly appreciated.
Use nsIHttpActivityDistributor and there is many information about the http transaction and socket transport through observeActivity callback.
Read the official documentation https://developer.mozilla.org/en/Monitoring_HTTP_activity.
I'm trying to port a win32 application to Windows Mobile 6 / 6.1 / 6.5. It uses winhttp which doesn't appear to be available on the mobile platforms.
My initial thought was to replace it with WinInet - but I wondered if anyone had a better idea?
WinInet is actually a more appropriate HTTP client library for client nodes.
Here's some things I like about WinInet voer WinHttp:
If your client app needs to make lots of requests from the same server, WinInet will implicitly queue the requests up so as not to flood the server. (But is transparent to the client app). In other words, it respects RFC 2616 guidelines on simultaneous connections. This is great when your app is pulling down a lot of images (or files) from the same server simultanously.
Will the use the IE cache for fetching content. (Which I assume an equivalent cache exists on Mobile platforms).
Proxy server auto-detected from IE settings. Probably less of an issue with mobile since the IP network is a bit more open. But if you had to support proxy servers with WinHttp, you'd have to use other API calls to specify the server directly.
I've used Wininet and it works. But it's not ideal as its timeouts are broken. And developing a complete asynchronous design with it required a ton of code.
So instead, I'm trying libcurl.
So far though, I still haven't managed to get it compile properly and link. Porting stuff is such a pain sometimes. But I digress. ;)