[Javascript] DevToolbar

[Conleyj at kubota-kma.com (James Conley)]

1) viewstate can be encrypted.
2) checksum validation can be run on viewstate to verify that it has not
changed on the client side
3) Viewstate can be stored server-side to alievate security issues
4) As Nick says "You need to ensure that every single character that is
submitted to the server is validated *by the server*, or your
application/site is at risk." This cannot be emphazised enough if you
are working with Internet applications. If you are only working on
intranet applications and are willing to a) trust your users not to be
malicious and b) trust that your firewall will keep out any malicious
hackers from getting onto your intranet then I wish you the best of
luck. 

http://msdn.microsoft.com/msdnmag/issues/03/02/CuttingEdge/

Viewstate is not a security hole per se, but just like query strings and
other hidden fields you may have used in the past, it's a potential
vehicle for malicious code. Since the view state is encoded, protected,
and validated, it does provide more security features than other hidden
fields that you may use for your own programming purposes.

...snip....
 
Many developers are hesitant to use view state because it's stored in a
hidden field and left on the client where it has the potential for
compromise. As Figure 2 shows, the information can be read by viewing
the source of the page. While this action alone is not a threat to the
application, having the view state on the client is a potential security
issue because it is information that all ASP.NET pages contain and
transmit to the Web server for processing.

.....<snip>....

This is not a bug per se and opens holes for attacks only if the basic
rules of data validation and data checking are not enforced. But this,
you understand, is a more general problem when you're trying to write
secure code.

...snip....

If EnableViewStateMac is True, then when the page posts back the
encrypted view state is algorithmically checked to verify that it has
not been tampered with on the client. The net effect is that you might
be able to read the contents of the view state, but to replace it you
need the encryption key, which is in the Web server's LSA.

james c


-----Original Message-----
From: javascript-bounces@xxxxxxxxxx
[mailto:javascript-bounces@xxxxxxxxxx] On Behalf Of Nick Fitzsimons
Sent: Thursday, February 16, 2006 3:55 AM
To: [JavaScript List]
Cc: [JavaScript List]
Subject: Re: [Javascript] DevToolbar


> Is the aspnet viewstate a defence against this kind of pagetampering, 
> or does it also simply accept changes? How do other languages protect 
> themselves?
> Is there any easy way of protecting the pages against these tools?

As others have pointed out, your server should never trust any
information sent to it by the client, and that includes ASP.NET
viewstate. In *any* JavaScript-capable browser you can type the
following into the location bar (names/ids from viewing the source of
blogs.msdn.com):

javascript:void(document.getElementById("__aspnetForm").elements["__VIEW
STATE"].value
= "some spurious rubbish")

and the viewstate is invalid. Thus, without any need for "hacker tools",
ASP.NET applications can have their state removed or changed. (Cookies
can be manipulated the same way.)

So you need to ensure that every single character that is submitted to
the server is validated *by the server*, or your application/site is at
risk.

Regards,

Nick.
--
Nick Fitzsimons
http://www.nickiftz.co.uk/