I am doing a Website 100% in ReactJS, It's a simple/medium complex, this has a Login, Profile and other sections more. After Users Log into the site the login callback returns some important values like: "Token, UserRole". Currently I'm storing these values in Web client using localStorage .
My doubt is the next: There is a better way to store this values? Because if any person changes the value from the Browser Console this could be a BIG ISSUE because they could change the role and then execute things that they never should do.
I thought to do it with Redux, but if the users Refresh the website then they lost the values, so I am not pretty sure to choose this.
What do you think guys?
TIA!
The general rule is to never trust any data stored client-side, except for an authentication token or the equivalent. All changes that the user makes that involves the server should be verified on the server. So, rather than:
if any person changes the value from the Browser Console this could be a BIG ISSUE because they could change the role and then execute things that they never should do
Instead, the right thing to do would be, when the client wants to do something (such as edit their profile), have the client send their authentication token (or session ID) with the rest of the payload to your server. Have your server examine the token, check that the user associated with the token actually does have the required permissions for what they want to do, and only then continue to process the request.
Whether you also happen to store some information in Redux or elsewhere has no impact.
Storing login-related information client-side is relatively common and isn't inherently bad - just make sure to always verify it on the server when something that requires permissions is requested.
One approach some use is for the server to create an encrypted JWT that only the server can decode, which gets sent with requests.
Related
I have built my app, I used plain JS on NodeJS and it is a single-page app. I didn't use express.
First the user needs to log in. The login-data is sent via websocket to the server and there the credentials are checked against a MySql-DB. If they are correct, the loggedIn-content is generated and sent back to the client, where it is displayed.
Now when a user is already logged in, and then refreshes the browser, he lands on the initial state of the app, and needs to log in again.
how can I fix this?
I read a lot about session-handling in NodeJS, but most articles include express, which confuses me to understand this whole concept.
HTTP itself is stateless, so you need some sort of way to identify the user.
Traditionally, this is done via cookies. When you respond to an HTTP request, you include a cookie in your response headers. For all subsequent HTTP requests, the client will include this cookie information back to you.
This means that you can send some sort of session identifier, and for all future requests you can look up the session data. The conversation goes a bit like this.
Client: Here's my login information, and I'd like the home page.
Server: Ok, thanks. Here's the home page. Also, remember that your session ID is 12345. Next time you ask me for something, tell me that session ID. (Logs in the database that session ID 12345 is associated with someuser.)
Then later...
Client: I'd like this other page. You told me to tell you that my session ID is 12345.
Server: (Loads session information for 12345, sees that it's associated with someuser.) Ok, here's that other page.
How you actually do the storage of all that is up to you. Many folks use databases, since they're often already using them for the application and it makes it easy to share session data with multiple instances of the application server.
Currently I am storing user information in localStorage, but for some reason smth tells me that this must be wrong due security or smth else... What would be the best practice to pass the user information for ex user_id into a http call later.
If I store user_id into localStorage, someone can change it and make calls on behalf of someone's else user_id. Could anyone suggest me the best practice how would I achieve such things that no one can manipulate with user logged in information.
One way I was thinking is, to always call the users/me and get the user info and then make the other call, would this be a better way?
Each time a user logs into your application you must authenticate them on the server side and either use a server side session which uses a cookie (or some sort of auth token) for requests back to your server.
It seems like you probably have an insecure web application if a request can be spoofed simply by changing a user id though.
You can store something like a user id or user name in local storage so long as you are only using it for a "remember me" feature to populate a form field for example.
I have been thinking over this issue from past few months. Recently, I have started with complete JS Built front-end, where the forms are posted using Ajax.
I have a doubt, how to recognize on the server side, from where the data is coming from. Is it coming from actual form event or it is coming from browser console.?
What I have tried:
Creating a two way handshake: Before posting the form, the Application will contact the server, and the server will send a token inside the cookie, which will be sent back with the form post. But, even if we post by browser console, that cookie will go carrying the token. So, Failed.
Binding Hidden Field: But if someone, is posting the data from browser console, he would definitely look for the hidden fields as well. Basically, he'll replicate my AJAX to send the same request, in the same fashion. FAILED!!
I am not able to figure out this part. Can anyone help?
Thanks in advance.
Rule #1 of programming for the Internet: Never trust anything from the client. EVER.
Rule #2 of programming for the Internet: Never trust anything from the client. EVER.
Rule #3 of programming for the Internet: You can not make the client trustworthy.
I know the first rule is duplicated twice, but it is worth it.
There is simply no way to do what you intend to do.
A person who wishes to send data to your server, via an AJAX request or a POST request, can easily do any of the following:
Modify the form using browser tools or a proxy and force-feed in whatever information he wants.
Capture the entire transaction, through a tool like fiddler2, and change the values and re-send them. No browser needed.
Modify the code running from your site to send (or allow) whatever data he wishes to send.
Use a tool like Curl to fake an browser and send whatever information he wishes to.
There is simply no way of knowing, on your server, where that information came from.
From a security point of view, you simply can not trust anything -- ever.
Validate the credentials, give the user a login token (usually a cookie) and then still be suspicious of everything the client sends you. If there is something that shouldn't be changed or updated, make sure your back-end doesn't allow it to be changed or updated.
We have tons of code in our application that looks like this:
if (user.HasPermission("MayUpdateFirstName") {
record.FirstName = FormData.FirstName
}
That way, if FirstName is passed in, and the user can't modify it, then it doesn't get modified.
I am building a WebApp which connects to my server through a web service.
Users (there is no login) which use the webapp can send their scores to the
server.
The code is written mostly in javscript, so anyone can read it.
As I know there is no 100% gurantee method of doing this, I am just looking for ideas
how to make it as hard as possible for users to send false scores.
Ideas?
10X!
EDIT
The server side web service is an asmx (.net) web service hosted on an IIS.
I can modify it as needed.
I'd say the best thing to do would be to have a webservice call that generates a guid on the the serverside, which is passed back. This becomes your session token. It's stored on the database or in cache on the server
Each subsequent call requires the passing of the token back to the server, which validates the token. If they pass a bad token you don't update.
This will only insure that the calls come from the correct process. They won't be able to spoof the entry with a single call
For a process (you seem to be talking about a game?) with a limited number of interaction points, you can record each user interaction and play it back to check that it results in a certain score at the server side (either in real time or later on for suspicious scores).
Otherwise (and this is typically impractical for an real-time action game where there are too many interaction points), there is not much you can do. You can have the game digitally sign the information it is submitting... but given that you are giving the full code including signing key to the client side, it is still easy for an attacker to obtain the key and sign invalid scores.
At this point you get yourself into an obfuscation arms race - how much can you make the client-side code unreadable and difficult to unravel, to prevent attackers from obtaining the key? You can never win this game, only deter the casual attacker. And ultimately you have to protect the entire client-side process from alteration, to stop all other forms of cheating (eg using Firebug to change variables like score or lives).
I create js app with Backbone and RequireJS for registred or non registred users. To retrive data from database I use simple JSON web service and of course some of methods are not avaiable for quest. Problem is that I don't know where or how I should store auth data retrive from server without reloading it in every view. Should I use cookies ?
I guess it depends on your authentication, authorization methods as well as the kind of security you need to consider for your users. If you're trying to be RESTful, you can't have sessions to save state (at least server-side). You could, but it wouldn't be RESTful due to saving of state on the server, if that matters to you. I've heard that it is okay to save state client-side but from what I've read, I'm not sure how the community feels about certain implementations that take this approach. (Like cookies, I'll revisit this later.)
Say you have someone login with username and password. You can hold that information in your Backbone app, maybe you have a model called AUTH that does this. Each time you make a request to the server you'd send that data each trip at which point the server authenticates and gives or rejects access to given resources. If you use Basic Auth this information would be in the header I think. Using SSL mitigates some of the major security concerns surrounding the sending of this information over the wire and for the rest of the discussion let's assume this is what we are using.
The other way that you could do this is to use encrypted cookie, encrypted cookie sessions. This is what I do with my current application. Honestly, I don't know if this is considered a violation of RESTful principles or not. The general chatter on the web seems to be a lot of "cookies bad, sessions bad" with some people saying, "get real." Using cookies would expose you to cookie hijacking if someone had access to the users computer, but depending on your application and the security needs it might not be an unreasonable option. It works for me and if it isn't RESTful, I like to call it RESTLike.
To close I'll just describe my setup. It would be nice to get your thoughts as well as the Stack's opinions on this also.
Basically I have a setup where when someone goes to the main page, the server checks for the encrypted cookie session. If the cookie session is invalid or non-existent, it gives the user the regular page with a chance to login. When they login, I send that information over POST so it's in the body of the request rather than the URI. (This is technically a violation of the REST HTTP verb concept since you use POST to save a resource.) When that information is processed, check the username, pass hash created by a unique salt, then the server creates an encrypted session cookie and passes it back to the user. Now, each time my user hits a route that requires authentication, the server checks the cookie to make sure it is still valid (time limit, user information, etc.) and if so - allows access. If not, it destroys the cookie information and sends back an appropriate status code. The backbone app reacts to this by resetting any view and data that shouldn't be in the hands of an unauthenticated user and shows them the login screen.
Hope this gives you an idea. This is the answer to how I do it, but if someone has criticisms or better ideas I'd be happy to upvote them instead.