State-Based Attacks CPSC 328 Spring 2009 State Web is stateless - - PDF document

state based attacks
SMART_READER_LITE
LIVE PREVIEW

State-Based Attacks CPSC 328 Spring 2009 State Web is stateless - - PDF document

State-Based Attacks CPSC 328 Spring 2009 State Web is stateless Server does not care what page or order Can follow any sequence of clicks to view content Can go straight to content External links URL typing 1


slide-1
SLIDE 1

1

State-Based Attacks

CPSC 328 Spring 2009

State

  • Web is “stateless”
  • Server does not care what page or order
  • Can follow any sequence of clicks to view

content

  • Can go straight to content
  • External links
  • URL typing
slide-2
SLIDE 2

2

Saving State

  • What if our service requires certain order?
  • Must log in before accessing admin page
  • What if server must keep track of things
  • What you ordered, did you pay?
  • How can Developer do this?
  • Include additional information with each exchange

(GET request)

  • Forms, POST, URL parameters

Hidden Fields

  • Something that is part of page, but not

shown

  • Defined parameters & assigned values
  • Sent back to server to communicate state
  • Part of a form
slide-3
SLIDE 3

3

Hidden Field Example

<html> <head> <title>My Page</title> </head> <body> <form name="myform” action="http://www.foo.com/form.php” method="POST"> <div align="center"> <input type="text" size="25" value="Enter your name here!"> <input type="hidden" name="Language” value="English"> <br><br> </div> </form> </body> </html>

Hidden Field Attack

  • Look for them (scan source)
  • Change their values
slide-4
SLIDE 4

4

Protection - Hidden Fields

  • Use misleading names for hidden fields
  • Use hashed/encrypted values
  • Don’t use them!
  • Use them for innocuous input only
  • Treat as user input!
  • Check their values (content filtering again)

CGI Parameters

  • Part of the GET request with URL
  • Name-Value pairs
  • At end of URL (after ?)
  • Pairs separated by &
  • Data is sent to server for processing

http://www.foo.com/script.php?user=mike&passwd=guessWho

slide-5
SLIDE 5

5

Parameter Attack

  • View source
  • Observe URL targets
  • In status bar
  • In tool tip
  • Edit request URL by hand

http://www.foo.com/script.php?user=mike&passwd=bigDummy

Parameter Attack

  • Try changing values
  • record=notMine
  • item=6789
  • Adding parameters
  • debug=on
  • debug=true
  • debug=1
slide-6
SLIDE 6

6

Protection - Paramters

  • Treat as user input!
  • Check values (content filtering again)

GET - POST, Who-What?

  • Both send info to server
  • GET
  • Per W3C, for idempotent form processing
  • No side-effect (e.g., database search)
  • POST
  • For transactions that change state on server
  • Have a side-effect (e.g., database update/insertion)
  • For sending large requests
  • Reload/refresh a GET vs a POST form - different

behaviors

slide-7
SLIDE 7

7

Cookie Poisoning

How to Off the Cookie Monster

  • Cookies revisited
  • Local file to store data
  • Data about you, session, etc…
  • Plain text
  • Change information in cookie file
  • Expiration date
  • Authentication data
  • Shopping cart

Protection - Cookies

  • Don’t use cookies for any authentication

data

  • Encrypt critical data - not fool proof
  • Treat cookies as user input
  • Be careful what you trust!
slide-8
SLIDE 8

8

URL Jumping

  • Breaking the standard (required) order
  • f site traversal
  • Access without logging in
  • Shopping without paying
  • Map the site, then try leaping around

A10: Poor URL Restriction

  • How do you protect a page for limited

access?

  • Don’t provide links to that page?
  • Just because there’s no link, doesn’t mean

people can’t find it

  • Worse yet, that they won’t be able to access it!
  • Security through obscurity does not work
slide-9
SLIDE 9

9

Protection - URL Restriction

  • Restrict all URLs unless public
  • Don’t leave php/perl/cgi files around
  • Don’t use “hidden” pages
  • Block access to non-web pages
  • Serve only known good (.html, .php, .asp, .pdf, …)
  • Hidden Fields
  • Cookies
  • HTTP-REFERRER
  • Server-Side Variables
  • Validate client side input!

Session Hijacking

  • Making the stateless Web, more state-ful
  • Keep track of the session between client &

server with a unique identifier

  • Session ID included with each request from

client

  • Session IDs delivered via…
  • Hidden Fields, Cookies, CGI Parameters
slide-10
SLIDE 10

10

Hijack Attack

  • Guess Session IDs
  • Sniff the wire to capture an ID
  • XSS to capture a session ID cookie
  • Session Fixation

Sniffing the Wire & Guessing IDs

  • Listen to

unencrypted traffic

  • Observe pattern in

ID values, guess the next one

slide-11
SLIDE 11

11

Fixation XSS

slide-12
SLIDE 12

12

Protection - Session Hijacking

  • Use cookies rather than hidden fields
  • Send securely
  • When user logs out, delete session
  • Use meaningful cookie expirations