[AccessD] OT Question that will be simple for those that know

stuart at lexacorp.com.pg stuart at lexacorp.com.pg
Sun Oct 2 22:12:25 CDT 2005


On 2 Oct 2005 at 22:11, Bryan Carbonnell wrote:

> On 02/10/05, Jim Lawrence <accessd at shaw.ca> wrote:
> > Within many web pages there is starting to appear a piece of code which is
> > curious. It looks like encrypted imbedded coding created by some obfuscating
> > tool.
> >
> > The block starts like 'value="dDwtNjIxMjI0NzQwO3Q8O2w8aTwwPjtpP.... and so
> > on for, sometime 1000 plus characters. I would look it up on the internet
> > but do not know even how to describe it.
> >
> > Is this the result of an obfuscating process for ASPX pages? Yes, I am
> > designing in ASP.Net and no, I have never run across this before. (The
> > disadvantages of being self-taught.)
> 
> The only time that I have ever seen this is when a PostNuke site that
> I run was hacked. it too me about 3 days to "decode" it (don't ask me
> how I did it, I don't remember) and it was a redirect to or from a
> Warez site.
> 

Tell that to JC, he's got one on the Home page of his new his site :-)
<quote>
<input type="hidden" name="__VIEWSTATE" value="VUI/M........
(18 lines of characters stripped)
</quote>

>From http://aspalliance.com/articleViewer.aspx?aId=135&pId=

ViewState is used to track and restore the state values of controls that would 
otherwise be lost, either because those values do not post with the form or because 
they are not in the page html..

Also http://jroller.com/page/javadujour?entry=viewstate_is_evil_jsf_is:

_viewstate is evil, or why JSF is better than ASP.NET ASP.NET uses nasty 
_viewstate hidden field to track application state. For some reason MS geniuses 
thought that storing data in the session puts too much load on a web farm, so they 
decided to spread the load over the Net. Of course, they themselves know different 
ways to track the state, and they suggest developers to weigh all pro and cons and 
either to use _viewstate, or to turn it off and use session, or even to use persisted-to-
database state. But who would bother analysing, if most example code contains 
_viewstate? The consequences are devastating:

* tens of kilobytes of useless junk (especially if you display bunch of rows of data) are 
moved around the Net
* all pages must be HTML forms to store hidden fields
* a user cannot jump out from the application, and then navigate back using direct 
URL in the address bar, because there is nothing in the session
* result page is returned immediately in response to submitted HTML form to keep 
hidden fields, thus clean page reload is impossible and results in double submit.






More information about the AccessD mailing list