I'm learning Redux and I can see people storing all kinds of information into the state and doing all kinds of different operations through reducers. But is Redux secure or is there any known vulnerabilities of using Redux? If there are then are there any best practices that I can follow to secure the state?
Maybe let's change the question - does keeping any data in the client side is safe? And answer is no. Any kind of secret data should never exist in the front side. State management system will not change the app security. Even if you have encapsulated state the data can be catched by watching the network and data coming to the browser or by traversing html because most of the data in the front side is just used in the view. So, really any kind of data which gets to the browser should be considered as fully transparent and only the backend can really secure what is given and what not.
Is it not a good idea to save passwords and sensitive information in your redux store. When you go into production, definitely turn off the redux-devtools setting because if you don't then anyone can see your whole application state with the chrome extension (if you care about hiding your app state). You have to be especially careful if you are syncing your state to something like local storage as well. In general, send passwords or sensitive info right to the server in an encrypted fashion.
Related
I have taken over development on an ASP.NET web forms app that is 100% designed to be used on mobile devices. Currently, the app makes very heavy use of session variables. The mode is default.
<sessionState timeout="600"></sessionState>
It won't surprise you that the app is buggy, and much of it's problems have to do with session data being lost, or, the entire session being lost.
Just some overview of the app in general:
No sensitive (security risk) data is stored in the session
The data in the session is small, but mission critical. No huge objects. Just a few INT's (Id's, etc), some strings, etc.
We have to assume that the user's bandwidth will be low, and that connectivity will be spotty
The data is unique per user
One of my suggestions to management about how to make this app better is to stop using Session variables and to use something else instead. I'm of the opinion that switching to cookies to store all of this data is a better way to handle this. I'm aware that some users may disable cookies (even on their mobile devices), but if that's the case, we can simply inform them that to use the site, they need to turn cookies back on.
I thought about using query strings, but simply from a programming stand point (building links, etc) query strings are a pain to work with.
I've come to this conculsion after reading this MSDN article about the various ways to persist State data, and each of their pro's and con's:
https://msdn.microsoft.com/en-us/library/z1hkazw7.aspx
My question here is: Are cookies the best alternative?
Cookies are limited in size and aren't really the best place if you've lots of variables. Also people don't like cookies, so may restrict them.
The ViewState is a great place to store data though. This is sent as a postback from your web forms and can be used to store reasonable amounts of data. For example if your application uses several pages to complete a process (e.g. ordering something), then you can persist data in the ViewState and this will be available when the page is posted back.
Used in the right way, the ViewState is very effective.
We have an internal CRM system which is currently a website that can only be accessed inside our intranet. The boss is now wanting to have it exposed to the outside world so that people can use it from home and on the road. My concern is security based in the fact we will be exposing our Customer base to the outside world. I have implemented 3 layers of security as follows:
User Name and Strong password combination to login
SSL on all data being pushed across the line
Once the user is logged in and authenticated the server passes them a token which must be used in all communication with the server from than on.
Basically Im a bit of newb in the respect of web security. Can anyone give me advice on whether I am missing anything? Or something should be changed?
There's a whole world of stuff you should consider, and it'll be really hard to quickly answer this - so I'll point you at a range of resources that should help you out / get you started.
First, I'll plug http://security.stackexchange.com, for any specific questions you have - they could be a great help.
Now, on to more immediate things you should check:
Are your systems behind a firewall? I'd recommend at least your DB is placed on a server that is not directly available to the outside world.
Explore and run a range of (free) security tools against your site to try and find any problems. e.g.:
https://asafaweb.com
http://sectools.org/
Read up on common exploits (e.g. SQL injection) and make sure you are guarding against them:
https://www.owasp.org/index.php/Top_10_2010-Main
https://www.owasp.org/index.php/Category:Vulnerability
How is your token being passed around, and what happens to it if another user gets hold of it (e.g. after it being cached on another machine)?
Make sure you have a decent password protection policy (decent complexity, protects against brute force attacks by locking accounts after 3 attempts).
If this is a massive concern for you (consider the risk to your business in a worst case scenario) consider getting an expert in, or someone to run a security test against your systems?
Or, as mrunion excellently points out in the comments above (+1), have you considered other more secure ways of opening this up, so that you don't need to publish this on the web?
Hope that gets you started.
If I put some pretty sensitive information in a session variable, how secure is it? Can it be access by a client writing a rogue page and making an ajax call to my application?
Thanks.
If you really need to store that data between requests, then, you should store in the server side.
To store information to use between requests you have these options:
Hidden Fields: You should never use this to store sensitive information, because the user (or an malicious user) can get that information;
ViewState: You should avoid to store sensitive information here, but if you really, really really need it, you should encrypt the viewstate;
Cookies: You should never use this to store sensitive information. Like the Hidden Field, it's easy to see the information inside.
Session: If you really need to store that data, here is the place you should use. In IT world, there is nothing safe, but this is the safer place to save that information.
I think I didn't forget anything.
In short, because it's stored on the server, it should be safe.
The variable will be safe unless you expose it. You can't just arbitrarily make ajax calls (or any other type of calls) to retrieve session variables. You'd have to be able to write code that executes on the server.
However, if someone is able to hijack your user's session they'd be able to see it on any page you display it (if you do). This security concern isn't restricted to session variables though. If you're worried about this, you might want to use HTTPS.
When dealing with Credit card data you have to be very careful. This is not something you can take lightly as there are all sorts of compliance regulations and laws to consider. Basically, Session is the only place I would consider ... if I did. I would still encrypt it. In truth, however, I would recommend not storing any credit card data if you can help it. There are lots of payment systems out there, and banks provide processing tools as well. If you let the user put it in durring the transaction, keep the entry secure, and store none of it, that is the safest from a legal perspective. You are not bearing risk by keeping the data.
If you MUST keep credit card data see the following PCI regulations:
PCI Compliance Guide
Additionally, you may find this guide on secure session usage helpful:
ASP.NET Fast, Scalable, Secure Sessions
My question is how to best handle temporary data for an session. The scenario is similar to a shopping cart or like a bet slip. While the user is navigating the site and adding items with unique ID's. I'm only interested in the data collected this way if the user wants to commit it.
I'm developing in ASP .Net 3.5 with jQuery,JSON and a MS SQL DB.
As I see it there are a few possible ways to do this.
Perform a full post back to the server. Store every selections, update page controls accordingly.
Send selections via a Ajax request back to the server and update displaying control.
Build all functionality in JavaScript and store all values in a session cookie. Nothing being sent to server until user choose to commit.
I really want to consider performance here but I don't want to end up with 1000's of lines of JavaScript code..
Any suggestions of the best implementation with pro's and con's?
Cheers,
Stefan
Storing things in a session cookie is not a good idea, because that will be sent back to the server with every request. If you could find a way to store the state on the client without using a cookie, then you might have a viable client-centric option, but i can't think of anything portable off the top of my head. There are things in HTML5 and Flash that can do it, but you don't want to go there - yet, in the case of the former, and at all, in the case of the latter.
I'd use AJAX to post back to the server (with graceful degradation to a full post for browsers that can't handle that), then store the information in volatile memory there - ie not in the database. Write it to the database only when you need to. This is very easy to do in Java (you can associate information with the session), so i assume ASP.net has some way to do it too.
All three possibilities look good to me. The question, however, is: how much traffic do you expect?
Each of the options you presented suits better to a given scenario. Let's say you will have A LOT (thousand of thousands) users and not a lot of hardware available then you should probably try to minimize the number of requests to your app and store data in the client as much as possible before sending it to the server.
If it is smaller application then using Session or some other central database storage would be fine.
It all depends on your requirements.
Like a lot of people I've gone with ASP.Net Forms authentication because it's already written and writing our own security code we're told is generally a bad idea.
With the current problems with ASP.Net I'm thinking it might be a good time to look at alternatives.
Important: ASP.NET Security Vulnerability - ScottGu
Video demonstrating attack
Microsoft advisory including workaround
From what I understand Microsoft tend to store things on the client side because it makes it easier to operate over server farms without needing database access calls.
I don't really care about server farms though and I'd like to simply have an opaque cookie that demonstrates my lack of trust in the callers.
Is there a decent solution that's already been proven solid?
Update: to clarify my question. I'm talking about the authentication token part of the forms authentication that I'd like to replace. The back end is quite easy to replace, you can implement the interfaces to store your users and roles quite easily. You can also use existing libraries like http://www.memberprotect.net/ which has been mentioned here.
I'd like to change the front end part of the process to use a token that doesn't provide the client with any leverage. Sticking with the existing back end infrastructure would be useful but not essential.
I've been working on an HttpModule that basically does what you're looking for. When a FormsAuthenticationCookie and FormsAuthenticatedTicket are generated, before the response is sent to the client (i.e., during the processing of the postback of the Login page/action), all of the details about the cookie & ticket are stored on the server. Also, the UserData from the ticket is moved to the server (if present) and replaced with a salted SHA-512 hash of the other properties in the ticket along with a GUID that serves as a key into the server-side store of the ticket.
The validation of the cookie & tickets compares everything the client provided (optionally including their IP address) with all of the properties that were known about them at the time they were issued. If anything doesn't match, they are removed from the request before the FormsAuthenticationModule even kicks in. If everything does match, the server's UserData is stuck back in the FormsAuthTicket in case you had any modules or code that depend on it. It's all transparent. Plus, it can detect suspicious and blatantly malicious requests and inserts a random delay in the processing. It also has some explicit padding oracle workarounds in there.
The demo app actually lets you create/modify your cookie & ticket values on the server, with the server encrypting your ticket for you with the machine keys. This way you can prove to yourself that you can't create a ticket/cookie that gets around the server validation unless you write the exact set of data to the server (which should be impossible under normal circumstances).
http://sws.codeplex.com/
http://www.sholo.net/post/2010/09/21/Padding-Oracle-vs-Forms-Authentication.aspx
http://www.sholo.net/post/2010/09/22/Sholo-Web-Security-and-the-EnhancedSecurityModule.aspx
-Scott
If you have your keys in the web.config and the attacker gets to it, they are pretty much done.
If that's not the case (they don't get the keys from your .config), then afaik the padding oracle shouldn't allow them to sign a new auth ticket. The paper explains ability to encrypt by taking advantage of the cbc mode, ending with a tiny bit of garbage there. It should be enough to make it an invalid signature.
As for the video where they get the keys with the tool, its against a dotnetnuke install. A default dotnetnuke has those keys in the web.config.
Implement the workaround, keep your keys off your site level web.config, if you don't use webresource.axd and scriptresource.axd disable those handlers, and apply the patch as soon as ms releases it.
I will simply recommend taking a look at InetSolution's MemberProtect product, it's a component designed with security in mind for the banking and financial services industries but is widely applicable to any site designed on ASP.NET or application built on top of the .NET platform. It provides support for encrypting of user information and a host of authentication methods from the simplistic to the very advanced and the various methods and functions are designed to be used as the developer sees fit, so it's not a canned solution so much as a very flexible one, this may or may not be a good thing depending on the particular situation. It's also a very solid foundation on which to build new member-based websites and applications in general.
You can find out more about it at http://www.memberprotect.net
I am the developer for MemberProtect and I work at InetSolution :)
This isn't a value-less question, but I have to say that I think your logic is suspect. It's no bad idea to consider alternative authentication solutions, but the newly-announced ASP.NET vulnerability should not push you to abandon a current (presumably working) solution. I'm also not entirely sure what the relevance of this comment is:
From what I understand Microsoft tend to store things on the client side because it makes it easier to operate over server farms without needing database access calls.
What is it about the vulnerability that makes you think that ASP.NET forms auth is broken any more than another solution?
The detail of the MS advisory would seem to suggest that pretty much any other authentication system could be rendered similarly vulnerable to attack. For example, any solution that uses the web.config file to store settings would still have its settings open to the world, assuming a successful attack.
The real solution here is not to change security, but to apply the published workaround to the problem. You might switch authentication providers only to find that you are still vulnerable, and your effort has gained nothing.
Regarding tokens/sessions: you have to push something to the client for authentication to work (whether you call it a token or not), and it's not this part of the process that causes the current security issue: it's the way the server responds to certain calls that makes this secret vulnerable to attack.