I have a Backbone application which handles public and private stuff.
Public => Login, Registration, News, etc.
Private => Chatting, other user specific information.
To secure the entire application I have a session-based authentication mechanism in node.js. This mechanism secures the backend-api. Now the question is how I can secure the front-end.
How do I secure routes in Backbone
How could I secure modules (requireJs) in Backbone
One idea I had was to split up the front-end into public and private and the server decides if it grants access to the private-assets.
What other front-end-secure concepts are out there?
To make it more specific:
I want to check client-side if the user is authenticated and I want to restrict loading require-js modules to unauthenticated people (to save bandtwitch)
your server should provide an API to check if the current user (possibly via their cookies) it authenticated.
In backbone, on your routes/navigations you can check to see if your user is authenticated and then execute code or not (probably calling a requireJS module after the auth check).
To my knowledge there is no backbone thing that has the concept of user state. You could implement a setTimeout loop to request the auth state from your server, and then implement Backbone.Events on top of that to emit an event when the user is no authed, which your backbone app could listen to and then trigger the rendering of a login view, or route the user to a login page.
I mainly user couchdb for my backend, and it has a $.couch.session function that will let me know of the state of the current user's auth. you will most likely need to implement your own session function that hooks into your backend framework.
Related
I'm currently playing around with a KnockoutJS SPA template in ASP.NET Core 2.1, and I managed to implement an authorization flow exactly as this one which was made in Angular:
https://fullstackmark.com/post/13/jwt-authentication-with-aspnet-core-2-web-api-angular-5-net-core-identity-and-facebook-login
As you can see in their User front-end service, basically the only check for whether the user is logged in on the client side is the check if the "auth_token" key exists in the client's local storage:
https://github.com/mmacneil/AngularASPNETCore2WebApiAuth/blob/master/src/src/app/shared/services/user.service.ts
this.loggedIn = !!localStorage.getItem('auth_token');
// ?? not sure if this the best way to broadcast the status but seems to resolve issue on page refresh where auth status is lost in
// header component resulting in authed user nav links disappearing despite the fact user is still logged in
Simply put, anyone can open up the browser local storage and insert a random string with the "auth_token" key and they'll be able to see everything admin-related in the UI (even though they will fail on API requests).
Can someone suggest a better flow for this? Or is the only option to send a "log in request" to the API, whenever an admin page is "opened"?
P.S. I am relatively new to the authentication schemes front, should JWT perhaps not be used for client-side content validation?
Considering JWT best practices, all your validations should be done in your back-end, since any validation coded in your web app could be read by any of your clients, resulting in a huge security flaw: anyone would know how to create a valid JWT for your application.
Is it a big problem to be possible to see your admin-related UI, even without any data? Considering that all of the routes which can return sensitive data are protected by JWT authorization, if a user access any pages or parts of your UI which require data, they would trigger a request to retrieve it, which would probably return a 401 (Unauthorized) HTTP status, or similar. A common front-end practice in these situations is to erase client user data, and redirect to a login page.
So, a typical flow would be:
User inserts a fake access token into their storage
User opens an admin page/ui which uses sensitive data in any way (showing, using for any internal logic, etc)
Web app does a request to the API requesting data
API returns a response which will be interpreted as an authorization error
Web app receive the API response, erase user access token and redirect them to its login page
In most cases, this entire flow will happen fast enough to block your user to further interact and explore your web app.
Would be better if you provide more information about your scenario, so anyone could understand if your worries are something that needs to be considered and truly solved. However, in most cases, the behavior above is accepted.
I need to authenticate users in browser (not mobile app) using AWS Cognito with username/pass, not FB/google IdProviders.
There are a lot of docs but they seem to be separate blocks which either incomplete, do not fit the requirements or do not fit each others :(
I created Cognito User Pool, then Identity pool and tied the userPool to the idPool, then I stuck. Do not know which library to use and how to use it.
The closest I find are:
https://aws.amazon.com/sdk-for-browser/ but my experience is not enough to convert their FB samples to not-using FB
https://github.com/aws/aws-amplify but using this lib I'll have to study React/Angular from the very beginning (I'm not a front-end developer, sorry) and I have no clue how to convert their npm-based samples to front-end javascript (npm is for NodeJS thus back-end, isn't it?).
All I need is plain html form with username/pass, send the request to Cognito and a way to check during the next page load whether the password was correct. If it matters I will use AWS Lambda as back-end for processing future tasks.
How can I do it? Is there a tutorial/doc for my case?
Thank you.
You can use AWS Cognito UserPools Hosted UI for your use case. The simplest form of authentication is using the Implicit Grant.
For more information about setting up Hosted UI refer Add an App to Enable the Hosted Web UI.. This will create a UserPool where users can register them self (If you plan to restrict this, you will need to either add users using the AWS Web Console, Cognito UserPools or using their SDK)
The steps are as follows.
Set up Cognito Hosted UI and register your application domain. This will create the login/registration pages for you where each of this will have a unique URL. What you have to do is, if the user is not authenticated (Let's discuss how to detect it later), you need to redirect the user to the Login page.
In the Login URL, you also need to specify the redirect back URL to the application so that after a successful login, Cognito will redirect back the user to the application providing the token in a query string.
You can then access the id_token from inside the application and use it for querying the backend.
Since the id_token is a JWT token you can verify it at your Backend using the public key available at the Cognito token endpoint.
To implement the JWT verification, you can also refer Cognito JWT Token validator NodeJS module.
Note: If you need to keep the user's logged in for a longer time period (Than 1 hr), you might need to use the Code Grant flow which will return a Refresh Token, which could be used to retrieve new id_tokens programmatically.
I am relatively new to web-developing as well as using React.js and wanted to double-check on some security concerns:
Authentication
Assuming part of my app should not be accessible for unauthenticated users and I implement this by calling for example AWS Cognito and a conditional render:
{Auth ? <userPanel/> : <smthElse/>}
Is there any scope for client-side manipulation i.e, is there a way to access the userPanel component despite being rejected by Cognito?
Authorisation
Furthermore, if I have different user groups (user, admin etc), what would be a safe way to restrict different parts of the App? Some options i have come up with so far:
Same as above, with directly calling the Cognito API and a conditional render
Maybe there is way to make the Redux state temper-proof and to use it in combination with private react-router-dom routes
Use private routes in combination with direct calls to the Cognito API
Thanks
Client-side authentication/authorisation is impossible and should be avoided.
The front-end should not be bundled with any sensitive data.
Secure your API endpoints instead, so that even if users edit the source to render the component/page, they will not see any sensitive data rendered unless they are authorised.
Nothing on client side is tamper proof. I think your solution is fine as long as you're performing a back-end validation as well, before rendering the page.
If you're really concerned that this might be changed from the client side, I would suggest setting up an entirely different route for authenticated vs non-authenticated users
I currently have a React-Redux Application.
I want to create an admin user in React-Redux.
If I create a state with userAdmin true or false will users be able to access the state and change this value? That is to say, is this a secure method of creating such access?
I am using webpack to create a bundle.js, and have a node.js server for serving data that is secured using JWTs.
Furthermore, is there a standard or semi-standard pattern for creating an admin user in a react-redux application?
My thoughts on this are:
Create a separate app for admin user management.
Create a state for the admin user and if that state is true then query the serverAPI for any admin action. But show the admin capability only if that state is true eg. delete other users, view details of users, but do not serve that data without an authorised API call. Then if the state is changed surreptitiously the user can only see the actions but is not able to access the API without the required authorisation.
tldr: your thoughts are correct
You are right in the assumption that the user could manipulate the state of the client side app to escalate her privileges. However, that shouldn't give any useful benefits if your architecture is done right.
Data that only admins should have access to shouldn't be transmitted to a regular user in the first place and changes that only admins should be able to do should only be accepted with JWTs that identify admin users.
Right management is something that has to happen server side. The client app just reflects that in the UI.
Let me first start by saying that I realize that this is very similar to many other questions about service access control but I can't seem to find one response that is relevant on all of the points below, so I am asking (possibly) again.
Some background:
I am building a web application with .NET that is protected by a custom forms authentication implementation. This same app (within the same domain) needs to leverage several REST services related to data management from within JavaScript/jQuery as many of the app's functions are not well suited to post back use in the forms.
I am trying to determine the most secure way to implement access control for the REST service based on the authentication done server side when the app was first accessed.
Here is an example use case for what I am describing:
user logs into asp.net site using forms authentication and upon successful authentication the user is taken to the landing page of the application
the user chooses to access a page at ~/Users.aspx from a link on the landing page, which forms auth allows based on the cookie created by the authentication in step 1
users.aspx loads some basic HTML elements, like an empty table and a hidden field that contains a token (GUID) generated at page load. The token in the hidden field is used by JavaScript to access a REST service that retrieves data to populate the table. The token is stored in a database with a pre-defined expiration.
when the REST service is called with the token it is checked for expiration and used to determine the user making the call and provide authorization to the data being accessed from the database, if the user is authorized to access/update the data the service performs the requested service operation, extends the expiration on the token, and returns a response.
I know that the token would be visible to someone sniffing the request/response on the network unless SSL is used to encrypt the transmission, so SSL is used to counter this.
My question is:
Are there other attacks that the service would be vulnerable to?
is there a better way to handle authorization and user identification for the REST service based on the server side login other than a statically assigned token for the service? It seems to me that the statically assigned user token would be less secure since it would give endless access to the service if it were obtained by a malicious user.
assuming the answer to #2 is no, is there a better way to transmit the token to the client and store it there for the life of the page use knowing that it needs to be accessible from JavaScript/jQuery?