Is Hiding Server Controls Enough ?

[Mr Newbie]

I was thinking about developing a workflow application yesterday and was
musing over the different approaches than one could take in restricting
specific actions on a ticket( Form ) at any said stage.

One approach I have used on other systems is to prevent the action buttons
appearing. For example, if one did not have the Role of Administrator, one
would be prevented from deleting a ticket not created by oneself.

However, it did occur to me that there was a possibility of manually
constructing the button code in the page which has been rendered to the
client.

If you have a button which was visible=false ( Not HTML hidden ), then would
it be possible to invoke the backend function by manually adding the tag/id
etc for this button ?

I guess I could experiement, but I wondered if there was an instant answer
available ?

 

[John Timney \( MVP \)]

no - hiding is not enough,as someone could simply reconstruct your hidden
elemtns.

At the least you need to use some form of access control, to verify who the
logged in user user is and then display the controls or not based on that
role.

--
Regards

John Timney
ASP.NET MVP
Microsoft Regional Director

 

[Mr Newbie]

OK, thanks for the reply. I do intend to use access control but I think
perhaps I didnt make myself clear enough.

Lets say that we have two users 'Jon' and 'Sarah'. John may delete anything
but 'Sarah' may only delete her own work.

Before the form is rendered, the control logic determines that this document
belongs to 'Jon' but that it is 'Sarah' who has opened it. Therfore the
logic sets the Visible property of the 'Delete' button to False so it is
not rendered to the client.

However, 'Sarah' is feeling evil today and decides to enter the tags she's
seen before on her own documents and loads the page, or at least somehow
manages to add this object into the document displayed and invoke its click
event

Will this activate the Server side click event for this button regardless of
if it has been displayed or not ?

Regards Mr Newbie . . .

 

[Kevin Spencer]

Yo Mr. Newbie,

Will this activate the Server side click event for this button regardless
of if it has been displayed or not ?

No it will not. It would require a great deal of skill to accomplish
something like this, if you do it correctly. That is, use an HtmlInputButton
Control or a Button WebControl (used as a Command Button would be best, as
this does not create a Submit button, and makes the job more difficult for
the would-be hacker). These controls use JavaScript to send information
about themselves in hidden form fields back to the server. So, the first
obstacle for Sarah would be not only to add a Delete button the the HTML,
but also to add the appropriate information into the hidden form fields. She
would also have to enter the correct information into the hidden ViewState
form field, in order to trick the server into reproducing the Page class and
Controls as if its previous state had included the button. This is because
HTTP is stateless. The server relies on the Request coming from the client
to reproduce its State if the Page is posted back. It has to build the Page
from scratch with each Request.

Sarah's only resort would be to get on to the computer right after John has
loaded the page in the state she wants, and to copy the HTML to another file
she could hide somewhere. Then, when John is gone, she could pull up the
page with John's information in it, and merge the HTML to create the state
she needs. Of course, this could be accounted for by a clever developer as
well.

In short, using Server Controls would indeed be your best bet.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
A watched clock never boils.

 

[Mr Newbie]

Thanks for that reply.

In essence, we are saying that it is technically possible, but highly
unlikely that a hacker would go to these lengths. At least not unless the
information contained was so inviting as to entice the would-be hacker to
have ago.

the would-be hacker). These controls use JavaScript to send information
about themselves in hidden form fields back to the server. So, the first

What information would it be ?, I guess its some sort of context mapping
which tells the server which server control is being mapped to which client
side field etc ???

Thanks again for taking the time to reply. I guess when I'm designing
systems I like to think from the hackers point of view as much as possible.
I suppose that says something about my mind set, but I would like to think
its from a defensive and positive point of view rather than from a
criminality angle!

Cheers - Mr Newbie . . .

 

[Kevin Spencer]

Hi Inimitable,

I like the way you like to think when designing!

In answer to your question, and in anticipation of similar follow-up
questions:

Basically, ASP.Net creates 2 hidden HTML form fields for server-side event
handling:

