Internet web security
Sponsored Links
This presentation is the property of its rightful owner.
1 / 179

Internet & Web Security PowerPoint PPT Presentation


  • 230 Views
  • Uploaded on
  • Presentation posted in: General

Internet & Web Security. References & Resources. Lincoln Stein, Web Security: A Step-by-Step Reference Guide Larry J. Hughes, Jr., Internet Security Techniques. What is web security?. Three parts of web security Three points of view Risks. Three components of web security. Browser Server

Download Presentation

Internet & Web Security

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Internet & Web Security


References & Resources

  • Lincoln Stein, Web Security: A Step-by-Step Reference Guide

  • Larry J. Hughes, Jr., Internet Security Techniques


What is web security?

  • Three parts of web security

  • Three points of view

  • Risks


Three components of web security

  • Browser

  • Server

  • Connection between the two (I.e., the Internet!)


Three points of view

  • User’s

  • Webmaster’s

  • Both parties’


User’s point of view

  • Remote server’s ownership known and true

  • No viruses or other damaging documents / sw

  • Remote server respects user’s privacy

    • Doesn’t obtain / record / distribute private info


Webmaster’s point of view

  • User won’t try to break in / alter contents

  • User won’t try to gain access to documents s/he’s not privy to

  • User won’t try to crash the server

  • User’s ID (if provided!) is true


Both parties’ point of view

  • Network connection free of eavesdropping

  • Info between browser and server delivered intact, free from tampering


Three (interdependent) parts

  • Document confidentiality

  • Client-side security

  • Server-side security


Document confidentiality

  • Protect private information from

    • Eavesdropping

    • Fraudulent identities

  • Mostly via cryptography


Client-side security

  • Protect user’s privacy and system’s integrity

    • Virus protection

    • Limit amount of info browser transmits (without user’s consent)

  • Protect organizations confidential information / network integrity

    • From Web browsing activities


Server-side security

  • Protect server from

    • Break-ins

    • Site vandalism

    • Denial-of-service attacks

  • Mostly firewalls and OS security measures


Risks

  • Risks that affect both client and server

  • Risks to the end user

  • Risks to the web site


Risks that affect both client and server

  • Eavesdropping

    • “Packet sniffers” (more …)

  • Fraud


Network snooping (sniffing) ...

  • Abuse of network debugging tools ...

  • Network interface into promiscuous mode ...

  • Solution: encrypt


Abuse of network debugging tools ...

  • E.g., Network General's Expert Sniffer

  • etherfind (SunOS)

  • tcpdump (free on Internet)

  • Sniffer FAQ

    • comp.security, news.answers

    • ftp://ftp.iss.net/pub/faq/sniff

    • http://www.iss.net/iss/sniff.html


Network interface into promiscuous mode ...

  • Report all packets to sniffer

    • Display / record

    • Analyze

  • Remote also possible


Fraud

  • Authenticate

    • Individuals, organizations

    • Transactions

    • Documents

  • Solution: digital signatures, certification authorities


Risks to the end user

  • Active content

  • Privacy infringement


Active content

  • Browsers download and run SW without notice

  • Java applets

  • ActiveX controls

  • Plug-ins

  • Helper app’s

  • JavaScript

  • Malicious (not many) / buggy (???)


Privacy infringement

  • Site-collected data on visitors

    • Server log (time, date, IP addr., document, referrer URL)

    • Proxy servers log (every site visited)

    • Cookies

  • User-provided data

  • Solutions: e.g., “stealth browser”


Risks to the web site

  • Webjacking

  • Server and LAN break-ins

  • Denial-of-service attacks


Webjacking

  • Break in & modify contents

  • Happens(ed) a lot

  • How?

    • Exploit holes in

      • OS, Web server, buggy SW

        • CGI scripts


Server and LAN break-ins

  • Various attacks at different protocol layers (OSI, more …)

  • Defense: firewall


Denial-of-service attacks

  • Cause server to crash / hang / “crawl”

    • OS, server, CGI scripts, Web site services

  • No real defenses

    • Place limits on resources used by server / other sw

    • Close known holes


Part I: Document confidentiality

  • Basic cryptography

  • SSL, SET, and Digital Payment Systems


Basic cryptography

  • How cryptography works

  • Symmetric cryptography

  • Public key cryptography

  • Online Resources

  • Printed Resources


How cryptography works

  • Plaintext

  • Ciphertext

  • Cryptographic algorithm

  • Key

Decryption

Key

Algorithm

Plaintext

Ciphertext

Encryption


