Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I have a method I'm testing right now for hiding javascript so that the user can't go around searching for it in the source files.
The method is this:
You have a bunch of javascript files included to make your application work. Libraries like jQuery, dojo, and your own code. This is pretty standard.
There is one critical piece of javascript code without which the app will not function, nor will any curious user be able to make heads or tails of the app without it. This critical piece does not get loaded by script tags. Instead, a small unobtrusive script calls to a database and returns the javascript in a big long string.
This string gets eval()-ed to make it live code. But the code was dynamically generated, so it won't show up if the user is looking through the source code or saves the website. Furthermore, you can add some kind of a salt or time-stamp to prevent users from trying to trick the database into revealing your javascript kernel.
I'm trying to get feedback on this from the community, and most of the examples I've turned up for hiding javascript with server-side code has just been people wanting to to include a .php file in the tags instead of .js. This is totally different.
So there you have it. Is this a good idea? What are the weaknesses?
eval() is generally frowned upon, but regardless, the big weakness is that I can simply sniff the HTTP requests and get your script. Obfuscation can make this more inconvenient, but with a good debugger its not that hard to follow a stack trace and get a good idea of what is occurring.
Even if the resource is transferred over SSL, it can be perused/manipulated once it has been loaded by the browser. To test this, I went to a secure website and examined a raw TCP response (both synchronous and asynchronous using XML HTTP) using SmartSniff. As expected, it's encrypted and unreadable. However, the same requests are all visible as plain text in Chrome's network activity inspector.
It's trivial to make Javascript code unreadable by humans (and even highly resistant to reverse engineering) - and you don't need to hide it in a of of other code. But why? Generically, the name given to this kind of code is malware.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I am building a web application for a company so they can test the app on a control group of people to see if they would like to try funding the app. Funding beforehand is not an option, however I would like to keep the code somewhat private, so that someone from an IT team can't just easily download all the app files and claim it as theirs. I have researched a little but also found little on what can be done to protect the files for the app which are written in javascript, html, css, ect. basic web development languages. i was just curious if anyone knew of a way to somehow protect these files if it is even possible. I'm not against sharing my code, however for a business opportunity I prefer that it remain private for the time being.
This question has been answered before: How can I obfuscate (protect) JavaScript?
But anyway, here's my take on the question:
You don't need to protect your HTML/CSS code, unless that aspect of the app is what is so proprietary. If that is so, obfuscate your code (there are many websites online that will do this for you).
From the information you gave me, I can infer that it's not the styling or the UI you want to protect, it's the application's logic. In that case, you can obfuscate and then minify the JS code such that it's very hard to deconstruct (although some web browsers do pretty-print the code). To see an example of this, go to Google, open the dev tools, and look at any JS file under the Sources.
I also saw another interpretation to your question. If you meant "to protect the application from being downloaded and then reuploaded", that sadly isn't possible with web apps (unless you explicitly check the domain that the app is running on and restrict the app from running on domains other than yours).
An implementation of the domain-protection would look something like this:
if (window.location.hostname !== "yourwebsite.com") {
alert("Invalid domain, redirecting to official app...");
document.location = "http://www.yourwebsite.com/app/";
}
After adding this protection, you can stop it from being removed by minifying and obfuscating the JS code.
For the css and Js a lot of people use minification. This makes your code really hard to read and finding the business logic in your code. As for the HTML you could uglify it. There is no real way to hide HTML,CSS, JS in your browser because the browser dev tools would reveal all of the code. There are only ways to make it unreadable.
JS minification tool : https://javascript-minifier.com/
Css minification tool : https://cssminifier.com/
https://developers.google.com/speed/docs/insights/MinifyResources
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I'm a C# developer, and use XAML for user interfaces. Lately I've been wondering something regarding HTML5+JavaScript development (used in Universal Windows App development, as well as for websites). Javascript is compiled and executed at run-time on the client device. So any user can go into the folder where they're stored on computer, and see all the code in it, right?
There is no unreadable alternative for js and html5. That's why so many websites are so slow in adopting html5 video and replacing adobe flash.
But if your entire application is client side and you worry about your code being stolen you're doing something wrong. Almost any application requires serverside code that isn't accessible.
And it doesn't matter anyway, who cares about some js that makes a div draggable or moves some html around.
I dont think readable javascript code is of any value...what matters is the server side code like php or ASP which really matters in the security of the websites
And even if the developer didnt want the user to read the javascript framework.. what option does he/she have to prevent it..?none!
The client side code is indeed visible by the client. If something is available client side, then you won't need a round trip to the server to get it.
For example you could imagine a simple calculator application. You could write it client-side, in Javascript, the app can ouptut the calculations immediately. Or you could write it server-side (in wathever language you want), which means you need to ask the server for the calculation (with an ajax request probably), and wait for it to respond.
Also some things doesn't make sense on the server-side. Pretty much any action that changes the DOM, which only exists client-side, in the browser.
I wrote about this on my blog a while back, see Protecting Your Code,
as an addendum to my free ebook, Programming Windows Store Apps with HTML, CSS, and JavaScript, 2nd Edition.
The short of it is that JS code it not protected, though you can make things a little more difficult with minification/uglification like many website authors do. You can also take steps by putting some of the code you care about into Windows Runtime Components written in C++ (C# can be decompiled). The only really secure solution is to have code on a server, and draw from that in an app which of course doesn't work for all cases, but is an option.
Note that some of my comments in that blog from 3 years ago might be a little dated. I believe that current Windows Store policy now allows you to load code from a remote server at run time.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I'm trying to accomplish the following:
Pull information from a module through Python. [Accomplished]
Constantly pull information from Python for use in HTML.
Avoid writing the entire HTML/CSS/JS document in print statements.
I've seen the term CGI thrown around, but don't really understand how it works. Simply put, I want to run the Python script which returns an integer value. I then would like to take that integer value into JavaScript so that it may update the designated tag. It should be able to execute the Python script every two seconds, receive the output, then apply it to the page. I do not want to write out the entire HTML document in Python by doing one line at a time, as I've seen some people doing on sites I've found.
It seems like doing something like this is far more complicated than it should be. The page should run, call the script for its output, then give me the output to use.
Well if you don't know what CGI is and find that what you ask for is "far more complicated than it should be", you first have to learn the HTTP protocol, obviously, and that's way to broad for a SO answer.
Basically what you want requires:
an html document
some javascript code, either linked from the document or embedded into it
a web server to serve the document (and the javascript)
a web server (can of course be the same as the previous one) that knows how to invoke your python script and return the result as an HTTP response (you'll probably want a json content type) - this can be done with plain CGI or with a wsgi or fcgi connector, in your case CGI might well be enough.
Then in the browser your javascript code will have to issue a GET request (ajax) every x seconds to the web server hosting the Python script and update the DOM accordingly.
This is all ordinary web programming, and as I said, a basic understanding of the HTTP protocol is the starting point.
Trying to write anything from scratch, if you don't know anything about the subject, is always going to be complicated.
That is why there is a whole world of tools to help you. I don't think you want CGI at all; look into one of the Python micro frameworks, in particular Flask. The tutorial there should give you the introduction you need.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
How can I prevent the user running my web page after downlading the page source?
We can't prevent downloading the source code, but can encrypt it.
But it doesn't good enough for me, because the encrypted code can work after downloading.
Thank in advance.
As a general rule, if the code runs on a remote machine it can be manipulated so they can execute it anyway.
You can make this more difficult through code obfuscation or by implementing some sort of DRM, but I would suggest that this will largely be more trouble than it's worth (since it just takes one person to break it and your code is back out).
1) You could, for example, require that some key be downloaded from a site you control before it'll execute, but the recipient might simply sniff their traffic and pass that value to the game themselves.
2) Or you could possibly set up your game to stream each of the levels or some important aspect of it to your game client, but again, there's not a whole lot stopping someone from just reading these aspects and implementing this mechanism themselves.
3) Perhaps you could encrypt these level packages dynamically on the server with a time-based key, but it just takes that one bored programmer with the technical know-how to reverse-engineer what your method is.
4) Another option that comes to mind is requiring some regular polling to a server you control and requiring some sort of response, but again, if your client can predict what this response is supposed to look like, it's easy for someone to rewrite the game to talk to their own program instead of your server.
5) You could also daisy chain a ridiculous number of dependencies of your javascript logic (breaking your own code into a number of dependencies) so it's slightly more difficult for another user to rebuild the required paths on their system. This might be useful to put off a casual user, but I doubt it'd put off a more knowledgeable user.
All in all, I'd suggest that you simply make the game available as is. Various game companies larger than you have attempted to implement DRM measures of their own with disastrous results (when they don't work as advertised) or just plain annoying for the end user.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
There are a lot of features and abilities of javascript that I am unaware of. I have developed a custom closed source CMS and I was thinking about adding a feature to allow for custom javascript that gets included on each page of their site (but not the backend system itself). I was curious of the risk involved with doing this? The CMS is built using PHP and there is javascript within the backend system of this CMS, but thats pretty much it.
If I allow custom javascript, can this be manipulated to retrieve all the php code, or to cause issues on the server itself?
I own the servers, so I can make any adjustments necessarily for safeguarding the server.
Again, this is purely for information and I appreciate any advice people can give me.
The javascript will be stored in a file and included using php on the page itself. I do have code that blocks anything inside to prevent the use of PHP within the code itself.
Can they steal my closed-source PHP code with JavaScript?
To answer your first question, no, your closed-source PHP code cannot be stolen by a user of your CMS software simply by uploading a JavaScript snippet.
This is because JavaScript runs on the client-side (the web browser).
If JavaScript is able to access your PHP code from the client-side, then they'd be able to access it without JavaScript. That would mean that you've configured something wrong on the web server side, like setting permissions on your files so that anyone can view them.
Is allowing JavaScript to be uploaded by a CMS user a good idea?
You'll get some folks who will scream ABSOLUTELY NOT UNDER ANY CIRCUMSTANCE. These are the same people who say things like:
Using eval() is always evil. It's not always evil, but it's almost always unnecessary.
Using global or $_GLOBALS in PHP is evil. Again, it's only evil if you don't know what you are doing. And again, it's almost always unnecessary.
You should read that as a WARNING. Don't treat this issue lightly, if you are careful, you can do it, but if you are not, it can really bite you in the a**. That's reason enough for most people to stay away from it.
Before you decide for sure if you should or shouldn't allow users of your CMS solution to upload JavaScript snippets, you should ask yourself the following question:
Who will be allowed to upload JavaScript snippets?
If the only people who have access to this feature of uploading JavaScript modules are trusted system administrators, then you should consider it safe. I put that in italics because it's not really safe, but it does, at that point, fall on these trusted users to ensure that they don't upload something malicious.
Maybe you get Mary Neophyte, webmaster(amateur) extraordinaire who decides she wants a cool scriptlet on her CMS front page that displays the current weather in Anchorage, Alaska. She goes to Google, types in "JavaScript weather script", and arrives at Weather Channel. She decides their implementation is just too hard to install. She keeps looking. She arrives at Boris' Weather Script at http:/motherrussia.ru/ilovehackingidiots/weatherscript.html.
This isn't your fault when her CMS starts compromising her end users. She was the trusted administrator who uploaded a malicious script purposefully (though ignorantly). You shouldn't be held responsible for this type of behavior.
Long story short, you should be able to trust the trusted users of your CMS to be responsible enough to know what they are uploading. If they shoot themselves in the foot, that's not on you.
Allowing non-trusted users to upload JavaScript
This absolutely, positively, without a doubt is never something that you should do. It is impossible for you to screen every possible obfuscation that someone could upload.
I'm not even going to get into this further. Don't do it. Period.
Regarding HTML/CSS
Don't assume that malicious code can't make it onto your website via HTML/CSS. While HTML is much easier to sanitize than JavaScript, it can still be exploited to deliver undesired JavaScript to a page.
If you are only allowing trusted users to upload HTML/CSS, then don't worry too much about it. I stress again, It is Mary Neophyte's fault if she uploads Boris' Weather Script to her site. However, don't let Boris himself come to your website and start uploading anything that will get displayed on a web page to anyone but ol' Boris himself.
TL;DR
I'll summarize everything into two rules:
Don't allow untrusted users to upload anything that will be displayed to anyone other than themselves.
Don't let anyone upload anything at all that gets executed server-side.
Allowing custom JavaScript would probably be a very bad idea. That would make your site vulnerable to cross-site scripting attacks and allow it to be a vector for cross-site request forgery attacks against other sites.