CONTEXT
I am building a web app which analyzes information on a user's site. I plan to do this by asking the user to add a JS snippet to their <head> which creates cookies that collect information about each visitor to that site.
PROBLEM
I would like to then send information that is held in this cookie back to my web app. I realize normally cookies cannot be accessed by anything other than code on the same domain, so I'm hoping that the JS snippet will read the content of that cookie and pass it back to my app - is this possible? What would be the best way to do it?
This is the basic pattern that's used by google analytics and most other website analysis tools as well as advertising modules. Your snippet, running on your user's site, can read/write cookies there. It can also make ajax calls to your own web service to communicate any data it gathers, including cookie contents. Your "app" doesn't run on your user's site, only the snippet (and any code it drags into the site).
Related
I am building a website in which I have included third part weather html widget, the widget looks from reliable source and is trusted over web. This widget is in the form of link and a small javascript tags which are then rendered once loaded.
I wanted to know how safe will my site data will be once I load this or other widgets, will they be able to sniff my site data including cookies, html,css etc.
When you use 3rd party JavaScript on your site, you have to trust them. You are, in effect giving them permissions to run whatever code they want in your site. That code could:
Read cookies that are not set as HTTP only
Access all the data on the page
Call JavaScript APIs from your server that would not normally be accessible to 3rd parties
Change anything on they page
Send any data they find back to the 3rd party (or any other party)
These ability could potentially be abused for any number of nefarious purposes such as stealing your data, redirecting your users, or tracking your users.
Here is a related article that goes into more detail: Jeremiah Grossman: Third-Party Web Widget Security FAQ
Cookies you can't copy because they work only for domain if u change domain the browser begin new cookies .
Html and js it is very easy to copy the is few option to do this:
httrack
use view source
and more option...
I have to display a third party site, say site X, upon successful authentication from my existing APIs, as it is, on my web site. But due to certain reasons, I cannot afford to use an iframe, which is the most obvious solution in this case, as that will expose the site X's URL when inspected in browser. So, I landed up on another idea to create a web app whose front end is written in AngularJS and use existing back end APIs written in C#. The application will basically have two pages, login and main page. Upon successful authentication from API on login page, user is navigated to main page. Now main page, I have to show another site. So, instead of using iframe on main page having source as site X, I will display an iframe with source Url as one of my API endpoint, say baseURL/data. So, this API will basically fetch the site X data and do something like server side rendering and return me an exact replica of site X which I will load in my webapp. When user will navigate on site X and route to any path, that route will be sent to same API and now the response will be replica of baseURL/data/route. Even though my API endpoint is now exposed instead of site X url in browser console, I am okay with this because that API is protected somehow and cannot be accessed as it is without proper authentication which I am doing in my case on login page.
I want to get more thoughts on this entire scenario and possible alternatives. Also, if anyone can suggest if/how it is possible to write such an API. I can think about changing AngularJS or C# as technologies in my project but definitely that's not the most go-to-solution for me. Any suggestions and thoughts are welcome!
Edit: I have created a site using a static site generator. I want my users to be able to access that site only if they are 'my users' i.e. authenticated by my APIs. But, that generator is not allowing me to integrate my API and neither I can get the static assets like .html, .css and .js files that I can host on my own server and integrate my authentication API. Hence, I had to think about a workaround like this.
First, about me: My language is objective-c, c++. I have built websites in the past, but have never created any true web applications or have ever gone into the trenches with javascript.
What I am trying to do: is create a web server for the purpose of testing iPhone applications. The server will:
Host a page
In which visitors can login with facebook
Upon facebook OAuth
Server will query facebook for visitor metadata (email and full name)
And store metadata (in some format, I don't know)
The server will also host an API (my iOS-app can talk to)
Which accepts iOS-app queries
And return stored metadata via JSON.
So my question is: How does this all work within an html document?
e.g. I can only query facebook after I know the visitor has logged in, to facebook. How do I (dynamically) let the html document know, "hey the visitor has verified with facebook OAuth, now call this inline javascript function"?
Any information you can point me to that tells me how javascript functions are called/interacts in an dynamic web environment would be greatly appreciated.
Thanks SO
Look into G-WAN. It's a powerful web application server which uses C, C++ and Objective-C scripts natively. It's probably the best web server out there, and you'll be on familiar ground.
As far as your question goes, you'll call these in your script tags. They can be anywhere, but with JavaScript, if it's in the head, you're going to want to wait until the DOM is fully loaded, otherwise you won't have access to nodes which haven't yet been rendered. That means if you're trying to access a DIV that hasn't been rendered, you'll get an error.
I'm working on a web application where users will create accounts. Then clients will be about to have a section on their site for users to login with my sites login credentials. However... I don't want the clients site to be able to see or handle their login credentials. I am wanting to do cross domain authentication just like facebook connect does.
I have done research and it looks like I will need to create a javascript library that users will need to add into their site. Inside that javascript file I will need to create an iframe that will connect to my main site. From there a cookie will need to be placed then checked.
Does anyone know of well written tutorials on how to do this or could you explain in detail on what all will need to be done?
EDIT:
How would the storing and reading of cookies work. Anyone have examples?
The simplest way would be a plain iframe. Twitter does it a lot. If your have to communicate with the parent site for some reason, try building an API with the postMessage function.
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?