1

Lecture Videos:
1. Firewalls
2. Intrusion Detection
3. Intro to Cryptography
4. Symmetric Encryption
5. Public Key Cryptography
6. Hashes
7. Security Protocols
8. IPSec and TLS
9. Wireless & Mobile Security
10. Web Security
11. Cyber Security
12. Law, Ethics, and Privacy
13. Modern Malware

XSRF/XSS (CSRF/CSS) - 11.2 (p391-p394)

Another broad class of vulnerabilities concerns input provided to a program by one user that is
subsequently output to another user. Such attacks are known as cross-site scripting (XSS) attacks
because they are most commonly seen in scripted Web applications.

The assumption is that all content from one site is equally trusted and hence is permitted to
interact with other content from that site. Cross-site scripting attacks exploit this assumption and
attempt to bypass the browser’s security checks to gain elevated access privileges to sensitive
data belonging to another site. These data can include page contents, session cookies, and a
variety of other objects.
2

The most common variant is the XSS reflection vulnerability. The attacker includes the
malicious script content in data supplied to a site. If this content is subsequently displayed to
other users without sufficient checking, they will execute the script assuming it is trusted to
access any data associated with that site. Consider the widespread use of guestbook programs,
wikis, and blogs by many websites. Unless the contents of these comments are checked and any
dangerous code removed, the attack is possible. attacker’s cookie script, which is provided with
the cookie associated with this document. Many sites require users to register before using
features like a guestbook application. With this attack, the user’s cookie is supplied to the
attacker, who could then use it to impersonate the user on the original site. To prevent this attack,
any user supplied input should be examined and any dangerous code removed or escaped to
block its execution.
XSS attacks illustrate a failure to correctly handle both program input and program output. The
failure to check and validate the input results in potentially dangerous data values being saved by
the program. However, the program is not the target. Rather it is subsequent users of the
program, and the programs they use to access it, which are the target. If all potentially unsafe
data output by the program are sanitized, then the attack cannot occur.

Validating Input Syntax

An important principle is that input data should be compared against what is wanted, accepting
only valid input, known as whitelisting. The alternative is to compare the input data with known
dangerous values, known as blacklisting. The problem with this approach is that new problems
and methods of bypassing existing checks continue to be discovered.

This type of comparison is commonly done using regular expressions. If the input data fail the
comparison, they could be rejected. In this case a suitable error message should be sent to the
source of the input to allow it to be corrected and reentered. Alternatively, the data may be
altered to conform. This generally involves escaping metacharacters to remove any special
interpretation, thus rendering the input safe.

Unicode uses a 16-bit value to represent each character. This provides sufficient characters to
represent most of those used by the world’s languages. However, many programs, databases, and
other computer and communications applications assume an 8-bit character representation, with
the first 128 values corresponding to ASCII. To accommodate this, a Unicode character can be
encoded as a 1- to 4-byte sequence using the UTF-8 encoding. Any specific character is
supposed to have a unique encoding. However, if the strict limits in the specification are ignored,
common ASCII characters may have multiple encodings. While strictly only the shortest
encoding should be used, many Unicode decoders accept any valid equivalent sequence.

There is a class of attacks that attempt to supply an absolute pathname for a file to a script that
expects only a simple local filename. The common check to prevent this is to ensure that the
supplied filename does not start with “/” and does not contain any “../” parent directory
references. If this check only assumes the correct, shortest UTF-8 encoding of slash, then an
attacker using one of the longer encodings could avoid this check. These examples demonstrate
the problems both with multiple encodings, and with checking for dangerous data values rather
than accepting known safe values.
3

Given the possibility of multiple encodings, the input data must first be transformed into a single,
standard, minimal representation. This process is called canonicalization. others recommend the
use of anti-XSS libraries, or Web UI frameworks with integrated XSS protection, that automate
much of the checking process, rather than writing explicit checks for each field.

There is an additional concern when the input data represents a numeric value. Such values are
represented on a computer by a fixed size value. Integers are commonly 8, 16, 32, and now 64
bits in size. Floating-point numbers may be 32, 64, 96, or other numbers of bits, depending on
the computer processor used. These values may also be signed or unsigned. Attacker could
specify a very large actual input data length, which is treated as a negative number when
compared with the maximum buffer size. Being a negative number, it clearly satisfies a
comparison with a smaller, positive buffer size. However, when used, the actual data are much
larger than the buffer allows, and an overflow occurs as a consequence of incorrect handling of
the input size data. Once again, care is needed to check assumptions about data values and to
ensure that all use is consistent with these assumptions.
4

