I'm working on an application that is loaded inside iframe within other web page. When user launches application I got request to my app like this one:
www.mypage.com/?user=1234
Then my app redirects user to
https://login.host.com/oauth2?response=code&client_id=my_app_id&scope=&
redirect_url=www.mypage.com/?index/loadApp
Given user id is used to check if there is already token in DB, if not - received code is used to receive new access token.
Question is following:
How do I prevent calls that aren't going from i-frame on www.host.com? Request "www.mypage.com/?user=1234" can be seen in firebug console, so, if someone manually enters this url in browser, he can launch app for random user. Whats more, if there will be found such token in DB, person will see this random user data!
I use request signing for all my requests. But I dont know what to do with this first request (www.mypage.com/?user=1234).
Whats is the best practice in such cases?
Thanks!
Your problem is, in essence, that your site isn't using any authentication for that first request! You need to come up with some scheme for the other web page to sign the request, and verify that signature before performing the redirect.
(Additionally, make sure that the URL that's being redirected to performs appropriate authentication as well...)
Related
I think it's important to say that I don't have any experience in the technologies nominated below, I have some idea what is going on, I've googled a lot, but still - more I google more dumb I feel. :)
Making an app in Ionic 2, users of this app can read/write data about themself in DB.
I am using Wordpress as backend, actually users will change values in the table that was created by some Wordpress plugin.
First problem - I have no experience at all.
Second one - I must understand which user is knocking to the server.
Because user can change only his own data in DB.
I've solved it by creating a script that checks GET request from app & that request has a param with user nickname, so I have turned this script to template and assignined it to the page. ( template was first thing that went to my mind, if you have better idea - please tell me how to do it better! ).
Well now I knew who it is, but I disliked that this so unsecure!
Its only GET request with user name in it and changes to bring into DB.
NOT GOOD.
I've thought that I should send not only nickname but also some kind of a password, so I can check if the user is actually genuine user, well, you know.
But knowing nothing about security, didn't know where to start so I've started googling.
I've find out that there is 'Basic Authentication' - disliked it because password is verry simple to decode (base64) and you must send it with every request (not safe).
Then I thought about crypting pass with strong algorithm like bcrypt & then send it with the request. Disliked it too - because at the end you are always send a password even if strongly crypted.
Now I've started to look in the direction of Auth 1.0
(because saw that wordpress has a plugin for it, I know little about wp however).
But after all I am not so sure that I am doing things in the right way.
I must finish many things, but I am stuck with this security issue and I don't know if it's my paranoia and there is simplier ways to accomplish what I want to do.
Don't have much time, don't want to waste time anymore.
Please, someone who is pro in this stuff give me an advise how to do this thing in the right way!
because I am going crazy with that stuff.
The best practice is to issue an access token from your server to your (or even third-party) client application by the following steps.
A user uses a client application.
The client application asks the user whether to use your service.
The user answers "yes".
The client application opens the authorization page of your service using a web browser. In other words, the client application makes an authorization request to your authorization server.
The authorization page explains to the user that the client application is requesting some permissions and asks the user whether to approve it or not.
The user inputs his/her ID and password into the login form in the authorization page and then presses the "approve" button.
Your authorization server authenticates the user and issues an access token to the client application.
The client application accesses a Web API of your service with the access token.
The Web API of your service checks whether the presented access token is valid or not.
If the access token is valid, the Web API returns a successful response to the client application.
RFC 6749 (The OAuth 2.0 Authorization Framework) defines 4 flows to issue an access token. Check the specification.
I want to register users to my webinars after they submit a form in my site, this is common practice but I'm having problems authenticating my application.
The problem is that according to the documentation Citrix doesn't support username-password authentication flow (where you put your user and pass in a request and you get a token):
https://developer.citrixonline.com/content/username-password-flow
Instead users need to be directed to a login page to complete their Citrix account credentials, supposedly this can be done by me just once and then save the token, however I couldn't find a method to do it safely, I tried once to save the token and just the next day it was expired. So how can I make sure I get a fresh access token without
I'm using this PHP library which is supposed to simplify the login process (maybe there is some clue in it):
https://github.com/jakir-hayder/Citrix-GoToWebinar-PHP-Library
First, read this primer on OAuth workflow to ensure you have the terms and concepts down pat. (You can ignore the fact that the example is for SalesForce -- OAuth is all the same.)
Then, you should understand that you're looking for the Citrix Token Request Endpoint, which they happen to call "Direct Login".
That should let you pass the username/password to get the token to use in subsequent requests. That what you need?
I would use Fiddler or Wireshark to collect the API calls that are made to the Citrix API when you log in. Then add some code in your applicaiton to send the same requests, parse the response that has the access token, and dynamically use that token however you've already got it set up in your application.
This is my first question here, so apologies if asking something trivial - though I didn't find an answer after an hour of digging.
I have a PHP website which needs to connect with a Facebook page in the following method:
On certain triggers, the site needs to post to the page's wall as the page itself. This has to be done automatically, even if no user session is available (e.g. if someone uses the site without actually having a Facebook account).
I found solutions using extended token expiration times (offline access), but in those cases, the post will always appear as the site admin (me, in this case). However, I need the post to be written by the page. When using Facebook as the page, I have no right to request an offline access token.
Is this even possible at the moment?
You need to cache the page access token on your server and use that to make the updates - the page login is pretty well documented here: https://developers.facebook.com/docs/authentication/pages/ -
Store the access_token in your server-side code and use that token to post as the page - the page access token won't expire if you have a long-expiry access token for the page admin, unless the user stops being an admin of the page, removes the app, etc.
I need to login with my account with php curl in a website that uses facebook connect to login.
I'll take as example site one of my favourite apps: Mousehunt
As you can see, it uses facebook (of course) to login: if you are already connected to facebook, it succeeds in automatic login, otherwise it popups facebook login.
How i can login into it with php curl? I know some about curl & cookie (cookiejar, cookiefile, post etc) but not too much.
Which is the target url to post data? How can i return to that site as user logged in?
Let me explain how this sort of FB login works. There is of course the alternate method used for desktop applications, which would make it possible, but this website doesn't use it.
So heres the deal:
The login button opens a link on facebook servers containing the api key of the website and some arbitrary information. So far so good. You could simulate that easily.
Then after accepting the privacy stuff you get redirected back to the website. You can simulate that as well.
But then comes the burden:
The location you get redirected to contains an facebook token after the hashtag (#).
The website can then read this token by Javascript and use it to query the facebook api to confirm your dientity.
The reason why this is done that way is easy:
Think about it. Everyone could fake a request in the name of the website and read your private data. But everything after the hashtag is never readable by the server the request is directed to. The web browser just does not pass it and it would be violating http standards and cause an error.
The only way to access it is by javascript. And this can only be by the website serving the request (where facebook redirects to). And the domain where facebook redirects to is locked by the application key owner.
You see javascript is an essential part of the security here.
I think it is very insecure indeed because there are many possible explits, but its very easy which is a reason why this form of login is spreading so much in comparision to e.g. openid.
So to sum it up: You need simulate a fully javascript enabled browser. It is partly possible but very complex and there are no out of the box solutions for that.
well, there might be a way.
looks like facebook request don't sign the permission scope in any way.
so this basically means you can grant the application/website more permission than they even asked for.
then you could grant the website permament permission - log in the usual way - and save the cookies.
then you can send those cookies along with curl.
if the website uses servers side login authentication, which is very likely, you will still be logged in, because the access token is permament.
however there is no guarantee for that hack to stay functional.
I have written a REST service that uses WSSE as an authentication method but i want to be able to use this rest service through a browser by creating a website around the service. I want the user to be able to log in on the website then when they view, for example the "view users" page an ajax request is made to test.com/users and back comes the list.
The part i'm trying to get my head around is the logging in/out on the website and keeping the user logged in across pages. Since in a true REST implementation there's no state held on the server, i can't use $_SESSION and now i don't know where to start!
What is the best way to go about this? Do i still need to store session information on the server then possibly use cURL to make the request?
Thanks
Jay
Why not use HTTP authentication? Once the client knows it needs to supply credentials, it will and for every request you will know who the user is from the request headers.
You can then tailor the response towards the particular user making the request.
Jan