Simple cryptosystem ...

  • Caesar Cipher

    • Simple substitution cipher

  • ROT-13

    • half alphabet ==> 2 x ==> plaintext


Keys cryptosystems …

  • keys and keyspace ...

  • secret-key and public-key ...

  • key management ...

  • strength of key systems ...


Keys and keyspace …

  • ROT: key is N

  • Brute force: 25 values of N

  • IDEA in PGP: 2128 numeric keys

  • 1 billion keys / sec ==> >10,781,000,000,000,000,000,000 years


Key

Decryption

Plaintext

Ciphertext

Plaintext

Encryption

Sender

Recipient

Symmetric cryptography

  • DES

  • Triple DES, DESX, GDES, RDES

  • RC2, RC4, RC5

  • IDEA

  • Blowfish


DES

  • Data Encryption Standard

  • US NIST (‘70s)

  • 56-bit key

    • Good then

    • Not enough now (cracked June 1997)

  • Discrete blocks of 64 bits

  • Often w/ CBC (cipherblock chaining)

    • Each blocks encr. depends on contents of previous


Triple DES, DESX, GDES, RDES

  • Variants on DES: decrease risk of brute-force guessing

  • Triple-DES

    • 1. W/ Key 1

    • 2. W/ Key 2

    • 3. W/ Key 1

  • ==> Effective key length ~168 bits


RC2, RC4, RC5

  • Proprietary (RSA Data Security, Inc.)

  • Variable length keys (up to 2,048 bits)

  • Outside US: 40-bit versions of RC2 & RC4

    • ==> Web browsers & servers


IDEA

  • Int’l Data Encryption Algorithm

  • Patented (AscomTech AG)

  • Popular in Europe

  • 128-bit key ==> more secure than DES

  • (One of) at heart of PGP

  • (Other is RSA)


Blowfish

  • Unpatented (Bruce Schneier)

  • In many commercial & freeware

  • Var-length key (up to 448 bits)


Symmetric not fit for Internet

  • Spontaneous comm ==> can’t exchange keys

  • Multiway comm ==> key secrecy compromised


Public key cryptography

  • Two-in-one

    • Cryptography

    • Digital signatures


Key

Key

Decryption

Recipient’s secret key

Recipient’s public key

Encryption

Public key cryptography

  • Asymmetric

Plaintext

Ciphertext

Plaintext

Recipient

Senders


Key

Key

Decryption

Sender’s public key

Sender’s secret key

Recipient

Sender

Encryption

Digital signatures

  • But, problem ...

Authenticated Plaintext

Plaintext

Digital signature

y

=?


Problem ...

  • Can cut & paste from older

  • Solutions

    • A --> B: random “challenge” phrase

    • B --> A: sign w/ secret key, return

    • A: decrypts w/ B’s public key, compare to original

  • Or, message digest functions


Key

Recipient’s secret key

Key

Key

Key

Sender’s public key

Recipient’s public key

Recipient

Sender

Sender’s secret key

Combining cryptography and digital signature

Signature text (“challenge”)

Message text

Authenticated Message

y

=?

Digital signature

Ciphertext

sig.

text


Message digest functions & message integrity

  • One-way hashes

  • Digital fingerprint for original message

  • Sender ...

  • Recipient


Sender

  • 1. Run message through digest function

  • 2. Sign hash with secret key

  • 3. Send signed hash & original message to recipient


Recipient

  • Decrypt hash w/ sender’s public key

  • Compare with result of running message through digest function

  • Match ==> verified integrity

  • In SSL (later): Message Authenticity Check (MAC)

    • MAC = digest(secret + digest(secret - message))


Message digest functions

  • MD4 (Rivest, MIT)

    • 128-bit hashes

    • Weaknesses ==>

  • MD5 (Rivest)

    • Most widely used

  • SHA: Secure Hash Algorithm (NIST)

    • 160-bit hash


Digital envelopes

  • Public key encryption SLOWER than symmetric ==> Hybrid

  • 1. Random secret key (“session key”; discard when done)

  • 2. Encrypt message w/ session key & symmetric alg.

  • Encrypt session key w/ recipient’s public key (==> “digital envelope”)

  • Send encrypted message + digital envelope


Key

Key

Key

Session key

Session key

Recipient’s secret key

Key

Recipient’s public key

Recipient

Sender

Digital envelopes

Message plaintext

Message plaintext

Ciphertext


Certifying authorities & public key infrastructure

  • Large public-key database

  • ==> management? Trusted third party

  • Certifying authorities (CA)


Key

Key

Individual’s public key

CA’s secret key

