What are the possible security risks one may face while developing a backbone app.Can someone tell me the best practices to mitigate such risks.
as in the router any users can find out the services being called
The secret to securing a Backbone app, or any other client, is that you don't rely on client-side validation. Be sure to validate on the server.
For example, if you were building a banking app, you wouldn't use Backbone to transfer $100 between a user's accounts and then send back to the server the new account balances as model updates. You would instead send to the server the user's intent to transfer $100 and let the server send back the new balances. This way the server can safely determine the user's authorization to make such a transfer between accounts, determine if sufficient funds exist, etc..
Client-side validation is nice to help reduce round-trips and give immediate feedback to the user, but it shouldn't be thought of as a method for securing an app. E.g. Validate the format of an email address or the strength of a password on the client before sending it to the server (where it should be validated again server-side) is a good example of client-side validation.
As for web services, there are different ways to protect them. You can use HTTPS or token-based authentication just for example.
Another issue might be that you expose too much data. For example: don't return a full user record (to populate your models) but instead only return the data actually required for your application.
I've seen examples where (hashed) passwords were sent to the client.
Something to consider when you are securing a backbone app is the access to the app itself.
Build an authentication page where the user enter his login/password then if the authentication is verified, set a cokkie session ID.
For example if you have a main view rendered on http://mydomain.com/app, you have to secure the access to the "/app" by using a cookies validation.
Example if your back-end is nodejs :
app.get('/app', function(req, res, next){
if(!loggedIn(req,res))
sendError(res);
else
next();
});
what loggedIn will fo is basically check if you have a sessionID in your cookies. If yes it will allow you to access your app otherwise an "unauthorised access" message will be prompted to the user.
As mentioned earlier, client side validation is important but you have to re-enforce it by using server side validation.
HTTPS for the web services is also important.
Related
I have a web application, where the frontend is built with react.js and typescript and the backend is build with ASP.NET Core 3.1 and connected to a SQL Server. The SQL Server is used for saving data, which I can enter in the frontend.
Now I want to implement a custom authentication system, where I can protect different endpoints with an authorization. I know there are several ways to go for, but I don't want to use a service / library, where a user could login with his google account for example.
Jwt seems in my Opinion a good way to go here, but I really don't understand the whole system.
This article helped me already a lot: Implementing authentication and authorization with React hooks, .NET Core Web API, and SQL Server .After reading this, I don't understand the relationship between logging in and how my backend knows, that a user is logged in (for protecting my endpoints).
Of course I already read many articles about authentication and authorization for ASP.NET Core. I've read about different services like:
Auth0 (seems not a good idea, because you can login with google etc.)
IdentityUI (seems good, I've seen a few youtube tutorials but they are all using another project structure, where the frontend and backend isn't separated. So they are using the razor pages like Login.cshtml, but I don't want to render any pages in the backend, only in the frontend)
For authorization for my controller in the backend, I planned to use the following:
[Authorize] // to protect endpoint
[HttpGet]
public async Task<IEnumerable<>> GetData()
{
// some code
}
But as I already said: I don't know / understand how my backend knows if a user is logged in (and how to check it).
Could somebody provide me an appropriate tutorial or an article, where is explained, how to manage authorization and authentication for frontend and backend? Or maybe somebody knows, how to use the IdentityUI with a frontend build with react + typescript and a backend, which shouldn't render any pages.
Thanks for your attention :)
Well... for detailed flow how they work, here is RFC 6749, this is a pretty comprehensive collection of knowledge related to the topic and the easiest approach would be wiki page in general.
But to simplify the process, just get to know these things:
What is JWT
Jwt just a string that was generated by some algorithm from a public/private key pair(don't even care how it works, just give it a key pair, some lib on every language would do the rest). This JWT often contain all the information that needed to specify who the user is(big word right ? but actually, userId is enough for simple case).
It contain 3 different parts Header, Payload and Signature, and the string assured it cannot be interrupted(or just modify it as we wish, and the validation process would failed).
Further detail here.
What happen on server side?
The most basically flow was send user, password to server for validate who we are and our account exists. Then, server side would take some necessary info out of it to generate the JWT token. The server which generate JWT token was normally refer to Identity Provider.
Then that token was send back to client, and client save it somewhere for later use.
Client side use token to request other resource
Normally, Identity Provider would provide a .wellknow endpoint that contain all necessary info for other resources to gather for validation process.
Now, client side send a http request to these resources with the JWT token. They use info gathered from .wellknow endpoint to validate was the JWT valid. If it is, we are who we claim we are, authentication process success.
The end.
Over-simplyfied flow imagination in your specific case
React Client => Request login => Identity Provider => Jwt Token send back => React client save it somewhere.
React Client => Request some resource over http with the JWT token => Resource server validate it (through info from .wellknow endpoint) => Authentication success or fail => normal process => send response back to client.
I'm developing simple CRUD app in react and express. Now, When user SignIn, I store the userId(from database) and JWT(web token) in localstorage and I use this userId and token to check isSignin() and isAuthenticated() for future API calls. Now, If I deploy or make production build of this application, the user info will be clearly visible in my localstorage and it can be threat to my security. Can anyone please tell me how to hide this information and implement these mathods in production ready app? I want deploy it on AWS. Because, I've seen on so many website, we cannot see our own userId other credentials in our own localstorage.
here my methods. The req are coming from front end in react and as soon as I am getting response to front-end my react code is storing that in localstorage.
exports.isSignedIn = expressJwt({
secret: process.env.SECRET,
userProperty: "auth"
});
exports.isAuthenticated = (req, res, next) => {
let checker = req.profile && req.auth && req.profile._id == req.auth._id;
if (!checker) {
return res.status(403).json({
error: "ACCESS DENIED"
});
}
next();
};
Randall Degges gave a very detailed explanation about why you shouldn't use localstorage to store sensitive data. I will point out the main part.
If you need to store sensitive data, you should always use a
server-side session. Sensitive data includes:
User IDs, Session IDs, JWTs, Personal information, Credit card information,
API keys, And anything else you wouldn't want to publicly share on
Facebook If you need to store sensitive data, here's how to do it:
When a user logs into your website, create a session identifier for
them and store it in a cryptographically signed cookie. If you're
using a web framework, look up “how to create a user session using
cookies” and follow that guide.
Make sure that whatever cookie library your web framework uses is
setting the httpOnly cookie flag. This flag makes it impossible for a
browser to read any cookies, which is required in order to safely use
server-side sessions with cookies. Read Jeff Atwood's article for more
information. He's the man.
Make sure that your cookie library also sets the SameSite=strict
cookie flag (to prevent CSRF attacks), as well as the secure=true flag
(to ensure cookies can only be set over an encrypted connection).
Each time a user makes a request to your site, use their session ID
(extracted from the cookie they send to you) to retrieve their account
details from either a database or a cache (depending on how large your
website is)
Once you have the user's account info pulled up and verified, feel
free to pull any associated sensitive data along with it
This pattern is simple, straightforward, and most importantly: secure.
And yes, you can most definitely scale up a large website using this
pattern. Don't tell me that JWTs are “stateless” and “fast” and you
have to use local storage to store them: you're wrong!
Source/Read more: Please Stop Using Local Storage
I'm a back-end developer who has to create the front-end too in the current project!
I'm using reactJs and I know that for authorizing users I should get an api_token from my back-end API then use the api_token in the next requests! so I should store the api_token (actually somewhere into the client's browser)! but where should I store it to be secure?
the first answer came to my mind was 'Local Storage' ! but I've read this article: Don't store tokens in local storage
I've searched and found #auth0/auth0-spa-js, but I don't know can I trust this package (and similar) or not?
these are the way's which I've found! but what's the correct way to store sensitive data like this?
The Auth Flow should be on the Web should be
Send User/Password Details to server
Server validates and returns encrypted token with some details inside and that's stored as a HTTP Cookie
Setup Protected endpoints so only users with token can access them
Security : HTTP Cookie only means that the browser doesn't have access to it on the client, only the server. But someone can simply just Copy Paste it into their cookies which if you're worried about or working on sensitive stuff, you will need to implement additional security measures such as the ones mentioned.
Generally, Device Management is not a web concern but you can also some validation on the token for things like make the token expire in 5 minutes, or expire on session end, DeviceId, Browser Id, IP address, send them an email that a new unknown IP has logged in, etc.
Never store private tokens in your frontend code
You should create a server that can only be accessed from a particular url (the url of your app). This server can have the secret tokens that you need to make calls. The that server can forward requests to the services you will use that need private tokens.
I have developed a single page AngularJS application. For data retrieval/storage, it communicates with REST APIs over https. As per client requirement, i need to implement Client Authentication. i.e., As the application is based on REST APIs, how can we ensure that the request made to API is from a valid client and not from fiddler or a tempered client.
the current approach is:
1> configure a client secret and a key in the angular app.
2> authenticate the client by requesting a token from server using this client secret and key.
3> server checks this secret and key, if validates, responds with a newly generated token.
4> all further requests from angularjs app would carry this token in header, to ensure that the request is from a valid client.
But it is not good enough, as attacker can easily capture the requests using fiddler and also can easily read the client secret and key. or can debug using firebug.
Is there any secure way to authenticate the client app?
No security possible in the case if your REST API call is been shield by any User Authentication. I mean if User need to put Username/Password then they are able to call those API then you can implement some security.
But if your requirement like follows :
Any GUEST user with any browser open your application pages, which intern call your REST API.
Then there is no security. Since any attacker can intercept your Request/Response and call it further.
Note : From security prepective, Whatever a Browser can do, any good attacker can do the same.
But if you shield REST CALL Pages with username/password validation, then you can restrict the calls from server side with proper session validation.
JSON Web Tokens (JWT - pronounced jot) might be what you're looking for. Auth0 has a swell blog post that specifically addresses AngularJS + JWT.
You cannot trust the client to validate anything. If the user is using Firebug or Fiddler to "trick" your application then all you can do is verify the information server side to ensure it is valid.
You can trust the client to keep the user's session safe (to some extent), but if you can't trust the user then you can't trust anything the client sends to you.
If you need to ensure the integrity of a piece of data that is held client side you can use a MAC (Message Authentication Code) which is effectively a hash of the message appended to a server-side secret key that can be later verified. Sometimes this is (incorrectly) called signing. JWTs are the current standard to accomplish this.
It depends at the end of the day what threat you are trying to keep your application safe against - if it is a game with high scores that runs on the client, there's not much you can do to prevent the user from altering their score before it is sent to the server. If you need to trust such data, run it server side.
I have 4 angular applications one is a landing app which asks user to login and has to redirect the user according to its type
to one of the other 3 applications. I am unable to figure how to should i achieve that.
Have the three apps running on different subdomains. Upon login backend send a redirect response, figuring out what type of user it is?
But this leads to cors Error. Also i am not sure whether the cookie which i am setting will be accessible in all the subdomains or not.
Is there a way out?
You can do a redirect, but it seems like an unnecessary step (and kind of convoluted for this type of application).
Instead of returning a redirect based on login, it seems more straightforward to just return the address you want to redirect to in the response. Trigger a lookup to determine which app you should be directing to (however you're doing that) and then return the address of the app in the response data. From within Angular, you can extract the address from within response.data in $http. (see angular docs). The nice thing here is you also keep routing control and knowledge of state within Angular itself.
As for the apps themselves--instead of a subdomain, you can simply put the apps into different folders on your domain. This deals with CORS and the cookie issue.
Otherwise, you'd need to set a CORS header. You would do this on whatever backend you're sending the requests to--there's usually some sort of library to make it easy, for example, Flask CORS for Flask. If you need to share cookies in this case, this StackOverflow answer discusses one way of doing it (using an intermediary domain).
Generate a security key for the user session with some TTL in an authentication table when you authenticate the user with your App1
Redirect the user to any other app in any domain with this security key where they can query the authentication table and verify the user.
Let these other applications work on their own (in the front end) and communicate with the back-end with the security key when necessary.
Lot of PHP frameworks has built-in support for this mechanism. My favorite is Silex.