Mage_IronWolf's WebLog

Maximum View State for a postback

2004-08-26T20:57:00Z

Am dealing with a web page written by someone else. I don't have the source code so can't change it now.

Issue, the viewstate is 9.5 million characters long. It saves out to over 9MB.

The page has a check box that does an auto postback.

When it does that, the page errors and tosses an exception:
Error in Application ErrorSystem.Web.HttpUnhandledException: Exception of type System.Web.HttpUnhandledException was thrown. ---> System.Web.HttpException: Maximum request length exceeded. at System.Web.HttpRequest.GetEntireRawContent() at System.Web.HttpRequest.FillInFormCollection() at System.Web.HttpRequest.get_Form() at System.Web.UI.Page.GetCollectionBasedOnMethod() at System.Web.UI.Page.DeterminePostBackMode() at System.Web.UI.Page.ProcessRequestMain() --- End of inner exception stack tr Code: -1

So my question would be, what is the maximum postback size you can have?

John

Some of what I learned at Dev Days 2004

2004-03-15T15:45:00Z

DEV DAYS 2004

I attended Dev Days 2004 in Minneapolis Thursday Mar 11. The main reason I went was for the security focus that it was to have this year. Dev Days was focused on .NET technology, however, a lot of what was covered in concept can be applied to legacy ASP systems.

There are a couple of primary key things I got out of it.

1 - Beware of hidden fields. Beware of using them to pass critical information when posting a page. They can be hijacked and be used to misrepresent that data. An airline was selling tickets for $1 because of this feature.

2 - Make use of Error handling built into the .NET framework. Modify the web.config file to push a user to a generic error page and log the error and as much of the rich data into the event log or appropriate file log.

3 - Be very careful of granting any rights to any part of a database other than execute permissions on Stored Procedures. Any extra information that can be gained is precious to a hacker.

4 - Don't assume that because it is Intranet, that you can code with other than best practice techniques. Develop a best practice for both Internal and External web code.

5 - Storing information in cookies is an invite to try to hack them. Be very careful of using them and if you do, make sure they are temporary and have a short life. It would be better to make the user login every 30 minutes than to leave the cookie out there to be stolen.

Some of the topics discussed were:

Threat modeling -- Identifying assets, architecture, relationships & threats. Determine where threats are dangerous and plan and design to prevent those from affecting you.

Disclosure -- All errors should be either handled or at least redirected to a neutral error page and the error logged.

Techniques to defend the application --

HTMLEncode all input echoed to a web page
Use regular expressions to validate
Run validation on server side even if it was validated on client side
Verify ValidateRequest on the html source page is set to true
Use encrypted techniques to access the database
Validate parameters being passed in to database
Logging errors and invalid password attempts to a log
Split out levels of security. Use NT permissions to protect pages in Intranet.
.NET will allow a web.config file for each folder. Levels of security can be tightened.

Some major common threats to applications --

SQL Injection -- Not as big a deal with Stored Procedures but still a possibility
XSS -- Cross Server Scripting -- Placing script tags that are echoed to the web page that can cause either damage, redirect or inconvenience to users.
Hidden tag overwriting -- Using hidden tags to change the page and cause errors.
Session Hijacking -- Using hardware to gather information and then log to the server with captured information.

I talked to Jacs and several others about the process we are using for securing our data connections. It isn't the absolute best practice, however, it is a legitimate process for securing them. The current best practice utilizes encryption but even that has to store a key somewhere.

Good day to all,

John Debnam
Comments Welcome

Much more detailed explaination of what we have implemented for our security

2004-03-05T21:34:00Z

I am going to explain the security process I did in the previous message. I think some concepts were crossed up.

1st half

The article at MSDN Building Secure ASP.NET Applications explains multiple processes that can be used to secure applications.

Microsoft has enabled ASP.NET to encrypt credentials and session state connection strings. (Q329290).

What I have done is to use the utility Aspnet_setreg.exe to encrypt a SQL DB login. This login is only granted the rights as explained in the (Q329290) article.

Each database environment has a different login. So, for DEV I use a database login of something like DB_DEV_ID, QA has a login of DB_QA_ID and PROD is DB_PROD_ID. Since the registry only gets a single setting, even if someone were to change the other registry settings the login would fail. The registry can not be ripped and placed on another machine as part of the decryption is a key to that specific machine.

Once I had that in place and proper rights granted to ONLY Stored Procedures for this login, I modified the web.config file to impersonate that login. ASP.NET security will not allow the impersonation id to be displayed. It is not available to the code.

This is all done per the 2 articles mentioned.

2nd half

I placed an Un-Encrypted registry setting for the environment. Every application will use the same setting so it only has 3 possible settings (DEV, QA, PROD), depending on the environment.

I then put 3 DB connection strings in the web.config file and name them uniquely.

<add key="cnHRDb_DEV" value="Integrated Security=SSPI;Persist Security Info=False;data source=DB_DEV;database=HR;" />

<add key="cnHRDb_QA" value="Integrated Security=SSPI;Persist Security Info=False;data source=DB_QA;database=HR;" />

<add key="cnHRDb_PROD" value="Integrated Security=SSPI;Persist Security Info=False;data source=DB_PROD;database=HR;" />

When I go to define the database connection, I read from the registry to determine what environment I am in and then use the proper connection string.

I can not connect to the Prod database with the QA login. Because of this, we can't cross environments on accident (or thru evil intent).

Conclusion:
This process means that the only location of the login is encrypted and can not be displayed or used for anything other than logging in. We only grant EXEC to Stored Procedures in the database so have no direct SQL happening.

I hope this explains it a bit better.

John

Quick thoughts on what we are doing for security with .NET

2004-03-03T22:25:00Z

My work has an initiative to remove all login information from web.config and UDL files. The problem we were facing was that we still had to edit those files when we changed environments. ie., when you move from DEV to QA, you have to change the DB server you were connecting to.

Working with another person here, I developed a 2 level approach for .NET apps.

1 - We are using the built in encryption/decryption in .NET to read a login/password from an encrypted registry setting and have the .NET application impersonate that login. This works well as we are using it to connect it to some HR information.

2 - To deal with the environment issue, I set up a registry setting on all levels of the servers, including DEV, with a single value. It's value is DEV, QA, or PROD. When I need to create a DB connection, I read the registry, determine the environment based on the value and then read out the proper DB connection string from the web.config. The web.config file contains all 3 strings.

Since I am using integrated security, the actual login is hidden. We don't have to worry about someone copying the wrong web.config file into the wrong environment and thus causing issues.

I also connect to a Web Service for some security. We filter certain pages in different applications based on levels of security. I have been able to use the same principal for changing the Web Service URL so that the correct one is being hit.

I am still working out a way to do this with the UDL files, without redoing all of the COM+.

Any comments or ideas would be appreciated.

John Debnam
Programmer/Analyst

Intro with a little bit about me

2004-03-02T00:38:00Z

My job entails new development and support of current ASP.NET applications and support of current asp applications. I will be attending the DevDays in Minneapolis on Mar 11. I have been part of our security development team here at work. I have set up code to use .NET's internal encrypted registry settings to do impersonation and then an unencrypted registry setting to read environmental settings to know what database to use and what web service to use to verify security. John