Certifying authorities (CA)

Certifying Authority (CA):

1. Verify individual’s ID

2. Create certificate

3. Generate message digest from certificate,

signs hash w/ its secret key

4. Return certificate to individual

Individual’s distinguished name

Signed certificate

Certificate request

(w/ public key)

ID info

$$$ Pay CA’s fee


Public key infrastructure

  • Site certificates: authenticate Web servers

  • Personal certificate: individuals

  • SW publisher certificates: executables

  • Certifying authority certificates

  • Common format: X.509v3

  • CPS: certification practice statement


Root CAs & certificate chains

  • Browsers delivered w/ signed certificates of well-known CAs (root)

  • Root CAs can sign

    • End user’s public key

    • Another (secondary) CA’s public key

      • ==> Signing authority

      • ==> Certificate chain

      • ==> “Hierarchy of trust”


Certificate expiration and revocation list

  • Invalidate public/secret key pair

    • Loss/corruption/theft of secret key

    • Change in ID info in certificate

    • Compromise of CA’s secret key

  • CRL: Certificate Revocation List

  • Certificate expiration date (1 year)


Diffie-Helman: encrypton without authentication

  • Encryption + authentication usually together

  • At least one party produces signed certificate ==> no anonymous comm.

  • Diffie-Helman key exchange: negotiate session key wo sending key

  • Each party picks partial key independently


Diffie-Helman (cont.)

  • Send part of key info

  • Other side calculates common key value

  • Eavesdropper can’t reconstruct key

  • Use symmetric algorithm

  • Discard session key at end

  • No authentication ==> “man-in-the-middle” attack


Man-in-the-middle attack

  • A, B want to communicate

  • C imposes in network between two wo arousing suspicions

  • A negotiates w/ C thinking it’s B

  • B negotiates w/ C thinking it’s A

  • A & B sending messages, C relaying

  • A & B think comm is secure; C reads & can modify

  • Hard to accomplish


Securing private (secret) keys

  • Stored on hard disk encrypted

  • When first invoked, prompt for pass phrase to unlock

  • Key read into memory

  • Problem: virus/other sw looking for private keys

  • Solution: on ROM on smart card (take away)


Key length and security

  • Longer key ==> more secure message

  • How long? How secure?

  • Good alg. + implementation + key management ==> brute-force only

  • Cost to crack vs. cost of normal use

  • Estimated cracking cost...


Cost ($)

Key length

40 bits

56 bits

64 bits

80 bits

128 bits

$ thousands

Seconds

Days

Months

Eons

> Age of universe

$ millions

< 1 Second

Hours

Days

Millennia

> Age of universe

Estimated cracking cost...


Key length & US encryption policy

  • Strong encryption classified as munition

  • SW must get export license

  • RC2, RC4 w/ 40-bit keys (or less)

  • RSA w/ 512-bit keys

  • Digital signature but no encryption

  • Financial app’s (e.g., Quicken)


US policy continued

  • Slowing effect on SW dev

  • Online products limited to export version

  • ==> Most browsers crippled

  • Servers overseas crippled

  • Must have both side for secure transaction

  • Versions of Netscape + IE exempt ==>128-bit keys


Resources

  • Stein’s on-line resource

  • B. Schneier: Practical Cryptography, 2nd Edition (Wiley, 1995)

  • R. E. Smith: Internet Cryptography (Addison-Wesley, 1997)


SSL, SET, and Digital Payment Systems

  • Internet cryptographic protocols

  • SSL: Secure Sockets Layer

  • SET: Secure Electronic Transactions

  • Other Digital Payment Systems


Internet cryptographic protocols


SSL: Secure Sockets Layer

  • History

  • Characteristics

  • SSL Transaction


SSL History

  • 1994: Netscape Navigator 1.0

  • 1994: S-HTTP (CommerceNet)

  • Similarities: digital envelopes, signed certificates, message digest

  • Differences

    • S-HTTP: Web protocol; pay (dead)

    • SSL: Lower level; free


SSL cracked

  • 1995, 1997: 40-bit keys (1 wk, 3.5 hrs)

  • 1997: predictable session keys

  • 1997: sniffer ==> file sharing attack discovered


Application

SSL

Transport

Internet

Network interface

Physical layer

SSL Characteristics

HTTP

FTP

S-HTTP

NNTP

TELNET


SSL Characteristics (cont.)

  • Flexibility, protocol independence

  • Not specifically tuned for HTTP

  • SSL connection must use dedicated TCP/IP socket

  • Distinct port for SSL-mode server (443)

  • Flexibility re symmetric encryption alg., message digest function, authentication method


