I'm developing a POS Client using Chrome (packaged) Apps. It will run locally on the installed computers and interact with the server via web service. This app should only run on specific computers at the stores.
I know I can go to each store and install the .crx file in which case I don't have to publish the app to Chrome Web Store. However, I want it to be published to Chrome Web Store so that I can take advantage of its auto-updating feature.
What should I do to make sure that the app can only run at the stores' computers? (I can go the the stores and setup anything needed at the first installation).
Options I have thought of:
Create some secret key and enter it to the app at the first time of running.
Build a small tool (winforms application) to generate time-based tokens and install it on the computers. The staff will need to enter the token each time opening the app.
Any better idea how to accomplish this?
You said the app needs to talk to a web service to work. That's the key to a simple approach. (Assume you don't care whether the staff acquires a nonfunctional copy of the client app.)
At startup, app checks for existence of a validation of some kind stored in chrome.storage.local. If it exists, startup continues.
If the validation is missing, the app checks for existence of a GUID stored in chrome.storage.local.
If the GUID is missing, generate and store one using something like window.crypto.getRandomValues().
Ask the server for a validation by sending the GUID and getting a response.
If a validation comes back, save it in chrome.storage.local and go back to the start of this sequence.
Otherwise tell the user to get lost.
A full-strength version of this approach would have some additional features:
Use an HMAC(GUID, secret) for the validation. I'm assuming the staff aren't tech superstars, so something simple like a boolean would probably suffice.
Optionally add a per-launch step that sends up the GUID and validation and confirms it's still valid each time.
When the validation is requested, you might prompt for the secret key you mentioned in your question. In normal cases this would be needed only at provisioning time.
In case you haven't figured it out yet, the server is now acting like a simple licensing server, so it's up to you to decide how to decide whether the validation request succeeds. Maybe it allows only N validations to exist at once, or after you're done provisioning you hardcode future validations to fail. Maybe it limits validation requests to certain IP addresses. You get to choose.
That's the gist. It's a simple DRM system that is easier to manage than the enter-secret-at-installation method, but that won't withstand an attack of more than 30 minutes (since a smart attacker will just inject another machine's GUID and HMAC validation into the duplicate machine's chrome.storage.local).
Related
I am creating a Chromium/Electron based Mac app. The app is essentially a browser for my customers to use a web service that I have no control over. My requirement is that users of my app (who may have root access on their Mac) should not be able to view the URLs the app is visiting, and should be unable to gain access to the cookies the app is storing. Normally it is not hard to MITM yourself, or attach a debugger to an app and dump memory to see the URLs and cookies.
How can I prevent these types of leaks to the user? If it's impossible, it may be acceptable to make it very hard so that a very high level of sophistication is needed.
Your users have full control of their devices, it is not possible to securely prevent them from proxying or exploring what your client-side app does. Obfuscation would seem like an option, but in the end, the http request that leaves your app will traverse the whole OS through different layers, and your user can easily observe that, if not else then in network packets (but usually much easier).
The only way it is possible to prevent the user from knowing what's happening is if you have your own backend. The frontend app (Electron) would make a request to your backend, which in turn could make any request with any parameters without the user being aware.
Note though that your backend could still be used as a proxy or oracle just like if the user was connecting to the real service. This might or might not be a problem in your case, depending on what you actually want to achieve and why.
The app is essentially a browser for my customers to use a web service that I have no control over. My requirement is that users of my app (who may have root access on their Mac) should not be able to view the URLs the app is visiting, and should be unable to gain access to the cookies the app is storing
Basically, you cannot (you could with the appropriate infrastructure. But you lack that infrastructure).
Network communications can be secured, to a point, using HTTPS (if you can't even use that, then you're completely out of luck - users wouldn't even need root access to the Mac to sniff traffic). You need to verify the server certificate to be sure you're connecting to the correct server.
One thing you might do - effectual just against wannabes, I'm afraid - is first run a test API call on some random server and verify that the connection either fully succeeds, with the proper server identification and matching IP, if the server exists, or that it properly fails if the server never existed. Anything else would be a telltale that someone has taken over the network layer, and at that point you could connect to a different server, making different calls, and lament that the server isn't answering properly.
Strings in memory can be (air quote) protected (end air quote) by having them available only for the shortest time, and otherwise stored in a different form - you can have for example an URL and a random byte sequence with the same length, then store the sequence and the XOR of the URL and the sequence. You can then reconstruct the URL every time you need it, remembering to clear it off any app caches it might find its way into. Also, just for the lols, you can keep a baker's dozen of different URLs sprinkled in the clear throughout the code. A memory dump at that point will turn out nothing useful.
Files, of course, can be encrypted with any one of several schemes - the files residing on the same machine that has to know how to decode them makes all such schemes ultimately vulnerable, but there again, you can try and obfuscate things. I once stored some information in a ZIP file - but it was just the header of an encrypted ZIP file, with the appropriate directory entry block glued at the end. The data were actually just gzipped in the clear, there was no password whatsoever. The guys that tried to decode the file thought it was a plain encrypted Zip file with the extension changed, wasted a significant amount of time with several Zip cracking tools, and ended up owing me a beer.
More than that, there is not much that can realistically be done.
A big advantage would be in outsourcing the API calls and "cookie" maintenance to an external service that you control, e.g. on Amazon AWS or Azure or similar. Then you could employ all kinds of protection schemes (for example: all outbound API calls could be stored in an opaque object, timestamped, nonced, and encrypted with your server's public key, and the responses sent encrypted with your client's unique key). Since this is relatively simple and cost-effective, it would also be my recommendation.
The App could have a private key hard-coded into it and my server could have the public for it and the App could sign everything. But then a hack could identify the private key in the object code and write a malicious App that signs everything with that same key. Then that App could use my server.
The App could do a key exchange with my server but how does the server know the App is authentic when it does the key exchange?
In essence you cannot know.
Reason is simple: since anybody can get to the client and have everything the client is and knows by reverse engineering the client (to which they have all they need to perfrom that), there is nothing that can prevent them from answering any challenge you might set to what the real app would answer.
You can make it harder on fake apps though. But they could (if done right) give the answer anyway.
E.g. how to make it harder:
The server sends a challenge to the client app to calculate e.g. the CRC32 (or md5, sha-1, sha-256, ... doesn't matter as such) of the app itself from a given start to a given end. If you set those start and end points to be fully random for every challenge you send, you essentially force the fake app to have the real app's compiled code in full ... So you place the burden of having to have the real app (not forcing it to be actually running the (unmodified) code, just having the actual unmodified code).
Take care that you would need to support the server side with allowing for multiple versions of the client etc. or you can't upgrade the clients anymore.
Anybody distributing a fake app would hence be forced to violate your copyright on the real app (and your lawyers would have am easier case maybe).
Alternatives:
To pick an alternative, you need to figure out why it's (so) important to have your client ?
If the client contains secrets: remove them, make the client display only and have an 3 tier model where you only let the user run the display part and keep all secrets on your servers.
If you get your revenue from selling an app, give it away for free and sell accounts on your server. Use authentication to do that: you can authenticate users (login&password, real 2 factor authentication , ...) you can also disallow them to dramatically change their geo location in a short time, disallow simultaneous logins, ...
But the price is the hoops for the user to jump through. And they might use other clients nonetheless.
If you allow logic (like e.g. used in online games) to use the power of the user's CPU to do things, you can still keep oversight on a logic level on the server: e.g. if it takes 5 minutes at the very minimum to complete a task in the real client, and if the client reports back as "achieved" before those 5 minutes are done: you have a cheater ... Similarly, make sure all important assets are only given from the server, don't trust the clients ...
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've been developing and maintaining a Chrome extension for my company where each customer would be assigned a unique ID in the code. We've been using the ID to determine license status and login to our services (paid extension with monthly subscription fee).
So far we've hosted the extension files ourselves and had unique update URLs for each customer extension. This has been nice and simple; go to our website, click install and you're done. With the latest Chrome release, however, that installation procedure has been thwarted by Google since they now require users to install extensions by dragging and dropping the CRX files into the chrome://chrome/extensions/ tab. Unless of course your extension is available through Chrome Web Store - which leads me to the problem:
We don't want the drag and drop CRX installation - requires Web Store.
We don't want multiple versions of the extension (one for each customer) on the Web Store since that's a maintenance hell every time we update the extension.
We don't want to use Web Store licensing because:
It requires OpenID login.
We sell the extension to schools with many students where the school pays the bill - not the student.
We don't want to lock our payment method to one browser, i.e. we want to be able to maintain licensing and payment through our or servers.
We don't want to have users input a license key since that's too much of a risk with several thousand students having to input the key - also it requires some kind of storage (cookies/localStorage) which would eventually get cleared requiring the license key to be input again.
I'm not 100% certain that my statements are completely correct, so feel free to enlighten me if I missed something.
If they are, the question is whether or not we can somehow tailor the extension for each customer through the Web Store (using the unique ID) without needing to publish one extension per ID?
As a side question any answers that might solve the problem with another method will also be accepted.
For the answer below, I assume your app is a packaged app, not a hosted app.
I have a solution that's fairly similar to your current implementation, but adds one extra step for users. For the student user, the process will work like this:
Download the app from the Web Store. The app does not function yet, and launching it just displays a "Please click the activation link provided by your school/institution" message.
Click a link hosted on your server (i.e., the server where you used to host the update URL) that looks like https://myserver.com/activateapp.php?custid=123456789. You host one such link for each institution you support, and it is the institution's job to provide its link to its students. This link activates the app.
From an implementation point of view, here's how it works:
Host a page, https://myserver.com/activateapp.php, on your server. Server-side, check that the custid parameter is valid. If it is not, send a 404 error.
Your app has a content script that is injected into https://myserver.com/activateapp.php that scans the URL and picks out the customer ID. Once the app finds the ID, it stores it in localStorage. Since invalid customer IDs produce a 404 error, you know that when the content script runs, the page is not a 404 error; therefore, it is reading a valid customer ID.
Any time the app wants to query your services, it checks if it has a customer ID in localStorage. If it does, it uses that ID; if it does not, it displays a message that the app has not been activated yet. Packaged apps will never have their localStorage erased unless your app is programmed to wipe its own storage, or the user does it from the console. Storage erasure will never "accidentally" happen. Even the strongest browser-wide data/cache purge will only clear localStorage from Web pages, not from apps and extensions.
For extra security -- if you don't want people randomly guessing customer IDs -- you can add an extra signature parameter, like https://myserver.com/activateapp.php?custid=123456789&sig=2464509243. This extra parameter is some server-verified transformation of the customer ID (ideally a cryptographic signature or a purely random value associated with the ID in a database) that is impossible for anyone to guess. When the request for activateapp.php hits the server, it checks for a valid customer ID and a valid corresponding signature. Of course, this doesn't stop people who have legitimate access to a valid link from sharing the link to unauthorized people, but I expect that was a vulnerability that existed in your old system anyway.
I'm in charge of an app that uses the internet to transfer data between sites, and some customers are being awkward about paying, so we need a mechanism that will allow us to cut off the service of non-payers. I'd like to protect against the admin people using firewalls to block off our checks, but conversely I'd like to give some allowance for our company web site disappearing for some reason and not being accessible.
The scheme I'm imagining is:
server makes twice daily check to web page using a URL like:
http://www.ourcompany.com/check.php?myID=GUID&Code=MyCode
This then returns a response that contains either nothing of interest, or the GUID and a value.
GUID=0
That zero indicates that the server should stop operation. To make it work again, the server will check every 5 mins for the same info, until the value matches what it thinks the code that it passed in should be transformed to.
This scheme makes sense to me, but the question really is how to protect against blocking. Given we know we must have internet access, how long should we continue to operate without being able to get the response from our web server? Is something like 14 days and then we just shut it off anyway the best way?
The solution I used in the end was pretty much as I suggested. Yes, it is defeatable using tools outlined here, but it is better than nothing.
The app checks daily to access a web site that contains a control file encrypted using public key encryption. It decrypts in memory, and if it finds its GUID, then it must match a code. To disable the operation, the code is set to 0 (zero) which will always fail. When disabled, it checks every two minutes to allow rapid restoration. There is also a manual mechanism to generate a code that will work for a week in case of server trouble.
The code will allow up to 14 days without connecting to the server before it takes this as a deliberate attempt to block it. After 10 days, it shows an error message which asks them to contact support.
This method is really easy to circumvent: just use a local dns server to point www.ourcompany.com to the local machine, or use a http proxy. Then the user can return whatever response they want to the program.
Assuming the user hasn't circumvented the check, how long you are to continue to operate without confirmation is a business decision and not a programming decision.
A user can use a tool such as OWASP WebScarab to change values on the fly to subvert your security model. You need to include something more difficult such as requiring a secure channel, comparing public key and so on.