Prevent XSRF:

SQL injection - 5.4 + potentially research from project 4

The SQL injection (SQLi) attack is one of the most prevalent and dangerous network-based security threats.

An application server webpage will make SQL queries to databases to send and receive information critical to
making a positive user experience. In such an environment, an SQLi attack is designed to send malicious SQL
commands to the database server. The most common attack goal is bulk extraction of data. Attackers can dump
database tables with hundreds of thousands of customer records. Depending on the environment, SQL injection can
also be exploited to modify or delete data, execute arbitrary operating system commands, or launch denial-of-service
(DoS) attacks.

SQLi is an attack that exploits a security vulnerability occurring in the database layer of an application (such as
queries). Using SQL injection, the attacker can extract or manipulate the Web application’s data. The attack is viable
when user input is either incorrectly filtered for string literal escape characters embedded in SQL statements or user
input is not strongly typed, and thereby unexpectedly executed.

The Injection Technique

The SQLi attack typically works by prematurely terminating a text string and appending a new command. Because
the inserted command may have additional strings appended to it before it is executed, the attacker terminates the
injected string with a comment mark “--”. Subsequent text is ignored at execution time.
5

SQLi Attack Avenues and Types

1. User Input: In most SQLi attacks that target Web applications, user input typically comes
from form submissions that are sent to the Web application via HTTP GET or POST
requests.
2. Server variables: Server variables are a collection of variables that contain HTTP
headers, network protocol headers, and environmental variables. Web applications use
these server variables in a variety of ways, such as logging usage statistics and
identifying browsing trends. If these variables are logged to a database without
sanitization, this could create an SQL injection vulnerability.
3. Second-order injection: In second-order injection, a malicious user could rely on data
already present in the system or database to trigger an SQL injection attack, so when the
attack occurs, the input that modifies the query to cause an attack does not come from the
user, but from within the system itself.
4. Cookies: Because the client has control over cookies, an attacker could alter cookies such
that when the application server builds an SQL query based on the cookie’s content, the
structure and function of the query is modified.
5. Physical User Input: This user-input could take the form of conventional barcodes, RFID
tags, or even paper forms which are scanned using optical character recognition and
passed to a database management system.

Attack types can be grouped into three main categories: inband, inferential,
6

and out-of-band.

An inband attack uses the same communication channel for injecting SQL code and retrieving
results. The retrieved data are presented directly in the application webpage.
Types of iband attacks:
1. Tautology: This form of attack injects code in one or more conditional statements so they
always evaluate to true. Eg: SELECT info FROM users WHERE name = ‘ ‘ OR 1=1 --
AND pwpd = ‘ ‘
2. End-of-line comment: After injecting code into a particular field, legitimate code that
follows are nullified through usage of end of line comments. An example would be to add
“- -” after inputs so that remaining queries are not treated as executable code, but
comments.
3. Piggybacked queries: The attacker adds additional queries beyond the intended query,
piggy-backing the attack on top of a legitimate request.

With an inferential attack, there is no actual transfer of data, but the attacker
is able to reconstruct the information by sending particular requests and observing
the resulting behavior of the website/database server.
Types of inferential attacks:
1. Illegal/logically incorrect queries: This attack lets an attacker gather important
information about the type and structure of the backend database of a Web application.
Preliminary/information gathering for other attacks based on descriptive error messages.
2. Blind SQL injection: Blind SQL injection allows attackers to infer the data present in a
database system even when the system is sufficiently secure to not display any erroneous
information back to the attacker. The attacker asks the server true/false questions. If the
injected statement evaluates to true, the site continues to function normally. If the
statement evaluates to false, although there is no descriptive error message, the page
differs significantly from the normally functioning page.

In an out-of-band attack, data are retrieved using a different channel (e.g., an

e-mail with the results of the query is generated and sent to the tester). This can be
used when there are limitations on information retrieval, but outbound connectivity
from the database server is lax.

