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.
Related
I am creating a website which until now is pure PHP. I was thinking that since very few people do not have JavaScript enabled (which I wonder why!) maybe I should create my website as a fully PHP site without any AJAX. Am I thinking wrong?
Just to be sure, if I implement some AJAX would it increase the risk of my site getting breached?
Should I be even worried about this and start using AJAX?
AJAX itself will not increase or decrease the security of your site, at least if its implementation is elaborate. The client (browser) will have turned JavaScript on or off. If it is turned on, there may be more insecurities on the client side, but this won't affect your server and hence your site.
Nevertheless, you should of course implement your AJAX entry points securely (this server side files that are accessed by AJAX requests). Two of the most important rules of thumb you should keep in mind are:
Treat every user input (whether coming in via AJAX or not) as potentially "evil" and therefore validate it thoroughly and use database escaping, ... Do NOT rely on client-side validation only!
A good website should offer all the possibilities accessible with javascript enabled also without it. Surely, this is not always possible, but one should try it at least.
I would suggest using a framework (depending on what background technology you are using, like PHP, Java, Perl) supporting AJAX, which will make the whole thing much easier for you. Also, you should maybe search for something like "securing AJAX applications" to get more detailed information on the topic.
Ajax is not inherently secure or insecure.
It does however open up 'opportunities' for insecure code. A mistake I commonly see is as follows:
The user is authenticated in code-behind when the page is loaded
A user id or other credentials are rendered out and picked up by JavaScript
These (totally unauthenticated) credentials are sent back over the wire by Ajax and not checked server side. Very easily hacked even with a simple tool like Fiddler!
You must apply the same level of security to your web methods/web API as you would elsewhere in your site. If you do, Ajax should be no more or less secure than 'regular' web pages. Things to watch out for include:
Proper authentication and authorisation checks in your web services or API
Anti-SQL injection measures
HTTPS if transmitting personal or sensitive data
Ajax makes websites more responsive and is pervasive across the modern web. Take care with security, and degrade gracefully for non-JS-enabled visitors if you expect a significant number of visitors to have JavaScript turned off or if any lost visitor is not acceptable to you, and you should have nothing to fear.
I am creating a website which until now is pure PHP. I was thinking
that since very few people do not have JavaScript enabled (which I
wonder why!) maybe I should create my website as a fully PHP site
without any AJAX. Am I thinking wrong?
I would say most people do have JavaScript enabled. Probably 2% at most have it disabled according to this post from 2012.
Just to be sure, if I implement some AJAX would it increase the risk
of my site getting breached?
Yes, technically it does. More code = more chance of bugs, and security bugs will be a subset of these.
You will also be increasing the attack surface of your application, as you will be generally be implementing more server-side handlers for user actions to be executed asynchronously.
There is also more chance of client side bugs being prevalent such as XSS (particularly more chance of DOM based XSS bugs sneaking in there).
Should I be even worried about this and start using AJAX?
You should be "rightfully concerned" rather than worried. The increased risk is considered acceptable by most sites, even high security systems such as banking applications. If implemented correctly it is possible for your site to remain "just as secure" as it was without AJAX.
As with anything web-based, pay particular attention to the OWASP Top 10 and follow secure coding practices to minimise the risks. It is always advisable to get a security assessment carried out by an external company to pickup anything you've missed, although this can be expensive.
I am new to webapps, so I apologize if this question seems naive, just looking to learn. I'm looking into using elasticsearch for autocomplete. All of the examples that I've seen show some form of jquery/ajax/angularjs that exposes the elasticsearch url to the user which seems like poor practice. What is the proper way of safeguarding the servers url, while still allowing ajax to make a call (even if indirectly) to it?
In the AJAX world, there is no way to secure the server URL. And that's ok; security by obscurity is not a good practice anyway. What you need to do is make sure your server can't be hacked through that URL. A couple of tips:
Disable scripting in ES. The newer versions of ES have it disabled by default out of the box.
Don't expose your bare ES server to the world. By default ES is available on port 9200, which means anyone can run any query (or do anything else they want). Make sure that port is blocked from external access. As one commenter pointed out, the Javascript should be calling your server, which should in turn be calling the ES server as localhost (again, be sure localhost:9200 is blocked from external access) or behind a firewall.
Clean up all input queries before passing them to ES. ES is less vulnerable than SQL to "injection" attacks, but it is still critical to filter out any nasty characters such as \ { " : and so forth, to limit string lengths to something reasonable, etc.
Good luck!
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've been trying to learn a little about SproutCore, following the "Todos" tutorial, and I have a couple of questions that haven't been able to find online.
SproutCore is supposed to move all of the business logic to the client. How is that not insecure? A malicious user could easily tamper with the code (since it's all on the client) and change the way the app behaves. How am I wrong here?
SproutCore uses "DataStores", and some of them can be remote. How can I avoid that a malicious user does not interact with the backend on his own? Using some sort of API key wouldn't work since the code is on the client side. Is there some sort of convention here? Any ideas? This really bugs me.
Thanks in advance!
PS: Anyone thinks Cappuccino is a better alternative? I decided to go with SproutCore because the documentation on Cappuccino seemed pretty bad, although SproutCore's doesn't get any better.
Ian
your concerns are valid. The thing is, they apply to all client side code, no matter what framework. So:
Web applications are complicated things. Moving processing to the client is a good thing, because it speeds up the responsiveness of the application. However, it is imperative that the server validate all data inputs, just like in any other web application.
Additionally, all web applications should use the well known authentication/authorization paradigms that are prevalent in system security. Authentication means you must verify that the user is who they say they are, and they can use the system, with Authorization means that the server must verify that the user can do what they are trying e.g. can they create a new data entry, or edit an existing one. It is good design to not present users with UI options that they are not allowed to perform, but you should not rely on that.
All web applications must do those things.
With respect to the 'interacting with the back end' concern: Again, all web applications have this concern. You can open up firebug/webkit, and look at all the the xhr requests that RIAs use in their operations, and mimic them to try to do something on that system. Again, this concern is dealt with by the authentication/authorization checks that you must implement. Anybody can use any webclient to send a request to the server. It is up to the developer to validate that request.
The DataSources in SproutCore are just an abstraction around how SC apps interact with the server. At the end of the day, however, all SC is doing is making XHR requests to the server, like any other RIA.
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.