SSL connection ==> all encrypted

  • URL of requested document

  • Contents of requested document

  • Contents of any submitted form

  • Cookies sent from browser to server

  • Cookies send from server to browser

  • Contents of HTTP header


1. ClientHello message

2. ServerHello (ack)

3. Server’s signed site certficate (+chain)

[4. Request client’s certificate]

Server

Client (browser)

[5. Client’s certificate]

6. ClientKeyExchange message (symmetric session key, digital envelope)

[7. Certificate Verify message (digital signature)]

8. ChangeCipherSpec messages (both)

9. Finished messages (both)

SSL transaction


SET: Secure Electronic Transactions

  • What is SET?

  • Why not just use SSL?

  • SET in a Nutshell

  • SET user interface


What is SET (Secure Electronic Transactions)?

  • Cryptogrqphic protocol

  • Visa, Mastercard, Netscape, Microsoft

  • Only for credit- and debit-card transactions

  • SET low-level services ...

  • SET high-level features ...


SET low-level services ...

  • Authentication

  • Confidentiality

  • Linkage


SET high-level features ...

  • Cardholder registration

  • Merchant registration

  • Purchase requests

  • Payment authorization

  • Payment capture (funds transfer)

  • Chargebacks (refunds)

  • Credits

  • Credit reversals

  • Debit card transactions


Why not just use SSL?

  • SSL: no support for high-level features

  • Server-side security

  • Avoid misuse of credit card number guessers

  • Avoid general-purpose U.S. export restrictions

    • Financial transactions excluded


SET in a nutshell

  • 1. Customer initiates purchase

  • 2. Client’s SW send order & payment info

  • 3. Merchant passes payment info to bank

  • 4. Bank checks validity of card

  • 5. Card issuer authorizes & signs charge slip

  • 6. Merchant’s bank authorizes transaction

  • 7. Merchant’s Web server completes transaction

  • 8. Merchant “captures” transaction

  • 9. Card issuer sends bill to customer


SET notes (functional)

  • Authentication in every phase

    • ==> Certificates for card issuer, merchant’s bank

    • All must register

      • ==> SW generates public & secret keys

  • Two key pairs for certain parts of protocol


SET notes (technical)

  • Secure Hash Algorithms (SHA)

    • ==> 160-bit hash

  • Public/secret key pair: RSA, 1,024 bit

  • Symmetric encryption: DES

    • 56-bit key

    • ==> Cost of cracking assumed higher than value of single credit card transaction


Other digital payment systems

  • Why need other payment systems?

  • First Virtual

  • CyberCash

  • DigiCash

  • Millicent


Why need other payment systems?

  • SET: credit/debit cards

  • ==> Transaction fees

  • ==> Not economical for low-cost

    • ==> Not good for impulse buying

  • Not anonymous

  • ==> E-money

    • Cryptography ==> complex systems


First Virtual

  • For intangibles (SW, web pages, games)

  • No encryption, all secret info previously by phone

  • Only PIN #

  • Merchant has CGI script to validate PIN

  • E-mail to customer w/ details of purchase to be approved


CyberCash

  • User: CyberCash Wallet SW on PC

  • Credit card / bank account info encrypted there

  • Merchant: Electronic Cash Register SW on server

  • Strong encryption

  • High transaction overhead

  • CyberCoin for small payments


DigiCash

  • Like phone cards/subway tokens

  • CyberBucks: electronic voucher

  • User mints, banks signs

  • Cost of signing = face value

  • Digitally signed w/ public key encryption

  • Can’t trace, unless try to use twice

  • Transmit money safely between peers wo bank


Millicent

  • DEC, late 1996

  • Low overhead, up to $5

  • Brokers & scrips (like gift certificate)

  • Merchant produces & validates

  • Broker sells at markup

  • ==> No centralized server for validation (bottleneck)

  • No strong cryptography (small amounts)


Part II: Client-side security

  • Using SSL

  • Active content

  • Web privacy


Using SSL

  • SSL at work

  • Personal certificates

  • Checklist


SSL at work

  • Establishing an SSL connection

  • Things to watch for


Establishing an SSL connection

  • URL must begin with https (“HTTP-secure”)

  • Thin blue line between URL & content

  • Key at bottom left: solid

    • Usually broken

  • Key has two teeth ==> crippled export-grade encryption

  • Communicator: padlock instead of key


More info about secure session

  • Click key/lock, or “security” button

  • Scroll down to get info about security and certificates


