CSCI 1320
Creating Modern Web Applications
Lecture 26: Security II
Review
 Security is a major concern
 Lots of obvious problems
 Lots of non-obvious problems
 SQL injection attacks
 Code insertion attacks
2
CS132 Lecture 26: Security II
7/27/2016
Cross Site Scripting Attacks
 The attacker inserts arbitrary HTML on your web page
 How can this ever happen?
 XSS
 What can go wrong
 Disrupt the page or the portion where inserted
3
CS132 Lecture 25: Security I
7/27/2016
Cross Site Scripting
 What if the HTML include <script> tags?
 Replace the page with a new one
 Fake instance of a page to get passwords, accounts, etc.
 Pass information from the page to foreign page
 Cookies, passwords, credit card numbers, session Ids
 Download user’s cookies (passwords) for other sites
4
CS132 Lecture 25: Security I
7/27/2016
Cross Site Scripting: How
 Suppose you allow user comments
 Guest book, ratings, wiki, postings, …
 Text is gotten from user, then inserted into HTML
 Suppose instead of typing “I love this page”
“I love this page<script
language=‘javascript’>document.location=‘http://bad/’;
</script>”
 What would happen?
5
CS132 Lecture 25: Security I
7/27/2016
Cross Site Scripting
 What can attacker do
 Reading data from URL (session id)
 Replace data in the URL
 Accessing/Replacing hidden form variables
 Loading foreign web page into a frame inside your page
 Using JavaScript to read and manipulate that frame
 Using code in the frame to monitor your activities
 Taking control of the browser
6
CS132 Lecture 25: Security I
7/27/2016
Cross Site Scripting: Prevention
 Don’t allow any HTML to be inserted
 Back end libraries to strip out HTML tags
 Don’t allow malicious HTML to be inserted
 Back end libraries to sanitize HTML
 Limited set of allowed tags for formatting
 Use something other than HTML
 Map to html on output
7
CS132 Lecture 25: Security I
7/27/2016
Cross-Site Request Forgery
 Suppose user logs into banking application
 Cookies used to validate user/session
 Suppose there is a URL that transfers money
 transfer?from=checking&to=43434&amt=1000000.00
 Agent puts an ad on another page
 Clicking on the add, generates that URL
 What happens if user clicks on the ad
 While logged into banking application
8
CS132 Lecture 25: Security I
7/27/2016
Cross-Site Request Forgery
 Use a random value for each request
 Set on previous request, kept in session
 Passed back as part of any request
 Validated by server before the action
 Effective URL will be different each time
 Can’t be spoofed by another client (easily)
 Can be passed to client in various ways
 Sent as part of html or xmlHttpRequest
 Included in a hidden form field
 Can also be put into header by JavaScript
9
CS132 Lecture 25: Security I
7/27/2016
Server Attacks
 Inputs from web page attack the server directly
 Outside login to server
 Weak passwords, user ids
 Access from other machines
 Server becomes compromised
10
CS132 Lecture 26: Security II
7/27/2016
Buffer Overflow Attack
 Code:
void function(char* text) {
 Stack (high to low)
8888: <ptr to text>
char buf[1000];
8884: <return address>
strcpy(buf,text);
8880: <old stack ptr>
// do some editing of buf
7880: buf[0 .. 999]
// save result
}
11
CS132 Lecture 26: Security II
7/27/2016
Preventing Buffer Overflow
 Check sizes of data before putting in array
 Reads, copies, inputs
 Randomize code locations between runs
 Don’t let data pages be executable
12
CS132 Lecture 26: Security II
7/27/2016
Server Attacks
 Can buffer overflow happen in Java? JavaScript? Php?
 Even safe languages can have problems
 Out of memory, out of file space
 Run arbitrary code (malicious servlets)
 Tie up server for long time
 Java/PHP/… security problems
 File access, exec, eval, …
13
CS132 Lecture 26: Security II
7/27/2016
What Else Can Go Wrong?
 PEOPLE
 Denial of service
14
CS132 Lecture 26: Security II
7/27/2016
Logging In
 Common operation
 Should be easy
 What are the problems?
 What are the operations to be concerned with?
 Registration (initial name & password)
 Log in (provide name & password to validate)
 Access while logged in
15
CS132 Lecture 26: Security II
7/27/2016
Logging In: Threat Model
 Spoofing URLs
 Sending lots of requests
 Wi-Fi snooping
 Internet snooping
 Reading logs
 Man-in-the-middle attacks
 Phishing attacks
 Brute force
 Loss of database (SQL injection attack; stolen laptop)
