I want to develop an application for IOS and adndroid with unity.
My concern is how to be sure that only my application can get some secret data stored in the google app engine server. Is possible do this thing?
I try to explain the malicious scenario that I want stop :
-apply reverse engineering to my application (here I know that is impossible do something)
-contact my GAE webservice (here I want apply something to be sure that it is a maliciuos request) to get the informations
Please let me know if other information are needed
Thanks in advance
create an unsecured / simple ssl type connection and encrypt the data you send on it.
using temporary shared keys for the duration of the connection should be about the best situation allowing you to "throw away a breakable key" after a certain time period.
From there its bog standard web request / sockets is it not?
I'm sure you can google foo something up for that!!!
Related
Im building a chat that uses a api rest full, but i found a problem storage jwt in client side (cookies and his problems), so i opted to use sessions(it's a better option in security terms), that adds state to my app.
I should create a separate server that handles the sessions and also have my rest api?, and apart another server that implements some functionality such as a push server (which I plan to implement). Because I really don't like the idea of having everything on one server, and if so, what should I take into account? (have more than an rest api server and other with his funcionality).
I'm a developer and i think so this require architecture knowledge, and i have no many idea about servers. If you can give me some idea about the topic to get better on it will be great, and what's the better option in this case.
Thanks, give a nice day
I just discovered that azure app services can scale both up and out. For out this means creating multiple instances. So my question is do I need to change my asp.net web app to support this? For example if a user asks to run an async report that runs in background and then comes back later to download the report will it just work? What about security. If a user has authenticated, gotten a cookie, and then leaves the app alone for a while and then continues will it work? Is there any documentation to help.
If your code doesn't support, you can always switch on server affinity. This ensures the request will route back to the same server. However this is not recommended you want any server to respond, rather the same one they started with.
You don't need to change your code, it will just work and its Azure is smart enough to route traffic to the servers for you, so your question about async, yes that will 100% work.
If you use store information in the cookie, it should work without server affinity, but if you use session, then you most likely will need to turn it on (depending on where session is stored - inproc, sql). Here is an article about server affinity https://blogs.msdn.microsoft.com/appserviceteam/2016/05/16/disable-session-affinity-cookie-arr-cookie-for-azure-web-apps/
Hope that helps
I've been looking at node.js, REST APIs and WebSockets lately to further my knowledge about backend and frontend web development. Trying to go with best practices I see REST API comes up all the time. Now my problem which I don't seem to understand how to properly solve.
Say for example I'd like to have client / server decoupled and for this I implement a REST API in the backend so that my frontend will access and get data to render. Specific (imaginary) example: lets say I want to build a rental service website. Now I would like to have an endpoint for my frontend to access information about certain products, let's say the number of bikes that have been rented so far. I'd like to be able to show this on my frontend (through the help of the REST API) but I wouldn't like for other people who call this REST API to be able to get the data (because espionage is a serious business and I'd like to keep the evil ones away, yes they can webcrawl but bla bla). So in essence I'd like for the localhost machine to be able to access (part of) the REST API but not anyone else. Things get complicated because I'd also like people to be able to create a user on my website so then I'd like to have other endpoints which can then be accessed without restriction because I'm thinking, what if at some point I'd like to have a mobile app that is integrated with the service. Then it will be unfeasible to restrict all requests to localhost.
How would you architect a secure server / client as this one? Or in your opinion is it not that big of a deal to have the REST API exposed to others (the evil ones)?
The above goes for WebSockets as well. I know REST APIs are all nice and neat but I think the future lies in near-realtime connections and so I'm likewise as interested in WebSockets (through higher level modules of course, Socket.io, SockJS etc.).
There are many solutions to secure your API out there and many of them are opensource. Which one you'll use really depends your detailed needs.
But to get you started I will mention a solution that is very accepted and supported by a large community:
Have a look at JSON Web Token, which are for example explained in this Article.
Basically your client requests an authentication token from the server and then stores it locally to reuse it for every request to your API.
The Server on the other hand may protect your API as needed. That means you may also have a public API that does not expect a token in the HTTP Header.
Tokens may also expire. That is handy if you, for example, will allow a new user for registering on your site for a limited time.
Here is another article that explains things.
Now on to the websocket part of your question. YES, you definetly want to protect your server side sockets as well. So look out for a library that supports authentication. Again, I think there are a number of opensource libraries out there.
To mention one: Primus.
Primus is an abstraction layer for many socket libraries underneath and lets you quickly change the socket provider. But it also has an authentication hook that you can implement.
And guess what.. you can use it to check for a JSON Web Token!
Hope this gets you started.
I want to create a SaaS extension for chrome.
How do I ensure that they cannot use my extension's functionality when their subscription is no longer current?
My basic idea is that whenever they want to use my chrome extension's functionality, the extension makes an ajax request to my server to check to see if today's date is before the subscription's ending date in my DB.
The extension is obviously is client based, so even if I have code on the client side that's only executed if my ajax request returns that they have a current subscription, couldn't an enterprising individual just look at my code and run it via console in a way that gets past my ajax request requirement?
Is there a way to enforce the subscription?
Edit:
This is mostly a conceptual question, but I'll try be clearer.
All the javascript code needed for my app to function is on their local machine, in their source files (to work it doesn't require access to my database).
so you could think of my code on their local machine as looking like this:
if (usersSubscriptionIsCurrent) {
runFeature()
}
And usersSubscriptionIsCurrent is true if the Ajax request to my server returns that their subscription is current.
Someone could still run my feature just by looking at the source code, and then typing runFeature() into their console.
I want to prevent that.
My extension relies on sending data from the extension to a related chrome app, so I just had the idea that I could also send the data to my server, which could then forward the data to user's chrome app if they have a current subscription. But yikes.
The more I think about it, the less I think it's possible for me to prevent, but I figured I'd ask in case anyone has a clever idea.
I think you are slightly confused about what counts as SaaS. Wikipedia:
Software as a service is a software licensing and delivery model in which software is licensed on a subscription basis and is centrally hosted. SaaS is typically accessed by users using a thin client via a web browser.
Emphasis mine.
If your app / extension contains all the logic required, it does not qualify as SaaS. Futhermore, as it is always possible to copy/dissect your app, taking out all license checks, you can't protect it against a determined attacker.
There are ways to protect your code to some degree, via obfuscation, offloading logic to (P)NaCl modules, native host modules, or, as Alex Belozerov suggested, load the code on runtime. Again, all of that can be broken by a determined attacker.
But if you truly have SaaS in mind (and not just subscription-based licensing), your client app should be a thin client: that is, your app logic should be processed on a server, with code safely away from clients. That is the only "sure" way to protect it, but incurs processing costs to you, but that's what subscription is supposed to cover in the first place.
You can get part of code needed from server side. So if user's subscription is over, he won't be apple to run your feature as part of code is missing. Concept of my idea:
var subscriptionStatusResponse = makeAjaxCall();
if(subscriptionStatusResponse.usersSubscriptionIsCurrent) {
runFeature_localCode(); // only part of functional
subscriptionStatusResponse.remoteCode(); // second part
}
Maybe the best solution is to check if their subscription is current as soon as the extension starts, and then use the chrome management API to uninstall or disable it if their subscription is over.
I'd love to hear better ideas though.
I am getting to the point in my Google App Engine development where I am signing users up. I collect the signup info, do some initial validation to make sure that things are the correct length/format, then send that info to the App Engine for server side validation and ultimately signup and login. I understand that I can think of the App Engine as extremely secure (it's Google anyway) and my client side is a Cordova application, which is also secure because it is wrapped in an app package. The only insecure part of the interaction is the HTTP POST request that I send containing the password. I see really only one option for making this more secure. I may be right, I may be wrong. I honestly have no idea.
I'm thinking that I could encrypt the password locally and decrypt it once it hits the app engine. The problem with this is that anyone monitoring my requests can read this decrypted value and they don't even need to decrypt it. They can just send it encrypted as it is. I can adjust this by making the encryption dependent on other variables that only the app engine knows about, but I'm not sure if that is a good way either.
I know next to nothing about web security, and very little about encryption techniques. What is the best way to send and store passwords with Google App Engine?
Don't reinvent the wheel and (as already mentioned in the comment) just use SSL.
It works out of the box for *.appspot.com domains (example) but if you want to enable it for your custom domain you will have to go through documentation.
Send over HTTPS - App Engine provides SSL for free - USE IT! Then at the server encrypt for storage. Never save passwords in plain text. If your using Python, check out the webapp auth api, which takes care of everything for you -> https://webapp-improved.appspot.com/api/webapp2_extras/auth.html