I want to have a form on our main member page that they can submit on, and then I want to pass the username and password to the service which will be embedded in an iframe on our site to allow a seamless login.
Sorry, this won't work with the browser's security model for iframes. Methods for getting around this (i.e. pushing data into the name of a window) exist, but would be terrible for passing secret information like a password.
A real solution here will require something like the embedded site authenticating the user independently. OpenID could help you, here.
Passing secret information this way is really dangerous, do consider other options as this one will harm your users a lot.
Related
I have a web site with following functionality: An user comes to www.mysite.com/page.php. Javascript on that page makes ajax API call to www.mysite.com/api.php and shows results on the same page www.mysite.com/page.php
I'm afraid of situation where somebody starts to use my api.php on own software, because using www.mysite.com/api.php costs me a bit money. Therefore I want that only users that have visited the page www.mysite.com/page.php can get valid results from www.mysite.com/api.php . There won't be any way for users to log in to my web site.
What would be the right way to do this? I guess I could start a session when an user comes to page.php and then somehow maybe first check on api.php that a session with valid session id exists?
If you just want the user to visit page.php before using api.php, the session is the way to go.
Typically, if you want a "soft" protection you use the POST verb to get results from your site. Then, if the user goes the the URL in their browser and just types the api.php call they will not get a result. This doesn't protect your site but it keeps search engines away from that url reasonably well and accidental browsing to it.
Otherwise, there are lots of authentication plugins for php.
http://www.homeandlearn.co.uk/php/php14p1.html for example.
You can check the request in several ways such as Token validation, Session validation or even by Server 'HTTP_REFERER' variable
Check the referrer with $_SERVER['HTTP_REFERER'] if its outside the domain block it.
Beware that people can alter their REFERER so its not secure.
Another better solution might be a CAPTCHA like this one from google https://www.google.com/recaptcha/intro/index.html
Cookies, HTTP-Referer, additional POST-Data or some form data, that you send in an hidden input field aren't secure enough to be sure, that the user comes from your site.
Everything of it can be easily changed by user, by modifying the http-headerdata (or if you use cookies, by changing the cookie-file on the client machine).
I would prefer the PHP-Session combined with an good protection against bots (ex. a Honeypot), because it's not so easy to hi-jack, if you use them properly.
Please note: If there is a bot especially for your site, you lost anyway. So there isn't a 100% protection.
How safe is it? I'm assuming it's not to safe and additionally i'm assuming it's possible but not safe at the same time.
Right now i have a master login that displays data for all users; specifically all the users that are top 10 users. I want to be able to display to everyone on the homepage (login not necessary) the data of these wigits.
Right now I'm using a simple iframe:
<iframe src="https://newuser_news.dhtml?usepage=info-leaders.html" style="width:100%; height: 900px;"></iframe>
But of course, i'm the only one that can view the data, anyone else that i send the link to it boots them back to the homepage that requests a login.
Mind you i'm working a system that i do not have full access to, i do not have access to the classes or methods or the DB. I do have the master username and password access.
I'm super stuck on this... Any help would be greatly appreciated.
The easiest way would be to get some access to the database to make your own modified widget that does not require any login. Maybe the system has an API available that would get you the information you need (or they could make it available).
If you cannot get any access to the database and the system cannot be modified to make that widget login-free, you could write your own widget in php that uses cURL to get the original widget using the username and password and present that. You would have to store the username and password on your server for that, so I would not recommend that solution.
I’m trying some little ideas, and I’ve hit a snag.
At the moment, when a user logs in, their password is stored in a variable which is handled later. Obviously all one has to do to get hold of the password is to go into the developer tools or console or whatever and add a statement like alert(pass.value);.
I know this is unrealistic but its been bugging me. Is there any way of detecting an alert statement and scrambling the password somehow? A regex or string replace?
Thanks!
If you want to have a secure system, don't store the password on the client side. There is absolutely nothing you can do in JavaScript that will prevent somebody from accessing the password if it is stored in a JavaScript variable.
All of your authentication should be handled on the server side. If you are storing passwords somewhere, do not store them in plain text, and do not use a home-brew encryption method. Cryptology is full of minefields and it's very easy to get something wrong, and I would recommend using a well thought-out system like bcrypt.
I would advise against keeping any kind of credential information client-side. One viable solution that's easy to implement is is a security token password. A simple process would look like this:
User access website. Informs credentials.
Website validates credentials. Creates temporary token associated with user ID, stores it client-side.
User access website. Informs token.
Token is validated against storage, user identified.
Hey am just curious to know if this can be done! I want to make a page that takes user name and password, and on submit, transfers the exact data right into the login form of a website(eg google, yahoo, facebook etc etc) and submits it right away. Please tell me how this can be achieved!
Thanx in advance!
Without installing plugins to enter the data and submit, no. You can't execute your script on a site from someone else. That would be too risky security wise.
Create private encryption method encrypt username and password save that as cookies and than to access your cookies and than decrypt those cookies again.
in short make use of cookies and if you neeed security care private encryption/decryption method.
Cookies are probably going to be your best bet. It might be difficult to port them from one page to another except these are webpages you have designed yourself and have declared variables to auto-fill the text-boxes.
Another approach will be to modify the code of these pages (if you have access to them) and use PHP and Ajax to connect to a database e.g a MySQL database (could be a database like Xampp running just on your local machine) and auto-fill the text-boxes.
Check this guide, it is a little similar to what i think you are trying to achieve
http://www.w3schools.com/php/php_ajax_database.asp
According to the Facebook API documentation, most of the work is handled through javascript.
That means that all the processing is done, and then the front end checks if the user is connected to Facebook/authorized. right?
My question is:
Suppose a user goes to my site for the first time ever.
He clicks on "facebook connect". The javascript verifies him as authentic, and it "redirects" to another page on my server. From then on, how do I know that the user is actually authenticated to my website, since everything is done on frontend?
I think this is correct, but aren't there some security issues..:
-After user clicks Login, Facebook redirects to a page on my site. AND they also create a cookie with a specific "Facebook ID" that is retrieved only from this user. My backened will "read" the cookie and grab that ID...and then associate it to my userID.
If that is correct...then it doesn't make sense. What if people steal other people's "facebook ID" and then forge the cookie? And then my backend sees the cookie and thinks it's the real user...?
Am I confused? If I am confused, please help me re-organize and tell me how it's like.
Facebook Connect uses a clever (or insane, depending on your point of view) hack to achieve cross-site communication between your site and Facebook's authentication system from within the browser.
The way it works is as follows:
Your site includes a very simple static HTML file, known as the cross-domain communications channel. This file is called xd_receiver.htm in the FB docs, but it can be named anything you like.
Your site's login page includes a reference to the Javascript library hosted on Facebook's server.
When a user logs in via the "Connect" button, it calls a function in Facebook's JS API which pops up a login dialog. This login box has an invisible iframe in which the cross-domain communications file is loaded.
The user fills out the form and submits it, posting the form to Facebook.
Facebook checks the login. If it's successful, it communicates this to your site. Here's where that cross-domain stuff comes in:
Because of cross-domain security policies, Facebook's login window can not inspect the DOM tree for documents hosted on your server. But the login window can update the src element of any iframe within it, and this is used to communicate with the cross-domain communications file hosted on your page.
When the cross-domain communications file receives a communication indicating that the login was successful, it uses Javascript to set some cookies containing the user's ID and session. Since this file lives on your server, those cookies have your domain and your backend can receive them.
Any further communication in Facebook's direction can be accomplished by inserting another nested iframe in the other iframe -- this second-level iframe lives on Facebook's server instead of yours.
The cookies are secure (in theory) because the data is signed with the secret key that Facebook generated for you when you signed up for the developer program. The JS library uses your public key (the "API key") to validate the cookies.
Theoretically, Facebook's Javascript library handles this all automatically once you've set everything up. In practice, I've found it doesn't always work exactly smoothly.
For a more detailed explanation of the mechanics of cross-domain communication using iframes, see this article from MSDN.
Please someone correct me if I'm wrong - as I am also trying to figure all this stuff out myself. My understanding with the security of the cookies is that there is also a cookie which is a special signature cookie. This cookie is created by combining the data of the other cookies, adding your application secret that only you and FB know, and the result MD5-Hashed. You can then test this hash server-side, which could not easily be duplicated by a hacker, to make sure the data can be trusted as coming from FB.
A more charming explaination can be found here - scroll about halfway down the page.
Same issues here, and I think Scott is closer to the solution.
Also Im using "http://developers.facebook.com/docs/?u=facebook.jslib-alpha.FB.init" there open source js framework. So things are a little different.
For me, via the opensource js framework, facebook provides and sets a session on my site with a signature. So what I am thinking is to recreate that signature on my side. - if they both match then the user is who he says he is.
So basically if a user wanted to save something to my database, grab the session signature set up by facebook and recreate that signature with php and validate it against the one facebook gave me?
if($_SESSION['facebookSignature'] == reGeneratedSignature){
// save to database
}else{
// go away I don't trust you
}
But how do you regenerate that signature? preferably without making more calls to Facebook?