SQLi Countermeasures
Examples of defensive coding include the following:
1. Manual defensive coding practices: Input validation (check if numeric, pattern validation,
etc.)
2. Parameterized query insertion: allowing the application developer to more accurately
specify the structure of an SQL query, and pass the value parameters to it separately such
that any unsanitary user input is not allowed to modify the query structure.
3. SQL DOM: SQL DOM is a set of classes that enables automated data type validation and
escaping [MCCL05]. This approach uses encapsulation of database queries to provide a
safe and reliable way to access databases. This changes the query-building process from
an unregulated one that uses string concatenation to a systematic one that uses a type-
checked API.
7

Digital Rights Management (DRM) - 19.2 (p609-p611)

Digital Rights Management (DRM) refers to systems and procedures that ensure that holders of digital rights are
clearly identified and receive the stipulated payment for their works. The systems and procedures may also impose
further restrictions on the use of digital objects, such as inhibiting printing or prohibiting further distribution.
8

In this model, the distributor need not enforce the access rights. Instead, the content provider protects the content in
such a way (typically encryption) that the consumer must purchase a digital license and access capability from the
clearinghouse. The clearinghouse consults usage rules provided by the content provider to determine what access is
permitted and the fee for a particular type of access. Having collected the fee, the clearinghouse credits the content
provider and distributor appropriately.

The system is accessed by parties in three roles. Rights holders are the content providers, who either created the
content or have acquired rights to the content. Service providers include distributors and clearinghouses.
Consumers are those who purchase the right to access to content for specific uses.
9

Wireless Networking risks - 24.1

iOS/Android security - 24.2 (vaguely) + Lecture (more focus on this honestly)
Key factors contributing to the higher security risk of wireless networks:
• Channel: involves broadcast communications - more susceptible to eavesdropping and
jamming. Vulnerable to active attacks that exploit vulnerabilities in communications
protocols.
• Mobility: Mobility results in increased risks.
• Resources: Limited memory and processing resources with which to counter threats such
as denial of service and malware.
 Accessibility: May be left unattended in remote and/or hostile locations, increasing
vulnerability to physical attacks.
Three components, each of which have different vulnerabilities:
• Clients: mobile phones, laptops, Bluetooth device, etc.
• Access points: mobile phone towers, Wi-Fi hot spots, and wireless access points to wired
local or wide-area networks.
• Transmission medium: which carries the radio waves for data transfer.

Type of threats:
• Accidental association: unintentionally locking on to a wireless access point from a
neighboring LAN network.
10

• Malicious association: A wireless device is configured to appear to be a legitimate access

point, enabling the operator to steal passwords from legitimate users then penetrate a wired
network through a legitimate wireless access point.
• Ad hoc networks: Peer-to-peer networks between wireless computers with no access point
(central control) between them.
• Nontraditional networks: Bluetooth devices, barcode readers, and handheld PDAs pose a risk
in terms of eavesdropping and spoofing.
• Identity theft (MAC spoofing): Eavesdrop on network traffic and identify the MAC address
of a computer with network privileges.
• Man-in-the middle attacks: User and an access point believe that they
are talking to each other, when in fact the communication is going through an intermediate
attacking device.
• Denial of service (DoS): attacker continually bombards a wireless access point, or some other
accessible wireless port, with various protocol messages designed to consume system resources.
• Network injection: targets wireless access points that are exposed to nonfiltered network
traffic, such as routing protocol messages or network management messages. E.g. bogus
reconfiguration commands are used to affect routers and switches to degrade network
performance.

To deal with eavesdropping, two types of countermeasures are appropriate:

• Signal-hiding techniques: including turning off service set identifier (SSID) broadcasting by
wireless access points; assigning cryptic names to SSIDs; reducing signal strength to the
lowest level that still provides requisite coverage; and locating wireless access
points in the interior of the building, away from windows and exterior walls.
• Encryption: Encryption of all wireless transmission.
The use of encryption and authentication protocols is the standard method of
countering attempts to alter or insert transmissions.

The main threat involving wireless access points is unauthorized access to the network. The
principal approach for preventing such access is the IEEE 802.1X standard for port-based
network access control, which serves as an authentication mechanism for devices.

