Introduction
POSTBACK in ASP.NET is an event
that occurs whenever an action is performed by a control in the ASP.NET page.
For example clicking a button on a ASP.NET form/page, causes data in that form
or page to be “posted back” to the server. This is an event and can be tracked or
detected using the “IsPostBack” property of the ASP.NET page. This
property simply allows the developer to check if the page is “called” or
“refreshed” as a result of a control event OR it is accessed for the first time. Button clicks, dropbox selection changes, or textbox changes, are all examples
of control events in ASP.NET. It returns “true” in the case of a control event and “false” in case it is accessed via link.
Often developers use this
property to be able detect first time loading of an ASP.NET form, to initialize
key variables like connection strings, or populate ASP.NET controls with field
values.
// Only if the form is accessed without raising a control event like a button click or selecting from a dropbox
If (!IsPostBack) {
// Initialize variables, controls
}
What happens if the developer mixes authentication check
code into the above logic?
Take a look at the code snippet
below, it checks for authenticated request within the if condition, which
checks for the IsPostBack property. This would mean that the authentication check
implemented within the if condition of IsPostBack propery, will be “called” or
“executed” only if the form is “accessed” the first time via a link, and would
not happen if someone invoked a control event.
How does the flaw manifest?
A flaw of this kind manifests
from the assumption that developers
make while coding, that a form will be accessed by an authenticated user first
time by clicking on a link. Developers assume that once the
form is presented or accessed, only then forms can be submitted and/or control
events can be invoked.
Just think about it, what will
happen if instead of requesting for a page/form a user tries to directly submit
a form?
If an attacker happens to send
any POST request for an internal action, for instance, to create a new
employee, along with parameters and the control event to invoke, The execution
flow will not enter the “IsPostBack”
if condition path above, and therefore will not execute or run the
authentication check. This is the root cause of the vulnerability. A simple
POST request would easily bypass authentication check implemented above.
2 out 5 ASP.Net applications I have audited seem to have
this flaw in a few sections dealing with form submissions.
How do we exploit this flaw?
In our scenario an application
allows only admin users to create new employees. The typical exploit involves, sending a POST
request simulating a form submission that creates an employee, along with all
the parameter names, and control event name like button.
Let’s see how it is done.
Exploit Steps
Try accessing the internal page, CreateEmployees.aspx
without login.
We are instantly redirected to a “Not Authenticated” page,
this is expected.
We do not stop here!
Lets send a HTTP POST request loaded with parameters directly to the form!
Now to understand the create employee feature, lets login
and create an employee.
Access the create employee form after login.
Create a new employee record.
Observe the HTTP POST request patent via Web Proxy tool. You
can see that along with textbox fields, control event name i.e name of the
button is also sent.
As shown a new employee record is created.
Now lets see if we can create an employee without
authentication.
Access the login page
Change the login request to a HTTP POST request with
appropriate parameters to the createemployees.aspx page.
Notice we are attempting to create an employee “HackEmp”.
This will trigger a PostBack event, and will render the
“IsPostBack” property to true. Notice the code writtin in the Page_Load event
of the form. The Page_Load event is always called every the page is requested
from the browser.
Since the HTTP POST request, would cause the IsPostBack
property to be rendered to true, it would effectively bypass authentication
check present in it.
This would mean that
the employee would get added into the database!
Lets us now login to the application as a legitimate admin
user, and check the View Employees section to see if out employee got added.
And lo! And behold! We created an employee without having to
login to the application.
From this we can conclude that
combining the authentication check, alongwith the IsPostBack property resulted
in a loophole in the authentication mechanism for the web application. Even
though the form is not accessible, it is still possible to invoke the
corresponding control event, like a button click code.
Recommended Fix
Since this flaw resulted from the assumption made by developers to check for authentication alongwith
the IsPostBack property check, the
obvious recommendation is to treat the two as independent conditional checks.
In other words the IsPostBack Property check, used to initialize variables when
the form is loaded for the first time,
should be in an independent if condition within Page_Load Method. The
Authentication check, used to verify if the request is from an authenticated
user, must be another independent user.
The fix should ensure that the authentication check must
always be called under the Page_Load event of ASP.NET page.
References
What is IsPostBack - http://forums.asp.net/t/1115866.aspx/2/10?What+is+IsPostBack
Page.IsPostBack Property -
http://msdn.microsoft.com/en-us/library/system.web.ui.page.ispostback%28v=vs.71%29.aspx
Versions Affected
NET Framework 1.1 and above
No comments:
Post a Comment