16
CS132 Lecture 26: Security II
7/27/2016
Sending Passwords
 How might you hide a password from the Internet?
 /login?uid=spr&pwd=password
 Send Hash(password) to server
 MD5(), SH1(), SH256()
 Does this work?
 Server sends Hash(password) to client
 Does this work?
17
CS132 Lecture 26: Security II
7/27/2016
Sending Passwords
 More complex protocols
 Server sends random string (i.e. session id) to client
 Client sends Hash(string + password) to server
 Client sends Hash(string + hash(password)) to server
 Client sends Hash(string + userid + hash(password)) to
server
 Do these work?
 Can they be checked by the server?
18
CS132 Lecture 26: Security II
7/27/2016
Secure Communication
 Want to make it so what is sent is unreadable
 To anyone who can see all Internet traffic
 How can this be done?
 Encryption
 Recall hash functions H(X) = <random number>
 These are not encryption functions
 What is an encryption function
 F(X) = Y easy to compute
 F-1(Y) = X difficult to compute (without additional knowledge)
 Examples of encryption functions
19
CS132 Lecture 26: Security II
7/27/2016
Encrypted Connections
 Encrypt all communication
 Simpler solution than trying to encrypt password
 Between the browser and the server
 Handles some of the issues raised with passwords
 Handles other problems as well
 Credit card numbers and other private information
 Encrypted communications are relatively standard
 Clients needs to agree on how to encode/decode
 Agreeing on an algorithm for encoding/decoding
 Agreeing on a key for that algorithm
20
CS132 Lecture 26: Security II
7/27/2016
Standard Encryption
 Both parties agree on a key K
 F(K) and F-1(K) are easy to compute
 If you know K
 But are difficult if you don’t know K
 May even be done in hardware
 Standard encryption functions available
 DES is probably the most common
 Problem: agreeing on K
21
CS132 Lecture 26: Security II
7/27/2016
Public Key Cryptosystems



Public Key Cryptosystems

Originator has two pieces of information X and Y

F(string,X) = encoded string

F-1(string,X) is difficult to compute

F-1(string,X,Y) is easy to compute
Examples

Y,Z are 200 digit primes, X is Y*Z

Create a string using X such that string can only be decoded knowing the factors of X

Other examples are possible
This is often used as part of a secure protocol

22
Agreeing on a key for a more secure encoding
CS132 Lecture 26: Security II
7/27/2016
Browser-Server Communication
 Can use encrypted communication in a web app
 HTTPS represents an encrypted (secure) connection
 HTTPS is just like HTTP
 Except that all data passed back and forth is encrypted
 Browser and server agree on a key
 Encryption is then done based on this key
 This is handled by the Secure Sockets Layer (SSL)
 SSL is not specific to web applications
23
CS132 Lecture 26: Security II
7/27/2016
HTTPS Connections

Browser makes a connection to the server

SSL handshake protocol
 Browser sends and requests a certificate
 Certificates are effectively keys that can be verified as authentic
 This is one way public key systems are used
 Server replies with a certificate of its own

SSL change cipher protocol
 Browser and server use their certificates to agree on a key
 Again using a variant of public key systems

Communication is done securely using that key
 Key is only used for this particular session
24
CS132 Lecture 26: Security II
7/27/2016
HTTPS Usage
 If you are sending confidential information
 Even just passwords
 Especially credit card numbers, etc.
 You should use HTTPS
 OPENSSL and other implementations exist
 Typically built into server and browser
 Different port used for secure communication
 Integrated into Apache using Mod_SSL for example
 Problem: Obtaining a certificate
25
CS132 Lecture 26: Security II
7/27/2016
Saving Passwords
 How to save passwords on your website?
 Why is this a problem? Does it matter?
 What if your site is compromised
 Users use same password for multiple sites
 This is something many applications do wrong
 Never store user passwords in plaintext
 Just store the hash of the passwords
 Cryptographically secure hash function
 MD5, SH1, SH256, …
 Is this sufficient?
26
CS132 Lecture 26: Security II
7/27/2016
Secure Password Hashing
 What happens if two users have the same password?
 What will the stored password hashes look like?
 Solution: “salt” the hashes.
 You generate a random string which is stored alongside the
hashed password for each user.
 Can just be the user id
 Compute and store hash($salt . $password)
 Is this sufficient?
27
CS132 Lecture 26: Security II
7/27/2016
Secure Password Hashing



28
Brute force attack on stored passwords

Compute SHA1($salt . $password) for possible passwords

This is relatively fast
Solution: “stretch” the hashes.

Instead of calling SHA1 once, call it thousands of times.

Makes it more expensive to mount a brute-force attack
Do you really want to write all that code?

