Friday, 22 February 2013

OWASP Top 10 #3 - Broken Authentication and Session Management. The risks and how to prevent an attack

This is one in a series of videos and blog posts that explore the top 10 most critical web application security risks as defined by OWASP.

OWASP - the Open Web Application Security Project, was formed in 2001 and is a not for profit charitable organisation.

It is an open community dedicated to enabling organisations to conceive, develop, acquire, operate and maintain applications that can be trusted.

In this session, I will deal with the OWASP #3 risk. Broken Authentication and Session Management .

I will define this risk and demonstrate Broken Authentication and Session Management at work. Later, I will demonstrate various techniques that can be employed to mitigate against the risk of Broken Authentication and Session Management.

So let’s begin with a definition:

“Application functions related to authentication and session management are often not implemented correctly, allowing attackers to compromise passwords, keys, session tokens, or exploit other implementation flaws to assume other users’ identities.” - OWASP Top 10, 2010

Actually, Broken Authentication is a bit of a catch all phrase.

You can read the transcript below.

HTML5 player



OWASP’s top 10 doesn’t restrict itself to just .NET technologies. Therefore QA do have two other courses: One focusing on Java and another on Linux, Apache and PHP.
For the purpose of these videos and blog posts however, I will focus on .NET technologies.
The best way to demonstrate this risk of Broken Authentication and Session Management is by way of an example.
Lets identify the presence of a broken session management risk.
I'll begin by opening up Internet Explorer and loading the vulnerable web app.
As you can see, I receive a page with the URL updated to include a unique session ID.
The web application uses this session ID to track the data and state for the current user.
At the moment, the app stores this session ID in the URL. That presents a risk.
Let me enter some data for the app to look after for me.
I'll type my name into this box here and then click the Save data button.
The app has started tracking this data and is in fact outputting it to this page. You can see it here in bold.
Session data is available throughout the app and across multiple requests, so I'll visit another page by clicking the About link in the top right hand corner.
And then I'll navigate back to the Home page by clicking that link.
Once again, my name or data is being displayed. Proving that the app has indeed persisted my data in the session.
Now let's take a look at what is going on.
I'll click on the Tools icon in the top right hand corner of Internet Explorer to open the Internet Explorer Developer Tools.
Then I'll click on the Network tab and click the Start capturing button.
If I click on the Home link in the top right corner of the page. You should see four network requests captured.
Let me select the first URL containing the request and session ID, then click the Go to detailed view button.
If I click on the Request Headers tab, you can see that there are no cookies being sent with the request. i.e. there is not a key named Cookie.
This reinforces that the session is not being persisted via a cookie. It is being persisted via the URL.
And that is our vulnerability.
So let's exploit that vulnerability.
I'll copy the URL of the page to the clipboard and then open Firefox.
Just imagine a user had copied the URL for a page they were on and then emailed it to a friend.
That sort of thing happens all of the time.
So in Firefox, which here represents another user and their browser, I'll paste the URL from the clipboard into the address bar and press enter.
As you can see, my name has appeared in the page thus demonstrating that the session that was begun in Internet Explorer has now been hijacked in Firefox.
Clearly, storing the session ID in the URL is a great risk. Not only do users innocently send URLs to their friends, attackers also capture network traffic and would be able to hijack a user's session. Perhaps one connected to a vulnerable ecommerce site that stores that user's credit card details.
So let's remove the session ID from the URL and store it via cookies instead.
I need to update the project and so I'll launch Visual Studio 2012 and open the project.
If I open the web.config file and locate the sessionState entry, you will notice that the cookieless property is set to UseUri.
I am going to change that to UseCookies.
Let me save the file and then return to Internet Explorer to reload the site.
This time, the session ID is no longer contained in the URL.
Like before, I will give the app some data to maintain. I.e. my name.
My data is output to the page in bold.
If I click on the About link to navigate to that page and then click on the Home link to navigate back to that page, you will see that my state has been maintained in the session.
As there is clearly no session ID in the address, this now confirms that session data is no longer persisted via the URL.
The Internet Explorer Developer Tools are still open from earlier and are still capturing.
I'll click on the first URL then click the Go to detailed view button. This URL represents the request associated with my reloading the app.
In the Request headers tab there is a cookie called ASP.NET_SessionId. This confirms the session is now being persisted via cookie.
So much for poor session management.
Let's take a look at authentication.
If you want to authenticate your users in your web app, you could of course write your own set of classes to manage users, roles and profiles. You could write code to register users, store their credentials securely and manage authorisation.
But this is difficult to do. There would be a lot of code to write and it would probably include flaws that you were not even aware of.
You are much better off using an established membership framework to begin with.
ASPNET, includes just such a framework.
We are going to need somewhere to store the credentials and it would make sense to store them in SQL Server.
Let me open SQL Server Management Studio 2012.
If I open the database for the current project, you will see that there are no tables in the database.
I'll head back into Internet Explorer and click the Register link in the top right hand corner of the page.
I'll fill out the user name, password and password confirmation fields then click Register to create a new account
In the top right corner of the browser, I can see that I am now logged in with the username that I created.
Now let me return to SQL Server Management Studio 2012 once again.
If I refresh the Tables node, you will see 5 tables that were automatically generated for me.
ASPNET Membership automatically creates these tables during registration unless of course they already exist.
If I begin a new query and set the context to my database, I can write a Select statement to retrieve everything from the webpages_UserProfile table and join it on the webpages_Membership table by matching the UserId of each table .
As you can see, the user name has been stored in the database along with the associated password which has been securely hashed.
This demonstrates that ASP.NET's native mechanisms to securely manage accounts and authenticated sessions is enabled and functional.
I will look at that in more detail when I explore the #7 of the OWASP Top 10; Insecure Cryptographic Storage.
But that's for another video.
OK. In this video, I have demonstrated a risk of broken session management and how to mitigate against it. I have also introduced you to the ASPNET Membership provider which is a powerful and robust framework for managing authentication in your web apps.


Flash player



If you are interested in OWASP training, we offer the following courses:

See you soon

Phil Stirpé
"I don't do average!"


  1. very nice article.Thanks for sharing the post...!

  2. Your blog is really very good. It has cultivated a new sense of inspiration in me to start a setup of my own. I just love the way you described everything.Please provide information related to etl testing like this.

  3. Hi, Great.. Tutorial is just awesome..It is really helpful for a newbie like me.. I am a regular follower of your blog. Really very informative post you shared here. Kindly keep blogging. If anyone wants to become a .Net developer learn from Dot Net Training in Chennai. or learn thru ASP.NET Essential Training Online . Nowadays Dot Net has tons of job opportunities on various vertical industry.
    or Javascript Training in Chennai. Nowadays JavaScript has tons of job opportunities on various vertical industry.