Things to watch for

  • Site name mismatches

  • Mixed pages

  • Export & domestic-grade cryptography

  • Certificate revocation and expiration

  • CA and site certificates


Site name mismatches

  • Validation of site’s certificate

  • Mismatch ==> warning

  • User’s option, continue or stop

  • Check remote site’s certificate manually before submitting confidential info.


Mixed pages

  • Can have mix un / encrypted

  • E.g., inline images of main SSL, wo

  • Doc info window show security info for ea element separately

  • Can have browser warn

  • Watch: form submitted without encryption

  • Have browser warn when submitting forms unencrypted


Export & domestic-grade cryptography

  • If downloaded from FTP or Web site ==> crippled version (probably)

  • U.S., Canada: buy shrink-wrapped

  • Other: Safe Passage (small Web proxy)

    • Joint product: C2Net Inc & Thawte Comm Ltd.

  • Proxy: uses strong encryption


Certificate revocation and expiration

  • Site certificate may be revoked

    • New to replace old cert (e.g., typo)

    • Site’s private key compromised

  • Serial # stored in cert. revocation list (maintained by CA)

  • Browsers don’t check list!

  • Only know when cert expires

  • If confidential info: CANCEL


CA and site certificates

  • Browser comes w/ public keys of CAs

    • “Self-signed” certificates

      • CA signed

    • View: Options->Security Preferences->Site Certificates->Signers

    • Can view contents

    • Can delete

      • E.g., Netscape Test CA (meaningless)


CA and site certificates (cont.)

  • Can deactivate without deleting

  • Can require warning before sending to sites certified by particular CA

  • Certificate from CA not on list?

    • Netscape: warning, accept / reject?

    • IE: reject, display warning, cannot complete connection

  • Can install additional CA certficates


CA vs. site certificates

  • Accept site certificate: tell browser that willing to exchange SSL-encrypted messages with one site

  • CA certificate: trust every site w/ cert signed by that CA

    • Be more careful!

  • Communicator->Security Info


Personal certificates

  • Analogous to site certificate

  • Name, e-mail, public-key

  • Signed by CA

  • VeriSign personal certificates

  • Obtaining a VeriSign personal certificate

  • Browser SSL settings


VeriSign personal certificates

  • Obtain own “digital ID”

  • Small fee

  • Two types

    • Class 1: casual use ($9.95/yr.)

    • Class 2: some guarantee of ID ($19.95/yr.)

    • (Class 3: high security; announced, not available yet)


Class 1: casual use

  • To obtain: complete form on VeriSign site

    • Auto process

    • No validation of info entered

    • Receive e-mail when signed cert ready

      • URL and access code to retrieve


Class 2: some guarantee of ID

  • To obtain: provide mailing address, driver’s license, ss #

  • Will be issued after validation of info w/ credit bureau

  • Info to retrieve sent by surface mail (prevent fraud)


What can you do with a VeriSign ID?

  • Not very much, at the moment

  • Few Web sites collect to customize

  • In the future: members-only areas

  • Send/receive encrypted e-mail

  • Reliability?

    • Class 1: No proof of ID

    • Class 2: better, but not fullproof


Send/receive encrypted e-mail

  • S/MIME (Secure Multipurpose Internet Mail Extensions): not yet popular

  • Can search a user’s cert, install & use

  • Better: PGP

    • Free, widely used, no reliance on 3rd party certification


Disadvantages of using personal certificate

  • Give up anonymity

  • SSL site can require browser to present certificate

  • Site’s use of info unknown (marketing, mailing lists)

  • Important in SET, corp. intranets


Obtaining a VeriSign personal certificate

  • Steps to obtain -- omitted


Browser SSL settings

  • Alert before

    • Entering, leaving secure doc space (server)

    • Viewing doc w/ secure/insecure mix

    • Submitting form insecurely

  • Control SSL protocol

    • SSL 2.0, 3.0, passwords

    • Caching of SSL retrieved documents [off]


Checklist

  • Always use SSL browser for confidential info

  • Never use crippled export-grade cryptography browser for confidential documents

  • Password-protect personal certificate

  • Never accept CA certificate from unknown Web site

  • Back up personal certificates


Online Resources

  • VeriSign: http://www.verisign.com

  • Safe passage: http://www.c2.net

  • PGP: www.pgp.com

  • RSA Data Security (S/MIME): http://www.rsa.com/rsa/S-MIME

  • Simple Perl-based packet sniffer: http://www.genome.wi.mit.edu/~lstein/talks/WWW6/sniffer

  • Tcpdump & libpcap (required for sniffer): ftp://ftp.ee.lbl.gov/tcpdump.tar.Z, libpcap.tar.Z


