In web application development, it is easy to focus too much on functionalities, performance and pixel perfection instead of the ground rules of computer science. Let’s look at a case where application security was at risk due to common assumptions about time.
Myths about time
There are plenty of myths about time among programmers. Here are a few:
- There are always 24 hours in a day.
- The system clock is always set to the correct local time.
- One minute on the system clock has exactly the same duration as one minute on any other clock.
Assumptions like these can affect what is known as the event loop in JavaScript in many ways. For example, it can stop tasks in the app from being executed and delay time passing in countdowns.
We recently experienced a bug in a fintech application, where security suffered due to the nature of time and event loop. Let’s take a closer look at this bug.
Tracking users’ inactive time
The app in question contained sensitive data, so it was crucial to track users’ inactive time and automatically log them out after a set number of minutes. From a user perspective in a secure fintech app, they should at least be able to see when the session is about to end, so that they can decide to stay logged in or log out. The easiest way is to display a popup with a countdown to automatic logout.
The pros and cons of using prewritten JavaScript solutions
There are plenty of JavaScript libraries with prewritten solutions that can be used in app development. This can be a great timesaver, but at the same time you have to trust the people behind the solution. In this case, the available script had a bug: The countdown stopped when the app tab was placed in the background. The session didn’t end and the user could end up being logged in for days. That is not a secure fintech app.
Browser differences
The bug only occurred in the Mac OS Safari browser, and this was the most important clue to be able to resolve the issue. One of many ways Mac OS differs from Windows and Linux is the CPU and memory management system. Their respective browsers therefore have different CPU and memory usage strategies. Whereas Chrome has one CPU process per tab, Safari has one process for all tabs, divided between the active tab and a few that have recently been placed in the background.
Another issue was that the script used the setTimeout() function to decrease the value of the countdown. It takes the timeout value and puts the defined task in the proper place in the queue, relying on the CPU provided to execute those tasks. These things combined resulted in a bug that stopped the countdown when the open tab was placed in the background – as there was no CPU, tasks were not executed, and the countdown didn’t go down.
Luckily, with a team of talented developers, there is no need to worry about bugs like these. There are no perfect developers in the world, and there are no bug-free applications – the important thing is how the bugs are dealt with when they appear. In this case, we managed to identify the issue and find a solution quickly and efficiently.
If you’re a developer who wants to know how to fix this issue, or if you just want to discuss how you would approach it yourself, feel free to leave a comment below!
If you’re a business owner, feel free to contact us for more information on how we can help you develop a secure fintech product of premium quality. Pragmatic Coders have the skills, resources and processes in place to deal with issues quickly and efficiently.
