Internet web security
Download
1 / 179

Internet & Web Security - PowerPoint PPT Presentation


  • 264 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Internet & Web Security' - shing


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

References resources
References & Resources

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

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


What is web security
What is web security?

  • Three parts of web security

  • Three points of view

  • Risks


Three components of web security
Three components of web security

  • Browser

  • Server

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


Three points of view
Three points of view

  • User’s

  • Webmaster’s

  • Both parties’


User s point of view
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
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
Both parties’ point of view

  • Network connection free of eavesdropping

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


Three interdependent parts
Three (interdependent) parts

  • Document confidentiality

  • Client-side security

  • Server-side security


Document confidentiality
Document confidentiality

  • Protect private information from

    • Eavesdropping

    • Fraudulent identities

  • Mostly via cryptography


Client side security
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
Server-side security

  • Protect server from

    • Break-ins

    • Site vandalism

    • Denial-of-service attacks

  • Mostly firewalls and OS security measures


Risks
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
Risks that affect both client and server

  • Eavesdropping

    • “Packet sniffers” (more …)

  • Fraud


Network snooping sniffing
Network snooping (sniffing) ...

  • Abuse of network debugging tools ...

  • Network interface into promiscuous mode ...

  • Solution: encrypt


Abuse of network debugging tools
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
Network interface into promiscuous mode ...

  • Report all packets to sniffer

    • Display / record

    • Analyze

  • Remote also possible


Fraud
Fraud

  • Authenticate

    • Individuals, organizations

    • Transactions

    • Documents

  • Solution: digital signatures, certification authorities


Risks to the end user
Risks to the end user

  • Active content

  • Privacy infringement


Active content
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
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
Risks to the web site

  • Webjacking

  • Server and LAN break-ins

  • Denial-of-service attacks


Webjacking
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
Server and LAN break-ins

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

  • Defense: firewall


Denial of service attacks
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
Part I: Document confidentiality

  • Basic cryptography

  • SSL, SET, and Digital Payment Systems


Basic cryptography
Basic cryptography

  • How cryptography works

  • Symmetric cryptography

  • Public key cryptography

  • Online Resources

  • Printed Resources


How cryptography works
How cryptography works

  • Plaintext

  • Ciphertext

  • Cryptographic algorithm

  • Key

Decryption

Key

Algorithm

Plaintext

Ciphertext

Encryption


Simple cryptosystem
Simple cryptosystem ...

  • Caesar Cipher

    • Simple substitution cipher

  • ROT-13

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


Keys cryptosystems
Keys cryptosystems …

  • keys and keyspace ...

  • secret-key and public-key ...

  • key management ...

  • strength of key systems ...


Keys and keyspace
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


Symmetric cryptography

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
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
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
Blowfish

  • Unpatented (Bruce Schneier)

  • In many commercial & freeware

  • Var-length key (up to 448 bits)


Symmetric not fit for internet
Symmetric not fit for Internet

  • Spontaneous comm ==> can’t exchange keys

  • Multiway comm ==> key secrecy compromised


Public key cryptography
Public key cryptography

  • Two-in-one

    • Cryptography

    • Digital signatures


Public key cryptography1

Key

Key

Decryption

Recipient’s secret key

Recipient’s public key

Encryption

Public key cryptography

  • Asymmetric

Plaintext

Ciphertext

Plaintext

Recipient

Senders


Digital signatures

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
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


Combining cryptography and digital signature

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
Message digest functions & message integrity

  • One-way hashes

  • Digital fingerprint for original message

  • Sender ...

  • Recipient


Sender
Sender

  • 1. Run message through digest function

  • 2. Sign hash with secret key

  • 3. Send signed hash & original message to recipient


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
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
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


Digital envelopes1

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
Certifying authorities & public key infrastructure

  • Large public-key database

  • ==> management? Trusted third party

  • Certifying authorities (CA)


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
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
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
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
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
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
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
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
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...


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
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
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
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
SSL, SET, and Digital Payment Systems

  • Internet cryptographic protocols

  • SSL: Secure Sockets Layer

  • SET: Secure Electronic Transactions

  • Other Digital Payment Systems



