I'm working on an implementation of the Facebook api and I'm to the point that i can fetch a users pages and would now like to display these to the user so they can select where to send the post. These page objects have an access token on them to verify requests with Facebook and intuition tells me you wouldn't want to send these through to the ui then back again. I could just make 2 calls when sending and receiving, filter the results to remove the access tokens, then when receiving a request make another call to the api and filter the page results by id.
I'm curious though if theres a way to get around making 2 api requests and reduce overall requests to the api and keep the usage down.
You could just store the page tokens in the session, when you get the list of pages - then you don’t need to make a second API request after the user made their choice.
(Session data is tied to a specific client, and never leaves the server. Only thge session ID is passed between client and server.)
Related
I am designing api for mobile application.
I am not sure should I have one endpoint login which will return tokens & user profile
Or have two endpoints and after login call getProfile endpoint.
I saw that people mostly use second option but I don't see benefit of that approach?
Thinking in terms of the single-responsibility principle (which basically says "API methods should do one thing really well"), I'd suggest separating these into two separate things:
POST /login would set up a session and return the session ID to be used in subsequent requests.
GET /profile would return profile information provided a valid session ID is provided.
There are obvious benefits along the "happy path" for combining these, mainly the fact that after a login operation completes, you automatically provide the user with the data they most obviously would want next (who the user is). Why waste an extra API call to find it out, right?
If that's all your API will ever need to support, then there's no reason to separate these. But there are a couple cases I can think of for why you might want them separate:
What if an existing and already logged-in user wants to fetch the latest profile information? This means you must support GET /profile anyway (or have them POST /login again which is wasteful).
What if profile information is already cached and the POST /login API call is only happening to re-authenticate the user inside the app to complete an action? You'd be wasting bandwidth by sending data that's not needed.
Additionally, testing is usually a bit easier when you have each API method doing the one thing they imply they do (POST /login logs the user in, GET /profile fetches the current logged-in user's profile).
So if I use the node he client how is auth information being passed around ?
In the photo frame example it checks form data using the express body parser for a user and is authenticated function call.
But then it also calls api functions and makes requests outside the browser.
Just curious what the process is storing and where and how it’s being passed around.
Obviously the application tells Google what it is with some use of the client ids but is there a token the application has access to as well once OAuth is finished identifying the specific user account and where is that ? And how does the connecting browser keep this between server calls ? The response headers seem empty of anything of that nature. Thanks in advance.
I have developed an app for Android/iOS which calculates a value based on the users input. If an event occurs, this calculated value will be sent to my Backend as normal HTTPS payload. My question is now, how can I make sure, that this value is really only calculated by the source code of my app? Is there a way to handle such a problem?
To make it clear: I want to avoid, that somebody is rooting his phone, extract the Auth-Token from the private storage of my app and sends a valid HTTPS-Payload to my Backend with fictitious payload, manually or by manipulating the source code.
From the view of the backend, it's difficult to evaluate the payload based on its values if it is valid or not.
Any suggestions appreciated!
----------EDIT-----------
For the sake of completeness: apart from the answers here, the following are also very interesting:
Where to keep static information securely in Android app?
How to secure an API REST for mobile app? (if sniffing requests gives you the "key")
You can’t trust data coming from the client. Period.
You should consider moving the calculation logic to the server and just sending the raw values needed to perform the calculation. You can easily get sub-second response times sending the data to the server, so the user won’t notice a lag.
If you need offline connectivity, then you’ll need to duplicate the business logic on both the client and the server.
Short of doing everything on the backend, you can't very easily.
I'd recommend some reading around CSRF (Plenty of articles floating around) as that's at least a good mitigation against bots outside of your app domain hitting your backend. The upshot is that your application requests a unique, random, identifier from your backend (which ideally would be tied to the user's auth token) before submitting any data. This data is then submitted with your app's data to perform the calculation on the backend. The backend would then check this against the random identifier it sent for that user earlier and if it doesn't match, then reject it with a 400 (Bad Request), or 404 if you're paranoid about information leakage.
I have an application. My application has 3 layers.
Front-end (contains front end design and functions)
Back-end 1 (layer 2 - this is the back end server that get data form front-end layer and gives to back-end 2 that contains database operations. this layer is just a transporter)
Back-end 3 is another back-end that triggers database operations by data that gets from layer 2.
When a XHR request send from front-end, it goes to layer 2, in layer 2 in Nodejs server, it will be add an API key and forward request to back-end 2 by special address. in back-end 2 it will check the API key first then trigger the operation.
Example:
1- form submited in front end to "/api/create_user"
2- in front-end 2 -> request handled "/api/create_user" get the request and
send to "/api/create_user_dkfjhierhgeirhuggridrfjkndf/APIKEY"
3- in back-end 2 -> it check the the request address and APIKEY then trigger
the request.
The problem is somebody has sent some request by an application they made out of my application.
My question is how can I check requests in layer 2 and make sure this request has been came from our front-end not out of our application?
So... you have an API on the internet, and a web application that uses the API.
Somebody took a look at your application, figured out what your API calls are (reverse engineered), and they wrote their own front end.
If your application is a website, there are some things you can enforce. CORS is one. https://en.wikipedia.org/wiki/Cross-origin_resource_sharing
With CORS, the web browser loads the webpage and sees a javascript xhr request. The web browser first ask the web server if the web page has permission to access the web server.
This relies on the web browser enforcing the access. If your adversary is using an app like curl, there isn't much you can do.
The most common mitigation is to require user registration and users need to login. Even this can be gamed, but now the adversary needs to duplicate your login flow, and grab the login credentials.
The final mitigation I'm aware of - You can continue to make it difficult for the adversary to get your pages. You can set a random cookie and verify that cookie for each request. You can set a secret code in the HTML, and pass that with your XHR request (like set it in a header) and verify it exists. You can change your API names, even make them randomly different every day. All these take time for the adversary to figure out, and until they figure it out, they are offline. If it's offline often enough, they might give up.
Which is safer in term of security, sending parameters thru url or JSON object?
URL:
www.mywebsite.com/search.php?password=t45vye45vh
JSON object:
request.post(url, data);
The GET method requests a representation of the specified resource.
Requests using GET should only retrieve data and should have no other
effect.
Whenever user want to data from server using only basic details like userId or some other id then use get request.
POST submits data to be processed (e.g., from an HTML form) to the
identified resource. The data is included in the body of the request.
This may result in the creation of a new resource or the updates of
existing resources or both.
Post method generally used for form or passing more number of data to server. Whenever something needs to store on server, post request is used. Eg. for registration, login, file upload, making new record etc.
It depends what you are trying to secure against. For information assurance and maintaining an accurate audit history the URL is easier to capture in logs than the body of a request. It is also simpler to parse in a WAF.
To protect against abuse of this information then you might want to make it less obvious. Anyone reading the standard webserver log that uses your first example will be able to see passwords. Your browser will also retain this value in its history and users can create bookmarks containing passwords - neither provides a secure method of storage.
For anything sensitive use POST.
With HTTPS enabled, it is true that query string parameters are encrypted and cannot easily be sniffed. However, GET requests are stored in browser history, and proxy and server logs by default. They can also be leaked in the referer header.
POST requests are unlikely to be logged, and do not have the referer issue.