views:

577

answers:

6

Okay, I'm still new to the whole ASP.NET and exactly how it posts back to its page. But I was wondering if it leaves a trace of what content is currently on the page.

For example, if I have a Social Security text box, and wanted to encrypt it and ship it off to another server I would do that through a hidden server script after posting back to the current page via a submit button or something of the sort.

Though if, when the page gets posted back to itself, it reveals the data. It becomes pointless to even encrypt/transfer it somewhere safely if someone was listening or has access to your browser logs.

So does posting back to the page keep the data secure, or does it open it up for easy access like a querystring would? And if it does not is there any secure way to get back to the server for the scripts there?

+4  A: 

ASP.NET uses an HTTP POST to send the data to the server - in order to secure any data, encrypt the submission with an SSL certificate and use HTTPS.

By the way, this is not unique to ASP.NET - HTTP POST is the industry-standard way of sending a payload of data over HTTP.

Andrew Hare
That protects against the unlikely scenario of a hacked router or corrupt network admin. Its more likely that a user (who gets to see html source in plain text, ssl or not) would want to fiddle with the viewstate.
MatthewMartin
A: 

store it as a business object when passing to server is pretty secure. and https is the most secure channel

waqasahmed
A: 

You can encrypt the viewstate with AES. If you want to get really paranoid, put the time of first request into the viewstate and refuse to use the viewstate after x minutes. I forget what viewstate mac does, but it yet another good thing you can turn on.

And finally, even if viewstate is secure, it is subject to replay attacks if you don't use SSL or have some other reason to believe the page will be replayed.

MatthewMartin
+2  A: 

ViewState

Use ViewStateEncryption. You can set that at the page level:

<%@ Page Language="C#" ViewStateEncryptionMode="Always" %>

You can also set it at the site level in web.config:

<system.web>
  <pages viewStateEncryptionMode="Always" />
</system.web>

Other Control Values

As Andrew Hare pointed out, that doesn't cover controls which hold their values locally.

Request and Response Security

Remember that you need to secure content both ways - to and from the server. SSL would help with both of those.

More background here.

Jon Galloway
Textboxes don't store their values in ViewState - ASP.NET rehydrates the values of form inputs from the request, not from ViewState.
Andrew Hare
"...that doesn't cover HTML native controls which hold their values locally." - No, I believe this is true for ALL controls, whether HTML or WebControls."It is a common misconception among developers that view state is somehow responsible for having TextBoxes, CheckBoxes, DropDownLists, and other Web controls remember their values across postback. This is not the case, as the values are identified via posted back form field values, and assigned in the LoadPostData() method for those controls that implement IPostBackDataHandler."http://msdn.microsoft.com/en-us/library/ms972976.aspx
Dan Diplo
Clarified the wording. Thanks for the reference.
Jon Galloway
A: 

You need to use SSL Certificates to protect any form post values. Also remember if a browser is hacked, everything is hacked.

So, the user can still tamper the form data or form data can be captured by plugins before the encryption happens.

Secondly, you cannot protect dumb users from hackers. So, always advice the users to ensure they are submitting to the right site and they don't see any certificate errors.

And finally, this is applicable to any thing and every thing which communicates over https and is not specific to ASP.NET

Ramesh
+1  A: 

PostBack is for passing server variables to the web browser in a way that lets them be passed back later, thus saving the server the need to keep track of the information in the session state between page views.

The initial passing of a textbox/input value to the server happens via traditional GET or POST variables passed in the HTTP connection, it's not related to the PostBack/Viewstate functionality of ASP.NET. If you turn on PostBack encryption, it just encrypts what the server sends to the browser so a user can't read or modify those variables.

You could try to encrypt the SSN field value on the web browser by writing an encryption function in Javascript, and then sending the encrypted text in a hidden field to the server, but you have to pass the algotihm and any encryption key to the browser, which means anyone listening in that could see the clear-text SSN could also see the encryption code and thus reverse any attempt you make to encrypt the SSN.

The best solution is to simply have your web site running under SSL (https://), which means the entire communication back and forth between the browser and server are encrypted. There's no need to re-invent the encryption wheel.

richardtallent