Securing Wireless Networks

Following techniques are recommended:
1. Use encryption for router-to-router traffic.
2. Use anti-virus and anti-spyware software, and a firewall on all wireless network endpoints.
3. Turn off identifier broadcasting.
4. Change the identifier on your router from the default.
5. Change your router’s pre-set password for administration.
6. Allow only computers with approved MAC addresses to access your wireless network.

An organization’s networks must accommodate the following:

• Growing use of new devices: Employees use a variety of endpoint devices.
• Cloud-based applications: Applications no longer run solely on physical servers in corporate
data centers, and end users can now take advantage of a wide variety of
cloud-based applications and IT services for personal and professional use.
11

• De-perimeterization: Given new device proliferation, application mobility,

and cloud-based consumer and corporate services, the notion of a static network perimeter is all
but gone. Now there are a multitude of network perimeters around devices, applications, users,
and data.
• External business requirements: Provide guests, third-party contractors, and business
partners network access using various devices from a multitude of locations.

Security Threats
Lack of Physical Security Concerns
The security policy for mobile devices must be based on the assumption that any mobile device
may be stolen or at least accessed by a malicious party. The threat is twofold: a) recover sensitive
data from the device itself; b) use the device to gain access to resources.
Use of Untrusted Mobile Devices
Personal phones, tablets, etc. Assume these to be untrustworthy and not have adequate
encryption/security.
Use of Untrusted Networks
Security policy must be based on the assumption that the networks between the mobile device
and the organization are not trustworthy, as the device may access an unsecure Wi-Fi or cellular
network to access company resources.
Use of Untrusted Applications
An employee may install malicious third party applications on their device.
Interaction With Other Systems
Synchronize data, apps, contacts, photos, and so on with other computing devices and with
cloud-based storage, which can store company data in unsecure locations.
Use of Untrusted Content
Mobile devices may access and use content that other computing devices do not encounter, such
as a malicious QR code.
Use of Location Services
Attacker can use the location information to determine where the device and user are located,
which may be of use to the attacker.

Mobile Device Security Strategy

Device Security
• Enable auto-lock if it has not been used for a given amount of time.
• Enable password or PIN protection.
• Avoid using auto-complete features that remember user names or passwords.
• Enable remote wipe.
• SSL protection is enabled.
• Make sure that software, including operating systems/applications, is up to date.
• Up to date antivirus software.
• Sensitive data should be prohibited from storage or encrypted.
• Ability to remotely access devices, wipe data/disable the device in the event of loss or theft.
• Implement whitelisting to prohibit installation of all unapproved applications,
or implement a secure sandbox that isolates the organization’s data and applications from all
other data and applications. Approved apps have public key/digital signature.
• Restrictions on what devices can synchronize and on the use of cloud-based storage.
12

• Train personnel on the risks inherent in untrusted content and disabling camera use.
• Disable location services.

Traffic Security
All traffic should be encrypted and travel by secure means, such as SSL or IPv6. Virtual private
networks (VPNs) can be configured so all traffic between the mobile device and the
organization’s network is via a VPN.
Two-layer authentication mechanism, which involves authenticating the device and then
authenticating the user of the device.

Barrier Security
Firewall policies can limit the scope of data and application access for all mobile devices.
Intrusion detection and intrusion prevention systems can restrict mobile device traffic.

Cybersecurity control categories (supportive, administrative, etc) - 15.2

• Management controls: Focus on security policies, planning, guidelines, and standards that
influence the selection of operational and technical controls to reduce the risk of loss and to
protect the organization’s mission.
• Operational controls: Address the correct implementation and use of security policies and
standards, ensuring consistency in security operations and correcting identified operational
deficiencies. These controls relate to mechanisms and procedures that are primarily implemented
by people rather than systems.
• Technical controls: Involve the correct use of hardware and software security capabilities in
systems. These range from simple to complex measures that work together to secure critical and
sensitive data, information, and IT systems functions. In turn, each of these control classes may
include the following:
13

• Supportive controls: Pervasive, generic, underlying technical IT security capabilities that are
interrelated with, and used by, many other controls.
• Preventative controls: Focus on preventing security breaches from occurring, by inhibiting
attempts to violate security policies or exploit a vulnerability.
• Detection and recovery controls: Focus on the response to a security breach, by warning of
violations or attempted violations of security policies or the identified exploit of a vulnerability
and by providing means to restore the resulting lost computing resources.