Ssl secure sockets layer
SSL: Secure Sockets Layer

  • History

  • Characteristics

  • SSL Transaction


Ssl history
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
SSL cracked

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

  • 1997: predictable session keys

  • 1997: sniffer ==> file sharing attack discovered


Ssl characteristics

Application

SSL

Transport

Internet

Network interface

Physical layer

SSL Characteristics

HTTP

FTP

S-HTTP

NNTP

TELNET


Ssl characteristics cont
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
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


Ssl transaction

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
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
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
SET low-level services ...

  • Authentication

  • Confidentiality

  • Linkage


Set high level features
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
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
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
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
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
Other digital payment systems

  • Why need other payment systems?

  • First Virtual

  • CyberCash

  • DigiCash

  • Millicent


Why need other payment systems
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
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
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
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
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
Part II: Client-side security

  • Using SSL

  • Active content

  • Web privacy


Using ssl
Using SSL

  • SSL at work

  • Personal certificates

  • Checklist


Ssl at work
SSL at work

  • Establishing an SSL connection

  • Things to watch for


Establishing an ssl connection
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
More info about secure session

  • Click key/lock, or “security” button

  • Scroll down to get info about security and certificates


Things to watch for
Things to watch for

  • Site name mismatches

  • Mixed pages

  • Export & domestic-grade cryptography

  • Certificate revocation and expiration

  • CA and site certificates


Site name mismatches
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Obtaining a VeriSign personal certificate

  • Steps to obtain -- omitted


Browser ssl settings
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
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
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
Printed Resources

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


Active content1
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
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
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
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
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 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
Hostile applets

  • Failure of phone-home restriction

  • Execute arbitrary machine instructions

  • Bypass Java security manager with hand-crafted bytecode


Failure of phone home restriction
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
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
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
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
Summary: No known attacks

  • Any of bugs

  • Theoretical

  • Most closed

  • Holes may exist

  • Security model sound


Annoying applets
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
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

  • ActiveX vs. Java

  • Authenticode system

  • Is ActiveX safe?


Activex control
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
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
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
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
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
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 cont1
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 and VBScript

  • JavaScript security problems

  • VBScript security problems


Javascript 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
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
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
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
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
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
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
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
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
Changing active content settings

  • Internet Explorer

  • Netscape Navigator


Checklist1
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?


Resources1
Resources

  • Internet scams

  • Java applets

  • ActiveX controls & authenticode

  • Virus checkers

  • Security holes in MS IE

  • Browser security pages & alerts


Web privacy
Web privacy

  • What Web Surfing Reveals

  • Server Logs

  • Cookies

  • PICS

  • Advice for Users

  • Advice for Webmasters

  • Policy Initiatives

  • Checklist

  • Resources


What web surfing reveals
What Web Surfing Reveals

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

  • Name

  • Employer

  • Geographic location

  • Browser

  • URL

  • Referrer


Record of urls visited
Record of URLs visited

  • Browser

    • History file

    • Document cache

  • Firewall

    • Organization

    • ISP

  • Remote server visited


They want your data
They want your data

  • Market researchers

  • Advertisers

  • Web merchants

  • Companies in their service

    • E.g., Engage Tech

    • DoubleClick


Server logs
Server Logs

  • What’s in a log file

  • Referrer logs

  • Proxy logs


Referrer logs
Referrer logs

  • Uses & abuses

    • “Belly dancer picture”

    • Bookmark referral

    • Search engine referral

    • Local file

    • Web site referral

    • Referral from SW developer


Bookmark referral
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
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
Local file

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

  • Ordinary file


Web site referral
Web site referral

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


Referral from sw developer
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
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
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
What happened?

  • GET instead of POST

    • ==> form fields appended to URL

  • Incorporated in confirmation page URL

  • Forwarded in referrer field


Proxy logs
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









Part iii server side security
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
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
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
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
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
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
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
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
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



ad