This material will not be in final exam
This presentation is the property of its rightful owner.
Sponsored Links
1 / 28

This Material Will Not be In Final Exam PowerPoint PPT Presentation


  • 57 Views
  • Uploaded on
  • Presentation posted in: General

This Material Will Not be In Final Exam. Cross-Site Scripting (XSS). What is XSS?. A vulnerability in Web applications that lets attackers inject client-side scripts into third-party Web pages Browsers of other visitors of compromised Web page run the script – expose any data browser handles

Download Presentation

This Material Will Not be In Final Exam

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


This Material Will Not be In Final Exam


Cross-Site Scripting (XSS)


What is XSS?

  • A vulnerability in Web applications that lets attackers inject client-side scripts into third-party Web pages

  • Browsers of other visitors of compromised Web page run the script – expose any data browser handles

  • Popularity of these exploits grows and has surpassed buffer overflow exploits


Non-persistent XSS Vulnerability

  • Web server does not properly sanitize user input but uses it “as is” to generate a dynamic reply (Web page)

    • This reply contains attacker’s script code

  • Attacker can craft the URL with his script embedded in it

    • URL points to the target site, supplies some input + script

    • Entice user to click on URL

    • Script will steal some user info that user shares with the site, e.g. a cookie


Example

Attacker

Google

3. Attacker’s script executes with Google’s privs

1. Click here:http://www.google.com?something</FORM><SCRIPT>….

2. Send in HTTP GET as argument to Google homepage:

something</FORM><SCRIPT>….

User


Persistent XSS Vulnerability

  • Data provided by attacker is stored by server and displayed to any future user

    • E.g. when posts to online message boards are not properly sanitized

  • Such a script can access any content the compromised server can


Where Do Vulnerabilities Occur

  • In server code that processes user input and dynamically renders the resulting page

  • In client code that runs in browser and renders Web pages with data from the server

    • JavaScript mostly

    • Document Object Model (DOM) – standard model for representing HTML and XML content


Defense: Escape User Input

  • Ensure that characters of input are treated as data, not as code

    • Translate any dangerous characters into another form of the same characters that cannot be interpreted as code

    • E.g., translate “<“ into “&lt;”

  • Some input could be encoded into different charset

    • Enforce charset in each server reply so that interpretation of user’s input is fixed


Defense: Validate User Input

  • Some Web sites want to allow users to input and render HTML

    • E.g., use HTML markup in emails and online posts

    • Escaping doesn’t help here since it would destroy HTML markup

    • User input must pass through the HTML policy engine to ensure it does not contain XSS


Defense: Cookie Security

  • Because XSS can be used to steal cookies, sites cannot rely only on cookies for authentication

    • Tie cookies to specific IPs

    • HTTP Only flag in browsers allows access to cookies from HTML documents only (scripts cannot access them)


Defense: Disabling Scripts

  • Browser-side defense

    • Makes some Web pages not render

    • Could be turned off for some sites which are trusted to be well secured against XSS


XML Randomization XSS Defense

  • Web application randomizes XML tag prefixes before delivering a document to client

    • Hard for attacker to predict randomized prefixes

    • Cannot inject scripts into application input

“Noncespaces: Using Randomization to Enforce Information Flow Tracking and Thwart Cross-Site Scripting Attacks”, Matthew Van Gundy and Hao Chen. In Proceedings of the 16th Annual Network and Distributed System Security Symposium (NDSS), 2009.


Insertion Vectors

  • Tag body

    • review.text = <script>attack()</script>

  • Node splitting

    • review.text = </p></div><script>attack()</script><div><p>

  • Attribute value

    • review.contact = javascript:attack()

  • Attribute splitting

    • review.contact = ’ onclick=’javascript:attack()

  • Tag splitting

    • review.contact = ’><script>attack()</script>

“Noncespaces: Using Randomization to Enforce Information Flow Tracking and Thwart Cross-Site Scripting Attacks”, Matthew Van Gundy and Hao Chen. In Proceedings of the 16th Annual Network and Distributed System Security Symposium (NDSS), 2009.


Tag Prefix Randomization

  • XML namespaces

    • User chooses a prefix for a tag

    • E.g. for <A> tag:

      • <p:axmlns:p=’http://www.w3.org/1999/xhtml’>

      • <q:axmlns:q=’http://www.w3.org/1999/xhtml’>

  • Leverage XML prefixes to annotate document with trust classes

    • “Label” of each trust class random and hard to guess by attacker

  • Prefixes randomly chosen on each document delivery

“Noncespaces: Using Randomization to Enforce Information Flow Tracking and Thwart Cross-Site Scripting Attacks”, Matthew Van Gundy and Hao Chen. In Proceedings of the 16th Annual Network and Distributed System Security Symposium (NDSS), 2009.


Example From Paper

Attack code

