We Keep Coding

Capture network access from a javascript web application

I have a web application running in my browser. It is third party obfuscated javascript. It connects to the server with SSL and it fetches data and then displays it in the browser. I want to get programmatic access to the data, but I cannot figure out how it gets it from the server.
I tried to open Chrome Canary Dev Tools, but it does not show any network access (other than loading some html, js code and images). I ran wireshark and it shows lots of network access (all encrypted, so it is useless). What gives? This javascript app seems to be able to fetch data in a sneaky way, so that Chrome Dev Tools doesn't show it.
Any advice how I can reverse engineer this?
EDIT: I think that the data is fetched by redirecting to a download link, or perhaps with window.navigator.msSaveBlob. Anyway, I found it using postman.

I was able to capture the API call using POSTMAN (native Win 6.0.9). I enabled a Proxy on port 5555, and then click the button to trigger the action in the web app.
Because the web is using SSL, I get an error "Your connection is not private". However, I can click Advanced / Continue and call the API anyway, which gets captured by POSTMAN.
Advice: In postman, capture to a new folder (called Proxy data). Try it first using a non-SSL site, such as this one.

Can I make a socket connection through Javascript

What I want to do
Make a simple socket connection to a server on the browser. I want to not send any header information with the socket connection.
The Problem
It looks like I am unable to make a socket connection with javascript that does not send header data (Is there a way to do a tcp connection to an IP with javascript?).
I thought maybe I could make a connection with a chrome extension, however it looks like the socket API is only available for chrome apps (Google Chrome Socket API in extensions).
I am thinking that I might need to make a native application that will make socket connections through requests made by the browser using Native Messaging.
Is there anyway I can achieve this or am I out of luck?

Raw socket connections through the browser are wrapped up in security concerns. Users can be easily manipulated to allow things to run that shouldn't.
TCP and UDP Socket API
W3C Editor's Draft 20 January 2016
is located here.
http://raw-sockets.sysapps.org/
Mozilla's API information here: https://developer.mozilla.org/en-US/docs/Archive/B2G_OS/API/TCPSocket "This API is available on Firefox OS for privileged or certified applications only."
If you work with raw TCP connections. I would suggest
(1) downloading PHP onto the local computer. PHP has a developer web host build in so you can run whatever application you want on PHP using the browser as your GUI.
(2) download node.js.

You are not out of luck you just need to achieve it with the understanding that you are working outside the box for normal browser based scripting created from security concerns, and that means the user/client needs to install something manually.
If you must use chrome browser on the client side, you will need to make an -extension- correction webapp. You can as a developer make one that you can use on your own computers.
https://developer.chrome.com/extensions/getstarted
https://developer.chrome.com/apps/first_app
Load the extension#
Extensions that you download from the Chrome Web
Store are packaged up as .crx files, which is great for distribution,
but not so great for development. Recognizing this, Chrome gives you a
quick way of loading up your working directory for testing. Let's do
that now.
Visit chrome://extensions in your browser (or open up the Chrome menu
by clicking the icon to the far right of the Omnibox: The menu's icon
is three horizontal bars. and select Extensions under the Tools menu
to get to the same place).
Ensure that the Developer mode checkbox in the top right-hand corner
is checked.
Click Load unpacked extension… to pop up a file-selection dialog.
Navigate to the directory in which your extension files live, and
select it.
Alternatively, you can drag and drop the directory where your
extension files live onto chrome://extensions in your browser to load
it.
If the extension is valid, it'll be loaded up and active right away!
If it's invalid, an error message will be displayed at the top of the
page. Correct the error, and try again.
This insures that non developers don't load an extension which does not comply with the normal security concerns.
Communicating between with the script on the web page to the extension.
Can be done with message passing ... https://developer.chrome.com/extensions/messaging
The extension can add content directly to the web page which is available to the script on the web page. If for example the extension replaced the web cam image with a static image when the webcam script reads what it believes is the webcam it gets the static image instead, which explains why I look like an alien from space on the webcam. Although I did not create an extension to do that, I merely modified an existing extension to replace the function that gets the webcam image with a function to get a static image.

You can use SignalR, it is javascript library (JQuery Plugin) and it enables you to open web sockets from the browser to a server. Please check the following links:
https://blog.3d-logic.com/2015/03/29/signalr-on-the-wire-an-informal-description-of-the-signalr-protocol/
http://blog.teamtreehouse.com/an-introduction-to-websockets
https://github.com/SignalR/SignalR

How to track/analyze GeoLocation requests in modern browsers?

Modern browsers such as Firefox and Google Chrome offer a javascript API that, upon the users permission, can detect and share the user's location coordinates with the web server. But to do this, it has to make an additional HTTP or other network request to a web service. Is there an easy way to inspect this request for troubleshooting purposes? To see what is being sent, to where, and how long it is taking.
It does not show up in Firebug or the Web Inspector.

Each browser engine works using its own logic.
The validated fonctionnality, common to everyone, is delivered with a lot of features (success, errors callback, watch, etc...) that can help you to troubleshoot it properly.
Please find below the mozilla doc about it if you want more informations.
https://developer.mozilla.org/en/docs/Using_geolocation