<input type="hidden" name="__EVENTTARGET" value="" />
<input type="hidden" name="__EVENTARGUMENT" value="" />

The "__EVENTTARGET" field is populated with the client ID of the Control
that causes the event, via a JavaScript client-side event handler inserted
into the HTML form tag by the ASP.Net engine. The "__EVENTARGUMENT" field is
populated with (if any) data that is passed along, in much the same way that
typical executable events pass Event Arguments. For most controls, this
field is not populated.

The ViewState is stored in another hidden HTML for field:

<input type="hidden" name="__VIEWSTATE" value="dDwtOT..." />

The data in the ViewState is compressed, and looks like gibberish, except to
the ASP.Net engine.

Upon PostBack, during the *LoadViewState* Event Handler method, the
ViewState is read, to prepare for restoring the Controls that will be
rebuilt to the state they were in during the previous Request.

All of the HTML form field values are read during the *LoadPostData* Event
Handler method of the page, providing the current client-side state of the
Page and Controls in it.

The *Load* method re-creates all of the Controls in the Page (including the
Page), and sets them to the state they were in during the previous Request.

Next, PostBack changes are processed by the Page and Controls in the page,
via the *RaisePostBackChangedEvent* method of the Page. This is where the
data in the form is compared with the PostBack data. Change events are fired
for Controls that have had their state changed, and have event handlers
specified to handle the Change event for those Controls. These events are
also handled at this time.

After that, the* RaisePostBackEvent* method is executed, which handles the
client-side event that caused the PostBack. At this point, the event-related
form field values are read, and an event is created, which is processed by
the affected Control's event handler for that event.

The *PreRender* event is executed next, which handles any additional
housekeeping that may be needed, and any code that the developer has defined
for additional pre-render processing. Sometimes changes must be made after
all of the current changes and events have been processed. This is the app's
last chance to do this.

The *SaveState* method saves the current client state of the Page to the
ViewState.

And finally, the page is *Render*ed to the browser.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
A watched clock never boils.

 

[Mr Newbie]

Thanks for your reply.

<input type="hidden" name="__EVENTTARGET" value="" />
<input type="hidden" name="__EVENTARGUMENT" value="" />

The "__EVENTTARGET" field is populated with the client ID of the Control
that causes the event, via a JavaScript client-side event handler inserted
into the HTML form tag by the ASP.Net engine. The "__EVENTARGUMENT" field
is populated with (if any) data that is passed along, in much the same way
that typical executable events pass Event Arguments. For most controls,
this field is not populated.

I dont see these two fields in my rendered output. Or any obvious insertion
into the <Form> tag. Below is a sample form, so I'm not sure where I am
going wrong here.

<form name="Form1" method="post" action="WebForm2.aspx" id="Form1">

Regards - Mr Newbie


<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<HEAD>
<title>WebForm2</title>
<meta name="GENERATOR" content="Microsoft Visual Studio .NET 7.1">
<meta name="CODE_LANGUAGE" content="Visual Basic .NET 7.1">
<meta name="vs_defaultClientScript" content="JavaScript">
<meta name="vs_targetSchema"
content="http://schemas.microsoft.com/intellisense/ie5">
</HEAD>
<body MS_POSITIONING="GridLayout">
<form name="Form1" method="post" action="WebForm2.aspx" id="Form1">
<input type="hidden" name="__VIEWSTATE"
value="dDwtMTE1NTQwNjg2NTs7PvczoUrHH4pklZ9uELF+TO+dJV7q" />

<input type="submit" name="Button1" value="Button" id="Button1"
style="Z-INDEX: 101; LEFT: 40px; POSITION: absolute; TOP: 136px" />
<input type="submit" name="Button2" value="Button" id="Button2"
style="Z-INDEX: 102; LEFT: 40px; POSITION: absolute; TOP: 184px" />
<input name="TextBox1" type="text" id="TextBox1" style="Z-INDEX: 103;
LEFT: 32px; POSITION: absolute; TOP: 24px" />
<input name="TextBox2" type="text" id="TextBox2" style="Z-INDEX: 104;
LEFT: 40px; POSITION: absolute; TOP: 72px" />
</form>
</body>
</HTML>

 

