I have got a 3rd party website, which my customer wants to me to login into in order to download some data periodicaly.
The data is customer specific, and password protected.
I have the username/password, and I have searched for ways to do the login automatically so that I can pull data, but so far with no success.
This is a method that I have tried:
http://crunchify.com/automatic-html-login-using-post-method-autologin-a-website-on-double-click/
When I look into the login page of the website which I am trying to login to (view source), I don't see the login form, but if I click on "inspect element" in chrome on the fields of the page it does show that there is a login form hiding in there.
Any suggestions
Edit:
Here is the website which I need to autologin to: http://portal.dorad.co.il/#/Login unfortunatlly it's not in english. The first field is the username, the second field is the password and the button is the login
Edit2:
Taking pomeh's advice, I was able to find the jQuery code that is being triggerted when the text boxes are being modified. Now I want to run this script manually using element.DomContainer.Eval
(function(n,t){function vi(n){var t=n.length,r=i.type(n);return i.isWindow(n)?!1:1===n.nodeType&&t?!0:"array"===r||"function"!==r&&(0===t||"number"==typeof t&&t>0&&t-1 in n)}function ne(n){var t=li[n]={};return i.each(n.match(s)||[],function(n,i){t[i]=!0}),t}function uu(n,r,u,f){if(i.acceptData(n)){var s,h,c=i.expando,a="string"==typeof r,l=n.nodeType,o=l?i.cache:n,e=l?n[c]:n[c]&&c;if(e&&o[e]&&(f||o[e].data)||!a||u!==t)return e||(l?n[c]=e=tt.pop()||i.guid++:e=c),o[e]||(o[e]={},l||(o[e].toJSON=i.noop)),("object"==typeof r||"function"==typeof r)&&
...
(t=n(this);r=r.not(t),t.removeData(f),r.length||clearTimeout(c)},add:function(t){function s(t,u,e){var s=n(this),o=n.data(this,f);o.w=u!==i?u:s.width(),o.h=e!==i?e:s.height(),r.apply(this,arguments)}if(!u[o]&&this[e])return!1;var r;if(n.isFunction(t))return r=t,s;r=t.handler,t.handler=s}}}(jQuery,this)
I am not sure how to activate it and give it the relevant data.
If you have the right mix of technical requirements then you want Single-Site-Sign-On (SSSO).
Not all of my clients have SSL and I don't want my user name and password on all of their sites. They are however all on the same server. Since my site supports SSL I can log in to my own site securely.
What you need to do conceptually speaking is log the IP of the administrator account along with the data/time stamp. Then if you visit your client's website (again, on the same server) from that same IP you can have your scripting language check the file. I require a short time-span (anywhere between 30 seconds to two minutes tops) and the same IP address. You can add additional technical requirements to strengthen security of course though your options will be limited as the domain name will be different. If the IP matches the criteria emulate the user being authenticated (static obviously since you likely won't/shouldn't have your administrative account information on their site) and you can be automatically signed in.
Maybe you could do this using a web scraping framework like:
Goutte for PHP (https://github.com/fabpot/goutte)
Scrapy for Python (http://scrapy.org/)
node.io for Node.js (https://github.com/chriso/node.io)
request for Node.js (https://github.com/mikeal/request)
WatiN for .Net (http://watin.org/)
In any case, I think a client side solutions will bring a lot of problems to do this. Maybe you can login into it using a form tag which points to the page, but you won't be able to manipulate the page afterwards. Also, you may not be able to use AJAX due to CORS restriction. You could embed the target page as an iframe but you can't either manipulate the page because of differents domains used (you can do that under certains conditions but it's hard to achieve this imho). So a server side solutions sounds better to me.
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.
I'm writing a new JavaScript based Web app, which I need to secure in the following specific manner:
I should only allow for my app's index.html to be served if the request for it comes from a specific site.
By doing that, I will be forcing my users to go to that specific corporate site first, which will require for them to authenticate. Once the user is logged onto that site, they are provided with a link to my app. If my app's index.html is requested in any other way, beside following that corporate link, I would like to redirect the user to that corporate site.
How can this be accomplished?
You can use document.referrer to get the referral page. Once you get that from your corporate site you can probably put in some logic to redirect to the corporate site if it doesn't match where you're expecting.
Something tells me this isn't the best way to handle user authentication, but I'm new to that aspect.
Note: I'm on my phone, so excuse lack of code tags for that tiny bit up there.
Set a variable to the document.referrer().Then check the condition properly to determine if the referrer is in the proper page and if its not do a redirect..
I have a web application which is used by lots of non-technical users. I have found that several of these users are saving the login page of the application to their desktops (which also saves the associated CSS and JS files). Then, to start using the application, they double click on that desktop icon which shows the local copy using the file:// protocol.
This can cause problems later on, e.g. if I change the login form, or the URL it posts to, etc. Also, certain javascript utilities, e.g. PIE.htc don't work using the file:// protocol.
Obviously what they should be doing is saving a browser bookmark/favorite, I'm looking for a way of detecting and warning those users without confusing the rest. I have been using some javascript to warn these users:
if (top.location.protocol == 'file:') {
alert('This application is not designed to be accessed from a desktop copy...')
}
But this will only warn users that have saved the desktop copy since I have added this piece of javascript.
Has anyone else had this problem and come up with clever solutions that they'd like to share?
Thanks
Update:
In the end I decided to do this by setting a cookie with a nonce value upon login page request, and storing the same value as a hidden field in the form. Then, in the form submit handler, check that the two are the same and show an error message if not. One could store the nonce in a session instead of a cookie, but I don't want to create unnecessary sessions.
If the user has saved the login page locally, they will likely have different nonce values in the saved form compared to the cookie (if they have a cookie at all).
Normally one wouldn't add CSRF protection (that's sort of what this is) to a login form, but it fulfills my requirements. I read about this technique on The Register, http://www.theregister.co.uk/2009/10/02/google_web_attack_protection/, Google implemented similar protection for their login forms, to protect against forging of login requests, http://en.wikipedia.org/wiki/Cross-site_request_forgery#Forging_login_requests.
I think your best bet is going to be educating the users to use bookmarks instead of saving physical files.
Other than that, there's probably a way to create a shortcut to your URL instead, perhaps during logon?
Maybe cookies? If site is running with file:\\ there probably are not any cookies within request. (Of course, now you should add some cookie (session data) on your login page.
Also, read about CSRF http://en.wikipedia.org/wiki/Cross-site_request_forgery and preventing method.
You could probably check the http referrer on the server side and warn users not coming from your hosted login form.
Edit:
Actually, a vaguely similar question has been asked before and got a good explanation why referrer is not an ideal solution and also provides an alternative solution: How to check if a request if coming from the same server or different server?
Why, don't you, instead of the alert, put a redirect to your page?
window.location = 'http://www.yourdomain.com'
Or you can also force a reload with window.location.reload();
Instead of message you may redirect your user to the real page which has login form, or show the help box that will explain that user should save page in such way.
You could set a session variable that is set as a hidden variable in the form. If that is not there, you redirect to your login form.
I have to make changes to classic asp website where once a button is clicked it autologins to a third party website with a intermediate page that warns that you are logging in to a third party website.
The thirdparty is providing us with a username and password and gave us an examle javascript to encode the password to send to them. Now where do I store the userid and password. I cannot execute the javascript on the serverside. It has to go to the client. If the asp page which has the encryption javascript goes to the client side then the source can be viewed and the username and password is given out.
Is there a way that I can have hidden asp page whose only job is to encrypt the password and create a new url and auto redirect it to that new url.
So when the user clicks ok on the intermediate warning page I redirect it to this hidden asp page which does the encryption and a creates a url for get method and redirects to that page.
I am a novice as far as java script and classic asp is concerned. Any ideas/ advice will be appreciated.
Thanks,
--Abbi
As SLaks said, it really doesn't matter what you do, if the client browser MUST send the user/pass to the final website, then you cannot prevent that client browser from being able to see that user/pass. It MUST see it, in order to provide it to the other website.
What you might want to consider is creating a page that is loaded server side and presented to the client browser from your website. Think iframe (but not an iframe, that's still client side); where your server requests the page from the destination server, and then presents that page back to the browser. This could get very complex depending on the kinds of interactions that happen on that page; you would basically need to proxy all GET's and POST's between your server and the destination site. But this would eliminate the need for giving the browser the username and password.
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?