A Confused Programmer's Blog

This blog is dedicated to C# and Java programming that I happen to do for living – with accent on curious cases and with sincere intent to make the world of coding a slightly better place as a result

OWASP 2011 conference impressions, part two

Today I am going to present the rest of what I consider to be the highlights from the OWASP IL 2011 conference that took place ten days ago. Jumping ahead, combined with my first OWASP post, the main conclusion that one can draw from the use cases presented is that coding is a business that involves some basic thinking in addition to ability to press keyboard keys in a sequence that will be accepted by a compiler.

One exploit – maybe the less obvious one – deals with using holes in session variables management at the server side. When the user logs in, she is usually assigned some session identifier cookie and session information is kept at server. Then, for each request for page that require authentication, session of the current user is checked, and if he does not appear to be logged in, he’s being redirected to the login page. How the current session is checked? – usually by checking if username or userid session variables are set. The exploit targets possible weakness if, for example, session[“user_name”] is the variable that is checked for logged in users, but also can be freely set from some other flows (for example, during user registration or password recovery process). In this case, session[“user_name”] will become non-null and the attacker will be able to access member content for the user whose name he set using the other flow. So, the best practice to avoid this weakness would be not to use session variables with the same names for the different flows.

Additional exploit related to the lacking session management takes advantage of poor coding:

Session[“user_name”] = username;
if (!ValidateUser(username))
Session.Remove(“user_name”);

In this case, for the duration of user validation, the user is actually authenticated. So the attacker who can catch the race or artificially prolong authentication (DOS attack on authentication servers, providing hard regular expression as a password) will access the member area for the user. These exploits might look far fetched, but they serve as a reminder to why the programmer should give his code a second thought. By the way, the full slides are here.

Comments are closed.

Subscribe to email feed

  • RSS
  • Delicious
  • Digg
  • Facebook
  • Twitter
  • Linkedin
  • Youtube

REST Assured and une

If you stumbled onto this article, it is safe to ...

Getting rid of Error

Since I upgraded my Windows 8 to Windows 10, I ...

Bypassing EULA step

We are working on automated testing of virtual appliance. This appliance ...

How I got rid of "Ac

OVF is a VMware virtual appliance format which allows you ...

My use-case of Perfo

In my blog I am set on a mission to ...

Twitter updates

RSS not configured