Printed Resources

  • Garfinkel, Simson: Pretty Good Privacy, O’Reilly & Assoc. 1995


Active content

  • Bad by design or bad by accident?

  • Traditional threats

  • Helper applications and plug-ins

  • Java

  • ActiveX

  • JavaScript and VBScript

  • Exotic technologies

  • What can you do

  • Changing active content settings

  • Checklist

  • Resources


Bad by design or bad by accident?

  • E.g., the Moldovan scam

    • Pornography site

    • Download viewer

    • Viewer disconnect user, turn off speakers, reconnect to ISP in Moldova (“900”)

    • Even when leave site, still connected


Traditional threats

  • Trojan horses

    • Pretend; introduce viruses, etc.

  • Viruses

  • Macro viruses

    • Across OSs

  • Rabbits: many copies

  • Worms: like rabbits, but spread across Net


Helper applications and plug-ins

  • Keep to bare minimum

  • Only from trusted sources

  • Check vendor’s support pages for discovered security holes


Java

  • Applet security restrictions

  • Hostile applets

  • Annoying applets

  • Inadequate applets


Java applets

  • <applet code = “example_applet” codebase = “http://www.some-server.org/some-directory/”<param name = “image” value = “example.gif”><param name = “color” value = “blue”></applet>


Applet security restrictions

  • Applet cannot

    • Read from / write to local disk

    • Access physical HW

      • Memory, disk drives, drivers

    • Access sys env info

    • Invoke sys commands / run external programs

    • Open network connections, only “home” (“phone-home restriction”)


Hostile applets

  • Failure of phone-home restriction

  • Execute arbitrary machine instructions

  • Bypass Java security manager with hand-crafted bytecode


Failure of phone-home restriction

  • 1996, Steve Gibbons, Edward Felten (independetly)

  • Temporary subvert domain-name system

  • ==> Circumvent net connection restriction

  • Send out hostile applet

    • Contact any machine on Net

    • Including on user’s side of firewall

    • Navigator 2.0; fixed (?) 2.01


Execute arbitrary machine instructions

  • Bug in Java interpreter loading of libraries

  • ==> Remote users can circumvent

  • Trick browser to download code library

    • Disguise as “broken” inline image

  • ==> Place in browser cache

  • Send applet that loads code

  • Library not restricted by security manager

  • ==> Applet “broken out of sandbox”

  • ==> Can do whatever it wishes

  • Navigtor 2.0, 2.01; fixed 2.02


Bypass Java security manager with hand-crafted bytecode

  • Sun, March 1997

  • Bug in Java bytecode verifier

  • Hand-craft bytecode

  • ==> Bypass Java security manager

  • ==> Execute forbidden commands

  • IE 3.01, NN 3.01; fixed later


Another phone-home restriction bug

  • Applets make network connections to machines behind corporate firewall

  • NN 3.02, 4.01; IE not known

  • No known fix


Summary: No known attacks

  • Any of bugs

  • Theoretical

  • Most closed

  • Holes may exist

  • Security model sound


Annoying applets

  • Infinite loop; slow machine

  • Allocate large memory structures

  • Make multiple copies of self in memory

  • Open window larger than desktop, prevent from getting to other windows

  • Open new windows faster than user can close

  • Windowing op’s that crash browser


Inadequate applets

  • Sandbox prevent bad and good

  • Future: control stepping out

    • Grant rights to read, write, print, make net connections

      • Selected files, dirs., locations

    • Code signing: authenticate ==> privileges

  • For now: run or not


ActiveX

  • ActiveX vs. Java

  • Authenticode system

  • Is ActiveX safe?


ActiveX control

  • <object id = “example_control” classid = “clsid:7223B620-9FF9-11AF-00AA00C06662” codebase = “http://www.some-server.org/some-directory/” width = 70 height = 40><param name = “image” value = “example.gif”><param name = color” value = “blue”><param name = “_version” value = “3”></object>


ActiveX vs. Java

  • Stripped down OLE

  • Everything Java applets do

  • Written in conventional language

  • Compiled into machine native code

  • Browser downloads control

  • Calls O, load to mem, exec.

  • Must be recompiled for OS / HW


Programmer’s advantages

  • Use familiar compilers & languages

  • Use existing programs, OLE components, libraries

  • Controls can do anything

    • Save to disk, report statistics, test network, check for viruses


Authenticode system

  • ActiveX controls cryptographically signed by authors before release

  • Uniquely identify SW developer

  • Provide guarantee that SW hasn’t been modified since signed

  • Browser checks signature

  • Similar process to other certification


