how to restrict user from accessing page like profile,change password in URL before login session begin for user
example : localhost/profile is access able even though user is not looggd in. how do i restrict it
Official guide has a good explanation about your case. You can check out the following page; you can make use of willTransition, beforeModel and similar hooks provided from route as described.
First I'd like to note that all security must be implemented on server side first, because client side (ember app in this case) is very vulnerable.
As for your question, I recommend to use ember-simple-auth addon. It does exactly what you need.
Related
I am still new to Angular apps and wonder about some security concerns and would appreciate some tips on how to handle this.
Lets say I access my Amazon S3 Server from my Angular Application. That for I need to write somewhere my bucketname, accesskey and secret key... but since it is all visible to the user everybody can see the secret key which does not make him anymore secret of course.
I can also not use something like a SALT etc. to create user passwords for the same reason. All is visible in the end and even with minify and uglify anybody can reverse it as well.
What is the best approach to do things like this? So far I can only think of one thing and this is to not use javascript or angular at all in this cases and for example only access my S3 bucket via PHP. But this cant be the only way I hope?
For Firebase it looks the same problematic since everybody can see all infos right away and can connect basically to my DB and than add for example information he want to. Of course I can setup rules and make certain things obligated but this can be also sniffed out easy inside my code at the end which seems all pretty unsafe if I compare this to a php/mysql backend.
You can use the Cordova SecureStorage plugin to store access and/or session tokens:
https://github.com/Crypho/cordova-plugin-secure-storage
Since the Android implementation of this secure storage uses the KeyStore, the users must have a secure screen-lock set (like fingerprint, pattern or PIN). The plugin provides functions to check this, so you will be able to give a warning (or block login) if this is not the case. Without a locked screen there is no way to save your keys in a secure way on Android.
I just installed the MEAN stack (MongoDB, Express.js, AngularJS, Node.js) and opened up the example program (as found on mean.io) and they have a basic app that you can login to and create blog "articles" just for testing and such.
Anyway, I removed the '#!' from the URL and it outputted the entire user and article models as they are in the database. It seams as though doing that made it stop routing through Angular and instead used the Express routes which are just JSON REST apis. Is this a flaw in the MEAN stack package, Angular as a whole, or maybe just a development environment setting? I can't imagine that this would be released with a huge flaw like that but maybe I'm just missing something..
Replicateable steps:
Follow installation instructions on http://mean.io
Goto your local app in the browser and create an account and login
Create an article
View the article item you just created and remove the #!/ from the URL, you then see the JSON object of your logged in user account
complete with hashed password and salt, as well as the article
object.
Its just an app configuration. If you change the routes.js from:
app.get('/articles', articles.all);
to
app.get('/articles', auth.requiresLogin, articles.all);
Then if you try and hit the url /articles directly you get the message:
"User is not authorized"
Instead of JSON listing all the articles.
As you say, removing the #! causes the routing to be handled by the server. The node API then dumps the user object in the response.
The problem is completely independent from Angular - the app is only served by Node at the / route. Angular then uses the hash value to show the correct page.
This is probably just a problem with the example provided by MEAN. The app itself is insecure, when they talk about best practices that refers to the code structure and setup rather than the quick demo.
You could ask them about it, since there will probably be people who build on top of the example and don't fix the security issues.
I'm developing a new web site that will be a single paged app with some dialog/modal windows. I want to use backbone for frontend. This will call backend using ajax/websockets
and render the resulting json using templates.
As a backend I'll use nodejs express app, that will return the json needed for client, it'll be some kind of api. This will not use server side views.
Client will use facebook, twitter, etc. for authentication and maybe custom registration form.
Client static resources, such as css, js, and html files will be handled by nginx (CDN later).
Questions that I have now:
How can I determine that a given user has the right to do some action in api(i.e. delete a building, create new building)? This is authorization question, I thought of giving user a role when they login and based on it determine their rights. Will this work?
Similar to the above question, will this role based security be enough to secure the api? Or I need to add something like tokens or request signing?
Is this architecture acceptable or I'm over engineering and complicating it?
Passport is an option for the authentication piece of the puzzle. I'm the developer, so feel free to ask me any questions if you use it.
I thought of giving user a role when they login and based on it determine their rights. Will this work?
Yes this will work. You can check for a certain role on the user after it's been fetched from the server. You can then display different UI elements depending on this role.
Will this role based security be enough to secure the api? Or I need to add something like tokens or request signing?
It wont be enough. Anyone could hop into the console and set something like user.admin = true. In your API you'll need to validate a user token from the request, making sure that the related user has the appropriate permissions.
Is this architecture acceptable or I'm over engineering and complicating it?
At the least you should have an API validation layer. That would make a decent enough start, and wouldn't be over-engineering.
For the authentication part of your question i would use everyauth which is an authentication middleware for connect/express. It supports almost every oauth-social-network-thingie.
For role management you could give node-roles a try. I didn't use it myself but it should help you out, because it checks the role on the server side. Of course that is only useful if your API is implemented in node.js. If that's not the case, you have to "proxy" the API calls over your node.js app.
I hope I could help you! :)
I'm trying to make a Twitter client with Adobe AIR, how can I successfully use OAuth with Javascript? I mean, I've used jsOauth but it seems to lack the oauth_signature somewhere...
One thing you can try is you can use the approach that is described in the Facebook developers section dedicated to authentication. You want the section that is called "Client-side flow".
In a nutshell they propose that you make an application that will redirect the page it is loaded in to a special URI with it's app_id and backurl in the query parameters. Once Facebook manages your app's permissions, it will redirect the user back to your page with a special access token in a URI fragment, e.g. http://example.com/my_app_page/#token=foobar. This way only your script on the client side can access this token and use it to make requests to the Facebook API.
go have a look at streamie, a twitter client based on node.js. In the source, you can find an extremly good implementation. It's done by cramforce. You find it on github:
https://github.com/cramforce/streamie
jsOAuth uses the Authorization header to pass the OAuth relevant data to the API service.
If you are having issues, by all means email me I'll be happy to look at your code. jsOAuth isn't flawless, I'm fixing bugs as they come up.
Theres a boiler plate for PIN based client auth here: https://gist.github.com/1071227
I developed an application in ASP.NET MVC. This app has an action that returns a JsonResult and I get it with jquery in client side. Everything works fine but I'd like to know, if is there any way to make a security in this action to return only requests that came from my website.
Is there any way to avoid others websites to request this action? Or avoid javascript in address bar (script injection) ?
Thanks
Short answer: No
Long answer: The only way to know that a request is legitimate is to interpret what's coming with the request. There's no magic in the http protocol. Probably, the most reliable way is to check the referrer and ensure that it's your site. But it's not hard to fool that check..
I have not tried this yet but have been thinking about how I might achieve this as well. My current thoughts are to add a custom attribute to the action that checks a token appended to the cal by the requesting application.
The token would be generated by the calling application based on a seed key that was provided to the requester upon applying to use the API. The custom attribute would authenticate the key before the action ran either allowing or denying the call.
As I said not fully formed yet but was thinking along these lines ... good luck and if you come up with something make sure you post back.
For other sites:
You can check the referrer, but that can be spoofed.
You can check to see if you have an active session with the user.
For the address bar:
There is nothing you can really do about that.
Others Websites can't make requests to your action using ajax because HTTP doesn't allow it, but it can still get called from the address bar, other program or anything.
If you whant to allow calls to your action only from specific parts of your website you can use the the html helper AntiForgeryToken and the attribute [ValidateAntiForgeryToken], you can check a tutorial about this over here: http://haacked.com/archive/2009/04/02/anatomy-of-csrf-attack.aspx. It's pretty much the idea abarr posted.