I want to use model-viewer or three.js to showcase some of my 3d models on a personal website. In order to display 3d models on the web, the client needs to fetch the files from the server (the 3d mesh and the texture images)
But I don't want my visitors being able to access any of these files. I hope you can point me in the right direction. Here are some ideas I had, but I don't think they'll work:
(1) Using something like crypto-js to encrypt and decrypt files
But when decrypting files on the frontend aren't users able to decrypt the files, too?
The key has to be transferred to the frontend code somehow, doesn't it?
(2) Splitting the files up into little pieces and recomposing them on the client
Same issue as with #1
The code for recomposition needs to sit on the client and can be used to access the files
When elaborating on those ideas, I am not quite sure if what I am trying to do is even possible 🤔
In case it is impossible... is there anything I can do to make it really hard for users to get access to the files?
The short answer is: If it is on a website, you don't stand a chance to protect it against a determined person with enough time on their hands. The only exception here was made for video-streams, which can use the 'Encrypted Media Extensions' API to get video to the screen without any parts of the browser being able to interact with raw data.
Whatever you do to protect the files, the code to read them needs to be sent to the browser as well. Eventually, the raw data will be somewhere in the memory of the js-runtime where it can be extracted using the built-in debugger. The same goes for any mechanism to somehow encrypt the code. It makes it more difficult, but not impossible. You could use WebAssembly to make that part of the code even harder to reverse-engineer, but I wouldn't need to do that:
In the end, the data needs to get to the webgl-api, so I could just use a browser-extension to intercept the relevant webgl-calls and obtain all the raw data there. You could go on and also encrypt the vertex-data in a way that can be decoded in the vertex-shader, but guess what: I can read the vertex-shader code as well.
And so the list goes on. There just is just no way to do it that cannot be somehow circumvented. But maybe you make it difficult enough for nobody to bother...
For me the most promising options seem to be:
use LoFi or partial models for rendering in the browser alongside renders of the full-resolution model. I've seen that on several sites for downloading CAD-/3D-models. They used merged models, sometimes reduced vertex-count, low-res textures and so on while providing images of what the final result will look like once I paid for it.
make up your own file-format or hide the file-format used in the network-view of the developer-tools. Google maps/earth for instance does that with their 3d-data (they are probably using something based on protobuf, but it's incredibly hard to reverse-engineer)
and yes, I guess you could also use the WebCrypto-API with a pre-shared secret so it is at least not too obvious which of the files contain the 3d-data.
Related
I've been tinkering a bit on a small application which would show a limited amount of data to the viewer in a nicer way. I was thinking instead of opting for a database (be it SQLiteor / MongoDB) to have my data stored in a simple json file. It would have below characteristics:
Static data (will never have to be updated - 100-150 arrays)
Not private data - can be freely accessed by anybody which has access to the application
Offline application (not a single connection with internet)
Multiple users which would read only the data
JavaScript being used for this
What I am wondering about though is simultaneous reads. The application would never be used to update the data, it remains static. However there might be several people using the application simultaneously. As the tool will be stored on a shared drive, accessible by several other clients at the same time (only to read the file).
As I haven't touched anything with data or databases yet, I'd wanted to see if anybody already tried this out before I go into it deeper.
I am aware of the implications in terms of security however the data inside the application is not secure data and can be accessed by anybody freely. I only want to show it in a nice way. And as it is static anyway I was going to opt for a JSON file i/o starting to work with a database to speed up the development.
As far as I can see from your description, I think that there should be no conflict. You should be fine.
It's actually fairly common to use JSON-formatted files to store truly-static data.
This is a bit less "simple answer" than I would like however I am not really sure where else would be best to get a collection of vulnerabilities related to this sort of thing. I will happily delete the question if someone has a problem.
So with that out of the way here is my scenario, I have a client heavy web based app, which is knockout with local storage to a web service. Now part of the users experience has hooks where users can write plugins and make their own functionality on top of the existing one. Although this part is not 100% relevant it basically is an event system where events are exposed and other javascript files can be loaded at runtime and listen and action these events.
Currently a plugin consists of:
A json descriptor file (which describes its dependencies and details, version etc)
An entry point file
Any other js/image/html files
Now we want to streamline the process so we were going to create a site which is a subdomain of our existing app where users can upload their own plugins in one central place, and then access them in the web app.
So we made the decision that the user can upload a zip file containing these files and we will do some server processing to confirm it contains the relevant stuff and then basically expose it for users to access.
Now my question focuses around the security vulnerabilities I should be worrying about here.
I know the zip files could contain anything so best we can do from my current understanding is just make sure the zip file contains the files we expect in the pattern we expect, i.e plugin-descriptor.json, entry-point.js then hope for the best.
I can also make sure there are only file extensions matching our accepted files, i.e js, json, html, png, jpg, gif etc.
There can be file size constraints put in and header checking on files to prove they are of the type you expect but not sure how technically feasible this sort of thing is.
As an example of a system like this, Wordpress has a collection of plugins users can access and apply to their site, they (and others) seem to use an SVN server they maintain and manually verify plugins uploaded, which I am not sure if we have the man power to do (Hence why I want to see if there is any automated way to vet these things). Also much like other sites where users can upload pictures, there must be best practices around handling these sort of scenarios.
Other than that I am not sure what else to look out for, and this feature may not be played in the next sprint, we are just working out the technical issues around it and trying to see what the best way of being able to have a list of plugins for users to access without us having to do LOTS of work maintaining it.
The current task is as follows:
It's about publishing spreadsheet tables online and making them accessible only to registered subscribers. The access to these spreadsheets is meant to be a paid service. Subscribers may access them online from wherever they are and do their calculations related to expenses or working hours and so on. These spreadsheets are developed in MS Excel. They are then converted into HTML/Javascript files via a macro app. The resulting Javascript code contains all the important formulas which need to be protected.
I know about Javascript "obfuscation" and scrambling" but would like to find a better solution since the two mentioned methods can be reversed.
The idea is to place the spreadsheet tables and the formulas for calculation inside of a Flash container file for protection. This Flash container file is not meant to link to or access any other external sources. The data which the users input into the spreadsheet would be saved in XML format.
Here is one tutorial which explains how to encrypt a Flash container file in order to prevent decompilers from making the content accessible:
http://code.tutsplus.com/tutorials/protect-your-flash-files-from-decompilers-by-using-encryption--active-3115
Here is a tool which claims to do the same, but it may be that it just obfuscates and does not go as far as the process in the tutorial above:
www.amayeta.com/software/swfencrypt/
There are some downsides of using Flash which I know. I will not list them here, they are discussed in this forum. Consider that in this case the security aspect outweighs the downsides of Flash. The conversion of the HTML/Javascript content into Flash format will add more effort to this project.
I would like to ask these questions to this community:
Is there a converter that could help to translate Javascript into Actionscript?
Would it be necessary to translate the Javascript into PHP in order to use it within Flash?
Would the effort be worth it?
No this won't be worth the effort as the client will have full control over the runtime of flash. This means that it would not be difficult to extract the functions used. If you must protect your formulas then you should only perform the calculations on your server (or any kind of well protected cloud, if such a thing exists).
If you think that your code will run fine in flash or a browser, then it should not be hard to run the code in a well protected backend server.
I'm planning to write a web app using either Backbone or Angular. We want to push "widgets" from the server to the client (i.e. semi-complicated, dynamic but largely autonomous UI elements... something maybe like the popular TodoMVC app). So we'll need to send over a template, some javascript (controllers etc.), probably CSS, and JSON data (models).
We're debating how to send over all the information. How much can be, and what should be encapsulated in the JSON?
Is it possible to create files out of data passed over? i.e. could we pull out CSS and apply the rules to our document? I believe it would be easier to run javascript passed over this way.
I'm under the impression that being able to cache the template is important... does that require loading it as a (separate) resource rather than as part of some huge JSON object?
As for CSS, it needs to be loaded before inserting into the DOM (so we don't want just a promise). Would it make sense - or even be possible - to pass our CSS rules in the JSON and extract them somehow?
EDIT: to more fully describe what I'm working with, I'm focusing only on the front-end. The back-end can be customized to send over resources however we want - they'll optimize that depending on what the front-end needs. Our backend stack includes MongoDB, Tapestry, ActiveMQ.
The payload that needs to get sent over will be all the resources necessary to push something like a Mac Dashboard Widget or Windows Gadget into the browser. So HTML, CSS, Javascript, data will all get sent over. We want things to be snappy and minimize server requests as much as possible, as some of these payloads may get to be somewhat large.
Your questions are rather vague and the answers can change by coding on a different build platform. Your chosen application design can also impact the best practices to follow for implementing X type of application to X device(s). There's more than one way to skin a cat ya know.
What information are you sending over? Is it a lot of raw data arrays? Is it more document based where XML could be more beneficial? You'll need to work with your DBA if the data is stored in a repository and you'll be querying it. Will you need to write code to format your data or will the DBMS output it in the format you need?
What do you mean the CSS needs to be loaded before being inserted? Everything loads in the order you specify so making sure your CSS loads at the proper time shouldn't be an issue. If you're using ASP.NET, you can also use a SSM (style-sheet manager) to serve your CSS and only load whats required. SSM's are great if you have a lot of style-sheets to serve.
A lot of the questions you asked will be answered as you get further into the design phase. In order to get some solid answers and not just speculation on what is the best method, you will need to publish a lot more details than this. Any answers at this point shouldn't carry much weight in your decisions. They certainly wouldn't mine.
With all the recent hype about JavaScript and HTML5 replacing Flash, I wanted to know - How would it be possible to protect client-side js code? Of course, it is possible to obfuscate it, but that would only make it a little harder. Also, for games which submit high scores to the server, wouldn't it be incredibly easy to modify those scores before they are sent to the server? I know even Flash files can be decompiled, but they can be obfuscated and flash decompilation is not as easy as modifying data in JS - could be done easily using a plugin such as Firebug. I'd like to know everyone's views on this.
Javascript, being parsed on the client, is never 100% safe. There will always be ways to find out what it does. A few days ago I've even seen a tool which unpacks packed javascript so the only thing you can really do is using "ugly" variable names (or actually, make a javascript packer transform your "good" variable names into short/ugly/nonsense ones)
To protect game results, you have to move some of the game logic to the server so the client cannot send arbitrary results.
Summarizing it: Don't put secrets in javascript code and don't trust anything coming from the client - no matter if it's from a form or generated/submitted via javascript.
You say that for game that sends high scores to the server it would be too easy to modify javascript and forge request?
Except for case, when you use some cryptography on the client, it is the easiest way to forge such request not even analysing the script but sending false request itself. Everything you send between server and browser can be easily viewed on computer, analysed and changed.