Is ActiveX safe?

  • MS: Authenticode keeps “bad” SW developers away

    • Same protection as with SW in store

  • 1. Evil hacker won’t apply for cert

  • 2. Developer introducing malicious control ==> breaking pledge

  • 3. Authenticode give way to identify source of malicious control


Is ActiveX safe? (cont.)

  • Basic assumption: protection from “bad by design”

  • Historically, most security holes “by accident”

    • Well-intended developers

  • Authenticode doesn’t help here

  • Also, no protection from viruses introduced during dev process


Is ActiveX safe? (cont.)

  • Main problem: binary trust model

    • Not trusted / trusted completely

  • Better model: finer gradation of trust

    • And privileges

  • Controlling ActiveX:

    • Don’t run at all (recommended)

    • Run signed controls automatically / Warn before running unsigned

    • Run all always


JavaScript and VBScript

  • JavaScript security problems

  • VBScript security problems


JavaScript security problems

  • Send email in user’s name

  • Get directory listing on local file sys

  • Upload contents of a file

  • Monitor pages visited by user

  • Log images viewed by user

  • Can be used to make denial-of-service attacks


Can be used to make denial-of-service attacks

  • Start CPU-intensive task

    • Allocate large mem chunk

    • ==> Slow system down to crawl

  • Make browser open windows faster than can close

  • Cause browser to quit / crash


JavaScript security history: bad

  • Lots of bugs

  • Netscape planned JavaScript code signing (same tech as for Java applets)

    • Only run if originate from trusted sources

  • Until then: Turn JavaScript off!


VBScript security problems

  • Little scrutiny by Internet community

  • No major security holes reported

  • Can be used to make denial-of-service attacks

  • Might have to reboot machine to regain control


Browser as security hole

  • No need for active content to compromise security

  • Bug can (have) be(en) exploited

  • E.g., IE, shortcut files copied to server + accessed over Internet

    • Open copy on user’s local machine, not server


Browser as security hole (cont.)

  • MS IIS challenge-response authentication

    • Fool IE to think that IIS wants authentication

    • ==> Hand over user’s password

  • Protection:

  • NT: hard-to-guess password

  • Firewall to reject file-sharing requests

  • Don’t run browser under admin acct


Exotic technologies

  • E.g., XML, dHTML, PointCast, VRML 2.0

  • Security “audit”:

  • 1. Command language interpretation?

  • 2. Modify files on user’s computer?

  • 3. Transmist info back to server?

  • 4. Create UI that mimic trusted part of OS?


Exotic technologies (cont.)

  • If “yes” to any be prepared for problems

  • E.g., VRML 2.0

    • Hooks allw Java /JavaScript code to be attached to objects, giving them behavior

    • VRML viewers need command interpreter ==> avenue for exploitation


What can you do

  • General precautions

    • User privileges

    • Virus checkers

    • Verify integrity of downloaded SW

    • Backups

  • Barring the gates

    • Firewalls scan HTML docs for <APPLET>, <OBJECT>

    • Ban Java, JavaScript, ActiveX


Changing active content settings

  • Internet Explorer

  • Netscape Navigator


Checklist

  • 1. What plug-ins / helper app’s installed? What for?

  • 2. Scan for viruses?

  • 3. Browse while logged on as admin / root?

  • 4. Up to date on browser’s security issues?

  • 5. Really need to view active content?


Resources

  • Internet scams

  • Java applets

  • ActiveX controls & authenticode

  • Virus checkers

  • Security holes in MS IE

  • Browser security pages & alerts


Web privacy

  • What Web Surfing Reveals

  • Server Logs

  • Cookies

  • PICS

  • Advice for Users

  • Advice for Webmasters

  • Policy Initiatives

  • Checklist

  • Resources


What Web Surfing Reveals

  • www.cdt.org (Center for Democracy & Technology)

  • Name

  • Employer

  • Geographic location

  • Browser

  • URL

  • Referrer


Record of URLs visited

  • Browser

    • History file

    • Document cache

  • Firewall

    • Organization

    • ISP

  • Remote server visited


They want your data

  • Market researchers

  • Advertisers

  • Web merchants

  • Companies in their service

    • E.g., Engage Tech

    • DoubleClick


Server Logs

  • What’s in a log file

  • Referrer logs

  • Proxy logs


Referrer logs

  • Uses & abuses

    • “Belly dancer picture”

    • Bookmark referral

    • Search engine referral

    • Local file

    • Web site referral

    • Referral from SW developer