[Mr Newbie]

Further investegation seems to indicate that these hidden fields only appear
when controls such as textboxes etc, have he Autopostback=true

If one has two buttons only , or the other controls do not have
autopostback=true, then these are not generated. I can only conclude that
the submitting button is sent along with the request header in this case as
usual.

I (guess) this is because when the form is submitted indirectly by controls
which could not normally cause a post, and therfore some other means of
recording the initiating event has to be provided for the server side logic.

I may be wrong, but it's good enough as a theory to be either validated or
burnt during debate.

 

[Bruce Barker]

you are correct to be worried about this. asp.net has added more security
checking for these cases, but you never have enough.

hacking asp.net pages is very easy, as the html protocol is well known. to
hack

all you need is notepad and a browser. using firefox or an IE addin really
helps. you hackers hiots the site and get a list of postback field values by
viewing source, info on firefox will list forms and their fields, IE addins
do the same.

once you have the field you make an html file:

<form method=post action="url of site to attack" >

used by auto postback - fill in control name to fake control post

<input type=hidden name="__EVENTTARGET" value="">
<input type=hidden name="__EVENTARGUMENT" value="">

magical viewstate - copy value from view source of actual browse

<input type=hidden name="__VIEWSTATE" value="">

add any field values to post back setting name to the control name,
value = to value to post back

<input type=hidden name="field1name" value="my value">

to postback a button, say your delete

<input type=hidden name="deletebuttonname" value="submit">

</form>
<script>document.forms[0].submit();</script>

just load the html in the browser, and it will do the atack. you should try
this on your site, should be easy.

you should have all BI logic re-verify the permissions. i use stored procs,
and have the procs recheck also.

-- bruce (sqlwork.com)

 

[Mr Newbie]

Thanks for the input Bruce,

I get paranoid about security when designing anything for a client because
if you get it wrong as a freelance/contractor, you really don't want to be
on the receiving end of any law suit, professional indemnity or not, its not
a good position to be in.

I am going to try this out in the next couple of days when I get a minute as
I thinks it's worth some further investigation and report my findings back
to the group/thread.

--
Best Regards

The Inimitable Mr Newbie º¿º

-------------------------------------------------------------

you are correct to be worried about this. asp.net has added more security
checking for these cases, but you never have enough.

hacking asp.net pages is very easy, as the html protocol is well known. to
hack

all you need is notepad and a browser. using firefox or an IE addin really
helps. you hackers hiots the site and get a list of postback field values
by viewing source, info on firefox will list forms and their fields, IE
addins do the same.

once you have the field you make an html file:

<form method=post action="url of site to attack" >

used by auto postback - fill in control name to fake control post

<input type=hidden name="__EVENTTARGET" value="">
<input type=hidden name="__EVENTARGUMENT" value="">

magical viewstate - copy value from view source of actual browse

<input type=hidden name="__VIEWSTATE" value="">

add any field values to post back setting name to the control name,
value = to value to post back

<input type=hidden name="field1name" value="my value">

to postback a button, say your delete

<input type=hidden name="deletebuttonname" value="submit">

</form>
<script>document.forms[0].submit();</script>

just load the html in the browser, and it will do the atack. you should
try this on your site, should be easy.

you should have all BI logic re-verify the permissions. i use stored
procs, and have the procs recheck also.

-- bruce (sqlwork.com)

I was thinking about developing a workflow application yesterday and was
musing over the different approaches than one could take in restricting
specific actions on a ticket( Form ) at any said stage.

One approach I have used on other systems is to prevent the action
buttons appearing. For example, if one did not have the Role of
Administrator, one would be prevented from deleting a ticket not created
by oneself.

However, it did occur to me that there was a possibility of manually
constructing the button code in the page which has been rendered to the
client.

If you have a button which was visible=false ( Not HTML hidden ), then
would it be possible to invoke the backend function by manually adding
the tag/id etc for this button ?

