Docsity
Docsity

Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity


Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan


Guidelines and tips
Guidelines and tips

Web Security: Understanding Cookies, Same Origin Policy, and Cross-Site Scripting Attacks, Slides of Javascript programming

An in-depth analysis of web security issues, focusing on the use of cookies for storing state information, the same origin policy for securing communications between client and server, and the risks and countermeasures against cross-site scripting attacks. It covers http protocol, web authentication via cookies, and the powerful capabilities of client-side scripting.

Typology: Slides

2013/2014

Uploaded on 01/29/2014

surii
surii 🇮🇳

3.5

(13)

130 documents

1 / 33

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
Information Security
Web Security
docsity.com
pf3
pf4
pf5
pf8
pf9
pfa
pfd
pfe
pff
pf12
pf13
pf14
pf15
pf16
pf17
pf18
pf19
pf1a
pf1b
pf1c
pf1d
pf1e
pf1f
pf20
pf21

Partial preview of the text

Download Web Security: Understanding Cookies, Same Origin Policy, and Cross-Site Scripting Attacks and more Slides Javascript programming in PDF only on Docsity!

Information Security

Web Security

Readings for This Lecture

  • Wikipedia
    • HTTP Cookie
    • Same Origin Policy
    • Cross Site Scripting
    • Cross Site Request Forgery

Web Browser and Network

  • Browser sends requests
  • Web site sends response pages, which may include code
  • Interaction susceptible to network attacks

Browser

Network

OS

Hardware

Web

site

request
reply

Web Security Issues

  • Secure communications between client & server
    • HTTPS (HTTP over SSL)
  • User authentication & session management
    • Cookies & other methods
  • Active contents from different websites
    • Protecting resources maintained by browsers
  • Web application security
  • Web site authentication (e.g., anti-phishing)
  • Privacy concerns

Use Cookies to Store State Info

  • Cookies
    • A cookie is a name/value pair created by a website to store information on your computer
Browser

Server

Enters form data
Response + cookies
Browser

Server

Request + cookies
Returns data
Http is stateless protocol; cookies add state

Cookies Fields

  • An example cookie
    • Name session-token
    • Content "s7yZiOvFm4YymG….”
    • Domain .amazon.com
    • Path /
    • Send For Any type of connection
    • Expires Monday, September 08, 2031 7:19:41 PM

Web Authentication via Cookies

  • HTTP is stateless
    • How does the server recognize a user who has signed in?
  • Servers can use cookies to store state on client
    • After client successfully authenticates, server computes an authenticator and gives it to browser in a cookie - Client cannot forge authenticator on his own (session id)
    • With each request, browser presents the cookie
    • Server verifies the authenticator

A Typical Session with Cookies

client server

POST /login.cgi
Set-Cookie:authenticator
GET /restricted.html
Cookie:authenticator
Restricted content

Verify that this client is authorized Check validity of authenticator

Authenticators must be unforgeable and tamper-proof

(malicious clients shouldn’t be able to modify an existing authenticator)

How to design it?

Client Side Scripting

  • Web pages (HTML) can embed dynamic contents (code) that can executed on the browser
  • JavaScript
    • embedded in web pages and executed inside browser
  • VBScript
    • similar to JavaScript, only for Windows
  • Java applets
    • small pieces of Java bytecodes that execute in browsers

HTML and Scripting

Browser receives content, displays
HTML and executes scripts

Browser as an Operating System

  • Web users visit multiple websites simultaneously
  • A browser serves web pages (which may contain programs)

from different web domains

  • i.e., a browser runs programs provided by mutually untrusted entities
  • Running code one does not know/trust is dangerous
  • A browser also maintains resources created/updated by web
domains
  • Browser must confine (sandbox) these scripts so that they

cannot access arbitrary local resources

  • Browser must have a security policy to manage/protect

browser-maintained resources and to provide separation

among mutually untrusted scripts

Same Origin Policy

  • The basic security model enforced in the browser
  • SoP isolates the scripts and resources downloaded from different origins
    • E.g., evil.org scripts cannot access bank.com resources
  • Use origin as the security principal
  • Origin = domain name + protocol + port
    • all three must be equal for origin to be considered the same

Same Original Policy: What it Controls

  • Same-origin policy applies to the following accesses:
    • manipulating browser windows
    • URLs requested via the XmlHttpRequest
      • XmlHttpRequest is an API that can be used by web browser scripting
languages to transfer XML and other text data to and from a web
server using HTTP, by establishing an independent and asynchronous
communication channel.
  • used by AJAX
  • manipulating frames (including inline frames)
  • manipulating documents (included using the object tag)
  • manipulating cookies

Problems with S-O Policy

  • Poorly enforced on some browsers
    • Particularly older browsers
  • Limitations if site hosts unrelated pages
    • Example: Web server often hosts sites for unrelated parties
      • http://www.example.com/account/
      • http://www.example.com/otheraccount/
    • Same-origin policy allows script on one page to access properties of
document from another
  • Can be bypassed in Cross-Site-Scripting attacks
  • Usability: Sometimes prevents desirable cross-origin

resource sharing