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
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.
IPv6 uses 128 bits (16 bytes), which should be enough for a while...
2001:0db8:85a3:0042:1000:8a2e:0370:7334
8
Baseline: Internet Protocol
An IP packet includes (among other junk)
• Version (v4 or v6)• Number of bytes in the packet• Time To Live • Protocol (TCP etc)
9
Baseline: Internet Protocol
An IP packet includes (among other junk)
• 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
Baseline: Internet Protocol
An IP packet includes (among other junk)
• 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
Baseline: Internet Protocol
How does IP traffic flow?
Each router has a strategy for forwardingpackets it receives.
If an output channel isslow, routersuse alternateroutes
12
Baseline: Internet Protocol
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
Baseline: Internet Protocol
An IP packet includes (among other junk)
• 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
Baseline: Internet Protocol
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.
Encryption and SSL: Key Concepts
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
Encryption and SSL: Key Concepts
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
Encryption and SSL: Key Concepts
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
Encryption and SSL: Key Concepts
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
Encryption and SSL: Key Concepts
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
Cookies in the Browser
Cookies in the Browser
Cookies in the Browser
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
contam. URL penetration
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
contam. URL penetration
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>
SQL Injection Attack
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.
SQL Injection Attack
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.
SQL Injection Attack
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!
SQL Injection Attack
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 –
Security Monitoringand PCI Compliance
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.
Security Monitoringand PCI Compliance
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 first scan
Our first scan
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!
Top Related