Hernan de Lahitte's blog
.NET Development from the trenches
Sign in
|
Join
Home
Contact
About
RSS
Atom
Comments RSS
Search
Tags
.NET General
Architecture
EDRA (Shadowfax)
Forms Authentication
GAT
MBI 3
Patterns & Practices
Security
Web Services
WSSF
News
Visit these related links:
Digit Factory S.R.L.
Patterns & Practices
Web Service Software Factory: Modeling Edition
ESB Guidance
Navigation
Home
Blogs
Archives
September 2009 (1)
July 2009 (2)
June 2009 (4)
May 2009 (2)
April 2009 (7)
December 2008 (1)
November 2008 (1)
September 2008 (1)
July 2008 (1)
June 2008 (2)
March 2008 (1)
January 2007 (1)
November 2006 (1)
October 2006 (1)
May 2006 (1)
December 2005 (2)
November 2005 (2)
September 2005 (1)
August 2005 (1)
June 2005 (2)
May 2005 (3)
March 2005 (1)
February 2005 (1)
January 2005 (1)
December 2004 (1)
November 2004 (2)
October 2004 (1)
September 2004 (1)
August 2004 (3)
July 2004 (4)
June 2004 (6)
May 2004 (3)
April 2004 (4)
March 2004 (8)
February 2004 (3)
Books
Writing Secure Code, Second Edition
.NET Framework Security
Security Engineering...
Newsgroups
About .NET security.
ASP.NET security.
Others
Disclaimer
Author Bio
Security
Security Developer Center
Building Secure ASP.NET Applications
Threats and Countermeasures
.NET Framework Security
Writing Secure Code
Keith Brown's web site
NCrypto project
Security Tools
Never Trust User Input: The ASP.NET ViewState case
This morning I came across an interesting post about user input validation (
ASP.NET __VIEWSTATE crypto validation prone to replay attacks
) and the popular ASP.NET viewstate artifact that many people use thinking their state information (Read: User Input data in transit) is secured by the ASP.NET infrastructure. I know that you may already validate “server-side” your sensitive input data against your “trusted” backends, nevertheless, you might take a look at the above article and
this
summary posted by
Scott
.
From Scott summary post:
The point is,
don't trust view state
(or the data that is put there by Web controls, such as the DataGrid). That is, if you have important information, such as pricing data, it's OK if it is placed in view state (such as in a row in a DataGrid), but don't grab the pricing data to charge by just poking around the view state (as in programmatically accessing the contents of a DataGrid). Instead, if you need to get pricing information (or any other important bit of information) for the final order processing, it is imperative that you
requery the database
.
Enjoy the reading.
Published Wednesday, May 04, 2005 10:19 AM by
HernanDL
Filed under:
Security
Comments
#
re: Never Trust User Input: The ASP.NET ViewState case
Wednesday, May 04, 2005 9:19 AM by
Wallym
I agree with you. :-) However, I had a customer that was adament that they would not requery the database for pricing information. They believed that their situation was valid. Its a battle I lost, though I did state that I felt that their reasons were not valid.
#
re: Never Trust User Input: The ASP.NET ViewState case
Wednesday, May 04, 2005 11:52 AM by
Scott Mitchell
Eep, you chose to summarize my article with the worst sentence in the entire entry! Chalk full of parenthetical side comments and a bit of a run-on... if I wrote this in a book my editor would likely vomit all over his keyboard.
Wally, what was your client's rationale for NOT requerying the database for pricing data? Was it solely because of performance reasons?
#
re: Never Trust User Input: The ASP.NET ViewState case
Wednesday, May 04, 2005 12:01 PM by
Daniel Auger
Server-side viewstate is another option.
http://msdn.microsoft.com/msdnmag/issues/03/02/CuttingEdge/
In that article, if I remember correctly, he stores thew viewstate in a file on the server, but it is very easy to convert the example to use a session variable for the viewstate.
#
re: Never Trust User Input: The ASP.NET ViewState case
Friday, May 06, 2005 9:17 AM by
Hernan de Lahitte
Sorry Scott about my sentence choice. However, I suggest you to polish your writing style so your boss won't feel sick when reviewing you. :-)
Leave a Comment
Title
(required)
Name
(required)
Your URL
(optional)
Comments
(required)
Remember Me?