dig 4104c – web design workshop j michael moshell web security lecture 8

DIG 4104c – Web Design WorkshopJ Michael Moshell

Web SecurityLecture 8

2

Objectives of today's lecture:

1) Introduce most common threats

2) Discuss Necessary Architectural Concepts

3) Introduce threat methods and responses

4) Provide ideas and directionsfor further exploration

Web Security - on the Fly

3

* Theft of proprietary data – - credit card numbers- personal data (e. g. South Carolina

Social Number Fiasco)

* Zombification of your computer –- becoming part of a botnet

* Vandalization or destruction of your site

* Denial of service attacks

Common Threats

4

* Concepts that must be mastered:

* Application Layer* Transport Layer* Internet Layer* Link Layer* Port* Firewall* Virtual Private Network* TLS (Transport Layer Security), daughter

of SSL (Secure Sockets Layer)* Cookies

Architecture of the Internet

Essential Architecture

Application: has themetadata neededfor the purpose - - >

Transport:Reliable, receipted - - - - >

Internet:Unreliable, multipath - - - >

Link: Ethernet, ATM, wireless- - - - - - ->(below): actual wires & electrons

6

Baseline: Internet Protocol

An IP address consists of 4 bytes,e. g. 200.240.82.114 = 32 bits; so, 2^32options (about 10^10 or 10 billion)

Not NEARLY enough, now that every sprinklerhead on every golf course ... needs one.

7


An IP address consists of 4 bytes,e. g. 200.240.82.114 = 32 bits; so, 2^32options (about 10^10 or 10 billion)

Not NEARLY enough, now that every sprinklerhead on every golf course ... needs one.

IPv6 uses 128 bits (16 bytes), which should be enough for a while...

2001:0db8:85a3:0042:1000:8a2e:0370:7334

8


An IP packet includes (among other junk)

• Version (v4 or v6)• Number of bytes in the packet• Time To Live • Protocol (TCP etc)

9



• Version (v4 or v6)• Number of bytes in the packet• Time To Live • Protocol (TCP, etc)• Source IP address• Destination Address• Header Checksum• The data

10



• Version (v4 or v6)• Number of bytes in the packet• Time To Live -- rhymes with "liver"

TTL: How many hops may it pass before it dies?

At every hop, TTL is decremented by 1

When it hits 0, nobody forwards the packet.

11


How does IP traffic flow?

Each router has a strategy for forwardingpackets it receives.

If an output channel isslow, routersuse alternateroutes

12


Analogy: It's the year 1700 ... no U. S. Post

I mail a letter from Edinburgh to Brooklyn

Someone takes itto London

Someone else takesit to Boston

A rider takes it to Brooklyn

13

Delivery is unreliable

Maybe the next letter goes via New Havenor Philadelphia

Maybe it gets lost or delayed along the way.

How could you builda RELIABLE (though slow) system

on an UNRELIABLE basis?

14

Recepts and Sequences

Solution: (1) serial - number your letters

(2) require receipts (return letters "I got it")

(3) If no receipt after 1 month, re-send

15



• Version (v4 or v6)• Number of bytes in the packet• Time To Live • Protocol (TCP, etc)• Source IP address• Destination Address• Header Checksum -- << wazzat?• The data

16


Header Checksum -- << wazzat?

All of the info except the 'data' is guarded bya hash-code. If the header is corruptedthe recipient (at any state) can detect it.

Why is there no DATA checksum?

That is an option for the next layer to implement.

17

Domain Name Service

136.224.108.14 is hard to use.

(And ... note: 332.14.22.11 is INCORRECT. Why?)

People like symbolic info: 'youtube.com'.

So a worldwide network of Domain Name Servers (DNS) provides a lookup service.

It's hierarchical.

18

Domain Name Service

To find an IP for a given URL:

1) Your ISP looks in its own DNS tables.2) If it cannot find, it asks its upstream DNS.3) This continues, back to the

Top Level Domain (like .com)

When you register or modify a domain name,frogwarticecream.com

The registrar must distribute this to ALL the DNSsystems in the world (at some level...)

19

Transport Control Protocol

Here's a simplified picture:

IP Header: IP Data

TCP Header:with sequenceand checksumcontrols

TCP data TCP Footercontrols

20

Application Layer: HTTP

MANY IP packets are usually necessaryto transmit ONE TCP message.

IP Header: IP Data

TCP Header:with sequenceand checksumcontrols

TCP data TCP Footercontrols

21

Application Layer: HTTP

HTTP, in turn, is carried inside the TCPmessage (spread across many IP packets):

IP Header: IP DataTCP Header:with sequenceand checksumcontrols

TCP data TCP FootercontrolsHTTP information

22

What is a PORT?