I guess I could experiement, but I wondered if there was an instant
answer available ?

 

[Mr Newbie]

Actually I just tested it. You CAN make the server invoke a button which was
made visible=false. I just used the method you prescribed and it does work
'Unfortunately'.

OK, well thats one method I definately will avoid. And I will have to be
more vigilant in my methods of ensuring security is maintained.

Thanks.

--
Best Regards

The Inimitable Mr Newbie º¿º

Thanks for the input Bruce,

I get paranoid about security when designing anything for a client because
if you get it wrong as a freelance/contractor, you really don't want to be
on the receiving end of any law suit, professional indemnity or not, its
not a good position to be in.

I am going to try this out in the next couple of days when I get a minute
as I thinks it's worth some further investigation and report my findings
back to the group/thread.

--
Best Regards

The Inimitable Mr Newbie º¿º

-------------------------------------------------------------

you are correct to be worried about this. asp.net has added more security
checking for these cases, but you never have enough.

hacking asp.net pages is very easy, as the html protocol is well known.
to hack

all you need is notepad and a browser. using firefox or an IE addin
really helps. you hackers hiots the site and get a list of postback field
values by viewing source, info on firefox will list forms and their
fields, IE addins do the same.

once you have the field you make an html file:

<form method=post action="url of site to attack" >

used by auto postback - fill in control name to fake control post

<input type=hidden name="__EVENTTARGET" value="">
<input type=hidden name="__EVENTARGUMENT" value="">

magical viewstate - copy value from view source of actual browse

<input type=hidden name="__VIEWSTATE" value="">

add any field values to post back setting name to the control name,
value = to value to post back

<input type=hidden name="field1name" value="my value">

to postback a button, say your delete

<input type=hidden name="deletebuttonname" value="submit">

</form>
<script>document.forms[0].submit();</script>

just load the html in the browser, and it will do the atack. you should
try this on your site, should be easy.

you should have all BI logic re-verify the permissions. i use stored
procs, and have the procs recheck also.

-- bruce (sqlwork.com)

I was thinking about developing a workflow application yesterday and was
musing over the different approaches than one could take in restricting
specific actions on a ticket( Form ) at any said stage.

One approach I have used on other systems is to prevent the action
buttons appearing. For example, if one did not have the Role of
Administrator, one would be prevented from deleting a ticket not created
by oneself.

However, it did occur to me that there was a possibility of manually
constructing the button code in the page which has been rendered to the
client.

If you have a button which was visible=false ( Not HTML hidden ), then
would it be possible to invoke the backend function by manually adding
the tag/id etc for this button ?

I guess I could experiement, but I wondered if there was an instant
answer available ?

 

[Mr Newbie]

Actually, I have manged to 'Fake' the postback and cause a hidden button to
fire it's click event with a great deal of ease *suprisingly*.

In another post further to the left, Bruce Barker outlined a simple method,
I tested it and unfortunately you *Can* fake it.

It's unfortunate that we have to use our creative talents to thwart the damn
hackers, but I guess thats life.

 

[Kevin Spencer]

Hi Mr. N,

In another post further to the left, Bruce Barker outlined a simple
method, I tested it and unfortunately you *Can* fake it.

There are workarounds for this. You can add information into ViewState,
which you can use to detect whether or not the page has been hacked. For
example, you might put the current Date/Time into ViewState, and not allow
the event to fire unless the ViewState contains (1) a DateTime value with
the key name you assign to it, and (2) a value that is within n number of
minutes of the current DateTime. That's off the top of my head. I'm sure you
or I or Bruce couold think up others. As the data is compressed, it would be
hard to even tell that it is there, much less what it is.

It's unfortunate that we have to use our creative talents to thwart the
damn hackers, but I guess thats life.

Yeah, the Internet used to be fun. Now it's too much like work!

The event form fields are only added when a Server Control has a client-side
event handler assigned to it.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
A watched clock never boils.

 

[Mr Newbie]

Thanks for your reply Kevin.

Your points are noted regarding the anti-hack, and I will look into this.

