I\'m making a simple website that lists files from a certain folder. If the user has admin rights, the user can delete files by clicking the \"Delete\" button.
In my
They simply won't see the button or even 'recieve' it. Your server will not generate any button code sent to the person.
You have to think of it this way. The user never sees any asp code or is able to process it. They only receive html. You can further ensure this by looking at the html and seeing what has been generated.
So in that regard you are safe.
My question is: can I be sure that this method is safe against known-code attack if user modifies the webpage client-side aiming to click this invisible button? Or I have to make precautions in CodeBehind and verify user rights in button clicked event?
I personally would also put another piece of code in the click event. Verifying that click comes from the user who is authorized to click that button.
What you could also do is to add a button from code behind as this (Assuming you are putting this button into a panel called pnlButtons):
Button btnDeleteList = new Button();
btnDeleteList.Text = "Delete List";
btnDeleteList.Click += btnDeleteList_Click;
pnlButtons.Controls.Add(btnDeleteList);
In other words, if user is Admin - add a button, if user is not an admin - do not add. In this case you do not have to play around with visibility.
hope this helps.
Yes, setting a button's Visible
property to false is enough to prevent its Click
and Command
events from being raised, as long as you don't turn off the default WebForms security features.
You can easily test this by temporarily adding an always-visible <input>
element to your .aspx with the same name
as the rendered <asp:Button>
:
<input type="submit"
name="ctl00$ctl00$MainContent$LocalMainContent$FileList$ctrl0$ctl17"
value="Fake Delete" />
Click the fake Delete button when the real Delete button is invisible. You should get an "Invalid postback or callback argument. Event validation is enabled..." exception.
Important notes:
Visible
property to false within an if (!IsPostBack)
block because it's possible for an attacker to bypass that check. See this answer for more information.EnableEventValidation="False"
to the @Page
directive or <pages enableEventValidation="false" />
to Web.config.EnableViewStateMac="False"
to the @Page
directive or <pages enableViewStateMac="false" />
to Web.config. This would allow an attacker to tamper with the hidden __EVENTVALIDATION field and do other nasty things.