When hosting a website using HTTP Authentication, if the client has not authenticated, the server will send a 401 Unauthorized response, including a WWW-Authenticate header. An optional directive in this header is realm:
A string describing a protected area. A realm allows a server to partition up the areas it protects (if supported by a scheme that allows such partitioning), and informs users about which paricular username/password are required.
(emphasis mine)
Let's say www.example.com requires authorization and has configured a realm value of Test Area. Back in the day, most web browsers would display a login dialog when receiving such a response, and say something along the lines of "Authorization required. The site at www.example.com says 'Test Area'."
But (at least recent versions of) Chrome, Firefox, and Edge, now all just display a generic message, without including the realm value. Interestingly enough, IE still displays the realm value (screenshots below, all Windows 10 64bit):
Chrome (v93.0.4577.82)
Firefox (v92.0)
Edge (v93.0.961.52)
IE (v11.1411.18362.0)
I'm pretty sure Firefox and Edge used to display it. Chrome may have a while back but seems like it was the first to stop. Since all modern browsers aren't displaying it, I assume there's some reason why..?? I've search all over the internet, and can't figure it out. I have a use-case where it would be helpful to users to have the realm displayed, as it would make it clearer which particular credentials they need to use. I know that you can't force the browser to display it, but it's just annoying. However if there is a valid reason for it not being shown I'll accept that.
The reason is that this could be abused for phishing attacks, by putting some misleading message into the realm. The login dialog for http authentication is part of the trusted browser UI, and giving the server the opportunity to modify that UI - even by just displaying text - is a security risk.
Related
I have a legacy web application. The app needs to be opened in IE while the user opens it from Edge Chromium. I've added the URL to the EM site list XML on a NAS share. This works great for other legacy applications we have.
However, this application uses a HTTP POST request.
When a user navigates in Edge to the web application, it loads fine in a new IE11 screen.
But when you use the search, it opens in a new Window and it seems the parameters from the HTTP POST request are not included. This results in a null request.
Is there any setup needed to include the HTTP post request in IE mode? I can't find this anywhere in the MS documentation.
We've replaced the post request with a get request and solved the issue this way
We had the same symptoms. I did not verify that the http method was changed from POST to GET, but the form variables from a POST operation were not being transmitted to the next page.
We were able to get this working by adding the source page (the one with the form variables in it) to the Enterprise Mode Site List in Edge.
In Edge, paste the following into the address bar (without the quotes): "edge://compat/SiteListManager"
I checked the box to Allow Redirects and also used IE5 Document mode as the Compat Mode because that is what was indicated by f12 tools when running the same page in real IE 11.
See also https://learn.microsoft.com/en-us/deployedge/edge-ie-mode-site-list-manager
And https://learn.microsoft.com/en-us/deployedge/edge-ie-mode-faq
When typing a web link into the safari URL field, the browser attempts to prefetch all links it has previously seen before, both GET and POST.
This causes each and every web link a server supports that is listed in the dropdown as a possible completion to be activated. This is problematic. For example, if a web site has authentication with an /auth/logout link for logging out, then this can cause the link to be activated if it appears in the dropdown, logging the user out unintentionally.
Many browsers send a specific header (eg. 'Purpose: Prefetch' in chrome) that allows the server side to filter prefetch/preload requests (eg. return a 503) but Safari doesn't seem to send any distinguishing header field. It also seems to try to prefetch POST requests, which seems very broken to me. Get requests are notionally at least idempotent, but POST requests are supposed to be understood to be data changing.
Has anyone got a solution to this? Please don't suggest that the browser preload feature can be turned off by the end user - that ISN'T a solution from a service delivery perspective.
Has anyone got an explanation as to why browsers would do this and NOT signal the purpose in a header field? (I get why prefetching is a useful Ux capacity, but not why its useful while typing URLs, especially for URLs already previously downloaded and thus capable of returning prefetching metadata that would allow a server to selectively disable the capability where appropriate) From what I can tell, this kind of functionality started to appear with header fields included, but some browsers have removed this signature. why? It seems to be dreadfully broken to me.
thanks.
I want to change the message that pops up during implementation of Basic Auth.The current default message is:
Server requires a username and password.
Something that would be more accurate for me is :
Server requires an Email and Password.
My problem is that i can't find or don't know where this message is set and if it can be changed. Most of the questions online are about Basic Auth implemention but this is not my problem -- i can implement it very fine. I just need a more accurate response for the user.
Here is how i force an authentication window using echo:
c.Response().Header().Set(echo.HeaderWWWAuthenticate, `Basic realm="Your Email is your Username"`)
return echo.ErrUnauthorized
NB: Only Firefox shows the realm message. Both Chrome and Opera do not.
This is not related to Go but actually to browser behaviour when receiving that header.
It seems Chrome/Chromium has a known issue with this related to the feature not considered secure by the development team, so I don't think you'd be able to fix it on your side unless you resort to some other authentication mechanism.
See here for more details:
https://bugs.chromium.org/p/chromium/issues/detail?id=544244#c32
Thanks for the responses but they were not satisfactory. I had to do some reading on this topic.
The correct answer is that the login prompt/dialog is a response built into the user-agent/browser and cannot be changed by the server. This also explains why some browsers show realm while others don't.
According to Wikipedia Basic access authentication all the server does is:
When the server wants the user agent to authenticate itself towards the server, it must respond appropriately to unauthenticated requests.
Unauthenticated requests should return a response whose header contains a HTTP 401 Unauthorized status[4] and a WWW-Authenticate field.[5]
The WWW-Authenticate field for basic authentication (used most often) is constructed as following:
WWW-Authenticate: Basic realm="User Visible Realm"
Let's say that a page is just printing the value of the HTTP 'referer' header with no escaping. So the page is vulnerable to an XSS attack, i.e. an attacker can craft a GET request with a referer header containing something like <script>alert('xss');</script>.
But how can you actually use this to attack a target? How can the attacker make the target issue that specific request with that specific header?
This sounds like a standard reflected XSS attack.
In reflected XSS attacks, the attacker needs the victim to visit some site which in some way is under the attacker's control. Even if this is just a forum where an attacker can post a link in the hope somebody will follow it.
In the case of a reflected XSS attack with the referer header, then the attacker could redirect the user from the forum to a page on the attacker's domain.
e.g.
http://evil.example.com/?<script>alert(123)>
This page in turn redirects to the following target page in a way that preserves referer.
http://victim.example.org/vulnerable_xss_page.php
Because it is showing the referer header on this page without the proper escaping, http://evil.example.com/?<script>alert(123)> gets output within the HTML source, executing the alert. Note this works in Internet Explorer only.
Other browsers will automatically encode the URL rendering
%3cscript%3ealert%28123%29%3c/script%3e
instead which is safe.
I can think of a few different attacks, maybe there are more which then others will hopefully add. :)
If your XSS is just some header value reflected in the response unencoded, I would say that's less of a risk compared to stored. There may be factors to consider though. For example if it's a header that the browser adds and can be set in the browser (like the user agent), an attacker may get access to a client computer, change the user agent, and then let a normal user use the website, now with the attacker's javascript injected. Another example that comes to mind is a website may display the url that redirected you there (referer) - in this case the attacker only has to link to the vulnerable application from his carefully crafted url. These are kind of edge cases though.
If it's stored, that's more straightforward. Consider an application that logs user access with all request headers, and let's suppose there is an internal application for admins that they use to inspect logs. If this log viewer application is web based and vulnerable, any javascript from any request header could be run in the admin context. Obviously this is just one example, it doesn't need to be blind of course.
Cache poisoning may also help with exploiting a header XSS.
Another thing I can think of is browser plugins. Flash is less prevalent now (thankfully), but with different versions of Flash you could set different request headers on your requests. What exactly you can and cannot set is a mess and very confusing across Flash plugin versions.
So there are several attacks, and it is necessary to treat all headers as user input and encode them accordingly.
Exploitation of xss at referrer header is almost like a traditional reflected xss, Just an additional point to make is "Attacker's website redirects to victim website and hence referrer header with required javascript will be appended to the victim website request".
Here One essential point that needs to be discussed is Why only with IE one can exploit this vulnerability why not with other browsers?
Traditional answer for this question is 'Chrome and firefox automatically encodes URL parameters and hence XSS is not possible..' But interesting thing here is when we have n number of bypasses for traditional xss bypasses. why can't we have bypasses for this scenario.
Yes.. We can bypass with following payload which is same way to bypass HTML validation in traditional payload.
http://evil.example.com/?alert(1)//cctixn1f .
Here the response could be something like this:
The link on the
referring
page seems to be wrong or outdated.
Response End
If victim clicks on referring page, alert will be generated..
Bottomline: Not just only IE, XSS can be possible even in Mozilla and Firefox when referrer is being used as part of href tag..
I've recently enabled Digest Authentication on an intranet website/application I am creating for my company in ASP.NET.
The reason I have done so is because Windows Authentication seemed to only work for some users, and not for others. I could not figure out why nor do I know enough about IIS to try and trace the issue. After some trial and error, I found that digest authentication seemed to give me the behaviour that I wanted. That is: allow only users with a valid account on the domain to log in to the website with their credentials.
The problem now, is that Firefox (3+) seems to ask for the user to authenticate on every HTTP request sent to the server. This does not appear to occur in Internet Explorer (6+) or Chrome.
I've tried searching for solutions but I always arrive at dead-ends. I'll find a discussion about the issue, and every posted solution leads to a dead link...or it's on Experts Exchange and I don't have access to view to solution.
The issue appears to be related (from what I've read) to the way the different browsers send their authentication headers vs how IIS interprets them. I'm not sure what I can do to change this though? One of the solutions I had found mentioned writing an ISAPI filter to fix this, but of course the link to the finished filter was broken and I have no idea how to go about making one myself.
I've tried messing with the NTLM and other auth related strings in about:config to try and force Firefox to trust my server but that doesn't seem to work either.
From a few other sources I've read, it appears that everything should work if I switch back to Windows Authentication, but then I'm back at square one where the authentication would work only for some users and not others.
A solution for either problem would work for me, but I have very little information for the Windows Authentication issue. If someone could guide me through tracing the problem I'd gladly post more information for it as well.
Here are the URLs I've found discussing what seems like the same problem. (Sorry I couldn't make them all links, it wouldn't let me post otherwise)
support.mozilla.com/tiki-view_forum_thread.php?locale=pt-BR&forumId=1&comments_parentId=346851
www.experts-exchange.com/Software/Internet_Email/Web_Browsers/Mozilla/Q_24427378.html
channel9.msdn.com/forums/TechOff/168006-Twin-bugs-in-IIS-IE-unfair-competitive-advantage-EDIT-SOLVED/
www.derkeiler.com/Newsgroups/microsoft.public.inetserver.iis.security/2006-03/msg00141.html
This is a know bug in FF. See Advanced digest authentication works from Internet Explorer however we receive multiple authentication prompts on each GET request from fire fox
IE 6 had the same bug.A potential workaround would be to re-enable "old" Digest in IIS6:
http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/1d6e22ac-0215-4d12-81e9-c9262c91b797.mspx?mfr=true
Currently, if the server send an opaque directive, the IE client will return this directive value as specified in the RFC. Unfortunately, for follow-on requests from the client where the nonce count is incremented (count 2 and beyond) the opaque directive value is not sent. This then fails authentication on the server and a 401 Unauthorized is returned. The IE client now requests the username and password for the new challenge and the file is retrieved.
This requires an additional round trip and the user is prompted for credential each time.
The RFC states that the opaque must always be sent on requests from the client.
The Digest implementation that IE6 is using is not RFC compliant (http://www.ietf.org/rfc/rfc2617.txt).
3.2.2 The Authorization Request Header
The values of the opaque and algorithm fields must be those supplied
in the WWW-Authenticate response header for the entity being
requested.
3.3 Digest Operation
A client should remember the username, password, nonce, nonce count and
opaque values associated with an authentication session to use to
construct the Authorization header in future requests within that
protection space.
Because the client is required to return the value of the opaque
directive given to it by the server for the duration of a session,
the opaque data may be used to transport authentication session state
information.
-------- Edit addition -----
Windows Authentication seemed to only work for some users, and not for others.
How did it fail? Did you enable impersonation?