342
Chapter 9
■
Security Vulnerabilities, Threats, and Countermeasures
boot time.
In most computers, the BIOS is stored on an EEPROM chip to facilitate version
updates. The process of updating the BIOS is known as “
flashing
the BIOS.”
There have been a few examples of malicious code embedding itself into BIOS/firmware.
There is also an attack known as
phlashing,
in which a malicious variation of official BIOS
or firmware is installed that introduces remote control or other malicious features into a
device.
Since 2011, most system manufacturers have replaced the traditional BIOS system on
their motherboards with Unified Extensible Firmware Interface (UEFI).
UEFI is a more
advanced interface between hardware and the operating system, which maintains support
for legacy BIOS services.
Device Firmware
Many hardware devices, such as printers and modems, also need some limited processing
power to complete their tasks while minimizing the burden placed
on the operating system
itself. In many cases, these “mini” operating systems are entirely contained in firmware
chips onboard the devices they serve. As with a computer’s BIOS, device firmware is fre-
quently stored on an EEPROM device so it can be updated as necessary.
Client-Based Systems
Client-based vulnerabilities place the user, their data, and
their system at risk of com-
promise 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 vulner-
able 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.
Applets
Recall that agents are code objects sent from a user’s system to query and process data
stored on remote systems.
Applets
perform the opposite function; these code objects are
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. The
arena of the World Wide Web is undergoing constant flux. The use
of applets is not as com-
mon 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 add-ons 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.
Client-Based Systems
343
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 cal-
culations 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, just as with agents, applets introduce a number of security concerns. They
allow a remote system to send code to the local system for execution. Security administra-
tors must take steps to ensure that code sent to systems on their network is safe and prop-
erly 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 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.
Do'stlaringiz bilan baham: 
