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
Related
I am trying to design a pairing application for my university this valentine. How is it supposed to work, you ask?? The clients will submit preferences to the server and after some days if any two clients have the same preferences, they will be notified -- not in any other case. A fool-proof framework design needs to be built for this purpose. What I am willing to do is to ensure my clients that even though they will be submitting their favourite responses to me via my website, I will still not be able to see those as if I would, this application will have issues of privacy. I am trying to match the user preferences with each other, they will obviously be encrypted and there is no way I can match any two unless I decrypt them at some point in my server locally -- assuming the fact that RSA encryption mechanism has a very little probability of collision of hashed values and I definitely cannot match them :) . The bottleneck here then is >> never ever decrypt the client preferences locally on the admin's machine/server. One approach which is currently on my mind is to introduce a salt while encrypting which will stay safe in the hands of the client, but still decryption needs to be done at some point in time to match these hashes. Can there be some alternative approach for this type of design, I think I might be missing something.
Turn things around. Design a mailbox-like system and use pseudonyms. Instead of getting an email once a match has been found, make people request it. That way you can leave the preferences unencrypted. Just the actual user has to be hidden from public. Start with an initial population of fake users to hide your early adaptors and you will be done.
I.e.: In order to post preferences, I'll leave a public key to contact me. The server searches matches and posts encrypted messages to a public site. Everyone can see these messages (or not, if you design properly) but I am the only one that can read them.
I want to handle some confidential data in one of my web application. So that the data shouldn't able to read by the Developer or Database administrator.
We can easily hide the data from DB administrator by implementing some encryption technique. But still the developer can see the data since he only creating the decryption technique. I want only the end user should see his data.
I can't encrypt data using some algorithms like PBKDF2 or DB side encryption methods Like TDE & EKM because still I need to keep the encryption key somewhere. If I keep in server side or in db the developer can access and decrypt the data. If I keep it in client side, the user can't access the information from a separate machine.
So How to handle this situation? Thanks in advance.
You are heading the direction of Zero Knowledge Web Applications, such as implemented by SpiderOak (see also crypton). These applications typically work by deriving a key from the user's password using something like PBKDF2, and performing encryption/decryption on client side. However, there are a number of complexities to overcome to make it true zero-knowledge, and also to meet usability requirements. One could write an essay on this, but instead I suggest you start by reading the linked references. If you have any questions, let me know.
In a nutshell, the "more zero-knowledge" you want the system to be, the harder it is to realise without sacrificing usability (one example is overcoming the points made in Javascript Cryptography Considered Harmful). However, there are various tradeoffs you can make in order to make it sufficiently difficult to cheat without affecting usability too much.
I need to keep the encryption key somewhere
No you don't. The user only has to remember it. For convenience you could save it in the browser's local storage.
Do ASP.NET Session[string key] data need to be encrypted to be secure?
If such data always stays on the server, doesn't that make it safe to store credit card information, passwords, etc. there, as long as the data were sent via SSL from the client?
With all the downvotes being thrown around here, I'll add my own two cents:
I think that anything that stays in server memory, including ASP.NET Session data, is safe in unencrypted form. An attacker would have to be able to execute code on the server in order to read the memory.
On a side note, once it's stored in a database, data should be encrypted. If it's sent to the client, it should also be encrypted, but that's outside the scope of this question. Lastly, of course, the data must be encrypted on its way from the client to the server.
Anything sensitive should go straight to the database, and not hang around in memory longer than needed. I don't understand why you'd need to store passwords or credit card data in session variables anyway, are you passing them between pages?
No. You should never store this information in the session. Even encrypted this information is vulnerable. Sessions may get hijacked, a server may get compromised and then everything that is in memory that happens to be used in memory as plaintext will be viewable to anyone with a hex editor. If you need references to this information, you should create hashes that are stored and not replayable that reference the information in a secure datastore.
EDIT: For those that think session data is safe:
http://en.wikipedia.org/wiki/Session_hijacking
http://en.wikipedia.org/wiki/Session_fixation
http://en.wikipedia.org/wiki/Session_poisoning
http://www.owasp.org/index.php/2.0_Session_State_(in)security_(and_the_dangers_of_State_Server)
There are ways of protecting session data, but if you need to keep very sensitive information such as passwords or credit card numbers, the session is not the place for it. Try coding to the Sarbanes Oxley legal requirements for banking and medical applications, and you'll find in your first audit that this is one of the first things that gets checked.
http://en.wikipedia.org/wiki/Session_management
I share m.edmondson idea, in the fact that sensitive information should be stored in database, (there are many techniques to dealing with sql-injection). Also for securing your site you should use HTTPS. But if you're going to store information that is not so sensitive for passing between pages you can use session variables, don forget to delete such variables as soon as possible. Remember you can aver going to the database to retrieve the data, only non-sensitive and time-consuming data should be stored in session scope.
Depends -- how much do you trust every other app on your server?
The question refers to the data being stored in memory on the same server, but that's just the default configuration. You can also set up a state server, write to a nosql db etc.
Stateless web servers are becoming increasingly more common thanks to the rise of the cloud and platforms-as-a-service.
Depending on your security policy, credit cards and passwords may not be the only information that you consider "confidential". Some orgs consider customer information such as addresses to be confidential as well. This means that any multi-step session checkout would contain "confidential" information.
The answer to this specific question may be a "no", but future readers might need to consider these additional items as well.
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.
Some web applications, like Google Docs, store data generated by the users. Data that can only be read by its owner. Or maybe not?
As far as I know, this data is stored as is in a remote database. So, if anybody with enough privileges in the remote system (a sysadmin, for instance) can lurk my data, my privacy could get compromised.
What could be the best solution to store this data encrypted in a remote database and that only the data's owner could decrypt it? How to make this process transparent to the user? (You can't use the user's password as the key to encrypt his data, because you shouldn't know his password).
If encryption/decryption is performed on the server, there is no way you can make sure that the cleartext is not dumped somewhere in some log file or the like.
You need to do the encryption/decryption inside the browser using JavaScript/Java/ActiveX or whatever. As a user, you need to trust the client-side of the web service not to send back the info unencrypted to the server.
Carl
I think Carl, nailed it on the head, but I wanted to say that with any website, if you are providing it any confidential/personal/privileged information then you have to have a certain level of trust, and it is the responsibility of the service provider to establish this trust. This is one of those questions that has been asked many times, across the internet since it's inception, and it will only continue to grow until we all have our own SSL certs encoded on our fingerprint, and even then we will have to ask the question 'How do I know that the finger is still attached to the user?'.
Well, I'd consider a process similar to Amazons AWS. You authenticate with a private password that is not saved remotely. Just a hash is used to validate the user. Then you generate a certificate with one of the main and long-tested algorithms and provide this from a secure page. Then a public/private key algorithm can be used to encrypt things for the users.
But the main problem remains the same: If someone with enough privileges can access the data (say: hacked your server), you're lost. Given enough time and power, everything could be breaked. It's just a matter of time.
But I think algorithms and applications like GPG/PGP and similar are very well known and can be implemented in a way that secure web applications - and keep the usability at a score that the average user can handle.
edit I want to catch up with #Carl and Unkwntech and add their statement: If you don't trust the site itself, don't give private data away. That's even before someone hacks their servers... ;-)
Auron asked: How do you generate a key for the client to encrypt/decrypt the data? Where do you store this key?
Well, the key is usually derived from some password the user has chosen. You don't store it, you trust the user to remember it. What you can store is maybe some salt value associated to that user, to increase security against rainbow-table attacks for instance.
Crypto is hard to get right ;-) I would recommend to look at the source code for AxCrypt and for Xecrets' off-line client.
Carl
No, you can't use passwords, but you could use password hashes. However, Google Docs are all about sharing, so such a method would require storing a copy of the document for each user.