I'm trying to intercept a web application which uses a HTTP proxy (basic HTTP auth password protected) to access its resources.
In Fiddler options, there is a setting for manual proxy configuration. But in that field, I can only define the proxy address and port. I need to define an username/password combination for upstream proxy.
Is there any way to do this?
Your scenario is a bit unclear. Clients should automatically prompt for proxy credentials when a HTTP/407 is received, although many don't.
If your question is: "How can I add a Proxy-Authorization header to all requests that pass through Fiddler?" then it's pretty simple.
Rules > Customize Rules > Scroll to OnBeforeRequest and add:
if (!oSession.isHTTPS)
{
oSession.oRequest["Proxy-Authorization"] = "Basic dXNlcm5hbWU6cGFzc3dvcmQ=";
}
Where dXNlcm5hbWU6cGFzc3dvcmQ= is the base64-encoded version of the "username:password" string. You can use Fiddler's Tools > TextWizard to base64-encode a string.
Related
I`m wondering if it is possible to implement following:
I have some service in GO (used for Firebase Cloud Messaging) it uses go package from firebase (firebase.google.com/go/v4) to send messages. This packge sends https requests. And One of them is to https://oauth2.googleapis.com/token to get token.
I can't change code in Firebase go-package, but I need to use proxy, that is why before sending message I need to set HTTPS_PROXY environment variable to my proxy address. It works fine.
Now I need to do some automatic tests and I have an emulator that has /token endpoint and return a valid token as response. Is it possible to use some kind of proxy that can redirect https requests to my emulators endpoint so that all requests to https://oauth2.googleapis.com/token should be redirected to my emulators endpoint /token?
And another question is there are any possible problems because of HTTPS ?
Is it possible to get rid of https and use only http after the proxy?
Found following solution:
Firebase Cloud Messaging package uses clone default transport to create http.client under the hood.
So we can configure http.DefaultTransport before calling app.Messaging(ctx) and set up any parameters we need (proxy, insecureSkipVerify ...).
So no problems at all.
I have a TinyProxy proxy on my router, and it sends traffic to an external parent Squid proxy that is not on the LAN to get processed. I added authorization to Squid so that it is not completely open to the world (user has to provide a username and password if they point their browser to the squid proxy, which works correctly).
Looking at the TinyProxy man pages I can see that it is possible to send basic authorization header information to the Squid parent via tinyproxy, but when I attempt to do so, it is not authenticating correctly (no browser configurations. This is a transparent proxy) and I am getting access errors on Squid's end. Below is an excerpt from the TinyProxy.conf man page:
AddHeader "X-My-Header" "Powered by Tinyproxy"
If the user who is allowed on Squid has the username: test and password: test1234 with the password hash: 123456789 and this is what I include in the TinyProxy.conf file:
AddHeader "Proxy-Authorization" "Basic test:123456789"
it is not authenticating correctly when I attempt to access an HTTP site. Is the format incorrect?
Also for reference, here is my squid.conf
auth_param basic program /usr/lib/squid3/basic_ncsa_auth /etc/squid3/passwords
auth_param basic realm proxy
acl authenticated proxy_auth REQUIRED
http_access allow authenticated
#http_access allow all
http_port 3128
I found a solution to my problem. When adding a header, it is not in the form "user:password_hash", it is in the form of a base64 string. i just used an online converter(http://www.tuxgraphics.org/toolbox/base64-javascript.html) to convert "test:test1234" to "dGVzdDp0ZXN0MTIzNA==". The AddHeader line in TinyProxy then becomes:
AddHeader "Proxy-Authorization" "Basic dGVzdDp0ZXN0MTIzNA=="
And it authenticates perfectly! I hope someone else other than me finds this useful, as I was not able to find a single "TinyProxy" adding header example.
Is there a way on a Google Search Appliance to enable optional https?
Under settings, under the heading Force secure connections when serving the options are:
No.
Use HTTPS when serving secure results, but not when serving public results.
Use HTTPS when serving both public and secure results.
I don't want to Force secure connections though, I want them to be optional.
ie, if someone requests the site as HTTP it serves as HTTP and if they request it as HTTPS it serves as HTTPS.
If I choose the 1st or 2nd options it accepts connections on HTTPS but immediately redirects to HTTP (ie, it forces HTTP). And the 3rd option forces HTTPS.
Is there any other settings that would enable it to accept HTTPS optionally?
You must install a valid ssl certificate or create a self-signed certificate. (Administration->SSL Settings)
In SSL Settings->Other Settings->"Force secure connections when serving?" you must select either: 'a' or 'b'
a. "Use HTTPS when serving secure results, but not when serving public
results."
b. "Use HTTPS when serving both public and secure results."
Unless all requests are coming from https, chances are you will select 'a'.
If 'b' is selected, you will receive an "unknown error" if sending query over standard http.
Now here's the major caveat:
Your observation that https still redirects to http, even with 'a' selected, is correct. The only method that I am aware of to force SSL when serving results with option 'a' is to send the additional 'access' query parameter '&access=a'
'a'=all
'p'=public (default)
https://www.google.com/support/enterprise/static/gsa/docs/admin/72/gsa_doc_set/xml_reference/request_format.html#1087053
BEWARNED: Depending on how your GSA is configured, there may be privacy implications if your organization maintains public collections containing private urls requiring authentication. URLS that require auth will be served right along with the rest of your results.
Changing the settings you mention to "No" will cause the GSA to use whatever protocol you started the experience with to be used.
Choosing the other options will cause the GSA to switch protocols.
Edit - It looks like this not possible. It doesn't matter what you request, the GSA will redirect based on the config.
If you create an SSL certificate for your GSA's host name and install the valid SSL certificate then it should serve results on port 443 (HTTPS) correctly.
i.e. if your GSA is "search.mydomain.com" then create a properly signed SSL certificate in that name and install to the GSA.
Typically this works without a certificate but the browser will show a warning message due to no SSL certificate / invalid SSL certificate.
I'm working with a sysadmin that uses a Juniper solution that behaves as a proxy. I have no idea what it is, but here's a picture of the web interface: http://imagebin.ca/v/1UKN1jGYPUWd
Through that proxy, I'm trying to use Sharepoint's REST API, unfortunately there are some headers (such as X-RequestDigest) that Juniper's proxy doesn't forward to Sharepoint.
Basically, I need the equivalent of nginx's proxy_pass_request_headers for Junipers' applications.
The sysadmin doesn't seem to know what HTTP header forwarding is, or how to configure it. Can anyone identify the solution he's using from the picture ? Does anyone know where to find documentation about this ?
Further to my comment added above, there appears to be no way to implicitly pass variables around. You can tell the current IVEOS images that the Web URL you're linking to is a Sharepoint Site, and it'll do "clever" things with the URL, but I'm not exactly sure what you want it to do, and whether they'll handle it.
Here are the screen shots for the "Sharepoint" configuration panels on the Web Resources page. As I'm not a Sharepoint Admin, I can't tell you whether these are useful to you or not.
I hope it helps!
You may be looking for the Web Resource custom header policy
https://www.juniper.net/documentation/en_US/sa8.0/topics/task/operational/secure-access-web-rewrite-custom-header-policy.html
Edit: The first resource became a dead link. New link: https://www.juniper.net/techpubs/en_US/nsm2012.2/topics/task/configuration/remote-management-secure-web-resource-policy-configuring-nsm.html
Fur custom headers (to send some user information) we've used the "Web Rewriting Resource Policy"
SSO Cookies/Headers > General tab -> Headers and Values
to pass custom user data (user name, role, client certificate).
I assume you have the backend application (sharepoint) configured as the a PTP (PassthroughProxy) we bresource. I am pretty confident that only standard HTTP headers are passed to the backend by default :(
To pass all custom headers I found following book (Juniper(r) Networks Secure Access SSL VPN Configuration Guide): https://books.google.be/books?id=5OYf6u5vzFsC&pg=PA369&lpg=PA369&dq=Juniper+pass+custom+headers&source=bl&ots=s5oF5NEKjP&sig=8091EV2Pyw6pIFQifMOIR2pLpLk&hl=de&sa=X&ved=0ahUKEwiFwpf6m_DOAhWFWRQKHXoRD0EQ6AEIPDAE
where it says
Passing custom headers can be enabled by:
Users > Resource Polities > Web > Custom Headers
This option may not be visible on the admin interface by default, it needs to be enabled:
Users > Resource Policy > Web > Web ACL and there's a "Customize" button
I'm trying to get Fiddler to work with my company's proxy. Every external request is returning 407.
So far I've tried adding oSession.oRequest["Proxy-Authorization"] = "YOURCREDENTIALS"; to the customized rules where I used my USERNAME:PASSWORD in base64. Still no luck.
Any ideas? Thanks.
What worked for me was much more simpler:
Rules > Automatically Authenticate
Note: There is an answer with a higher voting available. Because of SO sorting it is below the accepted answer.
I had the same problem, too, and solved it like this:
Started Fiddler with it's standard configuration.
Started IE and made a HTTP-request to an external web-site.
The proxy authorization dialogue popped up, where I entered my credentials.
In Fiddler searched the request headers for "Proxy-Authorization".
Copied the header value which looked like "Basic sOMeBASE64eNCODEdSTRING=" to the clipboard.
Altered the CustomRules.js with the following line within OnBeforeRequest:
oSession.oRequest["Proxy-Authorization"] = "Basic sOMeBASE64eNCODEdSTRING=";
So my approach was quite similar to yours just that in advance I checked what kind of proxy authorization the server required by using Fiddler to debug the authorization header. That way I found out I had to add "Basic" before the Base64 encoded credentials and I didn't even have to use the tool to encode the credentials to Base64. Just copied the value from the proxy authorization header.
My Answer is simple. If your company proxy is NTLM, download ,setUp and configure cntlm. Route your fiddler to cntlm port by setting proxy settings.
Done! that is how i configured fiddler in my company
What version of Fiddler are you using?
Fiddler will automatically chain to your organization's proxy, and all current versions of Fiddler support passing of authentication information between the client and the authenticating proxy.
How are you generating the HTTP requests in question? What are the exact HTTP response headers?
http://blog.bareweb.eu/2010/10/http-debugging-fiddler-tip-1/
There's an entry in the "Rules" menu for Requiring Proxy Authentication. Use that and you should get a bit further!
Fiddler should pick up native proxy configuration automatically.