Administration interface, back-office, dashboard, admin panel… several names for the same thing: the place where organizations manage their data, supervise the activity of a web platform, handle customer requests, activate user accounts, configure articles within an e-commerce platform…

When thinking about the security of web platform, the back-office is not necessarily the priority, for several reasons:
The access to that kind of application is usually restricted, to internal services of the organization, and sometimes to third parties, supposed to be trustworthy.

Naturally, the priority is put on applications exposed to the public, also known as “client-facing applications”: Customer website, APIs, webservices… anything known to be directly exposed. These “applications” have the largest attack surface, tons of features with a large variety of potentially vulnerable elements.

What are the risks with a back-office?

Direct attacks, from the outside:

Obviously, a back-office can be attacked, full-frontal. Attacking the authentication function is the most direct and obvious attack. But when the door is robust, what if the weakest part is the wall itself? Sometimes getting access to an internal feature of a back-office is easier than one thinks, even without being authenticated.

 

Direct attacks, from the inside:

Users of a back-office are supposed to be trustworthy. Are they?
If several right levels (privileges) have been implemented, maybe it’s worth putting them to the test. Otherwise, why implementing different rights and account types?

Legitimate users have many potential reasons to become evil at some point.
– To bypass a process they just don’t understand and they know they can short-circuit, by using whatever feature they are not supposed to get access to, but that they actually can access…
– To get access to the data of another user, which would be super useful…

Just think about any back-office you know, visualize the limitations its users face, and then think “rules are made to be broken”.

 

Indirect attacks, usually from the outside:

Now let’s get serious, and let’s move to “indirect” attacks. Frontal attacks are just not fun enough for hackers.

Let’s suppose the back-office door is solid like rock, the walls are strong like a mountain, and legitimate users are really nice and follow the rules. The perfect world.

Attackers play with the front-office (standard users’ application) and inject malicious data in the website, within whatever field or data input available to them. With some magic (not really), that malicious data they injected shows up in the back-office, where an administrator is currently working. Not just to say “Hello”, but to manipulate their web browser, and hopefully steal their “session” on the back-office.

Speaking figuratively, that attack is a bit like a booby-trapped parcel sent to a secure office, with a hidden microphone, or worse…

This scenario is not just theory, we regularly find and exploit that kind of weaknesses during security assessments on web platforms.
Real examples include the takeover of a chatbot application that insecurely made user questions available within the administration panel, and the takeover of an e-commerce website that simply had an insecure consumer listing, still within the back-office.

 

Beyond the simple back-office

Administration features are often linked to third party services, in order to inject live data from a web-platform, right into other business systems. As such, it is common practice to connect a CRM tool to a website, to track key information and streamline processes.

If not properly implemented, this type of interlinking can lead to a full compromise of bigger systems. That kind of weakness allowed us to take over such critical third party systems, through attacks on a website’s front-office.

 

Testing back-offices

Testing the reliability of a back-office is therefore a requirement, for organizations wishing to entirely secure their platforms.
Testing the whole back-office should be considered, but with strict budget constraints, limiting the scope to features linked to front-office can be an alternative.