Use a packet sniffer utility to analyze the raw network requests.

Replace remote JavaScript file with a local debugging copy using Greasemonkey or userscript

While debugging a client app that uses a Google backend, I have added some debugging versions of the functions and inserted them using the Chrome Developer Tools script editor.
However there are a number of limitations with this approach, first is that the editor doesn't seem to always work with de-minified files, and when the JS file is 35K lines long, this is a problem.
Another issue is that all the initialization that is done during load time, uses the original "unpatched" functions, hence this is not ideal.
I would like to replace the remote javascript.js file with my own local copy, presumably using some regex on the file name, or whatever strategy was suitable, I am happy to use either Firefox or Chrome, if one was easier than the other.

So basically, as #BrockAdams identified, there are a couple of solutions to these types of problem depending on the requirements, and they follow either 1 of 2 methods.
the browser API switcharoo.
The proxy based interception befiddlement.
the browser API switcharoo.
Both firefox and chrome support browser extensions that can take advantage of platform specific APIs to register event handlers for "onbeforeload" or "onBeforeRequest" in the case of firefox and chrome respectively. The chrome APIs are currently experimental, hence these tools are likely to be better developed under firefox.
2 tools that definitely do something like what is required are AdBlock plus and Jsdeminifier both of which have the source code available.
The key point for these 2 firefox apps is that they intercept the web request before the browser gets its hands on it and operate on the other side of the http/https encrpytion stage, hence can see the decrypted response, however as identified in the other post that they don't do the whole thing, although the jsdeminifier was very useful, I didn't find a firefox plugin to do exactly what I wanted, but I can see from those previous plugins, that it is possible with both firefox and chrome. Though they don't actually do the trick as required.
The proxy based interception befiddlement This is definitely the better option in a plain HTTP environment, there are whole bunch of proxies such as pivoxy, fiddler2, Charles Web HTTP proxy, and presumably some that I didn't look at specifically such as snort that support filtering of some sort.
The simplest solution for myself was foxyproxy and privoxy on firefox, and configure a user.action and user.filter to detect the url of the page, and then to apply a filter which swapped out the original src tag, for my own one.
The https case. proxy vs plugin
When the request is https the proxy can't see the request url or the response body, so it can't do the cool swapping stuff. However there is one option available for those who like to mess with their browser. And that is the man-in-the-middle SSL proxy. The Charles Web HTTP proxy appears to be the main solution to this problem. Basically the way it works is that when your browser makes a request to the remote HTTPS server, the ssl proxy intercepts the request and from the ip address of the server generates a server certificate on the fly, which it signs with its own root CA, and sends back to the browser. The browser obviously complains about the self-signed cert, but here you can choose to install the ssl proxy root CA cert into the browser, befuddling the browser and allowing the ssl proxy to man in the middle and make replacements and filters on the raw response body.
Alternative roll your own chrome extension
I decided to go with rolling my own chrome extension, which I am planning to make available. Currently its in a very hardcoded to my own requirements state, but it works pretty good, even for https requests and another benefit is that a browser plugin solution can be more tightly integrated with the browser developer tools.

Cross-domain SSL handshake failure in Firefox using xhr, client-certificate

The setup is as follows:
Firefox (both 3.x and 4b) with properly set up and working certificates, including a client certificate.
Web page with an XMLHttpRequest() type of AJAX call to a different subdomain.
Custom web server in said subdomain accepting requests, reponding with a permissive Access-Control-Allow-Origin header and requiring client verification.
The problem is that Firefox aborts the request (well, that's what it says in firebug anyway) abruptly. Running the setup with openssl s_server instead hints that Firefox actually doesn't even send the client certificate:
140727260153512:error:140890C7:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:peer
did not return a certificate:s3_srvr.c:2965:ACCEPT
The same exact setup works perfectly with Chrome, suggesting perhaps a bug in Firefox. However, performing the ajax call with a <script> element injected into the DOM seems to work as intended...
So, has anyone else run into this? Is it a bug? Any workarounds? Is there something obvious missing?

Chiming in 5 years later probably isn't much help to the OP, but in case someone else has this issue in the future...
Firefox appears to not send the client certificate with a cross-origin XHR request by default. Setting withCredentials=true on the XHR instance resolved the issue for me. Note that I also did not see this problem with Chrome--only Firefox.
For more info see this Mozilla Dev Network blog post. In particular, the following statement:
By default, in cross-site XMLHttpRequest invocations, browsers will
not send credentials. A specific flag has to be set on the XMLHttpRequest object when it is invoked.

The reason injecting the script works as opposed to a simple XHR request is because of the Single Origin Policy. This would probably explain why Chrome allows the XHR but not FF; Chrome considers the subdomain part of the same origin, but FF does not.
Injecting scripts from other domains (which is what Google Analytics does) is allowed and one of the practices to handle this situation.
The way my team handles this situation is by making a request through a server-side proxy.
I would recommend using a server-side proxy if you can, but the script injection method works fine as long as the code is coming from a trusted source.
I also found this article which describes your situation.