Download presentation source -


Nov 2, 2013 (4 years and 8 months ago)


Web Security

Sandy Kutin

CSPP 532


Web security: an overview

Company wants to build web site

Online purchasing

Requests for service or support

Viewing data files online

How do we make this process secure?



Usual answer: cryptography

TCP/IP in 60 seconds

Computers communicate
via packets, not connection

Packets are directed from
machine to machine

Smart nodes, stupid network

Contrasts with phone network

Internet Protocol controls this movement

Transfer Control Protocol: packets at destination

Could insert cryptography at any layer





IPsec works at IP level

Transparent to applications

Slows everything down

Some say it’s the future, some say it’s not

If every packet is encrypted: negates
optimization, firewalls




free Solution

Secure Sockets Layer (SSL)

Works at TCP level

Developed by Netscape

“Applications” now includes:

Handshake, Alert, Cipher Spec Change

Packets encoded by SSL Record Protocol

Implemented in web server, browser

Successor: Transport Layer Security (TLS)



SSL Record


LoSSLess Communication

SSL Record Protocol:

1. Fragment data into blocks; can compress

2. Append MAC to each block:

MAC = H(K | pad2 | H(K | pad1 | info | data))

H could be MD5 or SHA
1; similar to HMAC

info includes sequencing, length information

3. Encrypt each block (symmetric)

4. Append header, send fragment

BusineSSLike Handshake

How do we establish a session key?

1. Client says “hello”: version, random number

2. Server says “hello”: same, includes key
exchange method, optional certificate

3. Client initiates key exchange (may just
generate master, send it using RSA)

4. Both sides compute various keys from
master, random numbers in hello messages

5. Confirmation messages

HelpleSSLy Hoping

So, does SSL secure our site?

Confidential, authenticated transactions
are important, but not the only issue

Threat model: who might attack, and how

Steal customer data (credit cards)

Steal private corporate data

Deface web site

Denial of Service: prevent us from working

SSL has nothing to do with any of these

Trial Separation

How do we keep corporate data secure?

Solution: keep it separate

Only mix information when you have to:
use a floppy, or a laptop

Partial solution: restrict web server’s
access privileges (e.g., firewall, DMZ)

OK if data flow is mostly to the server

What about credit card numbers?

Stallings, page 464 (from the web site)



SET, I project

Secure Electronic
Transaction (SET)

MasterCard, Visa

Alice sends Bob order,
encrypted card info

Bob forward card
info to MC/Visa

MC/Visa pays Bob

Bob never gets card number

Credit card company never gets order information

Building a Better MouSETrap

OI = order info (include time), OIMD = H(OI)

PI = payment info (& time), PIMD = H(PI)

Alice signs (OIMD | PIMD) (SHA
1, RSA)

Alice sends Bob OI, E
(PI), PIMD, sig S

Bob compute OIMD, checks signature S

Bob sends OIMD, E
(PI), S to MC/Visa

They decrypt, check PI, check signature S

They transfer funds, Bob ships item to Alice

Improving our MindSET

Think outside the box

Q: How do we store credit card numbers?

A: Store them so we can’t read them

level solutions: harder to
implement, but better targeted to problems

Cryptography is only part of the solution

Any system can be broken

Build a threat model, measure costs

Breaking and Entering

Enemy could break in

Could corrupt data (deface web site)

Could steal data (including passwords)

Could gain control of system

Firewalls help, but there’s always a way in

Keep data separate whenever possible

Educate users about viruses, Trojan horses

Install patches as often as you can

Intruder Alert

Home security: locks stop easy attacks

Better: door, window alarms

(as long as they don’t go through the walls)

Even better: motion detectors

Alarms don’t stop anything directly, but
they alert the authorities

Fear of alarms forces criminals to hurry,
make mistakes

Law and Order

Deterrent to robbery: fear of prosecution

After a crime, police gather fingerprints,
DNA, eyewitnesses

Not aimed at stopping crime or recovering
goods, but at punishing criminals

Hard to do in computer crime; criminals
often minors or foreign nationals

Intrusion Detection

No matter what systems and protocols we
use, people will break in if they want

Hard to defend against determined
teenagers with nothing else to do

Solution: monitor system, detect
intrusions, watch for unusual activity

Honeypots: trap intruders

Gather evidence; maybe prosecute

At the very least, close off the holes

Denial of Service Attacks

One approach: break in, crash the server

Another: flood the server with bad requests

Distributed Denial of Service (DDoS):

Take over PCs around the country/world

Use them to overload a site

Only solution: have hardware routers
detect bad packets

Almost impossible; Windows XP may make
it worse

Here’s looking at you, KiDDoS

In the real world: to attack, you have to put
yourself at risk. Not on the Internet.

In the real world: attackers must learn
skills. Not on the Internet.

One person discovers a hole, writes a
script; now “script kiddies” can use it

Patches don’t work. Attackers will always
be ahead of users.

Beta testing doesn’t uncover security holes

Gibson Research Corporation

Steve Gibson’s security

Attacked, repeatedly, by DDoSs. No
defense. “Nothing more than the whim of a
year old hacker is required to knock any
user, site, or server right off the Internet.”

Distributed Responsibility

Owners responsible for their machines

ISPs responsible for their routers

Software writers responsible for bugs

EXPensive Problem

Attackers usually spoof source IP
addresses, to conceal their location

Easy to do in UNIX (as root)

Not possible in Windows 9x/ME, but
possible in Windows 2000/XP

Microsoft says: we’re fixing a bug

Gibson says: there’s no legitimate reason
home users would need this feature

Bruce Schneier: Counterpane

Author of “Applied Cryptography”

Feels only monitoring, intrusion detection,
active response can do any good corporate security

Solution: Insurance

Insure against damages from attacks

Lower rates for following good practices

Recommended Reading


Schneier, Sections 3.7, 23.2

SSL, SET: Stallings, Chapter 14

General security:

Stallings, Chapters 15