I want to let users create "apps" (like Facebook apps) for my website, and I'm trying to figure out the best way to make it secure.
I have a REST api
i want to run the user apps in an iframe on my own site (not a safe markup language like FBML)
I was first looking at oAuth but this seems overkill for my solution. The "apps" don't need to be run on external sites or in desktop apps or anything. The user would stay on my site at all times but see the user submitted "app" through the iframe.
So when I call the app the first time through the iframe, I can pass it some variables so it knows which logged in user is using it on my site. It can then use this user session in it's own API calls to customize the display.
If the call is passed in the clear, I don't want someone to be able to intercept the session and impersonate the user.
Does anyone know a good way to do this or good write up on it? Thanks!
For modern browsers, use the cross-window messaging interface provided by HTML 5
https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage
For older browsers, emulate the above messaging interface by creating a third IFrame on the same domain as your application, below the second external IFrame. You can then have bidirectional messaging from the 2nd to the 3rd and from the 1st to the 2nd by modifying the fragment part of the URL. The 3rd and 1st IFrames can communicate bidirectionally in javascript, because you're hosting them on the same domain.
You should be able to wrap both of the above methods into a single script, and maybe source one of these messaging layers to save you some time:
http ://json-rpc.org/wiki/implementations
If you have a REST API, you have no need for an iframe, in fact, iframes are considered very poor practice in modern web applications. An iframe would be useful if you have content on an external site that is not easily manipulated with javascript on the client side, or with your application on the server side. This content is usually in the format of an HTML document.
You've already stated that you have a REST API, so you can likely manipulate the data returned by a resource in any way you see fit. For instance, if the resource responds to JSON or XML requests, you could format and organize that data via Javascript from the client (web browser) or you could use your web framework to gather the data from the REST API and manipulate/organize it, making the result available to your application.
In order to secure the data as it is transferred back and forth between the client and the server, you could provide an API Token (lots of sites do this, e.g. Github, Lighthouse, etc.) for each user from the service provider and require users in your application to provide their API Token. The token could be passed in the HTTP headers to the REST service provider separating the token from the request and response data. HTTPS (SSL) is a must for this type of traffic to prevent eavesdropping.
Let me know if this is too general, I could give you a few specific examples.
Related
i'm new to asp.net web api, owin, and everything related to it.
I'm trying to find the best way to do this scenario:
1 - Web api to have all the connections and rest service
2 - Web site to show data to user on a browser using the restful service
3 - An mobile app that have some functionalities like the web site and access the restful service to get all the information
My doubt is: what's the best practice related to the login? I'll use owin/oath2 with Identity to login, but since it's going to be implemented on the web api, the login/register/forgot password should be on the web api directly (like the project template does) or should i move most of the functionality to the web site? Of course its easier to leave in the web api, but if i do it, i must duplicate my razor templates just to call the login part. Can someone give me a path to follow?
Thanks!
the answer is not, your web api should not have any html or js or css file, only the services that your need, the web api exposes the functions to register the user, next when you have to do request, you must Send a token, you can obtain the token using the URL that you have configure in owin, the URL is like /token and Send the username and pass.
Regards,
or must it be on the same server as the app calling it? I am new to web api so i am going through some tutorials, but they all assume the web api is part of the mvc app. Also, they show the calls to the api being done with javascript, but I want to make the calls in my MVC app controller. Is this possible?
You can host a Web API anywhere.
The only special thing to have into account when the Web API isn't in the same server that a web site that uses it, is that, by default, the Web API doesn't accept requests from a different domain. For example, if the web site is in "server1.com" and the Web API in "server2.com", then the calls to the Web API from the web server will be rejected.
If this is the case, you need to configure the Web API server to enable CORS (cross origin resource sharing), so that it accepts requests from a different domain. If you want more info about this, please look at this document:
Enabling Cross-Origin Requests in ASP.NET Web API 2
The Web Api can live wherever you want it to. Is typical to see a limited API used mostly to handle AJAX for the MVC application live with the MVC application, mostly because it makes it simpler to construct URLs to the endpoints. If you host the Web Api externally, then you'll have to hardcode the API endpoint URLs, as there's no way to use something like Url.Action to generate them automatically, any more. Regardless, it's a perfectly acceptable way to handle things.
You will probably at least want to add the base URL for the Web Api as an app setting in your Web.config, though. That way, you don't end up with hardcoded references to a particular domain strewn all about your app. That makes moving your Web Api to a different domain much easier, especially when talking about going from development to production.
It is also entirely possible to use a Web Api within your actual controller actions. You'll just need to use something like HttpClient to connect to it and issue requests.
So I am currently evaluating Dart's use as a potential language to re-write a campus organization's website. One critical aspect of this website is it's access control policies. It seems that anything written within the Dart web apps could potentially be compromised, and thus led me to asking the following question.
Is it possible to securely implement access-control to pages in Dart, using either just a web app or a combination of a web app and a dart-implemented server? Could it also be possible to implement that same concept using Apache with a proxy-passthrough to dart?
I don't understand what you actually want to achieve with a proxy-passthrough.
When you create a single page app in Dart all client code is loaded to the client. This is normally no security concern. When a view is shown it usually loads data from a server. Here you enforce security.
You can require the user to authenticate and decide in the server code if or which data you serve for this user or what update command you allow the user to execute. You can just return an error when the user invokes a function that he is not allowed to use.
I have two servers - web and app. The web server (IIS) serves only static files - HTML/CSS/JS. On executing the JS, the client gets the data from the app server (HTTP service using Web API, self hosted with OWIN). I need to bring in authentication so that my data as well as the content is restricted.
I can use SSL, I can pass username / password to the web api, have it authenticated and get back a token. I can pass this token for future web api requests. In my client app javascript (done using AngularJS), I can also maintain info whether the user is authenticated, what roles she has etc. (for user experience). But for security, I need to be able to ensure the html content requested (in the web server) is also having authentication and authorization done. How can I achieve this?
Should I change my app to make the web server call the app server internally rather than from the client? I can use MVC controllers or ASP.NET, but since I was using AngularJS, I thought it is not required, and is kind of a duplicate. Should I ditch pure .html files and move to .cshtml?
How is this done in the Angular + .NET world, when you data comes from a different server than your htmls?
We've been using JSONP with REST type api to do cross domain AJAX calls, but our Angular client code is within .cshtml files in a .NET project. Sounds like the simplest solution is to use the app server internally- I would go with that
I'm currently building a mobile application (iOS at first), which needs a backend web service to communicate with.
Since this service will be exposing data that I only want to be accessed by my mobile clients, I would like to restrict the access to the service.
However I'm in a bit of a doubt as to how this should be implemented. Since my app doesn't require authentication, I can't just authenticate against the service with these credentials. Somehow I need to be able to identify if the request is coming from a trusted client (i.e. my app), and this of course leads to the thought that one could just use certificates. But couldn't this certificate just be extracted from the app and hence misused?
Currently my app is based on iOS, but later on android and WP will come as well.
The web service I'm expecting to develop in nodejs, though this is not a final decision - it will however be a RESTful service.
Any advice on best practice is appreciated!
Simple answer: You cannot prevent just anybody from acecssing your web site from a non-mobile client. You can, however, make it harder.
Easy:
Send a nonstandard HTTP header
Set some unique query parameter
Send an interesting (or subtly non-interesting) User Agent string
(you can probably think of a few more)
Difficult:
Implement a challenge/response protocol to identify your client
(Ab)use HTTP as a transport for your own encrypted content
(you can probably think of a few more)
Of course anybody could extract the data, decompile your code, replay your HTTP requests, and whatnot. But at some point, being able to access a free Web application wouldn't be worth the effort that'd be required to reverse-engineer your app.
There's a more basic question here, however. What would be the harm of accessing your site with some other client? You haven't said; and without that information it's basically impossible to recommend an appropriate solution.