State-Based Web Application Attack: URL Jumping

The web is naturally a stateless system wherein you should be able to jump to any given URL without actually having to go through a predetermined flow of what to visit and do first. This is the reason why there's no built-in mechanism to prevent this or any similar state-based security attack.

The nature of the URL jumping attack, on the other hand, is to attempt to break the sequence or flow in order to complete a transaction without the other required actions. With the ever evolving internet, the demand for an application to maintain state or the need to have a specific sequence of page visits / operations becomes necessary. And so, prevention is necessary to avoid this type of attack from happening.



How To Test Your Web Application if it's Vulnerable

Let's take for example a 5-flow checkout process. First page goes to the cart, second page lands on order verification, customer information and shipping information, third page is address verification, fourth page requests for Payment and last page is the order-complete page. Try going through pages 1-3, and on the third page, directly type the URL on the address bar for your order-complete page, if it completes, and saves everything to the backend as successful then you have a serious problem.

How To Protect Your Web Application Against This Attack

There are a couple of ways that this can be prevented starting from weakest to the more permanent way of doing. Although, there are many, they all are derived from one concept - restrict all users from directly accessing a page within the sequence if it didn't come from or redirected from the expected entry or referring page.

1. Use of HIDDEN fields to check where the page request came from.

This solution is easy to implement but a very weak solution. It can only prevent attack from users that doesn't know a thing about HTML.

2. Use COOKIES to store last visited pages or identifiers.

This is a slightly better alternative since cookies can't be directly accessed on browsers. This protection can prevent mediocre hacker wannabes at best.

3. Use HTTP_REFERER to store last visited page.

This is a good alternative since this is not obvious to the users. The only problem is when users go through proxies that would probably be removing this due to privacy which would cause the unreliability and application to break or do weird things.

4. Use of SESSION variables.

This is also a good alternative given that it won't be easily tampered with since its generation is done on the server-side. The only downside to it is adds-up to the session garbage that might cause performance issues later. As long as you do it minimally, you should be fine.

5. Use of COOKIES and Encryption

Use encryption if you plan to store last visited pages or information into the client-side. This is i think the best alternative should you want to store last visited page and some other user-specific information on the client-side.

In conclusion, should you want to have your web application as secure as possible against this attack, consider implementing either #4 or #5.

Related Links:

• Related Links Widget for Blogspot