What is HTML Field Obfuscation?
And why do you need to know, anyway?
I am so glad you asked!
A great deal of app security focuses on the server-side component. Whether comprised of multiple microservices fronted by an API or a monolith, there is no question that a significant source of breaches occurs at the app. This is due to vulnerabilities in the platform, app frameworks (think Spring, Express, or Struts) or application code itself.
Many of these apps still present a traditional HTML interface. Even if it’s using Angular or Bootstrap or some other JavaScript framework to create the real-time, interactive experience users crave, it still relies on good old HTML to solicit input from users.
Many client-side attacks count on this, and exploit the markup language to great success.
Interestingly, F5 Labs research found in its analysis of breaches over the past decade that 86% of the time, apps and identities were the initial target. When most folks hear “identities” it conjures up images of LDAP or ADS or perhaps more modern methods like OAuth. The reality is that before any of that comes into play, first the actual data that comprises an identity – username and password – must be collected.
To do that, developers use an HTML element called “input”. The tag “input” is what tells the browser to render a text box so you can enter your credentials.
To help keep passwords hidden from prying eyes (that guy reading over your shoulder right now), HTML includes the ability to further specify the type of input you’re looking for. By declaring an “input” element of type “password”, you get some default behavior that automagically masks entered characters. In raw HTML, it looks like this:
input type=password name=credential_part_two>
Now, that’s cool and all, but attackers know this. MItB (Man In the Browser) attacks inject scripts (or exploit other browser and HTML behaviors) to attach themselves to these fields and slurp up the credentials as users type them in.
That’s obviously a Very Bad Thing™ that we want to prevent. Anti-fraud application services are designed to prevent scripts or browser extensions from successfully stealing credentials in this way.
To do that, they can use a technique known as HTML Field Obfuscation (HFO).
To understand how it works, first you have to see how an exchange normally works.
The user requests the login page, and as part of the response, a form is returned containing the elements needed to collect credentials. You can see they are clearly labeled and easily identifiable. Before you get all angrified at developers, remember that a significant concern – especially in the enterprise – is the sustainability of software. That means it has to be clear and written in such a way that when the next wet-behind-the-ears developer is handed the application, they can follow the code and its logic and modify and/or maintain it. We are conditioned not to obfuscate variables precisely because it makes code difficult to follow and more complex than it already is. So please, try not to punch the next developer you see because of this. They’re just following coding standards.
Now, obviously the naming and use of HTML types to identify credentials can make it extremely easy for malicious scripts, extensions, etc… to find exactly what they desire most: the credentials.
So what we need to do is obfuscate the fields before it reaches the client, and hopefully prevent scanners, skimmers, and loggers from being able to figure out where the credentials are.
We do this by inserting an anti-fraud application service into the mix. Essentially, it’s going to act as a proxy to mediate exchanges between the client and the target application and do some magic on the data to obfuscate field names. This is intended to confuse and frustrate attempts to leech off credentials.
The request is made exactly the same, and passed on to the application.
On the response, the anti-fraud application service quietly replaces specified HTML elements with encrypted versions using a designated private key. It then passes the modified HTML back to the client. The client renders the page as it should and the user sees no difference in the user interface. Only the HTML names have been modified, which only impact client-side scripts and frameworks. The modified page includes a script that ensures that client-side frameworks operate as expected.
This technique is designed to confound attacks that rely on identifying target data based on its associated named HTML elements. IT prevents scripts and extensions from latching onto those fields and siphoning off the information. There also exist advanced techniques based on HFO that go beyond just encrypting field values, including the addition of “decoy fields” to distract attackers.
No, HFO is not infallible. But it can stop lazy scripts and attacks that rely on easily identifiable field names to extract their digital bounty.
HFO allows for frequent, dynamic changes of highly-sensitive form fields without the costs and time associated with modifying the application itself. This maintains the integrity (and sustainability) of the application code whilst providing a layer of protection against attempted theft of sensitive data.
Although HFO and related techniques are often tightly associated with protecting financial-related applications, the reality is that all credentials are highly sought-after data today no matter what type of app or service they are for. The credential crisis is real, and so is the need to protect consumers and customers from having their credentials pilfered by malicious actors.
Stay safe out there!