In 2020, the notorious TrickBot malware gained yet another new infection vector capability: injecting malware into vulnerable BIOS and UEFI.

This malware is effectively a rootkit but is called a bootkit, and it’s

nicknamed TrickBoot. To read about this new malware evolution, visit thehackernews.com/2020/12/trickbot-malware-gets-

uefibios-bootkit.html.

Client-Based Systems

Client-based vulnerabilities place the user, their data, and their system at risk of compromise and destruction. A client-side attack is any attack that is able to harm a client. Generally, when attacks are discussed, it’s assumed that the primary target is a server or a server-side component. A client-side or client-focused attack is one where the client itself, or a process on the client, is the target. A common example of a client-side attack is a malicious website that transfers malicious mobile code (such as an applet) to a vulnerable browser running on the client. Client-side attacks can occur over any communications protocol, not just Hypertext Transfer Protocol (HTTP). Another potential vulnerability that is client based is the risk of poisoning of local caches.

Mobile Code

Applets are code objects sent from a server to a client to perform some action. In fact, applets are actually self-contained miniature programs that execute independently of the server that sent them—that is, mobile code. The arena of the web is undergoing constant flux. The use of applets is not as common today as it was in the early 2010s. However, applets are not absent from the web, and most browsers still support them (or still have addons present that support them). Thus, even when your organization does not use applets in your internal or public web design, your web browsers could encounter them while surfing the public web.

Imagine a web server that offers a variety of financial tools to web users. One of these tools might be a mortgage calculator that processes a user’s financial information and provides a monthly mortgage payment based on the loan’s principal and term and the borrower’s credit information. Instead of processing this data and returning the results to the client system, the remote web server might send to the local system an applet that enables it to perform those calculations itself. This provides a number of benefits to both the remote server and the end user:

■■The processing burden is shifted to the client, freeing up resources on the web server to process requests from more users.

■■The client is able to produce data using local resources rather than waiting for a response from the remote server. In many cases, this results in a quicker response to changes in the input data.

■■In a properly programmed applet, the web server does not receive any data provided to the applet as input, therefore maintaining the security and privacy of the user’s financial data.

However, applets introduce security concerns. They allow a remote system to send code to the local system for execution. Security administrators must take steps to ensure that code sent to systems on their network is safe and properly screened for malicious activity. Also, unless the code is analyzed line by line, the end user can never be certain that the applet doesn’t contain a Trojan horse, backdoor, rootkit, ransomware, or some other malware component. For example, the mortgage calculator might indeed transmit sensitive financial information to the web server without the end user’s knowledge or consent.

Two historical examples of applet types are Java applets and ActiveX controls. Java is a platform-independent programming language developed by Sun Microsystems (now owned by Oracle). ActiveX controls were Microsoft’s answer to Sun’s Java applets. Java is still

in use for internal development and business software, but its use on the internet is rare. ActiveX is now a now legacy technology and is both EOL and EOS. It was only supported by Internet Explorer. Most modern internet-capable systems no longer support these applet forms, but it is important to ensure that before assuming a system is secure.

Although Java and ActiveX are no longer in use on or over the internet, JavaScript is. JavaScript is the most widely used mobile code scripting language in the world and is

embedded into (included inside of) HTML documents using <script></script> enclosure tags. JavaScript is dependent on its HTML host document. It cannot operate as a standalone script file. Thus, it is not an applet—it is embedded code. However, that means it is automatically downloaded along with the primary web documents from any web server you access, since 95 percent of websites use JavaScript. JavaScript enables dynamic web pages and supports web applications as well as a plethora of client-side activities and page behaviors.

JavaScript is supported by most browsers via a dedicated JavaScript engine. Most of the implementations use sandbox isolation to restrict JavaScript to web-related activities while minimizing its ability to perform general-purpose programming tasks. Also, most browsers default to enforcing the same-origin policy. The same-origin policy prohibits JavaScript code from accessing content from another origin. The origin is typically defined by a combination of protocol (i.e., HTTP vs. HTTPS), domain/IP address, and port number. If other content has any one of these origin elements different from the origin of the JavaScript code, the code will be blocked from accessing that content.