I’ve always been having this problem in mind and always went with the easier more solution of doing it on the server. However, I decided I can ask more people about it, may be one of the enlightened can help me with a reliable solution.
Problem: you’re developing a web application that servers many users. Part of the features you offer involves calling an external API. That call is done for each user. The call can be made by either your server or the browser’s JavaScript. In either cases you persist the result of processing the data from the API call in the server’s database. I would like to offload calling the API and processing the results to the browser’s JavaScript and after it finishes it will callback the server with the data to persist. The problem that I see with this approach is that anyone can modify that JavaScript’s behavior (how easy is that thnx to firebug and its likes) to persist malicious/incorrect data on the server.
How can I - the server - trust that the data coming to me from JavaScript - following the previous scenario - is correct and not altered?
The simple answer is you can't, JavaScript is the least secure mechanism in the pipeline - the easiest to manipulate. If you want it to be secure, you should never rely on JavaScript for it.
Think of it in a more general sense: you can only secure an environment you at least somewhat control...you have no control over the browser, the JavaScript engine, or the user manipulating it.
Always validate server-side, always, always, always.
If you want to create some data on server A, give it to a client, and have that client pass it to server B verbatim, then you simply need to include an anti-tamper hash with it. Server A and B share a secret which they use as salt. As the client doesn't know this salt, it is unable to fabricate authentic data for itself.
Note that on its own, this technique only gives a strong degree of confidence that server A originated the data. There are other vulnerabilities you may need to consider, such as replay attacks of old data etc.
Related
Today I checked a source code of one of the websites done in Angular and I wondered if it is a good practice to display bits like below available for everyone to see.
ul class="nav-account desktop-only" ng-show="!User.isAuthenticated" ng-cloak
I understand it is safe in terms of back-end because I cannot set these parameters but I just wondered if this is a good practice or is there any alternative?
The client side is never secure, and can never be trusted. Validations on the client side are highly recommended, while the server side MUST be validated and secured.
So examples like these are generally "ok" if any actions sent to the server are authorized anyway. It will just fail.
There is no alternative. You can go and also see all the code for the controllers, directives and provides. Probably it is minified but a good it will make that readable again.
This is always anywhere the case if you give software to your client – you always do.
And even if you managed to obfuscate the code in a way nobody can ever read it again, the user could use a tool to simply log all request to the server made from his computer.
You cannot protect against your users. The only way to protect your service is to write a stable and secure API. (validate everything, send secure authentication tokens, protect against brute force)
Just as an example:
Apple does not try to hide their Angular directives. They are not even minified.
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 want to develop a game in NodeJS but i'm not sure how much 'easily' hackable it is. For example if i write my game rules in PHP modifing them will need the hacker to actually get access to the server, instead if my rules where in javascript anyone could easily rewrite the rules as they want.
More over if the game would involve people discovering rules as they play how could i prevent those rules to be there for anyone just by looking at the code.
The actual code of your Node.js app will remain unexposed. Ideally, your client (whatever you're doing on the browser side of things, whether this is rendering html elements or using html5 canvas) will only handle I/O and update your server, while your server will take care of all logic.
You can still use javascript client side, but keep in mind that your fear is legitimate concerning client side javascript. This is why it is common practice to separate input/output code (which happens in javascript on the client) from game logic code that happens on the server. So the worst thing someone would be able to do is to send a message to your server saying they are pressing every key at once, and you can filter for things like this.
Developing in nodejs means javascript on server. Javascript code on server which your players will not be able to see unless you open-source your game. This code won't be exposed to your players.
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.
Is it possible to insert data in a database using javascript only.
if yes then please post a simple example of it.
Since javascript is a client side language and not a server side,i think its not possible.
But then how to do it.
It is possible if you are using CouchDb
http://couchdb.apache.org/
Apache CouchDB is a document-oriented
database that can be queried and
indexed in a MapReduce fashion using
JavaScript. CouchDB also offers
incremental replication with
bi-directional conflict detection and
resolution.
Not directly.
Any server-side language could be made to do this.
Allowing end users to craft database queries however is just asking for it in the worst way.
The short answer is "no", javascript is a client side language, and has no ability to connect to a DB.
HOWEVER, the long answer is 'yes, but...'. There are a number of socket-libraries available in javascript (though most I saw seem to involve some flash/java trickery). Therefore, one could connect to the sql database (which would have the obvious security flaw) and submit the record from there.
It would be POSSIBLE, but absolutely stupid, difficult, and insecure.
Google: 'javascript odbc access'
First result
http://forums.asp.net/t/1285316.aspx
It IS possible. Though I don't know why you would want to do it. The code makes me think of when I did coding in ASP with ODBC support.
No you can't simply do that.
Javascript was created for Client Side which means it can be effective at Client Side.
You can use HTTP Scripting technologies to exchange data between Server side and Client Side, for example Ajax would be nice practice.
Javascript can post data to server but there must be a back-end that can evaluate the data posted by Javascript.
I don't know but maybe later they will be such a technique or tech.
Yes, it would be possible to create the ActiveX objects that could connect to the database and execute a query.
No, I won't post an example. Putting the code in Javascript means that anyone can just view the code and get the connection string, getting access to view and edit your database. Let's just say that the TTL for the database would get really short...
Javascript is primarily a client-side language and has no access to a database without the use of a server side language to supplement it.
It is possible to use AJAX to post the data to the server, which would prevent the page from posting back, giving the appearance that the javascript had performed the action. But inevitably you will need something like ASP.NET, PHP, Ruby, ect. to capture the data and persist it to the database.
EDIT: Although not what I would consider a true database, there is a library called Taffy DB which is a client-side javascript database. Keep in mind that it is an in-memory database and it does not persist data to the server, so the data will be gone as soon as the user closes their browser. The Taffy DB FAQ covers it's ability to persist the data pretty well.