Misconceptions in Client-Side Security: Reverse Engineering Obfuscation & Disguised Endpoints
The information provided in the following is for educational purposes only and should not be used to wrongfully infiltrate or manipulate an application without the legal consent of its owner.
Client-side security is never safe. No matter the practices followed, deterrents used, or tricks added, once content is presented to the user, on their machine, they have access to manipulate it in any form they desire. With that being said, understanding how certain techniques can be reverse-engineered will help a developer comprehend the concept of relying on access control and the server as a gateway to protected content.
A multitude of practices may be used to improve security, a few of which potentially beneficial, but never more than a trivial obstacle for a hacker. With many of the methods causing more issues in a developer’s workflow than they’re worth, it may be unproductive to use these strategies in production.
OWASP Top 10 & False Security
A6-Sensitive Data Exposure is listed as one of the Top 10 Most Critical Web Application Security Risks cautioned by the Open Web Application Security Project (OWASP). In regards to building secure applications, each of the following practices do not conform to this principle and should be understood as such.
What are methods of false security that may be introduced to make the developer feel as though they are implementing a secure solution?
Masking API Endpoints
At the foundation of the modern web is the asynchronous http request. In most cases, understanding how these are architected within an application can tell a infiltrator a lot about the state of the program to find ways in manipulating it.
If following a REST or possibly a GraphQL API implementation, an endpoint is the location in which a request is made for information. The URL appropriately defines the resource which is being retrieved or modified. With this in mind, does abandoning these standard conventions through disguising the target location sound appropriate?
Network Request Sniffing
Chrome DevTools’s Network panel (or alternatively Wireshark) can quickly expose these techniques. Especially with the preview feature, XHR calls returning JSON are becoming increasingly easier to examine.
Making use of a misnomer for the location of sensitive data may seem ideal, but in actuality it can confuse developers working with the codebase in the future. Additionally, performing other techniques such as hiding query parameters in the
Referer header URL is unnecessary. With the availability to quickly sniff the network calls, these approaches are ultimately frivolous.
Note: Methods using WebSockets have been thought to be preventative of these insecurities but “if you can sniff
http: you can sniff
ws:”. JSONP has also been used through script injection, but this is a very unsecure practice and should not be utilized.
As shown above, a seemingly inconspicuous REST call (
/assets/css/svg/generate) returns an encoded Base64 string. Now although there is the possibility that an actual SVG is being optimized here, it is always of interest for a attacker to dissect the response data when it is encoded in Base64.
Base64 Encoding & Modification
Base64 is not encryption. By design it is an ASCII string representation of binary data and should be thought of as such.
Encoding data on the server in a Base64 sequence and then modifying the string before exposing it to the client-side has been used by developers to restrict the plain view visibility of raw payload data.
An Impractical Approach
An example of a modification technique could be as simple as rearranging each character of the string in reverse order and moving the last
n characters to the front. By performing this step, or any similar process that the developer uses at their discretion, network sniffing for the encoded string would lead to the inability to decode the response payload.
atob() decoding method would throw an error, while other tools found online might be partially more successful. Base64 Decode and Encode may possibly decode the Base64 string, but certainly into a set of undecipherable characters.
Decoding the Request
Sifting through the source files of a web application becomes possibly the most difficult part in debunking client-side security solutions. But through basic find and search techniques, like querying for the
Request URL header value or looking for where a response’s property values are used, an intruder can and will eventually find the source of where the request is called from.
Based on the need to decode the response payload value on the client-side, this approach gives any meddler a direct blueprint of the exact design of this “pseudo-encryption algorithm”. If it is not backed by mathmatical principle and can be cracked in a relatively short period of time, without the use of quantum computing, it is not secure and should never be considered a viable substitute for proper endpoint security.
After implementing all of these erroneous data manipulation techniques, the XHR call may then be obfuscated to further the level of ambiguity of the processing methods used by the application.
Vulnerabilities in Obfuscation
Obfuscation is an approach used to prevent an individual from easily gaining insight into the logic running behind an application. Through manipulation of the source code, formatting, variable-naming, and other declarations become virtually unreadable.
Pretty-Printing Obfuscation in Browser
Through the formatting functionality of Chrome DevTools, in-browser source code becomes easier to visualize but with obfuscation, dissecting these methods are far from a menial task.
Reverse Engineering Obfuscation
And now, the reverse-engineered methods are very similar to the originals.
Deobfuscation, Web Scraping, & ASTs
As with any application, it is up to the developers to decide which practices they feel have technical worth and whether they will limit a hacker’s ability to manipulate the state of their application. But certain mechanisms like authorization frameworks, such as OAuth with JSON Web Tokens (JWT), are truly essential. Proper endpoint security solutions to ensure that sensitive resources are guarded safely and requests are coming from authenticated sources are imperative requisites for secure web applications.
Recognizing when a security implementation does more harm than added value to the application is the hardest part about deciding whether to use some of the tactics discussed. Take into consideration the above notions, perform research of your own, and make informed decisions.