What I think of is detecting authentication attempt and logging user in using PHP and standart HTTP credentials without bugging him with popup, when he does not try to login. That may sound easy, but we must keep in mind, that browsers check whether site is requesting authentication, and when it does not, they are bugging user with warning and they also send no data.
Is there any bypass? Any trick?
QUESTION SUMMARY:
I want url http://example.com/site to work wihout any promts and popups. User will see the site as anonymous.
I want url http://user:password#example.com/site to work without any popups too. User will see the site as user
To answer your question: no there is no way around it. The browser will not send the authentication information if it has not been requested by the website, and as you have discovered, it will also show an annoying security warning to the user. You should bite the bullet and use a GET param.
Related
I need to load the login page of another website (different domain), wait for the user to fill it in and submit it, then read the URL/Location/Querystring for a token parameter to my site and close the login page.
Don't want the username or password, only interested in the returned token (http://www.othersite.com/?token=blahblahblah), which will then be passed as a querystring to a page on my domain (http://www.mydomani.com/loadtoken.php?token=blahblahblah).
Currently, a user has to do this in a separate page, copy and paste the token into my page, since these tokens only have a short life, it's somewhat irritating practice, and if it can be done behind the scenes by the site instead it would make it simpler for everyone.
Reading around on iframes, divs and ajax suggest this is not possible due to security policies, cross site scripting, etc.
Is it possible? What should I be looking for or concentrating on, or can you give some examples.
Thanks for your help.
Edit: Should have said, I understand that it's possible to take the username and password and do a POST behind the scenes, but I really want to avoid making the users give my site their login details to another site, for obvious reasons.
The simplest method is to present the login form on your own site. The form posts to your server, and the handling script then does a CURL request to do its own request to the other server. This sends the login response (which presumably contains that token) to your server.
However, if this token takes the form of a cookie, and the cookie's required for the user to do further operations on their own on this other site, then this won't work. There is absolutely no way for your server to accept the cookie on the user's behalf, then send the cookie to the user in such a way that it appears to have been set by the other server.
The easiest way would be for you to post that form's information to the remote host and have that site send the token to a callback script on your own host.
I need to load the login page of another website (different domain), wait for the user to fill it in and submit it, then read the URL/Location/Querystring for a token parameter to my site and close the login page.
You can't do that
What should I be looking for
OAuth / XAuth (which will require the co-operation of the site you are trying to log in to)
I want to create my own personal login gateway into Gmail/Facebook/any other site. In this gateway I enter my master username and password, then I can choose where to login (gmail/facebook/etc) without entering those usernames because they are stored on the server.
I tried to implement this by using cURL to send POST request with the headers and post data sent in Firefox during regular login. However, this doesn't work for neither facebook or gmail.
Has anyone tried this or have an idea about why this doesn't work?
Thanks.
// Edited
I am thinking the problem that it doesn't work lie in the fact that the IP address of the php server which sent the curl request to gmail is different from my browser's so, when the response from the gmail server is fed back to the browser, it still cannot authenticate.
Or is that the cookie I sent using curl to Gmail server actually changes according to time.
Based on your reply to my comment cURL is useless for your problem. You need to authenticate your browser with your services (gmail, facebook, ...), what you are doing now is authenticating your script (or your server).
You will have to use JavaScript to accomplish what you want. If you store your credentials for the services on your server, then send them back to the client once you successfully log-in into your webpage. Then you could create a hidden iframe with the "src" attribute set to the login page of the chosen service. Once the iframe loads you can fill the login information (username/password) into the appropriate fields and submit the form. Once this is complete you should be loged-in into your services.
There are probably some other techniques but this is the first that springs to mind ...
This is not necessarily feasible, Gmail and Facebook may be doing very simple checks to see who the referer is and when it comes from your site rather than their own login page refuses to login. This is basic security checks.
You would need to look at their api to see if you can do anything, or possibly you could use javascript and a firefox plugin to write your username and password to the webform then submit the form, a bit of a hack but might do what you want.
There is no reason why the cURL method you tried wont work with the correct headers. playing around scraping sites like digg.com i found i needed a valid USER AGENT header and of course an appropriate REFERER URL, keep going with the curl technique if that will work best for you overall. use an http header add-on to firefox to see what headers you are sending to gmail and then fake them completely.
Tryusing firebug to find out what the response returned, It should always give you the best lead.
I see no reason why it wont work, I read my Gmail and analytics with Curl.
Have you configured curl to accept and store cookies? Usually once you've been authenticated for an online service it will send you a security token in the form of a cookie that you can send back with every subsequent request to verify your authorisation.
This question already has answers here:
Closed 13 years ago.
Possible Duplicate:
HTTP authentication logout via PHP
Hi
I have a some functionality on my website protected using .htaccess and .htpasswd.
When users attempt to access this, they get prompt to enter details. They enter their details and get in and can see stuff etc. All works fine.
My question is how do I create a logout functionality for this type of authentication. I know that they can close the browser window to "Logout". But this is not ideal. What would you suggest to me?
Thanks.
Tested on firefox and chrome. What you can do is send the user to http://logout:logout#example.com. This will replace their current username/password with logout/logout (it could be any invalid user/pass combination) and since they now have the wrong username/password, they will have to login again to access the site.
On opera this does not work, because you can have several usernames/passwords at the same time. It didn't work on IE either, because IE does not appear to support http://username:password#example.com URLs.
Browsers usually don't support this, see How do I log out?
Since browsers first started
implementing basic authentication,
website administrators have wanted to
know how to let the user log out.
Since the browser caches the username
and password with the authentication
realm, as described earlier in this
tutorial, this is not a function of
the server configuration, but is a
question of getting the browser to
forget the credential information, so
that the next time the resource is
requested, the username and password
must be supplied again. There are
numerous situations in which this is
desirable, such as when using a
browser in a public location, and not
wishing to leave the browser logged
in, so that the next person can get
into your bank account.
However, although this is perhaps the
most frequently asked question about
basic authentication, thus far none of
the major browser manufacturers have
seen this as being a desirable feature
to put into their products.
Consequently, the answer to this
question is, you can't. Sorry.
There are browser extensions that allow you to clear the HTTP authentication for a site.
For Firefox the WebDeveloper extension (which is one of my favourtie extensions anyway) offers this feature.
The menu for this is Miscellaneous/Clear Private Data/HTTP Authentication.
I ran into this issue several years ago. It is incredibly frustrating to discover there is a problem everyone is having and no one seems to want to solve in a general way.
As noted in Inadequate Logout functionality in HTTP Authentication I think the answer is to change the RFC to allow timeouts and support a log out button. The author's additional suggestion that the server be able to send a "log out" header would actually eliminate the need for any client user agent support since websites could simply include a link on a web page to a URL that returns the necessary response code and/or header to invalidate the current session.
It IS kind of possible to log out. You should implement logout page, which will return HTTP 401, until the user enter BAD login information, and then redirect somewhere else. Browser remembers the latest login information accepted, and therefore overrides correct login.
But this is kinda unusable, cos it needs user's cooperation.
Almost everything is in the title :
Here's what I'd like to do :
A nice html page with a php authentication process (http first then https & so on)
Launch a flex app which knows (I don't know how (this is the actual question !)) the user has already been authenticated and display his/her stuff he/she has to do for the day (or whatever...).
Of course if someone try to call directly the flex app I would display an "authentication error" message and then redirect to the authentication page.
I'm sorry for my English which is perfectible.
I was thinking about the session cookie : first authenticate then ass a variable on the server side, something like :
$_SESSION['authenticate']=true
Then, on the flex side, just send the cookie and ask if the user is properly authenticated, something like calling a php web page like :
https://is_authenticated.php?php_session=xxxx
Thank you
Olivier
What are you using on the server side? Remember that you shouldn't do anything in the flex application other then send the SESSION ID along with any requests. Any time where the client checks security, you have a bug. The server must validate the session and determine if the request is allowed.
It sounded in your last comment that you are worried about people manually calling a web page. Each page must check to see if the user is authenticated. I don't know your specific application, but you may try looking at AMFPHP and see how they do session authentication. Good luck!
Your on the right track!
You could use session-authentication, these links might help you out:
http://www.zend.com/zend/spotlight/sessionauth7may.php
http://www.tizag.com/phpT/phpsessions.php
There is also the possibility to use http-authentication
http://se2.php.net/features.http-auth
however http-authentication is not as flexible as session-authentication, and also means some more configuration on the serverside.I would therefore recommend you to stick with sessions.
This is exactly what I would do.. A few things to consider from a security standpoint:
If your php service (from flex) gets an unknown session token, always generate a new one. This also applies to your PHP application and is often overlooked.
I would generate the swf with javascript, and manually insert the session cookie using javascript. This way people won't download and safe (or cache) your php pages with sessions that are invalid in the future.
Even better would be to use a separate token other than the session, and on the server figure out what the session id was based on this flex token.
I was looking at the livehttpheaders plugin for Firefox and decided to test my login page. I noticed that the parameters shown inside of it contain my login and password. For example:
username=sarmenhb&password=thepassword&submit=Login
in plain English.
I don not see this on other sites.
What can I be doing wrong? I see this as a security flaw. The login page, all it does is validate and log in the user. All fields are ran through mysql_real_escape_string (in case that is relevant).
The information has to get to the server from the client some how. Use SSL if you are worried about security.
Even if you do an MD5 hash in Javascript, this does not help because it is trivial to submit the hash to the login page, and the hash effectively becomes the password. All things are plain text until they, or the transport, is encrypted. POST the variables, use SSL.
To add from my comment below. You may not see the headers for other-sites because they may use AJAX, POST method or another client-side mechanism to authenticate.
This reminds me of a certain building in a large city (I am sure there are others in other places) where they have a web based interface to the building concierge. Residents can log on to a web site (over http) and specify (among other things) who is allowed to enter their apartment for repairs etc in their absence. I am sure the whole thing was programmed by someone's nephew who is a 'guru'.
I am sure it is, shall we say, good enough.
You're seeing it for your site and not for others because livehttpheaders shows the URL for GET requests, but doesn't show the content for POST requests.
Sending login information through GET requests is a minor extra security hole over sending them POST, in that the URLs for GET requests are often logged in various places, whereas almost no one logs POST content. Does everyone with permission to look at the webserver logs have permission to know the CEO's password?
However, as others have pointed out, unless you're using https: for login, data is going across the network in plain text whether you use GET or POST. This is almost always bad.
Still, as an intermediate measure I would change your app to send username and password stuff as a POST, not a GET, so that you don't end up storing usernames and passwords in your webserver logs - it's no use using https over the wire if you're doing something that then writes the username and password to an insufficiently protected logfile on the server.
When you are using http and submit a form, the form contents are sent across the wire "in the clear", as you're seeing. When that form submission includes credentials, then yes, you have a security issue.
Among your alternatives are:
Use https, so that over-the-wire communication is encrypted
Use OpenID for login, which pushes management of https credentials off onto the user's OpenID provider
Use Javascript on the client side to encrypt the credentials before posting the form
The latter approach tends to get people into trouble if they're not very careful, because the mechanism for encrypting the credentials is fully visible to anyone who cares to inspect the javascript.
HTTP live header shows POST requests as well. Post sends the data the same way as GET does but the only difference being that the variables are passed in the url itself in GET but in POST they are appended to the HTTP header.
To get better security use encrypting in JS (only password or token+password). But that still can be hacked using rainbow tables for say MD5 or any other hashing technique.
SSL is the only way to achieve high security.