Bookmark referral

  • gate.swm.de http://ws084242.swm.de/~klein/bookmarks.html -> /~lstein/

  • Behind firewall …. But

  • Have name of machine (ws084242)

  • Can extract IP address from www.swm.de

  • Also company name


Search engine referral

  • 200.10.239.68 http://www.excite.com/search.gw?search=netscape+cookies+FAQ&collection=web -> /WWW/faqs/www-security-faq.html

  • Searched via Excite for netscape, cookies, and FAQ

  • Found WWW Security FAQ page


Local file

  • scilib-153.brown.edu file:///cs2/social%20impact./security.html -> /WWW/faqs/www-security-faq.html

  • Ordinary file


Web site referral

  • 194.117.215.97 http://www.trouble.org/survey/introduction.html -> /WWW/faqs/www-security-faq.html


Referral from SW developer

  • janice.informatik.uni-dortmund.ed http://webreferrnce.com/programming/perl.html -> /ftp/pub/software/WWW/cgi_docs.html


Referrer log privacy infringement examples

  • 1. User places order on merchant site

  • 2. Enters credit card + data to form

  • 3. Submits form (SSL)

  • 4. Receives confirmation page

  • 5. Ad in confirmation page

  • 6. User clicks on ad to jump

  • 7. Here’s the referre log of new site


Referrer log of new site

  • pressrm.dp.com http://www.merchant.com/cgi-bin/order?name=Lois+Lane&address=Daily+Palnet,Gotham+City&item=digital+altimeter&quantity=1&credit+card=4128112211331144&-> /index.html

  • What happened?


What happened?

  • GET instead of POST

    • ==> form fields appended to URL

  • Incorporated in confirmation page URL

  • Forwarded in referrer field


Proxy logs

  • Middlemen between user & server

  • Large ISPs to reduce BW demand

    • Cache popular doc’s locally

  • Also in firewalls

  • Log URL, time, date, referrer

  • ==> Collect lots of data on users

  • But also preserve privacy

    • Anonymizing proxies


Cookies


PICS


Advice for Users


Advice for Webmasters


Policy Initiatives


Checklist


Resources


Part III: Server-Side Security

  • Server Security

  • UNIX Web Servers

  • Windows NT Web Servers

  • Access Control

  • Encryption and Certificate-Based Access Control

  • Safe CGI Scripting

  • Remote Authoring and Administration

  • Web Servers and Firewalls


Server security

  • Why Are Web Sites Vulnerable?

  • Frequently Asked Questions About Web Server Security

  • Overview: Steps to Securing a Web Site

  • Online Resources


UNIX Web servers

  • Hardening a UNIX Web Server

  • Configuring the Web Server

  • Monitoring Logs

  • Monitor the Integrity of System Files and Binaries

  • Back Up Your System

  • Checklist

  • Online Resources

  • Printed Resources


Windows NT Web servers

  • NT Security Concepts

  • Windows NT Security Risks

  • Securing a Windows NT Web Server

  • Configuring the Web Server

  • Checklist

  • Online Resources

  • Printed Resources


Access control

  • Types of Access Control

  • Access Control Based on IP Address or Host Name

  • Access Control Based on User Name and Password

  • Other Types of Access Control

  • Access Control and CGI Scripts

  • Checklist

  • Online Resources


Encryption and Certificate-Based Access Control

  • SSL-Enabled Web Servers

  • Using Client Certificates for Access Control

  • Using Client Certificates for Web Server Access Control

  • Becoming Your Own Certifying Authority

  • Final Words

  • Checklist

  • Online Resources

  • Printed Resources


Safe CGI Scripting

  • Introduction to CGI Scripts and Server Modules

  • Common Failure Modes

  • Other Advice

  • Safe Scripting in Perl

  • CGI Wrappers

  • Checklist

  • Online Resources

  • Printed Resources


Remote Authoring and Administration

  • Degrees of Trust

  • Controlling Access to the Web Server Host

  • Remote Authoring Via FTP

  • Microsoft FrontPage

  • The HTTP PUT Protocol

  • An Upload Staging Area

  • Administering the Web Server Remotely

  • Access to the Server for Web Developers

  • Checklist

  • Online Resources

  • Printed Resources


Web Servers and Firewalls

  • What Is a Firewall?

  • Selecting a Firewall System

  • Configuring a Firewall

  • Automatic Proxy Configuration for Browsers

  • Examining Firewall Logs for Signs of Server Compromise

  • Checklist

  • Online Resources

  • Printed Resources


Bibliography/references


  • Login