I've just started to read about viewstate in asp.net. I know it is serialized data encoded with base64 and I know it can also be encrypted using a key[which is Auto-generated every time if we don't change the default in web.config in case of server farm or etc.]
but my problem is that how this key is shared with the client [so that the client could read it] that ensures the safety of data?
does it have to do anything with HTTPS protocols and shared keys or they are completely something else?
if it is something else, so how the keys are transferred throw the web?
Related
I was using Burp Suite to do some security testing on a site and I noticed that when it detects ViewState it will automatically tell you whether it has MAC enabled.
I'm curious if anyone know of a programatic way to determine if MAC is enabled if you are crawling a site without actually attempting to modify the ViewState, submit it and see if anything blows up?
From what I can tell Burp Suite is doing this just by look at the request (and not modifying/submitting).
ViewStates are basically BASE64 encoded strings. So what you can do is try to decode them with a BASE64 decoder. If it's encrypted you will get some binary content which is not really readable. If no encryption is used you will be able to see the contents. For instance Fiddler2 can assist you in decoding ViewStates in your browser.
Now there is also the option of using a MAC:
If the viewstate has its MAC enabled then there The security of this
system lies in the secrecy of the secret key value. This value is
always stored on the server, either in memory or in a configuration
file (more on this later)—it is never written to the page. Without
knowing the key, there would be no way for an attacker to compute a
valid view state hash.
from MSDN "View State Security".
You can check this by decoding the VIEWSTATE (if not encrypted) and verify if a 20-byte hash is present at the end of the ViewState structure.
How does one prevent passwords and other sensitive data submitted to and received from ASP.NET web pages in IIS/ASP.NET dump files?
Steps to reproduce
Using Visual Studio 2010, create a ASP.NET MVC 3 intranet application.
Configure it to use IIS 7.5.
Fire it up and register an account (say bob123 as the user and Pa$$w0Rd as the password. I'm assuming that the SQL Express database is created and the site is fully functional.
Using task manager, right click on the w3wp process and create a dump.
Open the dump in an editor capable of displaying its contents as hex, such as SlickEdit.
Search for "Pa$$0Rd" and "Pa%24%24w0Rd" in the hex dump. You should be able to find several copies of it stored as ASCII, Unicode, or encoded.
Note that it doesn't matter whether you use HTTPS because it only encrypts the communication. ASP.NET stores that data in the clear in memory or disk.
The problem
Common wisdom has it to encrypt sensitive data and not to store it in the clear. However an employee may receive a dump of an IIS/ASP.NET application and discover passwords and other confidential data of users because this information is neither encrypted, nor is memory used by ASP.NET cleared after usage.
This puts them at risk simply because they have access to it. Dump are sometimes shared with partners (such as Microsoft) to help them diagnose issues in their code. It is a necessary part of diagnosing some really complex problems in one's application.
Things I looked at
Use SecureString for passwords and other sensitive data. However, the ASP.NET Membership provider, along with other frameworks like WCF, often accepts passwords as System.String, which means that those copies will still be in the dump.
Looked to see if there is anything in the framework to clear out a copy of System.String when it is no longer being used. I couldn't find anything.
Investigated whether one can zero out the memory used for requests and responses once IIS is done with it, but I was unable to find anything.
I investigated wether one can encrypt files IIS receives (as HttpPostFile) so that they are not stored in the clear. We may receive documents that are extremely confidential and every step is made to encrypt and protect them on the server. However, someone can extract them in the clear from an IIS dump.
What I was hoping for is to tell IIS/ASP.NET that a specific request/response contains sensitive data and that IIS/ASP.NET will clear out the memory when it is done using it.
A dump file by definition dumps all the memory the application uses at the moment it is dumped, If you were to create a filter so that certain things were excluded then you could never be sure that you had enough data to zero in on a problem.
Would you be comfortable handing over your databases / configuration settings to a third party? if not then you probably shouldn't be handing over dumpfiles either. (imho)
I know this doesn't answer the question directly but why not look at this problem differently.
You could easily put together some javascript to do the hashing client side. I would combine the password with something random such as a guid that is sent down by the server and is valid only for a single use. The data exchange would no longer contain the password and the hash could easily be compared server side. It would only be valid for the session so someone looking at the dump data couldn't use the hash to "authenticate" themselves in future.
On the file side, how are these files being uploaded? directly from a web page? There are quite a few javascript libraries that do encryption (blowfish) and I would definitely use this option when sending a sensitive file. It does have a speed penalty but you can be sure that the data is secure.
I have used MachineKey.Encode to encrypt a ID that is getting passed as a query string to a page but as expected this is making the URL huge.
Is there a option such as HTTP handlers that could customize the url but still load the required page?
Also I am yet to find out if MachineKey.Encode is using the MachineKey that I have defined in my web.config file to encrypt the data, can anybody confirm this for me with web information that backs this up.
Thanks.
Also I am yet to find out if MachineKey.Encode is using the MachineKey that I have defined in my web.config file to encrypt the data, can anybody confirm this for me with web information that backs this up.
It does indeed use the configured keys. MachineKey calls MachineKeySection.EncryptOrDecryptData to perform the encryption, which uses encryption objects configured from the machine key section. If you want to see for yourself, the interesting calls are EncryptOrDecryptData=>EnsureConfig=>ConfigureEncryptionObject=>SetKeyOnSymAlgorithm
I'm creating a site for distributing software to clients. We're implementing lots of security bells and whistles on it to reasure the clients that software they're running wont have been tampered with.
I'm toying with the idea of encrypting the files we upload to the server, but I'm not sure if there's much point conisdering the overhead it entails. The files are decrypted anyway when being transmitted to the client. As well as this, if a hacker gets into the server and replaces the encrypted files, they can also change any hashes we made of the files to check they havnt been manipulated.
So... is it worth encrypting the uploaded files?
You should sign rather then encrypt your files.
When using PKI, it is the act of encrypt (or encrypt a hash of) your file with your private key, instead of doing so with the receiver's public key.
Then everybody that download the file can verify that the file was not tampered with.
File encryption is useful when either you share a secret with your
receivers, or that you have their public key available. Typically it
is not useful in case of file distribution as you describe it.
I will answer with a question: what is the point in encypting files on the server when you don't have any control over what the clients will do with the decrypted versions anyway?
Oh security.
How can the client be sure they're talking to the correct server.
How can the server be sure they're talking to a legal client.
How can the user be sure they're not using a compromised client etc.
Is the server in your custody or is it a shared server. How volatile is the data and is datatheft an acceptable risk or not.
Please expand your current situation. Do you use encrypted communcation. Is the communcation over internal or external lines. Do you thrust the server support team.
I have an application which stores data to the persistent store by setting the contents of the PersistentObject as a hashtable, e.g. saving preferences is done by entering strings as the keys and values of the hashtable and then setContents is called on the PersistentObject with the Hashtable passed as the parameter.
I understand that the data is saved unencrypted. If I enable content protection in the IT policy for the device will this implementation of persistent storage automatically start encrypting the data or do I have to change the implementation to use for example the ContentProtectedHashtable for saving the contents?
All the information I have found so far about content protection has been with regards to the BES IT policy and nothing about implementation in the application, which makes me think that the standard implementation (i.e. just commiting a Persistable object to PersistentObject object) is adapted automatically to encrypt the data??
Any ideas?? Thanks.
See the documentation for net.rim.device.api.util.ContentProtectedHashtable for one way to implement content protection.
Also see this document for a more in depth discussion of content protection.
I don't think it has something to do with IT policy, it's rather PersistentContent which has encryption/decryption functionality:
This API was designed to allow applications to protect data in a database if the user has enabled Content Protection/Compression in their device's security settings. It consists of two main methods (encode and decode), as well as a number of helper methods.
...
Note that encoding can be performed anytime, whether the device is locked or unlocked. However, an object that was encoded using encryption can only be decoded if the device is unlocked. This can pose a problem if the device locks while an application is performing a potentially long operation during which it requires the ability to decode encrypted data, such as sorting encrypted records. In this case, the application can obtain a ticket. So long as a strong reference to a ticket exists, decoding encrypted data is allowed. Thus, applications should release tickets as soon as possible to allow the device to reach a locked and secure state.
See riccomini - code blackberry persistent store for encryption implementation.