Originating with Unix:A message arrives at an Operating System:What to do with it?

Front end software- recognizes and processes the IP- extracts the TCP, assembles it, requests

retransmits as necessary until complete

- examines TCP packet for port number- passes TCP data to the associated application

23

Well-Known Ports:

20: FTP Data Transfer22: Secure Shell (SSH)23: Telnet (unencrypted)25: SMTP (Simple Mail Transfer Protocol)53: DNS80: HTTP118 or 156: SQL443: HTTPS

And ... there are MANY others http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers

24

What happens when ...?

A TCP packet arrives requesting servicefrom a port?

The OS runs the associated code and attempts todeal with the TCP data contents.

HOWever ... every OS is different, and many of thoseports are watched by risky, failure-pronesoftware.

512: Remote Process Execution514: Remote Shell, etc.

25

What is a Firewall?

A system resource that can MANAGEport access.

* completely CLOSING unused ports* admitting only TRUSTED users to some ports* permitting only some actions on some ports* monitoring all port access and logging it

The only thing more important than good viruscontrol, is a good firewall, well managed.

26

Where are Firewalls?

Lots of places.

Your PC

Prog

Firewall

Your DSLRouter

Firewall

WebServer

Firewall

ApacheWeb

Server

PHPresource

27

Where are Firewalls?

Lots of places. Each may choose to blocka given port.

Your PC

Prog

Firewall

Your DSLRouter

Firewall

WebServer

Firewall

ApacheWeb

Server

PHPresource

28

The Great Chinese Firewall

Last summer, in Beijing,HTTPS quit working!

Your PC

Prog

Firewall

Your DSLRouter

Firewall

WebServer

Firewall

ApacheWeb

Server

PHPresource

Firewall

443

Firewall

29

VPN to the Rescue!

Using an innocuousport, the VPN 'tunnels'through the firewalls

Your PC

Prog

Firewall

Your DSLRouter

Firewall

Purdue University

FW

VPN

VPN

HTTP80

HTTPS443

Firewall

30

VPN: Secure?

VPN can use its ownencryption, not relyingon HTTPS

Your PC

Prog

Firewall

Your DSLRouter

Firewall

Purdue University

FW

VPN

VPN

HTTP80

HTTPS443

Firewall

31

VPN: Why doesChina Allow?

(1) It's hard to stop;(2) They may not want to.

Your PC

Prog

Firewall

Your DSLRouter

Firewall

Purdue University

FW

VPN

VPN

HTTP80

HTTPS443

32

The RSA Public Key Encryption System: Key idea:

• "Trapdoor function": Easy in, difficult out.

Encryption and SSL: Key Concepts

DataEncryption

Anybody canEncrypt and sendA message to Bob

Bob’s Mailbox

33

The RSA Public Key Encryption System: Key idea 1:

• "Trapdoor function": Easy in, difficult out.

Encryption and TLS/SSL: Key Concepts

DataEncryption

Decryption

Bob’s Mailbox

Only Bob has theKey to his mailbox.

34

The RSA Public Key Encryption System: Key idea 2:

• "Symmetry": two keys are created: Key 1, Key 2.

If you ENCRYPT with Key 1, you can DECRYPT with K2

If you ENCRYPT with Key 2, you can DECRYPT with K1

How does it work? You don't want to know the math..It involves prime numbers and factorization.


35

Bob wants private data from Alice. Bob creates a Key pair (two big, special numbers)Bob posts one (the public key) on his websiteBob keeps the private key in a secret place

(Private Key)

Public Key


Alice in Atlanta

Bob in Boston

36

Bob wants private data from Alice. Bob creates a Key pair (two big, special numbers)Bob posts one (the public key) on his websiteBob keeps the private key in a secret place

(Private Key)Alice grabs acopy of the Public Keypublic key

Public Key


Alice in Atlanta

Bob in Boston

37

Alice uses the public key, encrypts data ('plaintext'),sends it to Bob. Chris the Criminal grabsa copy as it goes by.

key

plaintext ---> Encryptedpublic key ---> message

public key attempt to Chris getsdecipher ?? garbage


Alice in Atlanta Bob in BostonChris the crook

38

Bob uses the private key to recover Alice'splaintext.

privatekey

plaintext ---> Encrypted de-public key ---> message cypher

plaintext


Alice in Atlanta

Bob in Boston

Chris the Crook

SSL and the Internet

• Uses a public key encryption technique

to exchange keys with your browser.

(PKE is too slow for all of the traffic.)

Relies on a "Chain of Authority" to verify

That security certificates (public keys)

Actually belong to who they say.

Chain of Authority

• How it works?

• My business has a security certificate.

• You don't trust it, so you check with its

issuing authority (Thawte, Inc.)

* Who is Thawte? Check with THEIR issuing

