I wanna know, is there a way to compress javascript with a method that cannot be easily uncompressed by another?
I have used some tools like jscompress and other products. They're nice and useful, but they provide methods to uncompress/decode script too. The problem is other programmer or maybe hacker, can easily uncompress my script, the impact is my js ajax link, variable can be seen by the hacker. You know that what happen if they found our link. Maybe post direct value via ajax etc.
There is not a way to do this in client side javascript, it is inherently insecure. You should be using a call on your server to hide your API key.
FAQs from the w3:
http://www.w3.org/Security/faq/wwwsf2.html
If by your question you mean that you do not want the variables and Ajax links in your script to even be accessed by others ever, then you are talking about encryption, not just compression.
If the code was truly encrypted so that the Ajax links were not recoverable, the browser could not decrypt and therefore not even execute the script.
Obfuscators will make your code fairly illegible, but you are not going to be able to hide destination URLs in Ajax calls from hackers. All one needs to do is look at the browser's developer tools and watch the network calls.
It's important to design your application with the assumption that users and hackers are able to see all the JavaScript. If you can keep it secure under these conditions, that's ideal.
So if the question is just about making your code hard to read, obfuscate. But the kind of security you seem to be asking about needs to be done server side.
Related
I want to write a PHP script which executes code on a foreign website just like using the JS-console on that webpage. I don't want the server to act like the client on that certain webpage.
To make it even more difficult, the JavaScript must be executed on a different frame (when executing the JavaScript manually I'd switch to the correct console by clicking on the specific Frame in the dropdown menu above the console (Chrome)).
If I try to do something nearly impossible here, please don't hesitate to tell me exactly that.
You should try to describe what your end goal is. You are probably going down the wrong path here. There is no way to add javascript to a page that you don't serve yourself.
If I understand what you mean (and more detail would really help here). You want to automate something that you can do manually on a browser yourself, by manually running javascript on a webpage (via the console). The only reason I can think you would want to do this is to trigger an Ajax request/API call or submit a form.
This is technically possible, but it would be better to look for an actual API that you can talk to directly; you could do this by inspecting the network tab of the developer tools, but if they don't have a public API you may have to do a fair amount to fake the request; and if anything changes on the server it could all stop working.
If they don't have an API that you can call, or if they have put measures in place. Then there is a good chance that you are trying to misuse a website; and they may well put further measures in place to stop you (this is why captchas exist).
If you can figure out the details of a request to send, then you could use CURL to make the request - this page may help: https://davidwalsh.name/curl-post
If you really still find that you need/want to actually run javascript on a remote page, then this is "browser automation", and while technically could be triggered from PHP - requires much more to make it possible. Selenium is primarily used to automate tests, but would allow you to do this: http://www.seleniumhq.org/ via JavascriptExecutor but I would recommend you do some futher searches for tutorials, as it's too large/broad to really cover here:
https://seleniumhq.github.io/selenium/docs/api/java/org/openqa/selenium/JavascriptExecutor.html
First of all, I've tried to look for answers in different questions and forums, but I've struggled to find the correct search keywords, so I haven't found anything relevant.
Basically, I've taken on developing a simple implementation of a live chat widget for websites, similar to olark, liveChat, etc. Since, I will be using Socket.IO, I am looking for an easy way to provide the javascript code to a potential client (which might very well not be tech savvy). So the idea is to have just a simple <script> tag which either dynamically creates another script tag with the source pointing to my server, or just a script tag with the correct source.
The problem I have is regarding the server response to that request. In the test implementation, I am adding a script tag which makes a call to the server and the server responds with the javascript code in a string, which I find a very crude way to do it. The reason why I can't just serve a simple javascript file is, because it needs to be personalized, so I can keep track of where the client is connecting from in order to get the to the proper "agent" (manager of website). I could probably create separate files for each user, but I am not sure how maintainable and efficient that would be.
So my question is, how would I serve this personalized javascript code in an efficient and secure way? I am using Laravel as a backend, if that makes any difference.
In the test implementation, I am adding a script tag which makes a call to the server and the server responds with the javascript code in a string, which I find a very crude way to do it.
If it works for your needs, this is a good solution.
If it feels crude, there are a few things which can help keep it clean. Keep your javascript in a separate file and use file_get_contents to read from that file. Where you need to use placeholders to personalize this, you can add %s and use sprintf to pop in the personalizations.
There are a few pretty large ad networks out there which are serving up javascript in just this fashion so I do not believe there is anything inherently wrong with this method.
As far as security goes, I'm not sure what you can do besides making sure everything is served via HTTPS. I'd hope that there is no need to pass sensitive information via get variables.
You can transmit just the javascript without a <script> tag to the client and then use eval() to run the code there.
Is it possible to not allow people view one of my website's JS file?
Demo:
http://js.maxmind.com/js/geoip.js
If you copy the URl and paste it in the browser, it will say "Unauthorized". But if you put it inside the HTML, it will do it's work.
Can I do that with my code.js file?
JavaScript is an interpreted computer programming language. It's not being compiled and it runs on the client's browser/computer, therefore, the client must see the script in order to execute it. That's why you cannot hide the code.
You can define in your server folders as restricted and that means the user can not access them directly, but when the browser loads the page it have to load all the components such as images, css files, js files etc...
If the browser can load them, it means the user can see them as well.
For example, you can also define that users are not authorized to see any .jpg files but they can easily save any image. Actually the browsers usually saves the images anyway on your local computer and cache them, so next time you load the page, it won't have to download files that weren't changed again.
As others already mentioned, trying to hide a js code is very bad practice and you need to avoid it. If you want the make the life hard for other developers that wants to copy your code you can use this site to obfuscate your js code, but remmeber, it only makes it harder to read by humans, it does not provide you any security.
First, let me explain loud and clear: that is the worst security I can imagine for what it is trying to do. It is just shouting, "HEY NOBODY LOOK AT THIS INSECURE FILE."
Your question has been viewed 41 times so far. That means up to 41 people are wondering what that mysterious does and probably half of them can find easily out. In short, don't do this.
There is no client side security. I refer you to this answer, for instance.
As for how to implement the situation, as noted in comment it's probably done by checking the referrer header. To find out fully check the request headers in the dev tools in your browser and compare to the request headers used by curl (e.g. by using a post bin).
It is not possible to not allow people to view one of your website's JS files.
To be more precise, if someone can execute your JS file, they can view it.
Although you cannot prevent a user from being able to look at your javascript you can make it extremely difficult for them to understand what they are looking at through obfuscation or minification, for the latter there are many services that will do this for you; look at this for example. As for obfuscation I don't know of any way to do it automatically but it would be a similar approach.
If you have information in the javascript that you truly cannot allow a user to see, then I would suggest moving it into the server side code and only pass to the javascript the absolute minimum. As I am not sure what you are using on the server side I cannot give you a specific example; however in the past when using MVC I achieved this by passing the values I needed either to a hidden input ( if the value needed to be posted back with a form) or through jQuery.Data
Okay, the title of this topic is really stupid - but I am not able to sum it up in a better way than that. So here is more detailed version of my problem:
I am creating a small JavaScript library that enables developers to send strings on custom events to a dedicated server (url defined in the library). Lets say the library is called "testLib", the developer that uses this library could write something like this:
function success() {
testLib.send("Everything OK");
}
So everytime this success function is called, a REST call (POST-request) is made to the server that is definded inside the library. So far, thats no problem.
But the ugly thing is that everyone with firebug or similar could call these "testLib.send()" method too. Thats really ugly, because the hole sense behind this library is to track only the events that the developer has defined. Of course, the server will take care of the basic validation (origin check, API key,..), but still: One could start firebug and just call the "testLib.send" method.
Is there any chance to build an authorization mechanism that prevent the "firebug user" from sending rest calls via the predefined library methods?
Nothing practical.
The library runs on the client's computer. You have no control over that. They can edit the JS to their heart's content. They can bypass it entirely and send hand-crafted HTTP requests if they want (or write a quick script to bomb the server with requests).
Any real protection you implement has to be on the server.
Writing Javascript is like writing open source. FireBug is but one of the plugins which can get into your script, modify it on the fly, invoke methods, access variables, etc. In fact, you don't have to go that far: The Javascript console in most browsers contains a quick eval input box. Because Javascript is an interpreter, anyone can get in and do as they wish.
You have two options which might make it a tad more difficult (though certainly NOT impassable):
1) Obfuscation and/or packing the script, when you are done - though most obfuscators can easily be bypassed
2) Having your methods check who called them - have a look at arguments.callee.caller for that. That said, this might run into problem in strict mode.
Your best bet is to repeat any validation in the server side, as you say. If the server side validation fails - this actually tells you something: Someone deliberately bypassed your Javascript, and you can deal with him accordingly.
Hope this helps
TG
Authenticating users
If you application authenticates a user when the page loads, then every request from the client side will come along with authentication cookie so basically you will be able to detect who the sender is.
Obfuscation and private closures
But if you'd like to prevent programmatic access to that particular function that your best bet is function closure to make that function private and inaccessible and some code obfuscation that prevents people from plainly rewriting the whole stuff. One great obfuscation is the Javascript packer with Base62 enabled.
But this kind of things will of course obfuscate your library, but publicly accessible functions would still be accessible.
Preventing anonymous users
However. If you'd like anonymous users to prevent from sending stuff to your server you can't do that really, but you can identify unauthorised requests, by having your functions to require some sort of a registration key that your developers (real users) would have, but anons wouldn't.
And maybe some other resources found on Google may help just a well. Just to scratch the surface. XHR for instance allows users to send username and password to authenticate the request which may be exactly what you're after. But you should know better since you have the library design not us.
No. Because javascript runs on the client side, there's nothing you can do to prevent someone from reading what the client is executing and executing it themselves. There are things you can do to obfuscate your calls, but this is security through obscurity - and shouldn't be relied on. If you want to make sure that ONLY the developer is making calls to your API, they would need to do it on the server side.
I'm modifying an existing web application that features the ability to administrate users who are able to log into the system. When modifying a user's details via a dialog, update data is sent to the server via AJAX. A few lines of javascript to then update the current page to reflect these changes is returned with the intention of being executed. This strikes me as poor form - isn't executing remotely acquired JS dangerous?
If I were to modify this, I would have the AJAX call that sends the updated information then call another function that gets the latest data from the server via AJAX (or just refresh the page, if I am feeling lazy). Is there any advantage (mainly security, but from an architectural perspective as well) to making this change, or am I being anal?
Assuming we're talking about eval used on non-json.
People will tell you all sorts of things, most of it has some basis in reality. I'd say one reason that is really understandable: it will make the code a nightmare to maintain and it will be very hard to trace bugs.
There are security concerns, a lot of people like to jump on the "javascript is the clients problem" bandwagon. I say if it comes from your site, it's your problem too.
In the end, there is no good reason I can think of to eval javascript from the server. Pass data from the server, and write the javascript on the client-side to react to that data.
All JS executed by the browser is remotely acquired.
The server that returned the JS/JSON via AJAX is the same server that returned the HTML that did the AJAX call in the first place.
It if's possible to do something bad, it can be done whether you eval the result of the AJAX call or not.
Personally, I don't see the issue. Sure, people say things such as "It allows code execution client-side" however if the potential attacker is able to affect that, then that's your problem - not the ability to modify the code.
Seriously, I think you have far more pressing concerns than that. I'd personally spend that 10 minutes or so reviewing your code and looking for flaws instead of working on an alternative to eval(). I think it'll improve your security a fair bit more.
Mike Samuel mentions MITM. I don't see why. If you're susceptible to a MITM attack then chances are that code can be injected straight into the initial HTML page (again, sure, slightly higher risk but is it really worth worrying about? Your choice.)
If a trusted developer wrote all of it and you protect it the way you do the rest of your HTML page, then no.
But even if it is JavaScript written by trusted developers, if it is served over HTTP, then an attacker can modify it in-flight because HTTP over free wireless is often susceptible to MITM.
This can be used to effectively install a keylogger in the current browser window to steal user passwords, redirect them to phishing pages, etc.
The attack might work like this:
Web page does a GET to http://example.com/foo.js.
Attacker modifies foo.js mid-flight to add JavaScript that does window.addEventListener("keypress", /* a keylogger that sends all keys to evil.com cross domain by image loading tricks */)
Browser loads modified JavaScript.
User enters a password in an <input type=password>.
Evil wins.
Since HTTPS (assuming no mixed content) is not susceptible to MITM, it is not vulnerable to this attack.
You probably don't want to just call another function after you send the data update because you could then display information that isn't true if an update fails. At least with the current model, your service can tailor the javascript based on whether or not the update was successful. You may want to consider having the service just return a true/false and have the call back function handle the updating of the UI.
Sort answer: Yes
Long answer: You should just send data for both security reasons and to keep your implementations separate.
Improperly sanitized user-submitted content or advertisements could inject code and get it run. Granted, this would have to be a targeted attack, but hey maybe you're working for a startup that's going to be the next Google or a forum system that's going to be the next vBulliten. Even if you have 10 users, security holes are still holes and are still bad for you and your users. Also, bad security advice left lying around SO will lead others to make bad decisions.
Do you really want to have to make sure the code you generate on the fly and send to the client is correct in all possible cases? What if someone else works on just one half of the system? Are they going to know every variable name to avoid stomping on? Just sending data is the best way to keep a 'small' change in your client/server communication from breaking everything in ways that aren't obvious and will take forever to debug.