Tackling Security Issues

We had a chance to fix few security issues in our client's web app. In this post I'm going to share our thoughts about issues like these, how we fixed and how to avoid these altogether.

Jarmo Pertman — 2020-10-20 (3 minute read)

Problem Description

Problem itself was pretty simple - it allowed a bad actor to create a link allowing him/her to steal Coop end-user's login credentials or to hijack their session when navigating to it. As Ando wrote on his blog then problems like this are still very common even in the year 2020 despite of many frameworks/libraries trying developers to prevent making mistakes like these. However all developers still need to think as an attacker the whole time when writing code. These reported security issues would not have seen any daylight when previous software development partners of Coop would have paid some extra attention. It was time for us to think like an attacker instead! We did put our white-hats on and started coding.

More Technical Description

When logging into the Coop's e-commerce site there is a code which allows specifying URL to be shown after successful login. This is normal functionality within web applications to allow navigation to URL-s requiring authentication so that after user logs in he/she sees the page which was originally navigated to. Web applications with bad UX show a front page or some other default page after logging in losing the original navigation intent. The redirect path is provided as a GET query parameter called next. For example a link https://ecoop.ee/et/logisisse/?next=%2Fet%2Fostunimekirjad%2F would redirect user to his/her purchase lists. Now, when that kind of a functionality is offered then it is always very important to validate that parameter. When not validated then attacker can provide its own to cause some problems. For example, attacker could provide a link like this https://ecoop.ee/et/logisisse/?next=https%3A%2F%2Fattack-site.com which would redirect successfully logged in user to a site under attacker's control at https://attack-site.com. Attacker could show there a login page similar to Coop's with an error message of "Invalid username or password". Unsuspecting user would think at that point that they must have made a typo when logging in and would enter their correct credentials again. After that attacker would send them back to the original Coop site where user would be logged in. However, attacker now has user valid credentials. It's a perfect crime since user would not know that he/she just gave their credentials to an attacker. It is just a matter of time when attacker uses that information to its purpose.

Solution

As already mentioned in the previous paragraph then solution to this seemingly simple problem is just to validate the redirect parameter value. There are multiple possibilities to do that and it depends on the need of the web application. We chose to create a simple code, which whitelists (always use a whitelist instead of a blacklist!) all available routes. In other words - if there is a route specified in our code then redirecting there is allowed. Otherwise redirection is halted with an error message. Simple as that. I'm not going to show any specific code blocks here since it will be really different between each project (if you're really curious then look at Ando's article).

Conclusion

Security is one of the aspects which is not taken all too often seriously enough before an incident has happened. Fortunately this time for Coop an outside security engineer noticed this problem and reported it instead of trying to cause problems. It is unfortunate that it took so much time from reporting before getting solved, but at least it is solved now. When you are a software engineer then never trust user input because there might always be this one person who does send an input which your code does not expect. Always try to think like an attacker to mitigate these situations.