The event form fields are only added when a Server Control has a
client-side event handler assigned to it.

I created a form with two buttons on it and each had a handler associated
with the click event but the two fields did not appear. It was only when I
added extra controls and turned on Autpostback, that the fields emerged in
the render.

-
Best Regards

The Inimitable Mr Newbie º¿º

 

[Kevin Spencer]

Yes, sorry about the confusion. It has to have AutoPostBack turned on in
order to raise the event. So, just having the event-handler code won't cause
the PostBack necessary to raise the event. That's what I meant, but it
didn't come out that way!

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
A watched clock never boils.

 

[Mr Newbie]

No worries. Thanks for your reply.

 

[John Timney \( MVP \)]

its worth reading up on the net2 membership and login controls to undertand
where you can better apply security.

http://beta.asp.net/QUICKSTART/aspnet/doc/security/default.aspx

The problem wth just hiding controls is that their server events may still
be accessible as you have found. You need to ensure that fucntionality is
not avaialbale regardless of the interface requesting the methods -
technically you need to render the methods inaccessible based on a users
authorised role in your application.

--
Regards

John Timney
ASP.NET MVP
Microsoft Regional Director

Actually I just tested it. You CAN make the server invoke a button which
was made visible=false. I just used the method you prescribed and it does
work 'Unfortunately'.

OK, well thats one method I definately will avoid. And I will have to be
more vigilant in my methods of ensuring security is maintained.

Thanks.

--
Best Regards

The Inimitable Mr Newbie º¿º

Thanks for the input Bruce,

I get paranoid about security when designing anything for a client
because if you get it wrong as a freelance/contractor, you really don't
want to be on the receiving end of any law suit, professional indemnity
or not, its not a good position to be in.

I am going to try this out in the next couple of days when I get a minute
as I thinks it's worth some further investigation and report my findings
back to the group/thread.

--
Best Regards

The Inimitable Mr Newbie º¿º

-------------------------------------------------------------

you are correct to be worried about this. asp.net has added more
security checking for these cases, but you never have enough.

hacking asp.net pages is very easy, as the html protocol is well known.
to hack

all you need is notepad and a browser. using firefox or an IE addin
really helps. you hackers hiots the site and get a list of postback
field values by viewing source, info on firefox will list forms and
their fields, IE addins do the same.

once you have the field you make an html file:

<form method=post action="url of site to attack" >

used by auto postback - fill in control name to fake control post

<input type=hidden name="__EVENTTARGET" value="">
<input type=hidden name="__EVENTARGUMENT" value="">

magical viewstate - copy value from view source of actual browse

<input type=hidden name="__VIEWSTATE" value="">

add any field values to post back setting name to the control name,
value = to value to post back

<input type=hidden name="field1name" value="my value">

to postback a button, say your delete

<input type=hidden name="deletebuttonname" value="submit">

</form>
<script>document.forms[0].submit();</script>

just load the html in the browser, and it will do the atack. you should
try this on your site, should be easy.

you should have all BI logic re-verify the permissions. i use stored
procs, and have the procs recheck also.

-- bruce (sqlwork.com)





I was thinking about developing a workflow application yesterday and was
musing over the different approaches than one could take in restricting
specific actions on a ticket( Form ) at any said stage.

One approach I have used on other systems is to prevent the action
buttons appearing. For example, if one did not have the Role of
Administrator, one would be prevented from deleting a ticket not
created by oneself.

However, it did occur to me that there was a possibility of manually
constructing the button code in the page which has been rendered to the
client.

If you have a button which was visible=false ( Not HTML hidden ), then
would it be possible to invoke the backend function by manually adding
the tag/id etc for this button ?

I guess I could experiement, but I wondered if there was an instant
answer available ?

 

[Mr Newbie]

Thanks John,

By the way, what is your region ?

Yes, I have done a little with ASP.NET 2.0 Personalisation and Membership,
so I am aware of some of the basics, however, I think that one has to assume
there is a loopholes and try ones best to find them before someone finds
them for you.

