I am trying to intercept a https request which serves a JS file and use my local file instead.
Used fiddler tool and i am able to successfully intercept all the http request served files.
But unable to do it for the https files.
Note: I have kept my JS file in a local server..I just used the direct path like C:\test\test.js
Did you enable the Decrypt HTTPS Traffic option?
Fiddler2 includes the ability to decrypt, view, and modify HTTPS-secured traffic for debugging purposes. The decryption feature is disabled by default.
By default, the session list will show only a CONNECT tunnel through which the HTTPS-encrypted bytes flow.
Enable the traffic decryption option by clicking Tools > Fiddler Options > HTTPS and ticking the Decrypt HTTPS Traffic box.
Update:
You might want to send the alternate javascript from your proxy by the way (instead of changing the source to include a script file on the users local computer).
Also, as pointed out by EricLaw in the comment to this answer:
You'd also want to look at Fiddler's AutoResponder tab which allows you to return files from your local disk instead of transmitting the request to the server.
On this tab you can enter a match rule and an action string, and Fiddler will undertake the action if the request URI matches the match rule.
Extra (because of a comment that this can't be done because it would defeat the purpose of https)
Q: The HTTPS protocol was designed to prevent traffic viewing and
tampering. Given that, how can Fiddler2 debug HTTPS traffic?
A: Fiddler2 relies on a "man-in-the-middle" approach to HTTPS
interception. To your web browser, Fiddler2 claims to be the secure
web server, and to the web server, Fiddler2 mimics the web browser.
In order to pretend to be the web server, Fiddler2 dynamically
generates a HTTPS certificate.
Fiddler's certificate is not trusted by your web browser (since
Fiddler is not a Trusted Root Certification authority), and hence
while Fiddler2 is intercepting your traffic, you'll see a HTTPS error
message in your browser.
It's hardly a new concept by the way, mitmproxy can do it to as far as I can tell.
Hope this helps!
Related
I need to call an HTTPS REST API (Kubernetes) that uses self-signed certificates (almost all Kubernetes clusters are like that).
I have the cluster's root CA certificate (and also the client certificate. See docs)
How can I make this HTTPS GET request in browser and without user interaction (e.g. without asking the users to download and install the CA certificate)?
Using plain fetch throws the ERR_CERT_AUTHORITY_INVALID error. The axios library documentation is pretty confusing regarding what they support, and I'm not sure they support CAs in the browser.
How can I make this HTTPS GET request in browser and without user interaction (e.g. without asking the users to download and install the CA certificate)?
You can't do this with your setup. Browsers will only accept certificates issued by predefined trusted certificate issuers. If there would be a way to silently accept anything outside of this then stealth man in the middle attacks would be easy.
Therefore you have to options: make the user accept your certificate or get a certificate issued by a public CA. Given that such certificates can be free the latter option is likely the easier one.
I have a webpage, serverd via https from Tomcat, with serviceworker according to examples for fetching a resource and store it in the cache. If Tomcat is not running, the page is served from the cache storage - so far so good.
My Tomcat configuration contains the redirectPort attribute to redirect http to https. The problem I have: When Tomcat is not running and my webpage is accessed via http, browser shows: Connection refused since the http 302 redirect is not stored in the cache. How I could achieve that?
Unfortunately service workers require https for safety, so you cannot have a service worker intercept an http request.
If you would like to force browsers to visit your page in https you could enable HSTS:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security
The HSTS list can be preloaded in the browser allowing it to work offline. Note, however, you need to be careful when enabling HSTS as if you make a mistake it can be difficult to correct.
Alternatively browsers are slowly moving towards loading https by default unless the user explicitly types http. For example:
https://blog.chromium.org/2021/03/a-safer-default-for-navigation-https.html
I'm using Google Firebase, and unfortunately, Google Firebase put some countries under sanctions which means they must use a proxy (or VPN) to access the website.
Is there any way I can set a proxy setting for each client request that they can freely access Firebase without a VPN?
I know there are options for Node.js, but I'm looking for a web browser solution. Firefox has this proxy settings, and Google Chrome also has some options for extension developers, but I need a solution that works just in a web page, and it means when a user comes to my website, he/she does not need to set a proxy to access Firebase.
Example: when a user comes to my website from (for example) Syria or Sudan, they don't need to set VPN for their browser, because I have done some proxy configuration in my website
Short answer: You can't do it website-only.
Longer answer / explanation:
I know there are options for Node.js,
Good... that could work. Deploy your own Node.js server on Heroku or the like, which proxies requests to Firebase.
but I'm looking for a web browser solution. Firefox has this proxy settings, and Google Chrome also has some options for extension developers, but
This could work too, but as I'm sure you've considered... that would rely on the end-users installing those extensions before attempting to visit your site.
I need a solution that works just in a web page,
Nope. Not possible. The Google servers will not respond to any request coming from a sanctioned country. If a request comes from a disallowed country, the Firebase servers won't respond with your website - instead they respond with a 403. Firebase won't send the website. Your website won't be sent to the client. It doesn't matter what your website contains, it will never be sent to those end users in the first place.
Even if you host the site elsewhere, and just use the Firebase database, it still won't work - for the same reasons. When the Firebase servers receive the request from a browser running in a sanctioned country, they respond with 403.
The question then becomes: How to make the request appear to come from outside the sanctioned country, from the website only?
You can't, not when you only control the website itself. That part of the request/response cycle is, for end-user protection purposes, handled by the browser. Browsers do not expose that functionality to webpages.
If you want to handle everything for your users, without them needing a VPN (desktop, or browser), your only choice will be to send the request to a different non-Google server (such as a Node.js server you host on Heroku or the like), which then makes the request to Firebase on their behalf, gets the response, and responds back to the client. That way, to the Firebase servers, it looks like the request is coming from X* location.
*X: Where ever the Heroku server is running.
Yes, I need to enable cross site scripting for internal testing of an application I am working on. I would have used Chrome's disable-xss-auditor or disable-web-security switches, but it looks like they are no longer included in the chrome build:
http://src.chromium.org/svn/trunk/src/chrome/common/chrome_switches.cc
What I am basically trying to achieve is to have a javascript application running locally on pages served by Apache (also running locally) be allowed to run scripts from a resource running on another server on our network.
Failing a way to enable xss for Firefox, Chrome, or my least favourite - IE, would there be a way to run some kind of proxy process to modify headers to allow the xss to happen? Any quick way to use Apache mod rewrite or some such to do this?
Again, this is for testing only. In production, all these scripts run from the same server, so there isn't even a need to sign them, but during development and testing, it is much easier to work only on the parts of the application you are concerned with and not have to run the rest that requires an full-on application server setup.
What you need is just a little passthrough service running on the first server that passes requests over to the second server, and returns the results it gets back from the second server.
You don't say what language the server side of your application is written in or what kind of data is passed to or returned from your service, so I can't be more specific than that, but it really should be about 15 lines of code to write the passthrough service.
What are asking for isn't cross-site scripting (which is a type of security vulnerability in which user input (e.g. from the URL) is injected into the page in such a way that third party scripts could be added via a link).
If you just want to run a script on a different server, then just use an absolute URI.
<script src="http://example.com/foo.js"></script>
If you need to perform Ajax requests to a remote server, use CORS or run a proxy on the current origin.
Again, this is for testing only
Just for testing, look at Charles Proxy. It's Map Remote feature allows you to (transparently) forward some requests to a remote server (based on wild card URL matching).
For our APP we have a Web App and a API service, On A certain event the Web app polls the api service for the state of the event using Javascript. Both the apps run on a separate HTTPS sub domain and with a self signed certificate(as it is still in alpha). The problem occurs that the polling is aborted because the https api connection is untrusted. Is it some way for the Javascript request to override the untrusted certificate issue?
Is it some way for the Javascript request to override the untrusted certificate issue?
No, it's because of the same origin policy restriction.
In your case I suppose that you have a page hosted on https://foo.bar.com and you are trying to send an AJAX request to https://baz.bar.com which is not allowed.
You may take a look at the following guide which covers the different possibilities to circumvent this restriction. They range from JSONP, server side script bridges, Flash proxies, screen scraping with YQL, ...
No, you have to add the self-signed certificate to your machine/browser's trusted certificate store.
You also have cross-domain origin issues (the different subdomain), which is separate from any certificate issues. If you're already using JSONP, you're fine; but if you're trying to make an XHR request to a different domain, it's not going to work.