E-commerce case study: how penetration tests prevent attacks on mid-sized companies
Penetration test at a mid-sized retail company. Three critical findings in the shop and customer accounts, fixed and confirmed in a retest.
A mid-sized retail company wanted to know whether its shop and the customer data behind it would hold up against a targeted attack. Three critical findings, all fixed and confirmed in a retest.
Brief and scope
A defined scope, a report with reproduction steps, a retest.
Environment
A mid-sized retail company with its own shop, customer accounts and a connected merchandise management system. The name stays unnamed out of discretion.
Scope
Shop and customer accounts, the interfaces behind them, and the question of how far an attacker gets from there.
Result
Three critical findings, each documented with reproduction steps, fixed and confirmed in a retest.
The trigger was a date, not a suspicion
The reason was the approaching seasonal trade. An outage or a data leak at that time hits a retail company differently than in the rest of the year, so the question was not meant theoretically.
Testing therefore followed what would be of most use to an attacker: access to customer accounts and to order data.
Where the routes were
The critical findings concerned authorisation. The calls were authenticated but not authorised everywhere: at several points, changing an identifier gave access to data belonging to another account.
Weaknesses like that are unspectacular and effective at the same time. They need no exploit, only the observation that an identifier appears in the call and that nobody on the server side checks whether it matches the account logged in.
The circle was closed
All three critical findings were fixed before the seasonal trade began. The retest checked and confirmed the fixes.
The retest is the part many tests leave out. Without it, it stays open whether a measure works or only exists on paper.
What you can take from this
Authorisation flaws are the most common serious weakness in applications with user accounts, and automated tools reliably miss them, because every call looks technically correct.
The timing of a test should follow the business, not the budget year. Fixed before the season is something other than found after it.
And a retest belongs in the engagement, not in an option.
Related to this case study.
A similar project?
Referenzdetails nennen wir nach Freigabe und im persönlichen Gespräch.