Crypto code is notoriously tricky, the bugs are subtle, and the consequences of doing it
wrong are dire.

Solution: Use Passport, bcrypt, (or similar) for Node.js. Solutions exists for other
frameworks as well.

These solve of the problems we’ve mentioned, can become more computationally
difficult as computing power increases, and are available in most web libraries
CS132 Lecture 26: Security II
7/27/2016
Secure Password Hashing
 Your threat model should look like this:
29
CS132 Lecture 26: Security II
7/27/2016
Other Threats
 You might want to look these up
30
CS132 Lecture 26: Security II
7/27/2016
Next Time
 Security LAB
31
CS132 Lecture 26: Security II
7/27/2016
Privacy and Web Applications
 What is privacy?
 How important is privacy?
 What data do you want to keep private?
32
CS132 Lecture 26: Security II
7/27/2016
Privacy Policies
 Statement saying what the web site does with any information it
collects
 Or otherwise obtains from the user
 And why the web site needs this information
 Generally considered legally binding
 Must obey the laws of the land
 Different lands have different laws
 Users may or may not pay attention
 Google privacy policy
 itunes store policy
33
CS132 Lecture 26: Security II
7/27/2016
Sensitive Information



34
Personal information

Name, address, phone, email

Age, sex, race, …

Past contributions, purchases, rentals, friends, …

Why is this sensitive?
Financial information

Credit cards

Bank accounts
Legally sensitive

Health information (HIPA)

Student information (FERPA)

Information from children
CS132 Lecture 26: Security II
7/27/2016
Using the Data
 Amazon
 Google
 Facebook
 Microsoft
 Apple
35
CS132 Lecture 26: Security II
7/27/2016
Using the Data
 Data might be required for the application
 Credit card numbers
 Order information
 Data might be helpful to the application
 Past buying history in making recommendation
 Past credit cards used
 Past shipping history
 Data might be helpful in the future of the application
 Data might be needed to assist application sponsors
 Targeting ads, emails, etc.
36
CS132 Lecture 26: Security II
7/27/2016
Why Care About The Data



37
The data might be worth more than the application

Selling personal information is lucrative

Providing contacts is lucrative

Ads are worth more if targeted correctly

Ads pay for the application
The data can be misused if it gets in wrong hands

Unauthorized use of credit cards

Release of health information

Who looks at pornography
Laws make your application responsible

For specialized data

For general privacy (EU)
CS132 Lecture 26: Security II
7/27/2016
The Role of a Privacy Policy
 Delineate what types of information are collected
 Whether that information is used immediately or saved
 Specify why the information is needed
 Not always done
 Useful if the application is not obvious
 Specify who owns the information
 If you own your information, company can’t use it freely
 If they own the information things are more flexible
38
CS132 Lecture 26: Security II
7/27/2016
The Role of a Privacy Policy
 Specify what the application can do with the information
 Use in the application only
 Use in the application and the owning company
 Use in the application, owning company, affiliates
 Share (sell to) with related businesses
 Share (sell to) with anyone
 Specify what controls you have over the information
 Can you stop it from being collected
 Can you request any collected information be discarded
39
CS132 Lecture 26: Security II
7/27/2016
Legal and Ethical Issues
 Privacy has legal implications
 Already covered by laws in many places
 Already covered by laws in many domains
 European policy is generally much stricter than US
 You are responsible for breaches of your policy
 You need to use “best efforts” to avoid them
 Implications can be large
 Fines, imprisonment
 Cost to protect the consumer
 Costs related to the breach
40
CS132 Lecture 26: Security II
7/27/2016
Other Legal and Ethical Issues
 If your web site sells something
 That doesn’t get sent
 That isn’t valid (i.e. airline ticket)
 That is defective
 New eBay policy on payments
 If your web site performs a critical purpose
 Analyzing data to determine if you are sick or not
 Monitoring a nuclear plant
 Creates lethal X-rays
 Crashes an airplane
41
CS132 Lecture 26: Security II
7/27/2016
Other Legal and Ethical Issues
 What if your web site gives out bad advice
 Bad medical advice
 Bad legal advice
 What if your web site gives out fake product ratings
 What if your web site disguises ads as fact
 What if your web site freely distributes private material
 Copyright violations
 What if your web site becomes compromised
42
CS132 Lecture 26: Security II
7/27/2016
Your Responsibilities
 You are the creator/maintainer of the web site
 You should understand your responsibilities
 Both legally and morally
 How much attention should you pay to these issues
 As you design the site
 As you code the site
 As you develop a privacy policy
 Is it more important to get a working application fast
 Or to have a secure one?
 Is this really a trade-off?
43
CS132 Lecture 26: Security II
7/27/2016