PKI - 23.3

Public-key infrastructure (PKI) is the set of hardware, software, people, policies, and
procedures needed to create, manage, store, distribute, and revoke digital certificates based on
asymmetric cryptography.

The principal objective for developing a PKI is to enable secure, convenient, and efficient
acquisition of public keys.

In order to verify a certificate, you need to know the public key of the signing CA. This could, in
turn, be provided in another certificate, signed by a parent CA, with the CA’s organized in a
hierarchy. Eventually, however, you must reach the top of the hierarchy, and have a copy of the
public key for that root CA. The X.509 standard describes a PKI model that originally assumed
there would be a single internationally specified hierarchy of government regulated CAs. This
did not happen. Instead, current X.509 PKI implementations come with a large list of CAs and
their public keys, known as a “trust store.” These CAs usually either directly sign “end-user”
certificates, or sign a small number of Intermediate-CAs that in turn sign “end-user” certificates.
Thus, all the hierarchies are very small, and all are equally trusted.

Self-signed or nont trust-store CA = untrusted.

Current implementations suffer from a number of critical issues:

14

The first is the reliance on the user to make an informed decision when there is a problem
verifying a certificate. Unfortunately, it is clear that most users do not understand what a
certificate is and why there might be a problem.
Another critical problem is the assumption that all of the CAs in the “trust
store” are equally trusted, equally well-managed, and apply equivalent policies.
A further concern is that different implementations, in the various Web browsers and operating
systems, use different “trust stores,” and hence present different security views to users.

Many applications do not require formal linking of a public key to a verified identity. In many
Web applications, for example, all users really need is to know that if they visit the same secure
site and are supplied with a certificate for it, that it is the same site and same key as when they
previously visited. This is analogous to ensuring that if you visit the same physical store, you see
the same company name and layout and staff as previously. And further, users want to know that
it is the same site and same key as other users in other locations see.

The first of these, confirming continuity in time, can be provided by user’s applications keeping
a record of certificate details for all sites they visit, and checking against these on subsequent
visits. Certificate pinning in applications can provide this feature, as is used in Google Chrome.
The Firefox “Certificate Patrol” extension is another example of this approach.

The second, confirming continuity in space, requires the use of a number of widely separated
“network notary servers” that keep records of certificates for all sites they view, that can be
compared with a certificate provided to the user in any instance. The “Perspectives Project” is a
practical implementation of this approach, which may be accessed using the Firefox
“Perspectives” plugin. This also verifies the time history of certificates in use, thus providing
both desired features for this approach. The “Google Certificate Catalog” and “Google
Certificate Transparency” project are other examples of such notary servers.

In either of the above cases, identification of a different certificate and key

to that seen at other times or places may well be an indication of attack or other
problems. It may also simply be the result of certificates being updated as they
approach expiry, or of organizations incorrectly using multiple certificates and keys
for the same, but replicated, server.
15

Kerberos - 23.1
Approach that organizations can use to secure networked servers and hosts through use of
authentication software tied to a secure authentication server. Trusted third-party authentication
service. It is trusted in the sense that clients and servers trust Kerberos to mediate their mutual
authentication. In essence, Kerberos requires that a user prove his or her identity for each service
invoked and, optionally, requires servers to prove their identity to clients.

Kerberos makes use of a protocol that involves clients, application servers, and a Kerberos
server. Impersonation: an opponent can pretend to be another client and obtain unauthorized
privileges on server machines. To counter this threat, servers must be able to confirm the
identities of clients who request service. Each server can be required to undertake this task for
each client/server interaction; this places a substantial burden on each server. An alternative is to
use an authentication server (AS) that knows the passwords of all clients and stores these in a
centralized database. Once the AS has verified the user’s identity, it can pass this information on
to an application server.

Must be done in a secure way so that someone does not observe the password in the network or a
plaintext message sent by the AS in order to imitate it. Encryption and special messages are used.

