I'm wondering if anyone knows a javascript library where I could remotely login to a site, then browse pages upon logging in.
This is very easy with php's curl but I'm wondering if there is a javascript equivalent where I can execute multiple remote url's under a single http session.
Basically what I'm looking to do is post a username/password to one of my sites and then immediately post some other commands to a different url (same remote domain) using the authenticated session.
I haven't come across anything like this yet so I'm wondering if anyone can point me in the direction (if it's even possible). Can definitely be HTML5.
Due to same origin policy restrictions in browsers this is not possible using javascript. You need a server side script that will act as a bridge between your site and the remote sites. Then talk to this local script using AJAX.
There are some techniques available to bypass the same origin policy:
If you don't need to read the response of your POST calls, you can create a FORM by javascript with an action to any url (not limited to the same origin policy) like in this question: How do I send a cross-domain POST request via JavaScript?
But this means you rely only on session cookies for the security, this is open for XSS attacks.
As you own the other domain site, you could develop a small service that returns a JSON with the data you need, and use the JSONP technique, eg:
<script src="http://otherdomain/curl?url=page.html&callback=cb">
</script>
May be you could signin before using the POST technique above and sending a secret token that you reuse in the url to improve the security.
And finally there is a way to act/read on other pages using a bookmarklet.The idea is to inject in the other domain's page a script that can run with all the privileges, and send back information to your domain.
But this requires a manual action (click a link or a browser bookmark)
Related
I'm trying to create a javascript plugin which needs the ability to send and receive data from another domain.
Conceptually, the plugin is simple:
The users installs a piece of javascript code
The code communicates with central server (on another domain), sends some info about the user's site (a form of query) and get's some info back
The server domain would be fully under my control , but as you can see, end-users should be able to use the plugin just by installing a piece of javascript code.
Is this possible and if yes, what would be the simplest form of implementation?
Thank you!
You basic problem will be circumventing the same origin policy of JavaScript (Wikipedia). Basically you have two options, if you want to use only JavaScript on the client side:
CORS (cross-origin resource sharing): Here you enable the sharing on your domain and the JavaScript on the user's side will be able to interact with any data as if it was on their own server, thus you have no problems with the same origin policy. You can do AJAX request in the same way as if interacting with your own server. For details on how to activate this on your server environment see here. Note however, that this is not supported by older browsers see caniuse.com for details.
JSONP: All requests use the JSONP syntax. Wikipedia on the topic
I need to provide a functionality similar to "Share with Facebook" for my social networking site. Facebook uses nested iframes and also xd_receiver concepts. I want to write a JavaScript API(JS file hosted on my domain), which can be used by different sites to call my web server APIs in order to share, post or recommend on my social networking site. I have a few questions -
Even though I provide the JS API, and diff sites load the JS file using the source, if any API call is made, it will again be a cross domain call(If I am comprehending correctly) and will be rejected on the server?
How to overcome such situation?
Is there any other better mechanism to implement this functionality?
Please suggest so that I can proceed with the implementation.
I think the default way is to use jsonp to get around cross domain limitation. http://en.wikipedia.org/wiki/JSONP. It might require a change in your api though. A user requests your api through the src of a script tag passing in a function callback. Your api would return pass your json response to the function specified.
Do you know why they use iframes and not simple get requests with JSONP/Images/scripts?
The answer is security. I cannot write a script that clicks their button which will automatically "like" the page.
Using plain old JavaScript with a JSONP will allow the developer to automatically click the button. Do you want that to happen?
The requests are made by the browser and not from the JS file, so, your requests will be cross-domain every time they did from another domain site.
Your server will only reject cross-domain requests if you implement a referrer validation.
And you can use JSONP if your API needs custom contents from your site...
To allow cross domain requests, you need to set the following Header in your HTTP Response:
Access-Control-Allow-Origin: *
The implementation will vary depending on the back-end you are using.
If the host in the Origin header of the request is anything but the host of the request, the response must include the listed Origin in the Access-Control-Allow-Origin header. Setting this header to * will allow all origins.
For very specific information on cross origin resource sharing see http://www.w3.org/TR/cors/. If you're not big on reading w3c documents, check out MDN's primer.
Note: Internet Explorer does its own thing with regards to cross domain requests. This answer is a good start if you have issues with IE.
Just wondering if it's possible to use an XMLHTTPReq to login to a website, and store the cookie. Specifically I'm after the PHPSessionID from the website I am logging into.
I then want to pass this cookie into another request to submit a form.
Any ideas of how to do this?
Cheers,
Nick
You will be able to get your own site's cookies from document.cookie. In the AJAX callback, use a library to parse the value and read the cookie you're looking for.
Of course, if the server sets the cookie HttpOnly (which it should be doing), it won't be available in document.cookie.
At this pont, you need to reevaluate what you're doing:
If the form points to your website, your server script would have access to the cookie anyway.
If you're sending the user's session ID to another domain, why? This is a huge red flag that screams security problem.
If you're logging in to another site, then no – the same-origin policy prevents you from accessing another site's cookies.
Edit: Since this is for your own use, you can do this in a way you're not limited by the browser's origin restrictions. Some thoughts:
You could make a Chrome extension. Extensions aren't subject to origin restrictions, and the development model and API is pretty much the same as what you'd do on a regular web page.
You could use Node, which has no restrictions. You'd be able to invoke your script from the command line, but the API is going to be slightly different that what you'd use in a web page.
Use your language and framework of choice to POST to the login page, get the Set-Cookie header in the response, and use it to send a Cookie header in another POST to the form target.
You can only send cross-origin requests using XHR if both the browser and server support CORS. Additionally, the third party site needs to allow your site to send such requests and to receive its responses. If it doesn’t, you aren’t allowed to send the request or receive its response respectively.
We have a "widget" that runs on 3rd party websites, that is, anyone who signs up with our service and embeds the JavaScript.
At the moment we use JSONP for all communication. We can securely sign people in and create accounts via the use of an iFrame and some magic with detecting load events on it. (Essentially, we wait until the iFrames source is pointing back to the clients domain before reading a success value out of the title of it).
Because we're running on JSONP, we can use the browsers HTTP cookies to detect if the user is logged in.
However, we're in the process of transitioning our system to run realtime and over web sockets. We will still have the same method for authentication but we won't necessarily be making other calls using JSONP. Instead those calls will occur over websockets (using the library Faye)
How can I secure this? The potential security holes is if someone copies the JavaScript off an existing site, alters it, then gets people to visit their site instead. I think this defeats my original idea of sending back a secure token on login as the malicious JavaScript would be able to read it then use it perform authenticated actions.
Am I better off keeping my secure actions running over regular JSONP and my updates over WebSockets?
Websocket connections receive cookies only during the opening handshake. The only site that can access your websocket connection is the one that opened it, so if you're opening your connection after authentication then I presume your security will be comparable to your current JSONP implementation.
That is not to say that your JSONP implementation is secure. I don't know that it isn't, but are you checking the referrers for your JSONP requests to ensure they're really coming from the same 3rd-party site that logged in? If not, you already have a security issue from other sites embedding your javascript.
In any case, the 3rd-party having an XSS vulnerability would also be a very big problem, but presumably you know that already.
Whether you are sent cookies during opening WebSocket handshake by browser (and if so, what cookies) is not specified by the WS spec. It's left up to browser vendors.
A WS connection can be opened to any site, not only the site originally serving the JS doing the connection. However, browsers MUST set the "Origin" HTTP header in the WS opening handshake to the one originally serving the JS. The server is then free to accept or deny the connection.
You could i.e. generate a random string in JS, store that client side, and let that plus the client IP take part in computing an auth token for WS ..
using JavaScript, it is much needed to get some pages from the web using without actually moving from the current page and hidden from the user's eyes.
To request a web page without showing it to the user, it is easy to use XMLHttpRequest but it has its own limitations most importantly it does not retrieve cross-domain pages very well. For security reasons the browsers (Mozilla FireFox 3.6+ in my case) retrieve a header from the target site and if the referrer's location is allowed access in that header, only then will the browser continue getting the target web page and JavaScript can only then parse the retrieved info.
This causes the XMLHttpRequest to work with some pages and not work with others if you are trying to access cross-domain pages. Of course it works well if you need to retrieve the information from the same location as the referrer page where the XMLHttpRequest is located.
This is a big problem, when security is not really no 1 priority. For example, imagine writing a script for retrieving live data from a statistics-producing web site or imagine a bot that needs to retrieve data from an online gaming web-site.
Now, how can JavaScript be used to get pages from other domains (cross-domain reference)?
I thought maybe we could find a plug-in that does the job (of course after installation upon user's permission) and then use its properties by JS and eliminate the need for XMLHttpRequest. Do you know any such plug-in or another roundabout for this problem? (ie get cross-domain data by JS without XMLHttpRequest) of course we cannot use XMLHttpRequest as we don't have any control over the target page headers and we obviously want to hide the whole process from the user
You’ll find that it’s the priority that the target site puts on their own security that is most important. If they're unconcerned about JavaScript on other sites accessing their site, they can set the HTTP Access Control headers for cross-domain XMLHTTPRequest, provide a crossdomain.xml file for Flash, provide a JSONP API, or provide some hooks for iframe monitoring.
The second solution is to make the requests to a server on your domain which proxies the request to the target site. In certain circumstances you may be able to use a third party server which supports cross-domain or JSONP requests, like Yahoo! Pipes.
If neither of these is feasible, you'll need to convince the user to allow you to run your own code on their PC. This could be via a signed Java applet which requests special permissions, or your own custom browser plugins or extensions.
There are several ways including using JSONP with XMLHttpRequest, using Flash and using iframes.
Here is some information on this subject. http://snook.ca/archives/javascript/cross_domain_aj