How to correctly add header in TinyProxy to authenticate in Squid - proxy

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.

Related

407 authenticationrequired in JMeter

I work in a company where we use a proxy to access any browser website.
We would like to start API testing with JMeter, but have a problem.
Whenever I try to add an API call to petstore.swagger.io/v2/pet/10, for example, and put in the proxy details in the "Advanced" section of the HTTP request + adding an HTTP authorization manager with Username + Password, it still gives me a "407 Authenticationrequired" error back.
Request headers:
Response headers:
In the information I have also it's that the proxy is "Ruleset Name: Authentication with Kerberos and NTLM Fallback".
This is quite a problem if I'd like to test internal APIs with any authorization on it.
HTTP Status code 407 means that proxy authentication required, it seems that you're using a corporate proxy to access the application under test and this proxy requires credentials.
You have 2 options of passing the proxy credentials to JMeter:
Command-line arguments like:
jmeter -H my.proxy.server -P 8000 -u username -a password
JMeter System properties (you can put these lines to system.properties file
http.proxyUser=username
http.proxyPass=password

Fiddler gateway proxy username/password

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.

Why windows 8 sends different authorization header after login into MS account

What we have?
Client : win8, ie11, logged in into system using domain credentials.
Server : 3 tomcat7 nodes run beyond apache 2.2.22. application uses waffle library to authenticate windows users who are logged in into domain in sso manner.
Application uses spring security and the main thing regarding this topic is that filter that handles login via form comes before filter that handles authentication headers.
NegotiateSecurityFilterProvider supports only Negotiate protocol, not NTLM
What we do?
Go into application via direct link : https://app.domain.com/app_name/subordinates.do.
It is ok, we are bearing valid kerberos header (it is good and big one kerberos token which fiddler describes as 'Authorization Header (Negotiate) appears to contain a kerberos ticket' ^^) and waffle on application side passes us inside with kerberos reply.
Logout.
Login via form on login page: we make post request with user_name and password, again we bearing same kerberos token. Application uses user_name and password to login us with help of waffle WindowsAuthenticationProvider. Here we get authenticate before we rich NegotiateSecurityFilter, so there is no any kerberos header within reply from server. Anyway everything is ok.
Now we are log into MS account via OS. And magic happens.
When trying to login via direct link we get 'The handle specified is invalid' error on login page as SPRING_SECURITY_LAST_EXCEPTION constant. my guess here is that we send some kind of invalid authorization header
And when trying to login via form we get 'The parameter is incorrect'. here i think we send ntlm type 1 POST request with empty body but we still have invalid header so application does not recognize it and does not sent 401 reply and thereafter waffle sends null name to AD and here error comes (just guess)
BUT when I turn fiddler on to see what is really happened then everything begins to work fine as before login into MS account. Ok, to figure out what header are sent to the server I used some code inside cmd file:
UDPATED add code and output
var cookieContainer = new CookieContainer();
var authRequest = (HttpWebRequest) WebRequest.Create("https://app.domain.com/app_name/home.do");
var credentials = CredentialCache.DefaultNetworkCredentials;
authRequest.Credentials = credentials;
authRequest.CookieContainer = cookieContainer;
authRequest.AllowAutoRedirect = false;
var authResponse = (HttpWebResponse)authRequest.GetResponse();
Console.WriteLine("Request headers:");
foreach (string header in authRequest.Headers.AllKeys) {
Console.WriteLine("\t{0}: {1}", header, authRequest.Headers.Get(header));
}
Console.WriteLine("\nResponse: {0} {1}", (int)authResponse.StatusCode, authResponse.StatusDescription);
Console.WriteLine("Response headers:");
foreach (string header in authResponse.Headers)
Console.WriteLine("\t{0}: {1}", header, authResponse.GetResponseHeader(header));
foreach (var cookie in cookieContainer.GetCookies(new Uri("https://app.domain.com/app_name/")))
Console.WriteLine("Received cookie: {0}", cookie);
Console.WriteLine("\nPress ENTER to exit");
Console.ReadLine();
Here what I get:
Request headers:
Authorization: Negotiate oTMwMaADCgEBoioEKE5UTE1TU1AAAQAAAJeCCOIAAAAAAAAAAAAAAAAAAAAABgOAJQAAAA8=
Host: {host}
Cookie: JSESSIONID={sessionId}
Response: 302 Found
Response headers:
Vary: Accept-Encoding
Content-Length: 0
Content-Type: text/ plain; charset=UTF-8
Date: Tue, 04 Feb 2014 11:44:15 GMT
Location: https://app.domain.com/app_name/login.do?error_code=1
Server: Apache/2.2.22 (Win32) mod_ssl/2.2.22 OpenSSL/0.9.8t mod_jk/1.2.37
Received cookie: JSESSIONID={sessionId}
It is definitely much smaller header than kerberos one what fiddler sees when authentication works.
So questions are:
1. Why does loging into MS account affect what headers are sent to server?
2. Why it begins to work when fiddler on?
3. What type of this header : Negotiate oTMwMaADCgEBoioEKE5UTE1TU1AAAQAAAJeCCOIAAAAAAAAAAAAAAAAAAAAABgOAJQAAAA8= and how should it be handled by server?
UPDATE 17 March 2014:
wireshark capture shows KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN error after tgs request, server mentioned - machine name with apache.
After investigation with support team we found out that special user which is used to run tomcat servers on different nodes didn't have spn for domain name of machine with apache (it had spn for resource domain name but not for current machine). After spn was added problem disappeared.
After decoding oTMwMaADCgEBoioEKE5UTE1TU1AAAQAAAJeCCOIAAAAAAAAAAAAAAAAAAAAABgOAJQAAAA8= we can see that it contains NTLMSSP (a new version).
Check browsers configuration:
In Internet Explorer: webpage should be in "Local intranet" zone (in a zone in which user is logged automatically) and that IWA, Integrated Windows Authentication is enabled.
If that's not the case, please take a look in Wireshark for dns and kerberos packets.
Check DNS:
IE uses dns to resolve webserver address into principal name. CNAME address is resolved into A address. If not found, IE will not ask for Kerberos service ticket at all (and will fallback to NTLM).
Check SPNs:
When Active Directory can't find requested principal (or there or two, or more). Then IE falls back into NTLM.

Is it secure to pass login credentials as plain text in an HTTPS URL?

Is it secure to pass login credentials as plain text in an HTTPS URL?
https://domain.com/ClientLogin?Email=jondoe#gmail.com&Passwd=123password
Update: So let's say this is not being entered in the browser, but being generated programmatically and being requested with a POST request (not a GET request). Is it secure?
Solution:
It is not secure to use this type of URL in a GET request (i.e. typing the URL into the browser) as the requested URL will be saved in browser history and server logs.
However, it is secure to submit as a POST request to https://domain.com/ClientLogin (i.e. submitting a form) while passing the credentials as part of the POST body, since the POST body is encrypted and sent after making a connection to the requested URL. So, the form action would be https://domain.com/ClientLogin and the form field values will be passed in the POST body.
Here are some links that helped me understand this better:
Answer to StackOverflow Question: Are https URLs encrypted?
Straightforward Explanation of SSL and HTTPS
Google Answers: HTTPS - is URL string itself secure?
HTTP Made Really Easy
No. They won't be seen in transit, but they will remain in:
browser history
server logs
If it's at all possible, use POST over HTTPS on authentication, and then set a "authenticated" cookie, or use HTTP Digest Authorization over HTTPS, or even HTTP Basic auth over HTTPS - but whatever you do, don't put secret/sensitive data in the URL.
Edit: when I wrote "use POST", I meant "send sensitive data over HTTPS in POST fields". Sending a POST http://example.com/ClientLogin?password=hunter2 is every bit as wrong as sending it with GET.
TL;DR: Don't put passwords in the URL. Ever.
Passing login info in url parameters is not secure, even with SSL
Passing login info in POST body with SSL is considered secure.
If you're using SSL, consider HTTP Basic authentication. While this is horribly problematic without SSL, it is no worse than POST with credentials, it achieves what you want, but does so according to an established standard, rather than custom field names.

Configuring Fiddler to use company network's proxy?

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.

Resources