Sunday, 17 February 2013

Insecure Postback based authentication flaw in ASP.NET


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.


Page.IsPostBack Property -

Versions Affected
NET Framework 1.1 and above

No comments:

Post a Comment