authority … back to a trusted source.

• Your browser has a list of trusted authorities.

• (The police-verification story.)

Cookies

HTTP is STATELESS ("fire and forget").

Your browser would remember nothing

about a session ... until cookies came along.

Commonly stored info include:

* logged-in state

* passwords for frequently visited sites

* and most importantly – Session ID cookie -

Cookies and Sessions

A cookie contains:

= Name

= Value

* Expiration time (GMT)

* Path cookie is good for

* Domain cookie is good for

* Security requirement & HttpOnly

Items marked * are optional. If not specified,

default values are used.

Cookies and Sessions

A cookie contains:

= Name

= Value

* Expiration time (GMT)

* Path cookie is good for (default: requested obj.)

* Domain (default: requested domain)

* Security requirement (if present, use https)

* HttpOnly (e. g. do not allow Javascript access.)

Cookies and Privacy

An analogy:

A hobo visitor to your house makes a mark

on your front gate, to remind

himself (and others) about you:

("This home gives out food.")

("Bad dog")

Cookies and Privacy

Normally, browser will only release

a cookie to the IP address that

originally SET it.

But if, when setting the cookie, the setter

specifies somebody ELSE as the setter,

this is a 3rd party cookie.

You can set your browser to reject 3rd party cookes.

Cookies in the Browser

Threat Methods

* Cross Site Scripting

* SQL Injection Attack

* Password Penetration

* Port Scan Attack

* Buffer Overflow

* Viruses and Worms etc.

Cross Site Scripting

Non-persistent XSS:

If candystore.com is vulnerable to XSS,

Badguy puts an "apparently innocent"

link on his scraper site, pointing to

candystore.com. BUT

The link contains parameters that make

candystore.com reveal private info.

What's "Cross" about it?

My browser Evil Site Vulnerable

Site

candy.com

seek 'candy' return

contaminated

URL

link using

contam. URL penetration

Non-Persistent XSS

My browser Contaminated Vulnerable

Site, e. g. forum Site

candy.com

seek 'candy' return

contaminated

URL

link using


Persistent XSS

My browser Contaminateable Vulnerable

Site, e. g. forum Site

candy.com

Baddy submits

a post containing

dangerous script The post is now

available for anyone

to download

Persistent XSS hits

My browser Contaminated Vulnerable

Forum Site

Request a post candy.comreturn

contaminated

posting

link using


XSS Cookie Theft

A common attack is to run a script which harvests

the cookies in your browser and sends them

via email to the crook.

If you access a bad site ((a) hostile OR (b) contaminated), you don't even need to click on a link. The cookies are already gone.

But (a) is not your problem, as a web developer.

(b) IS your problem. You may be a 'carrier' of XSS.

If you accept user content of ANY kind, it MUST be filtered.

XSS Cookie Theft

A common attack is to run a script which harvests

the cookies in your browser and sends them

via email to the crook.

The crook can now use the cookies to "look like you" and

hijack your session; e. g. to access the private data on

a server to which you were logged on.

Cross Site Scripting

What distinguishes "contaminated" HTML?

It's complex to recognize, because many exploits exist.

You can't just reject <script> tags. So it's a good idea to use

a sophisticated filter that's updated all the time.

I use http://htmlpurifier.org/

It's a PHP library; runs fast; and is updated regularly.

It's free.

See the demo at http://htmlpurifier.org/demo.php

SQL Injection Attack

HTML with script in it:

<html><head>

<script>document.write("this script runs now");

</script>

</head>

<body>

<H1>Innocuous HTML</H1>

</body>

</html>HTML purified:

<H1>Innocuous HTML</H1>


This attack is not usually a third party attack (trying to trick

a site user into helping the bad guys)

but is a direct attack BY the bad guys.

Like XSS, SQLIA involves submission of data to your script.

If data input becomes part of a Query, it's vulnerable.

Examples: Enter a user's password, look it up in a member table.

Allow a user to search your site for some information.


Example:

q = "SELECT * FROM users WHERE name = ' " .$userName. " ';"

where $username comes from a $_POST field.

Hostile attack: submit this to the form: ' or '1'='1

Yields this total query

q = "SELECT * FROM users WHERE name = '' or '1'='1' ';"

So the query condition is 'where TRUE' and returns ALL!


Naive defense: just filter out the ' and " characters from input.

But there are many other exploits. Again – smart strategy is

to use a built-in filter.

For PHP there's mysqli_real_escape_string

But you ALSO need to:

* Validate inputs as strictly as possible. Why accept all text?

* Give the user only the necessary privileges, not 'ALL'

* Read up on SQL Injection Attack defense

Password Security

