Why should I use angular.js or other like js frameworks when I know they are not secured.
What I mean by security is:
All the code is written in pure javascript. The javascript can be edited in devtools or firebug. Something like form submission can be easily manipulated. Even if I try to do server side validations for all the http requests, I end up doing double the work.
How can I effectively use angularjs keeping above in mind?
Thanks.
All client side code is susceptible to modification. For that reason you don't put anything that needs to be secure into the client code. The client code should define the view elements for the end user and give them an easy means to communicate with the server. Regarding security 99% of this needs to be handled server side by appropriately protecting the data that is sensitive. In terms of server to client communication you need to use SSL. Angular has some things built in to help with security see $sce and ngSanitize but IMHO your back-end should be safe because anyone can re-write a front end or use a command line tool to send various curl requests at the server until something gives. The client code really has no need to contain anything proprietary outside of the client code itself if that's your concern you can use obfuscation tools but ultimately even compiled code can be decompiled or disassembled .
You should always do both client and server-side validation. No matter what library you're using, this is required. It shouldn't be seen as "double" the work. It's just "the work".
Even if you weren't using Angular (or another Javascript library), I could still use devtools to make a request via Javascript to your server - it still needs to handle it.
If you're worried about code security, you can use an obfuscation/minification tool.
Of course you should use minification js tool for your client side code if you worried about its logic. But keep in ming this:
Do not keep service info (like many id`s and etc.) on client
And always use both type of validation in dangerous places
Use crypto/tokens
Related
Lot of the time I end up repeating the code on the server as well as the client. Example I have a registration form; validations I do for required field, email address regex are same on the both server and the client. I ideally want to write code in one place and not repeat.
If you're using express.js, take a look at the express-expose module. It seems to do what you're looking for:
expose objects, functions, modules and more to client-side js
I am going to assume that you aren't talking about a node.js application (for that take a look at either now.js or express-expose).
In these cases, what I would recommend is to do as much server side as possible, as a client can disable javascript (the is a particularly strong point when dealing with validation). You could use ajax to hit up the server, run the code there, and return in javascript.
I'm looking for some solution of next problem: Now i'm developing an Rails app. I want to have possibility to code in Ruby at browser and then execute that code in my Rails app.
Are there some ready solutions?
UPD:
what about code highlighting?
what about Native Client?
https://github.com/codegram/rack-webconsole
Or you could simply pass the Ruby code to the server via post and call eval eval(CODE).
You should note that especially the second way is very insecure since it gives the executing code complete access to your system.
If this really has to be done "Locking Ruby in the Safe" could help secure it.
EDIT:
For syntax highlighting take a look at Code Mirror and ACE. Both are decent source code editors with ruby support.
There aren't really any real-world deployable solutions for this yet, but you might look at text/x-ruby as a proof of concept.
There's also the Cloud9 IDE which functions as a browser-based IDE, and will persist code back to your server to be run.
eval is what you are looking for. A user enters Ruby-code, which gets POSTed to your rails app. Inside your controller you will need to eval the submitted Ruby code.
But. You probably don't want this. If there really seems to be a need to evaluate and run user submitted code, you most probably will need to re-think the need for that feature. This is almost impossible to make secure. And even when you secure it from certain users, it can be exploited trough XSS; which can actually take over a server in no-time trough this "feature".
I've been looking at the API for Flattr, http://flattr.com/support/integrate/js , which has a cool way of accepting query variables for their JavaScript to load.
My question is, do most APIs use something other than JavaScript to accept these different variables for their services? EG:
Ruby on Rails
PHP
Python
Then these are parsed by the respective language and returned as outputted JavaScript to the requesting website?
Cheers
Javascript itself is totally capable of reading how it's embedded to the HTML it belongs to, by reading document.getElementsByTagName("script") and further parse/match their src attributes. Therefore, it's not a problem at all for it to further parse the query variables attached at the end, and dynamically (all in javascript, client side) load components within.
Any javascript libraries that allow you to pack the whole thing and deploy to your own web server should take this approach, since there's no server to handle the request anyways.
On the other hand, javascript libraries that are hosted on other sites that allow you to use (like YUI) MAY take the server approach like you mentioned.
In my personal experience, projects that I have worked on have used server side languages to deal with get params.
So a request might be /myjavascript.js?id=123123 The server side language would create the correct javascript for that request.
Keeping everything on the server side has the advantage of not allowing the user to see what is going on. If this isn't a problem for you, javascript is more than capable of handling different params.
In my experience it's fairly common that widgets embedded into others' sites gets their parameters by parsing them from their script tags. It makes the widget script static and self-contained and thus easier to distribute through eg. a fast CDN. Performance is important when you're going to convince someone else to add your javascript to their site as poor performance from the widget can make the entire site appear sluggish.
A better place to specify the parameters than query parameters would however be to specify them in the URL:s hash-part as that part isn't included when caches are checked and thus the script would have to be downloaded fewer times - which of course is good for performance, especially if the parameters might shift a lot.
When I say "Vanilla Coding", I am referring to websites that don't utilize server side coding (such as PHP, ASP, etc.), only HTML, JavaScript, and CSS.
I know that there are a plethora of sites that already exist that don't utilize (to my knowledge) any of the common, server side languages used by many others (PHP, ASP, etc.), but still function just fine!
I am confused! How do these sites continue to save login information, keep records, etc. etc. without using a server side scripting language? Is there something that I am missing? Can JavaScript access more (such as databases and local files) than what I thought it could?
EDIT
Turns out I've made a serious and shameful mistake in assuming that just because it ended with a .html extension that it was client-side only. That is okay though because I'm learning. Thanks so much for the help everybody!
Essentially, unless you have some sort of server-side programming, you don't stand a chance at making a site with any amount of functionality. To break it down for you:
What you can do without server-side scripting:
Serve static pages
What you need server-side scripting for:
Absolutely everything else
Even something so simple as keeping a site consistent and up to date is a nightmare on wheels without, at the very least, some some sort of management system that pre-generates the static pages to be served. (Technically, one could argue that Copy+Paste in Notepad counts as this.)
As has been mentioned elsewhere; obfuscating the true nature of precisely what system is being used is trivial; and having URLs ending in, say, .html while using PHP is no issue.
Edit: In the most perverse case I can think of off the top of my head, you could have a lighttpd server masquerading as an IIS server, serving pages generated by an offline renderer fed to it by a Perl FastCGI script, sent together with PHP signature heading and using a mix of .asp and .jsp file extensions.
Of course, noone would do something as silly as that. I think…
No client side script can access server side information (like a database) without some sort of server side communication (through something like ajax or the like)
If you really ( i mean really as in don't do it ) want to do logins and the like on clients side, you would have to make some sort of cookie that you store on the user's computer, also you would need a list of users (which anyone can read) to use against
This answer is very late but I leave this reply for anyone who may stumble upon it.
Using javascript/jQuery, and various APIs a simple site can be created only using client-side coding.
For instance, a simple shopping cart type of site can be created. I've done it before.
There are few (not many) strictly 100% jQuery based shopping cart solutions that are open-source.
How does the PG (pay gateway) get taken care of? You are limited to accepting payment through paypal, google checkout, and direct deposit.
What about allowing customers to leave comment? You can use API's like Disqus. What about chat support? Zopim is pretty handy.
How do you get notified when purchase is made? Paypal & google checkout notifies you.
What about sending mass email? Mail Chimp.
Personally, I almost always use WordPress or some other types of CMS but using only vanilla coding to build a simple site is not only feasible but very sensible in certain circumstances.
You're not going to see whether a site is using a server side language unless they let you see the file extensions. With URL rewriting, MVC patterns, etc., it's easy to hide, or even fake that information. Therefore, chances are very good that the sites that you think aren't using a server side language are actually using one.
Now, a site can save certain information in cookies, such as some basic preferences, but any authentication they appear to be doing wouldn't actually be doing anything without a server-side script accessing a database somewhere.
As a side note - I have worked on a site where the content was actually static, but made to look like a blog or CMS. It was an absolute nightmare and hugely error-prone.
What are these sites that you think aren't using server-side scripting?
Nowadays a lot of sites are using Javascript as a server side solution, Node.js being the most popular. Check out this list: https://github.com/joyent/node/wiki/Projects,-Applications,-and-Companies-Using-Node
I have got a particular requirement where some critical algorithms have to be handled in the client-side script and it got to be secured. Using javascript will just expose the algorithm. I am currently evaluating ways to secure the algorithm on the client script. Appreciate any suggestions and alternative approaches.
One option I am thinking about is to download a small applet to the local PC, get the calculations done in it and update the results back. Before deciding on this, I want to know if a client script itself can be made secure coz that would be much easier.
Thanks in advance!
You CANNOT secure anything on a client PC.
Everything you are doing client-side is crackable and spuffable.
That's the PC of the client. It will be doing anything the client has requested it to do.
Script is not secure, also what level of security do you need? If you download anything to the client the client will be able to look at the algorithim. Of course if you download a native dll, then decompiling it will be harder, the question is if this is good enough.
That an important thing most people miss when evaluating security nothing is trully 100% secure. Because your server admin could go in and steal the binaries off your server. And if your using third party hosting who knows who has access to the server.
The idea is to raise the bar. Do you want to prevent the average script kiddie? Obfuscate it, make it hard for them to understand the gain of understanding the algorithim might not justify the pain in trying to understand it.
The best that you can probally do is keep the algorithim on the server and expose it via a web service.
Everything that the end-user is controlling to 100% may be tampered with, and this is especially true with JavaScript that is so easily exposed.
You are going down the wrong path. You need to rethink your approach.
You could build a web-service containing the critical algorithm and call it from javascript.
Bottom line is, if someone wants your logic ... they will get it unless it is server-side and they never obtain it in any way.
What you want is a Javascript obfuscator
Nothing on the client side can be totally "secure".
Anything you make them download will have to be run on the client PC, and so can be analysed. If you have them download an applet or a native executable, it will still contain machine instructions that can be analysed at the very least to an assembly level.
Is there no way you can have the client upload the data to your server instead and perform the calculation on the server side?
It it's client-side, then it's not secure. Anything with critical security concerns should be done on the server.
An NPAPI plugin will execute on the client-side and make reverse-engineering much more difficult.... but of course a determined hacker will be able to reach-through...
Theoretically (and I mean this is a Comp.Sci. sense) this is possible. The cryptographical technique is known as "fully homomorphic encryption". For now, the method isn't practical yet. There are no compilers available that are able to transform your algorithm in its equivalent secure form.