“Noncespaces: Using Randomization to Enforce Information Flow Tracking and Thwart Cross-Site Scripting Attacks”, Matthew Van Gundy and Hao Chen. In Proceedings of the 16th Annual Network and Distributed System Security Symposium (NDSS), 2009.


Trust Policy

  • Defines tags that are trusted

  • Defines HTML tags and operations that are allowed in untrusted content

  • Everything else is denied

  • Server delivers both the potentially hazardous content and the trust policy

  • Client browser enforces policy on server-delivered content

“Noncespaces: Using Randomization to Enforce Information Flow Tracking and Thwart Cross-Site Scripting Attacks”, Matthew Van Gundy and Hao Chen. In Proceedings of the 16th Annual Network and Distributed System Security Symposium (NDSS), 2009.


Deployment

  • Both client and server need to be modified

  • Easy add-on to existing software

  • Client proxy can protect multiple clients in a network

“Noncespaces: Using Randomization to Enforce Information Flow Tracking and Thwart Cross-Site Scripting Attacks”, Matthew Van Gundy and Hao Chen. In Proceedings of the 16th Annual Network and Distributed System Security Symposium (NDSS), 2009.


MANET Security


What Is MANET?

  • Mobile Ad-Hoc Network

    • Wireless nodes

    • Changing topology

    • Possibly no trusted authority

    • Usually battery operated with limited CPU/memory


Security Challenges

  • Wireless medium

    • Sniffing and jamming are easy, impersonation too

  • Peers as routers

    • No trust in routers, may sniff, drop or fabricate data

  • Changing topology

    • Routes are learned, can be manipulated by attackers

  • No trust infrastructure or trusted entities

    • How to distribute keys

  • Limited resources

    • Algorithms must be simple and cheap


Physical/Link Layer Attacks

  • Sniffing: attackers can easily pick up wireless transmissions because they are broadcast at specific frequency (MAC spoofing possible too)

    • Frequency hopping

    • Directional antennas

    • Encryption

  • Jamming is easy

    • But attacker needs powerful transmitter

    • Directional antennas

  • MAC protocol misuse to monopolize shared medium

    • How to create a distributed protocol that detects and penalizes misbehavior?


Ad-Hoc Routing

  • Routes are learned when needed (due to mobility)

  • Dynamic Source Routing (DSR)

    • Source puts entire route in packet header

  • Route discovery

    • Request messages broadcast

    • Intermediate nodes add themselves to the message

    • Reply unicast to the source with full path recorded

    • Nodes can cache overheard routes and may reply from cache

    • Link breakage results in error messages that delete routes in the network that use the broken link


Ad-Hoc Routing

  • Ad-hoc On-Demand Distance Vector Routing

    • Source just specifies destination

    • Routers on path forward as they see fit

  • Route discovery

    • Request messages broadcast

    • Intermediate nodes repeat the message, cache next hop to the source

    • Reply unicast to the source, intermediate nodes cache next hop to the destination

    • Intermediate node may reply from cache

    • When link breaks intermediate node may attempt to rediscover new route

    • Error messages remove routes that used the broken link


Routing Attacks

  • Routing message flooding (DoS)

  • Routing table overflow

    • Fill with bogus routes

  • Routing cache poisoning is easy

    • Just fabricate requests or replies with spoofed source

  • Fabricate false error messages


Network Layer Attacks

  • Drop packets, modify them or replay them

  • Delay packets

  • Inject junk traffic

  • Wormhole Attack

    • Tunnel packets to another location

  • Blackhole Attack

    • Make the node part of many routes

    • Drop all traffic


Wormhole Attacks

  • Attacker records traffic at one point in MANET, tunnels it (perhaps selectively) to another point and replays it

  • Replayed traffic can arrive sooner than original traffic

    • This leads to an attacker node becoming part of many routes

  • Attack works even for traffic not going over attacker nodes directly, and for encrypted traffic

“Wormhole attacks in wireless networks,” Yih-chunHu , Adrian Perrig , David B. Johnson, IEEE Journal on Selected Areas in Communications, 2006


Detection of Wormhole Attacks

  • Packet leash

    • Information added to the packet to restrict the distance it can travel in one hop

    • Geographical – recipient must be close to sender. Sender records its location and time when packet is sent, recipient checks for validity.

    • Temporal – packet lifetime ends after certain time. Sender records the time when packet is sent, recipient checks for validity.

  • Requires synchronized clocks

  • Recorded information must be signed

“Wormhole attacks in wireless networks,” Yih-chunHu , Adrian Perrig , David B. Johnson, IEEE Journal on Selected Areas in Communications, 2006


DoS Attacks

  • Consume node battery, CPU or memory

  • Overflow node’s routing table

  • Flood the node with routing messages

  • Flood the node with data traffic

  • Drop node’s data traffic


  • Login