The AS shares a unique secret key with each server. These keys have been distributed physically
or in some other secure manner. The user logs on to a workstation and requests access to a
particular server. The client process representing the user sends a message to the AS that
includes the user’s ID and a request for a ticket-granting ticket (TGT). The AS checks its
database to find the password of this user. Then the AS responds with a TGT and a one-time
encryption key, known as a session key, both encrypted using the user’s password as the
encryption key. When this message arrives back at the client, the client prompts the user for his
or her password, generates the key, and attempts to decrypt the incoming message. If the correct
password has been supplied, the ticket and session key are successfully recovered.

The ticket constitutes a set of credentials that can be used by the client to apply for service. The
ticket indicates that the AS has accepted this client and its user. The ticket contains the user’s ID,
the server’s ID, a timestamp, a lifetime after which the ticket is invalid, and a copy of the same
session key sent in the outer message to the client. The entire ticket is encrypted using a secret
DES key shared by the AS and the server. Thus, no one can tamper with the ticket.

The ticket can be used to request more tickets from a Ticket Granting Server in order to avoid
inconveniencing the user by having him enter the password multiple times for each service or to
store the password, which would be a security risk.

Opponent would be able to reuse the ticket to spoof the TGS. To counter this, the ticket includes
a timestamp, indicating the date and time at which the ticket was issued, and a lifetime,
indicating the length of time for which the ticket is valid (e.g., 8 hours). Thus, the client now has
a reusable ticket and need not bother the user for a password for each new service request.
Finally, note the ticket-granting ticket is encrypted with a secret key known only to the AS and
the TGS. This prevents alteration of the ticket. The ticket is re-encrypted with a key based on the
16

user’s password. This assures that the ticket can be recovered only by the correct user, providing
the authentication.

If this lifetime is very short (e.g., minutes), then the user will be repeatedly asked for a password.
If the lifetime is long (e.g., hours), then an opponent has a greater opportunity for replay. An
opponent could eavesdrop on the network and capture a copy of the ticket-granting ticket then
wait for the legitimate user to log out. Then the opponent could forge the legitimate user’s
network address and send a message to the TGS.

In the message to the TGS requesting a service-granting ticket, the client includes an
authenticator encrypted with the session key, which contains the ID and address of the user and a
timestamp. Unlike the ticket, which is reusable, the authenticator is intended for use only once
and has a very short lifetime.

Note the ticket does not prove anyone’s identity, but is a way to distribute keys securely. It is the
authenticator that proves the client’s identity. Because the authenticator can be used only once
and has a short lifetime, the threat of an opponent stealing both the ticket and the authenticator
for presentation later is countered. Later, if the client wants to apply to the TGS for a new
service-granting ticket, it sends the reusable ticket-granting ticket plus a fresh authenticator.

The next two steps in the protocol repeat the last two. The TGS sends a service granting ticket
and a new session key to the client. The entire message is encrypted with the old session key, so
only the client can recover the message. The ticket is encrypted with a secret key shared only by
the TGS and server V. The client now has a reusable service-granting ticket for V. Each time
user X wishes to use service V, the client can then send this ticket plus an authenticator to server
V. The authenticator is encrypted with the new session key.

If mutual authentication is required, the server can reply with the value of the timestamp from
the authenticator, incremented by 1, and encrypted in the session key. The client can decrypt this
message to recover the incremented timestamp. Because the message was encrypted by the
session key, the client is assured that it could have been created only by V. The contents of the
message assures C that this is not a replay of an old reply. Finally, at the conclusion of this
process, the client and server share a secret key. This key can be used to encrypt future messages
between the two or to exchange a new session key for that purpose.
17

Networks of clients and servers under different administrative organizations generally constitute
different realms. That is, it generally is not practical, or does not conform to administrative
policy, to have users and servers in one administrative domain registered with a Kerberos server
elsewhere. However, users in one realm may need access to servers in other realms, and some
servers may be willing to provide service to users from other realms, provided that those users
are authenticated. Kerberos provides a mechanism for supporting such interrealm authentication.
For two realms to support interrealm authentication, the Kerberos server in each interoperating
realm shares a secret key with the server in the other realm. The two Kerberos servers are
registered with each other.

Bit operators (AND, OR, XOR, etc.) - 20(p619)/21(p636) (know about these in general
potentially, as they are mentioned a bit here only)
18
19