Thanks for your replies; it all goes into my internal cookbook for future
reference. As I said in another reply in the same thread, its just a pity
that mankind has to expend so much energy to ensure the defeat of our
shortcomings (Criminal Elements).

I often muse over what the outcome would be or not if we were to co-ordinate
world efforts using the total sum of mental end physical energy expended on
stopping people behaving in a manner other than in alignment of the common
good.

I know that's a bit philosophical for this newsgroup, but what the hey !

--
Best Regards

The Inimitable Mr Newbie º¿º

----------------------------------------------------

its worth reading up on the net2 membership and login controls to
undertand where you can better apply security.

http://beta.asp.net/QUICKSTART/aspnet/doc/security/default.aspx

The problem wth just hiding controls is that their server events may still
be accessible as you have found. You need to ensure that fucntionality is
not avaialbale regardless of the interface requesting the methods -
technically you need to render the methods inaccessible based on a users
authorised role in your application.

--
Regards

John Timney
ASP.NET MVP
Microsoft Regional Director

Actually I just tested it. You CAN make the server invoke a button which
was made visible=false. I just used the method you prescribed and it
does work 'Unfortunately'.

OK, well thats one method I definately will avoid. And I will have to be
more vigilant in my methods of ensuring security is maintained.

Thanks.

--
Best Regards

The Inimitable Mr Newbie º¿º

Thanks for the input Bruce,

I get paranoid about security when designing anything for a client
because if you get it wrong as a freelance/contractor, you really don't
want to be on the receiving end of any law suit, professional indemnity
or not, its not a good position to be in.

I am going to try this out in the next couple of days when I get a
minute as I thinks it's worth some further investigation and report my
findings back to the group/thread.

--
Best Regards

The Inimitable Mr Newbie º¿º

-------------------------------------------------------------

you are correct to be worried about this. asp.net has added more
security checking for these cases, but you never have enough.

hacking asp.net pages is very easy, as the html protocol is well known.
to hack

all you need is notepad and a browser. using firefox or an IE addin
really helps. you hackers hiots the site and get a list of postback
field values by viewing source, info on firefox will list forms and
their fields, IE addins do the same.

once you have the field you make an html file:

<form method=post action="url of site to attack" >

used by auto postback - fill in control name to fake control post

<input type=hidden name="__EVENTTARGET" value="">
<input type=hidden name="__EVENTARGUMENT" value="">

magical viewstate - copy value from view source of actual browse

<input type=hidden name="__VIEWSTATE" value="">

add any field values to post back setting name to the control name,
value = to value to post back

<input type=hidden name="field1name" value="my value">

to postback a button, say your delete

<input type=hidden name="deletebuttonname" value="submit">

</form>
<script>document.forms[0].submit();</script>

just load the html in the browser, and it will do the atack. you should
try this on your site, should be easy.

you should have all BI logic re-verify the permissions. i use stored
procs, and have the procs recheck also.

-- bruce (sqlwork.com)





I was thinking about developing a workflow application yesterday and
was musing over the different approaches than one could take in
restricting specific actions on a ticket( Form ) at any said stage.

One approach I have used on other systems is to prevent the action
buttons appearing. For example, if one did not have the Role of
Administrator, one would be prevented from deleting a ticket not
created by oneself.

However, it did occur to me that there was a possibility of manually
constructing the button code in the page which has been rendered to
the client.

If you have a button which was visible=false ( Not HTML hidden ), then
would it be possible to invoke the backend function by manually adding
the tag/id etc for this button ?

I guess I could experiement, but I wondered if there was an instant
answer available ?

 

[Kevin Spencer]

I often muse over what the outcome would be or not if we were to

co-ordinate world efforts using the total sum of mental end physical
energy expended on stopping people behaving in a manner other than in
alignment of the common good.

The outcome would be the Kingdom of Heaven!

--
:-D,

Kevin Spencer
Microsoft MVP
..Net Developer
A watched clock never boils.

Thanks John,

By the way, what is your region ?

