I'm using php to redirect users to a directory protected with apache basic authentication. I'm using the following url format to automatically log users into this directory:
http://username:password#www.somewebsite.com/protected.
This works fine in all browsers except IE, which no longer supports passing the username/password in the url.
Is there another way for a web application to automatically log a user into a directory protected with apache basic auth?
Update: If possible, please disregard the inherent downsides of using apache basic auth and http unless you are able to provide a viable alternative that addresses this question...namely how I can automatically log a user into a protected directory. This is for a client that is already using apache basic auth. Thanks :)
Microsoft has an detailed explanation of this issue including different workarounds in their knowledge base. This should get you on to a good start.
Please do also take a look at my comment about mixing HTTP with Basic Auth. You usually don't want to do this if security is an issue. Always use HTTPS because Basic Auth is not encrypted.
Related
I am following a tutorial on setting up realms.
I am protecting the URL http://fec.example.com:80 with a apache web agent pointing to my openam server.
When I access http://fec.example.com:80 I expect it to go to
http://subscribers.example.com:18080/openam/XUI/?goto=http%3A%2F%2Ffec.example.com%3A80%2F#login/
But instead it goes to:
http://subscribers.example.com:18080/openam/XUI/?goto=http%3A%2F%2Fopenam.example.com%3A18080%2Fopenam%2Foauth2%2Fauthorize%3Fresponse_mode%3Dform_post%26state%3D704b6f90-af10-214e-92bb-61b2ab1d05e5%26redirect_uri%3Dhttp%253A%252F%252Ffec.example.com%253A80%252Fagent%252Fcdsso-oauth2%26response_type%3Did_token%26scope%3Dopenid%26client_id%3Dwebagent%26agent_provider%3Dtrue%26agent_realm%3D%252Fsubscribers%26nonce%3D6F8D1B2B7D3EDD5547812671C2415BAB&realm=%2F#login/
Any ideas on how I can fix this?
Thanks
This means you are using Agent version 5 and this is now using OIDC to achieve SSO. Please have a look at the docs.
I have site where user need to get http basic authentication prior to access the url lets say www.mybasicauthurl.com. Basic authentication can be passed in either way
Browse the url and enter the username, password on the pop-up if not done already.
Access the url as: username:password#www.mybasicauthurl.com
Now I use approach #2 supply the basic auth credential via url itself. This works fine and I can able to see the legitimate web page but
When I open firebug and see the all loaded static files it shows me something like
http://username:password#www.mybasicauthurl.com/static/jquery/jquery.js
http://username:password#www.mybasicauthurl.com/static/css/styles.css
http://username:password#www.mybasicauthurl.com/static/image/image1.png
Please note the prepend text username:password# in the url. I don't want that I just want these static files to be loaded normally like
http://www.mybasicauthurl.com/static/css/styles.css
I don't know if this is something done by the browser or apache server.
Would be appreciated even if share some useful link that I missed to google.
If you want to avoid HTTP auth on static resources, the best thing to do is to remove it server-side.
That means static resources would ba available without authentication, but if nothing important is present in the static resources, that's good.
Should be something like that:
# Apache < 2.4
<Location /static>
Satisfy Any
Allow from all
</Location>
# Apache >= 2.4
<Location /static>
Require all granted
</Location>
Another point. If the thing you do not like is the presence of username:password in the HTML source, that's effectively quite bad, and depending on the browsers versions it may or may not be supported (tends to be removed). That's a clear text information, could be intercepted or stored on the browser cache. But you are also using http:// and not https:// and this is even worse. The username:password is transmitted in clear text for each request of the browser, everybody can read this information!
When using Basic HTTP Authentification you must use HTTPS. Credentials are transmitted with a simple base64 encoding, it's just an ascii-7-trick encoding (like utf-8 is an encoding). So if you want to protect this username/password information you will also need HTTPS.
I would appreciate any hints regarding the following issue:
The problem summary:
While using Negotiate:Kerberos in IIS 7.5, the authorization works correctly right until we setup URL rewriting (using the MS module "URL Rewrite 2.0") - any rewritten URL then returns "401.1 Unathorized" (requests not matching any rewrite rule keep working though).
The setup:
Windows Server 2008 R2 x64
IIS 7.5
URL Rewrite 2.0
Server is in a domain
SPN exists for HOST/hostname and HOST/hostname.domain (created by default)
Pool is using default ApplicationPoolIdentity (no custom account, not network service)
Kernel mode set to OFF
Authentication providers set to "Negotiate:Kerberos" only (no NTLM or annonymous)
URL Rewrite rule as as "^(.*)/$" => "index?x={R1}"
The result:
1) When accessing any URL not matching any URL rewrite pattern, Kerberos is working correctly, i.e. Kerberos ticket is issued (verified using klist), sent (verified using netmon and HTTP headers) and accepted (verified by URL being accessible and appropriate AUTH_USER property set to my domain account name) => no problem here.
2) When accessing any URL matching URL rewrite pattern, e.g. "hostname/foo" the result is:
HTTP Error 401.1 - Unauthorized
You do not have permission to view this directory or page using the credentials that you supplied.
Module WindowsAuthenticationModule
Notification AuthenticateRequest
Error Code 0x80070055
Requested URL http://hostname/index?x=foo
Physical Path D:\wwwroot\
Logon Method Not yet determined
Logon User Not yet determined
(if we try to access the rewritten URL directly, e.g. hostname/index?x=foo, Kerberos works again normally)
The attempts to solve it so far:
After googling, we have tried several options:
turning kernel mode ON: Kerberos stopped working completely, using either default pool identity or network service (I suppose we would need to setup additional HTTP SPN and/or use custom domain account with additional SPN for that account explicitly)
turning "useAppPoolCredentials" ON: no difference
enabling "Failing Request Tracing": surprisingly these failing 401.1 requests ARE NOT generating any output into the fail logs no matter what rule we try to setup (e.g. 400-999) - the folder is just empty (while other errors, like 404 or even handshake 401.x when accessing not-rewritten URLs are generating logs - very strange)
The conclusion:
So far we have reached a dead end - it may be some weird kind of "double hop" issue requiring using a custom domain account rather than default app pool identity, but as we're in fact accessing the same resources, it seems more like a URL Rewrite issue.
Any tips, hints, pointers? Anything would be highly appreciated.
Best regards,
Marek
we face the same issues as you do. By enabling extended error logging, we were able to put the finger on the actual problem, which seems to be a bug in the rewrite module (or at least in some part of IIS, which is related to the module):
When the URL gets rewritten, the access to the new rewritten URL is checked (seemingly hardcoded) using Basic Authentication and NTLM, neither of which has been configured on the Website at hand. The only configured authentication provider is Kerberos. Since the client doesnt send NTLM nor Basic credentials, there is no way this can work.
We (another person on the current project) are sending the issue to Microsoft. I will let you know, when I get any result.
It seems as though you have multiple issues here.
Failed-Request Tracing Logs
To fix your missing logs issue, you must make sure that the user that is running your site's AppllicationPool has read/modify rights to the folder where those logs are generated, otherwise you won't see anything. See the section labeled "Enable Failed-Request Tracing" on this page: Troubleshoot Failed Requests Using Tracing in IIS 7
What isn't clear is the fact that the site's Application Pool Identity (found in Advanced Settings for Application Pool) is the account that needs read/modify rights to that folder.
Once that is fixed you can load the XML logs in IE and see a much clearer picture of what is going on.
401.1 - Unauthorized Issue
A possible fix to your 401 error is to make sure unlisted file name extensions are allowed in Request Filtering. Go to IIS --> Sites --> [your site] --> Request Filtering
You have two options here:
Allow File Name Extension... and add the value "." (minus the quotes), see this answer.
Edit Feature Settings... and enabled the option "Allow unlisted file name extensions"
The 1st option should work well, the 2nd option obviously opens up a gaping hole but allows everything so you should be able to get it working.
I hope that helps.
I am not asking how. I am asking if. Is it possible to bypass a 403 error on the web?
Let me explain a bit in detail. On a web server the IIS has set up a directory for a project we are such that it is not accessable to the outside. So if you type the path to that directory in a web browser, the web browser will say that it is not accessable and it will throw a 403 error.
Now, here is the problem. Some files are placed there with some secure information. A programmer on our team has made a big deal about this and the fact that the files are placed on a server that is accessalbe to the outside world. On the other hand, I think this is not such a big deal since if a user on the outside tried to go to that directory, his web browser will throw the 403 error. But other people on the team say that a hacker can still somehow access it.
So that leads me here and to my question. Is it possible to bypass a 403 error on the web? I say no. Some network guys at work say maybe. I am not asking how to do it. I am only asking if it is really possible.
I gather from your information that there is a web server with a directory setup on the web like so
http://www.example.com/directory
Now, if you navigate to this URL you get a 403 Forbidden error? However, if you know the name of a file you can go to http://www.example.com/directory/MyImportantDocument.docx and it is possible to view the document at this location?
Unless there is a runnable script on your server that does this, it is not possible to view the directory contents via the web. However, URLs are not considered secure as they are logged in browser history, proxy and server logs and can also be leaked by browsers' referer header. I assume the files are stored here so they can be accessed by a remote application?
File names can be easily brute forced by an attacker. Tools such as dirbuster and dirb do this automatically. Therefore, if the files do not need to be readable remotely, they should be moved to an internal server, not accessible from the internet or DMZ.
If access is needed you should implement some sort of authentication. At the very least activate basic auth on IIS. This will prompt a web browser user for a username and password in order to view files, or the files can be accessed programmatically by setting the appropriate Authorization header, which is an encoded username and password.
Better would be something with comprehensive session management, like an application pre-built for this purpose. E.g. a CMS which is kept up-to-date and securely configured.
Also you should make sure that the IIS website is only configured to be accessed via HTTPS which will protect against traffic snooping of the credentials, URL path, headers and file contents.
In some cases (e.g. Back-end or web server mis-configuration) it's possible to bypass 403. For understanding those methods read this script:
https://github.com/lobuhi/byp4xx
this script contained well-known methods and collected from various bug bounty communities.
So if your back-end server not vulnerable to this script, probably it's safe.
So basically it is NOT possible if the server software itself doesn't has any bug. But if you have other parts of your website that are public and probably using a dynamic scripting language that may higher your risk if someone is able to find a hole with something like "access file from filesystem".
In general I would recommend you to NOT store any security relevant files on a public server that don't need to!
If you could avoid it, it's always the better way.
There is a simple exploit to bypass .httacess restrictions... Try to Google "bypass error 403" and you will find the method. As auditor I can confirm that it is not a good practice (and if I see it I will always raise it as an issue) if you store credentials (or any other sensitive information) in plain text on web server.
I've set up a small test server that does custom two-factor authentication on Apache, using a mechanism similar to this:
In <VirtualHost> file (of course, there are lots of other settings!):
<Location /2factor>
PerlAccessHandler Apache::TicketAccess
ErrorDocument 403 /perl/login.pl
</Location>
So, when I try to access a file in the /2factor directory I get redirected to a login script where I verify a user, password and TOTP from Google Authenticator, if an appropriate cookie is not present. This all works perfectly from both a browser and a smartphone app.
I've been asked to move this code to IIS, but all the example code I see uses either the browser's built-in authentication or LDAP-based solutions. How should I approach this? I'm not wedded to Perl; a C#-based method is perfectly acceptable.
Note, my test environment is just IIS 5.1 and XP.