Some things you cannot prevent (or, it's tough!)

* users who reuse passwords from one site to another.

Crack one, then follow 'em to other systems.

Some things you can do, to make penetration harder:

* require relatively long, mixed passwords

(letters, numbers, symbols)

* lock out after n (<10) failed tries

* require passwords be changed periodically

and not reuse old ones (e. g. "within last 4 passwords")

Firewall Ports

We usually just trust the ISP to set up the firewall correctly.

They usually don't.

The list of possibly open ports is very large.

runs to 65535, including

Well-known: 0 – 1023

Registered (1024 – 49151)

Dynamic (49152 – 65535)

Firewall Ports

You can adjust your ports via some table setups.

iptables -A INPUT -i lo -j ACCEPTiptables -A INPUT -p tcp --dport 80 -j ACCEPTiptables -A INPUT -p tcp --dport 443 -j ACCEPTiptables -A INPUT -p tcp --dport 143 -j ACCEPTiptables -A INPUT -j DROP

However, it's easy to misconfigure ... best to work with

your ISP to open the minimum set of necessary ports

Security Monitoringand PCI Compliance

Payment Card Industry: Billion$ to lose ..

So they established STANDARDS for compliant sites.

In 2013, gateway and merchant account vendors

are getting tough about PCI compliance.

Our biggest customer: ASME (Mechanical Engineers):

-- No more conferences until PCI Compliant –


Simplest rule: NEVER Keep credit card numbers,

expiration dates, or security codes!

Pass them to the gateway and do not store in database, file,

print or cookies or sessions.

But there are MANY other issues to be addressed.


We had to play the game.

So we hired a scanning firm to get started.

Wow .... we weren't even CLOSE.

Our first scan

Our Response

Turn over the System stuff to our ISP

Revisit and strengthen our scripts' input filtering.

The problem, it turned out, was NOT an actual vulnerability,

as the particular $_GET was only feeding an

if ($x=='something') type mode-test.

BUT it was sufficient to fail the scan. So we filtered it, too.

Before our Second Scan..

We got a suspicious e-mail. (paraphrased.)

Greetings,

We're Panoptic Security. Your merchant account vendor has hired us to walk you the PCI certification process.

Relax, it'll be painless.

Our reaction: Who ARE these guys?

The Chain of Authority

First rule: Trust No One.

Look up Panoptic Security. Are they authorized PCI

compliance scanners? How to find out?

Go to the PCI site.

pcisecuritystandards.org

Approved Companies and Providers.

But Panoptic was NOT listed.

Other red flag:

Panoptic's e-mail contained grammatical errors.

The Chain of Authority

Call our merchant account provider.

Yup ... they are indeed our subcontractor. (Whew.)

Call Panoptic. Why aren't you listed by PCI?

We are a branch of Sxxxx (named a company)

We looked up Sxxxx ... and they were approved.

The Steps to Success

We set up a separate server at regmaster4.com

and had our ISP do all their magic to it.

We did all OUR magic to a dummy system on that

server ("solve a simpler problem first.")

We had Panoptic scan it. All clear.

The Steps to Success

We began the SAQ: The Dreaded Self-Assessment

Questionnaire (235 questions.)

I culled out 32 of them that I didn't understand, and sent

them to our ISP.

After a week I called them. They said "we're drowning

over here!" Too much.

The ISP maxes out

I figured out all but 8 of the answers, my myself.

Finally I got answers to these questions from the ISP.

Two biggies, I had to implement for myself.

* Database removal -- > put on SEPARATE server

* Host Intrusion Detection System

OSSEC

Open Source Security

A Host Intrusion Detection System that

* Monitors suspicious activity

* Watches all logs, reports changes

* Free, open source

OSSEC

Sends me love-notes like this one:

I send to ISP. He says "nah, no problem" ... ??

OSSECHere's a cool one (from China):

OSSECStill much to learn ... workin' on it

And ... the Happy Ending!

What we learned

1) Our ISP ain't the sharpest knife in the drawer,

with respect to security

There ARE ISPs who have more capability in this area.

Go to your ISP's forum and search on PCI, to see

how much they know about it.

Our ISP is very service-oriented, but we are still going to

consider moving ...

What we learned

2) Security is a big job, if you're handling

serious amounts of money.

Even ONE breach can cost you lots of bucks, if you

are found to be non-compliant

So you must invest in the effort to find and fix all

the vulnerabilities that turn up, in your

SAQ and your Scans (every 3 months)

What we learned

2) Security is a big job, if you're handling

serious amounts of money.

Even ONE breach can cost you lots of bucks, if you

are found to be non-compliant

So you must invest in the effort to find and fix all

the vulnerabilities that turn up, in your

SAQ and your Scans (every 3 months)

And that's all, folks!

dig 4104c – web design workshop j michael moshell web security lecture 8

Documents