Yes, I have done a little with ASP.NET 2.0 Personalisation and Membership,
so I am aware of some of the basics, however, I think that one has to
assume there is a loopholes and try ones best to find them before
someone finds them for you.

Thanks for your replies; it all goes into my internal cookbook for future
reference. As I said in another reply in the same thread, its just a pity
that mankind has to expend so much energy to ensure the defeat of our
shortcomings (Criminal Elements).

I often muse over what the outcome would be or not if we were to
co-ordinate world efforts using the total sum of mental end physical
energy expended on stopping people behaving in a manner other than in
alignment of the common good.

I know that's a bit philosophical for this newsgroup, but what the hey !

--
Best Regards

The Inimitable Mr Newbie º¿º

----------------------------------------------------

its worth reading up on the net2 membership and login controls to
undertand where you can better apply security.

http://beta.asp.net/QUICKSTART/aspnet/doc/security/default.aspx

The problem wth just hiding controls is that their server events may
still be accessible as you have found. You need to ensure that
fucntionality is not avaialbale regardless of the interface requesting
the methods - technically you need to render the methods inaccessible
based on a users authorised role in your application.

--
Regards

John Timney
ASP.NET MVP
Microsoft Regional Director

Actually I just tested it. You CAN make the server invoke a button which
was made visible=false. I just used the method you prescribed and it
does work 'Unfortunately'.

OK, well thats one method I definately will avoid. And I will have to be
more vigilant in my methods of ensuring security is maintained.

Thanks.

--
Best Regards

The Inimitable Mr Newbie º¿º



Thanks for the input Bruce,

I get paranoid about security when designing anything for a client
because if you get it wrong as a freelance/contractor, you really don't
want to be on the receiving end of any law suit, professional indemnity
or not, its not a good position to be in.

I am going to try this out in the next couple of days when I get a
minute as I thinks it's worth some further investigation and report my
findings back to the group/thread.

--
Best Regards

The Inimitable Mr Newbie º¿º

-------------------------------------------------------------

you are correct to be worried about this. asp.net has added more
security checking for these cases, but you never have enough.

hacking asp.net pages is very easy, as the html protocol is well
known. to hack

all you need is notepad and a browser. using firefox or an IE addin
really helps. you hackers hiots the site and get a list of postback
field values by viewing source, info on firefox will list forms and
their fields, IE addins do the same.

once you have the field you make an html file:

<form method=post action="url of site to attack" >

used by auto postback - fill in control name to fake control post

<input type=hidden name="__EVENTTARGET" value="">
<input type=hidden name="__EVENTARGUMENT" value="">

magical viewstate - copy value from view source of actual browse

<input type=hidden name="__VIEWSTATE" value="">

add any field values to post back setting name to the control name,
value = to value to post back

<input type=hidden name="field1name" value="my value">

to postback a button, say your delete

<input type=hidden name="deletebuttonname" value="submit">

</form>
<script>document.forms[0].submit();</script>

just load the html in the browser, and it will do the atack. you
should try this on your site, should be easy.

you should have all BI logic re-verify the permissions. i use stored
procs, and have the procs recheck also.

-- bruce (sqlwork.com)





I was thinking about developing a workflow application yesterday and
was musing over the different approaches than one could take in
restricting specific actions on a ticket( Form ) at any said stage.

One approach I have used on other systems is to prevent the action
buttons appearing. For example, if one did not have the Role of
Administrator, one would be prevented from deleting a ticket not
created by oneself.

However, it did occur to me that there was a possibility of manually
constructing the button code in the page which has been rendered to
the client.

If you have a button which was visible=false ( Not HTML hidden ),
then would it be possible to invoke the backend function by manually
adding the tag/id etc for this button ?

I guess I could experiement, but I wondered if there was an instant
answer available ?

 

[John Timney \( MVP \)]

not that really bad movie I hope.......lol

--
Regards

John Timney
ASP.NET MVP
Microsoft Regional Director

I often muse over what the outcome would be or not if we were to
co-ordinate world efforts using the total sum of mental end physical
energy expended on stopping people behaving in a manner other than in
alignment of the common good.

