The application managed shift rotas, absence records and payroll references, and it had run on an internal server since 2010. In 2020 it was published through a reverse proxy so staff could use it from home, and nobody treated that as a change requiring review. Four years later an employee changed a number in the address bar and saw a colleague’s record, complete with salary band and home address.
How an internal system became an external one
The decision was made in a fortnight during the first lockdown, by people trying to keep the business running. A reverse proxy was configured, authentication continued to work as it always had, and the application looked identical to users. What changed was the population of people who could reach the login page, which went from staff on the office network to anyone on the internet. The application had been written on the assumption that only trusted users would ever see it, and that assumption was now false.
The flaw itself
Broken access control, which has topped the OWASP Top 10 since 2021 for exactly this reason. Record pages were addressed by a sequential identifier, and the application checked that a user was logged in without checking whether the record belonged to them. Any authenticated employee could read any other employee’s file by incrementing the number. There was no exploitation involved and no tooling required, which is why an ordinary user found it by accident rather than an attacker finding it deliberately. A tester would have found the same thing in the first hour of any assessment.
“Applications written for an internal audience carry assumptions that stop being true the moment you publish them. If you put something on the internet during 2020 that was never designed for it, that system needs testing now. In our experience roughly half of those hurried publications have an access control problem of some kind.”
William Fieldhouse, Director, Aardwolf Security Ltd
What made the investigation difficult
The application logged authentication events and nothing else, so there was no record of which pages any user had viewed. That left the company unable to establish whether anybody had exploited the flaw across four years, and unable to bound the exposure for its notification. Around twelve hundred current and former employees had records in the system. The absence of application logging turned a single technical flaw into a data protection matter with no factual answer to the obvious question.
What changed afterwards
Access to the application was moved behind the corporate identity provider with multi-factor authentication, and the reverse proxy was restricted to authenticated sessions rather than publishing the login page openly. Object level authorisation checks were added to every record endpoint and the fix was verified independently. Application-level audit logging was implemented with a year of retention. A rule now requires web application testing for legacy systems before any internal application is published externally, and an internal network penetration testing engagement covers the other applications on the same server, several of which turned out to share the same assumptions.
Frequently asked questions about legacy applications
These questions follow any incident involving an older internal system.
Is it worth testing an application due for replacement?
Yes, if the replacement is more than a few months away. Systems scheduled for retirement have a habit of running for years longer than planned, and they usually hold the data that matters most.
Does putting it behind a VPN make it safe?
It removes the anonymous internet as a threat and leaves every authenticated user able to exploit an access control flaw. Network controls limit who can attempt an attack. They do not fix the application.