The outcome would be the Kingdom of Heaven!

--
:-D,

Kevin Spencer
Microsoft MVP
.Net Developer
A watched clock never boils.

Thanks John,

By the way, what is your region ?

Yes, I have done a little with ASP.NET 2.0 Personalisation and
Membership, so I am aware of some of the basics, however, I think that
one has to assume there is a loopholes and try ones best to find them
before someone finds them for you.

Thanks for your replies; it all goes into my internal cookbook for future
reference. As I said in another reply in the same thread, its just a pity
that mankind has to expend so much energy to ensure the defeat of our
shortcomings (Criminal Elements).

I often muse over what the outcome would be or not if we were to
co-ordinate world efforts using the total sum of mental end physical
energy expended on stopping people behaving in a manner other than in
alignment of the common good.

I know that's a bit philosophical for this newsgroup, but what the hey !

--
Best Regards

The Inimitable Mr Newbie º¿º

----------------------------------------------------

its worth reading up on the net2 membership and login controls to
undertand where you can better apply security.

http://beta.asp.net/QUICKSTART/aspnet/doc/security/default.aspx

The problem wth just hiding controls is that their server events may
still be accessible as you have found. You need to ensure that
fucntionality is not avaialbale regardless of the interface requesting
the methods - technically you need to render the methods inaccessible
based on a users authorised role in your application.

--
Regards

John Timney
ASP.NET MVP
Microsoft Regional Director

Actually I just tested it. You CAN make the server invoke a button
which was made visible=false. I just used the method you prescribed
and it does work 'Unfortunately'.

OK, well thats one method I definately will avoid. And I will have to
be more vigilant in my methods of ensuring security is maintained.

Thanks.

--
Best Regards

The Inimitable Mr Newbie º¿º



Thanks for the input Bruce,

I get paranoid about security when designing anything for a client
because if you get it wrong as a freelance/contractor, you really
don't want to be on the receiving end of any law suit, professional
indemnity or not, its not a good position to be in.

I am going to try this out in the next couple of days when I get a
minute as I thinks it's worth some further investigation and report my
findings back to the group/thread.

--
Best Regards

The Inimitable Mr Newbie º¿º

-------------------------------------------------------------

you are correct to be worried about this. asp.net has added more
security checking for these cases, but you never have enough.

hacking asp.net pages is very easy, as the html protocol is well
known. to hack

all you need is notepad and a browser. using firefox or an IE addin
really helps. you hackers hiots the site and get a list of postback
field values by viewing source, info on firefox will list forms and
their fields, IE addins do the same.

once you have the field you make an html file:

<form method=post action="url of site to attack" >

used by auto postback - fill in control name to fake control post

<input type=hidden name="__EVENTTARGET" value="">
<input type=hidden name="__EVENTARGUMENT" value="">

magical viewstate - copy value from view source of actual browse

<input type=hidden name="__VIEWSTATE" value="">

add any field values to post back setting name to the control
name, value = to value to post back

<input type=hidden name="field1name" value="my value">

to postback a button, say your delete

<input type=hidden name="deletebuttonname" value="submit">

</form>
<script>document.forms[0].submit();</script>

just load the html in the browser, and it will do the atack. you
should try this on your site, should be easy.

you should have all BI logic re-verify the permissions. i use stored
procs, and have the procs recheck also.

-- bruce (sqlwork.com)





I was thinking about developing a workflow application yesterday and
was musing over the different approaches than one could take in
restricting specific actions on a ticket( Form ) at any said stage.

One approach I have used on other systems is to prevent the action
buttons appearing. For example, if one did not have the Role of
Administrator, one would be prevented from deleting a ticket not
created by oneself.

However, it did occur to me that there was a possibility of manually
constructing the button code in the page which has been rendered to
the client.

If you have a button which was visible=false ( Not HTML hidden ),
then would it be possible to invoke the backend function by manually
adding the tag/id etc for this button ?

I guess I could experiement, but I wondered if there was an instant
answer available ?