DOM-based XSS Attacks                  M.Sc. Project thesis       Zdravko Danailov            Krassen Deltchev    zdravko....
AbstractConcerning the matter of modern Internet Security, we are obliged to understand the meaning andproper utilization ...
ContentsAbstract ............................................................................................................
List of TablesTable 1: Classification of sources.............................................................................
List of FiguresFigure 1: XSS basic classification, derived from A.Klein [L3].................................................
Figure 47: DOM-based cross-site scripting stage 1.....................................................................XXXI...
List of Abbreviations0day             Zero-day exploit/attackAFA              Application Flow AnalysisBM               Bu...
QA-Team             Quality Assurance TeamRegex               Regular expressionRE                  Requirements engineeri...
1 Introduction 1 IntroductionNowadays, the differences between Web Application Security and Web Services Security can beha...
1 Introductionexploitation of Web-Application servers. Server-side XSS attacks are designated as follows –Persistent and N...
1 Introduction1.1 Limitations of the paperIn this project thesis, we should explicitly outline the following limitations i...
2 General approach to DOMXSS and limitations of the paper2 General approach to DOMXSS and limitations of the paperIn this ...
2 General approach to DOMXSS and limitations of the paper2.2.1             Non-persistent XSS AttacksThe Non-Persistent XS...
2 General approach to DOMXSS and limitations of the paperThis abstract scenario is presented more illustrative as a proces...
2 General approach to DOMXSS and limitations of the paperto compromise it. The complexity of deployment includes the testi...
3 DOMXSS Attacks3 DOMXSS AttacksIn the previous chapter, we have paid attention to attacks, which exploit the technical ab...
3 DOMXSS Attacksobject, loaded in the users Browser. If the client-side logic26 of the Web-Application is not properlysani...
3 DOMXSS Attacksexample, concerning the DOM-based exploit of HTML527 localStorage API, he proves thecorrectness of the sep...
3 DOMXSS Attacks    1. The attacker has to find and exploit vulnerabilities into the Technical Model of the platform.    2...
3 DOMXSS AttacksThese strategical changes in the Web-Application design and implementation cause numeroustactical deployme...
3 DOMXSS Attacks    4. understand the Data Flow of the Web-Application;    5. understand how to apply proper security poli...
3 DOMXSS Attackstechnical explanation of DOMXSS.On behalf of Enum1, we completed Enum1.1. As next, we would like to cover ...
3 DOMXSS AttacksHTML5, RIA (Flash, Silverlight etc.), overlap the server-side components, as: Presentation layer,Business ...
3 DOMXSS Attacks    3. Is the attack feasible or not?As already stated, the attack exploits the client-side implementation...
3 DOMXSS AttacksPayload) and an Impact (factor). These S3MM parameters should be briefly explained in theAppendix. On beha...
3 DOMXSS Attacks    •   object assignment and    •   location methods .For further information, please visit [L7].  Main t...
3 DOMXSS AttacksSources are represented there, e.g. see Amit Kleins list. Furthermore, domxsswiki gives a greatopportunity...
3 DOMXSS AttacksWhy is so important such separation?If a DOMXSS is represented in the S3MM and its Storage component matte...
3 DOMXSS Attacks         Char              ASCII Number               escape           encodeURI          encodeURICompone...
3 DOMXSS Attacksof the XHR-object, most probably a large group of Web clients,specified as default for the clientOS, will ...
3 DOMXSS AttacksLinux/UNIX) in which different types of attacks can be executed. It is developed and can be usedfor educat...
3 DOMXSS AttacksPlease enter your password:<BR><input type = "password" name="pass"/><buttononClick="javascript:alert(I ha...
3 DOMXSS Attacksthe “escapeHTML()” function48, as shown in the next code fragment.function displayGreeting(name) {  if (na...
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
DOM-based XSS Attacks
Upcoming SlideShare
Loading in …5
×

DOM-based XSS Attacks

1,933 views

Published on

Concerning the matter of modern Internet Security, we are obliged to understand the meaning and proper utilization of Web Application Security and Web Services Security.
In this paper, we discuss one of the recent and misunderstood problems, related to Web Application Security.
In distinction to the standard Web Application Cross-Site Scripting Attack Vector, DOM-based XSS conveys a way to inject malicious payload on Layer 7 ISO/OSI Model on the client-side implementation of the Web-Application logic. Precisely, DOMXSS represents a subclass of this dominant Web Application Attack Vector – XSS.
Therefore, we observe the comprehensive environmental aspects of DOMXSS; we divide them in two layers – Programming environment, which concerns the DOM Abstraction Model, Web-Application coding language and the rendering engine of the Web client (Web-Browser); and Implementation environment – the Web Application programming logic and source code.
Because of the fact, that this subclass, should be still considered as misapprehended and consequentially – systematically avoided by the security and scientific communities, the main objectives of this project thesis are: proposing and evaluating of related categorizations and meta-model, demonstration of case studies and sanitization best practices, and further propositions across the problem – DOM-based XSS attacks.

Published in: Education, Technology
  • Be the first to comment

  • Be the first to like this

DOM-based XSS Attacks

  1. 1. DOM-based XSS Attacks M.Sc. Project thesis Zdravko Danailov Krassen Deltchev zdravko.danailov@rub.de krassen.deltchev@rub.de Ruhr-University of BochumFaculty Of Electrical Engineering And Information Technology Chair for Network and Data Security Horst-Görtz Institute Prof. Dr. Jörg Schwenk First examiner: Prof. Dr. Jörg Schwenk Adviser and Second examiner: Dipl.-Ing. Mario Heiderich 16. April 2012
  2. 2. AbstractConcerning the matter of modern Internet Security, we are obliged to understand the meaning andproper utilization of Web Application Security and Web Services Security. In this paper, we discussone of the recent and misunderstood problems, related to Web Application Security.In distinction to the standard Web Application Cross-Site Scripting Attack Vector, DOM-based XSSconveys a way to inject malicious payload on Layer 7 ISO/OSI Model on the client-sideimplementation of the Web-Application logic. Precisely, DOMXSS represents a subclass of thisdominant Web Application Attack Vector – XSS.Therefore, we observe the comprehensive environmental aspects of DOMXSS; we divide them intwo layers – Programming environment, which concerns the DOM Abstraction Model, Web-Application coding language and the rendering engine of the Web client (Web-Browser); andImplementation environment – the Web Application programming logic and source code.Because of the fact, that this subclass, should be still considered as misapprehended andconsequentially – systematically avoided by the security and scientific communities, the mainobjectives of this project thesis are: proposing and evaluating of related categorizations and meta-model, demonstration of case studies and sanitization best practices, and further propositions acrossthe problem – DOM-based XSS attacks.KeywordsXSS, DOM-based XSS, DOMXSS, DOM-based XSS taxonomy, Web Application Security, MobileSecurity, Web Application Attack Vector, Application Flow Analysis, Function Flow Analysis, DataFlow Analysis, Static Model Checkers, Dynamic Model Checkers, JSLint, Web Applicationscanners, DOMinator, Security patterns, JavaScript/AJAX Coding Patterns, JavaScript/AJAXDesign Patterns, Anti-Patterns, DOM and Web-Browser Patterns, HTML5, Filters, ESAPI4JS,ECMAScript conventions, Secure ECMAScript, Direct Proxies
  3. 3. ContentsAbstract ..................................................................................................................................................List of Tables......................................................................................................................................IVList of Figures......................................................................................................................................VList of Abbreviations.........................................................................................................................VII1 Introduction .....................................................................................................................................1 1.1 Limitations of the paper............................................................................................................32 General approach to DOMXSS and limitations of the paper ..........................................................4 2.1 What is DOM? .........................................................................................................................4 2.2 Types of XSS Attacks...............................................................................................................4 2.2.1 Non-persistent XSS Attacks..............................................................................................5 2.2.2 Persistent XSS Attacks......................................................................................................63 DOMXSS Attacks............................................................................................................................9 3.1 Historical reference work..........................................................................................................9 3.2 Explanation of the technical background................................................................................11 3.2.1 Environment and Threat Model......................................................................................11 3.2.2 Classifications.................................................................................................................16 3.2.3 Sources and Sinks...........................................................................................................16 3.2.4 URL obfuscation – Encoding/Decoding.........................................................................21 3.2.5 Attack scenarios..............................................................................................................23 3.2.5.1 Case study: Testing environment and educational scenario....................................23 3.2.5.2 Case study: Real time scenario – AOL....................................................................26 3.2.5.3 Example: Stored DOMXSS.....................................................................................30 3.2.5.4 Example: JavaScript private functions ...................................................................314 Prevention and defense...................................................................................................................35 4.1 Lack of sufficient collaboration between the teams, involved in the Defensive STO Model 37 4.2 Function Flow and Data Flow Analysis..................................................................................41 4.3 JavaScript/AJAX patterns – false usage of patterns and conventions ...................................43 4.4 False usage of filters...............................................................................................................48 4.5 Related tools...........................................................................................................................58 4.5.1 Tools Requirements Rules (TRRs).................................................................................58 4.5.2 Penetration Testing Tools................................................................................................61 4.5.2.1 Static Code Checkers: DOM XSS Scanner.............................................................63 4.5.2.2 Educational Tools: Web Goat (IDE/Framework)....................................................64 4.5.2.3 Dynamic Web-App Scanners: DOMScan...............................................................66 4.5.2.4 Dynamic Web-App Scanners: DOM Tracer (Mozilla Firefox)...............................66 4.5.2.5 Dynamic Web-App Scanners: Web Scarab and Web Scarab-NG...........................67 4.5.2.6 Mixed tools: DOM Snitch.......................................................................................68 4.5.2.7 Mixed tools: DOMinator Project (Mozilla Firefox)................................................69 4.6 Synopsis..................................................................................................................................735 Future work....................................................................................................................................756 Conclusion......................................................................................................................................77Affirmation.........................................................................................................................................IXBibliography.......................................................................................................................................XIList of Links.....................................................................................................................................XIIIAppendix.........................................................................................................................................XVI III
  4. 4. List of TablesTable 1: Classification of sources.......................................................................................................19Table 2: Classification of sinks [L7]...................................................................................................20Table 3: Encoding Differences, derived from [L13]..........................................................................22Table 4: Address bar double encoded XSS.........................................................................................22Table 5: Decoding differences, derived from [L13]...........................................................................23Table 6: Scenario types.......................................................................................................................23Table 7: Code fragment of vulnerable to P-DOMXSS Web-Application [L10]................................31Table 8: DOMXSS on private JavaScript function [L25]..................................................................32Table 9: DOMXSS S3MM database proposal....................................................................................33Table 10: Defensive STO Model........................................................................................................36Table 11: A general classification of patterns.....................................................................................44Table 12: Example 1 for an Anti-pattern, a well-known DOMXSS Sink [S10]................................46Table 13: Example 2 for an Anti-pattern, a well-known DOMXSS Sink [S10]................................47Table 14: DOM and Browser patterns [S10]......................................................................................47Table 15: Browser dependent cssText Attack Vector [L7].................................................................49Table 16: Listing 2, example of JavaScript filtering code for e-mail.................................................51Table 17: Integrated XSS user agent filters........................................................................................55Table 18: Evaluation of OP2 secure Browser.....................................................................................58Table 19: TRRs...................................................................................................................................59Table 20: TRRs matrix according to the particular tools....................................................................60Table 21: DOMXSS Tools list............................................................................................................62Table 22: WebGoat topics...................................................................................................................64Table 23: innerHTML examples, html5.org.......................................................................................65Table 24: Web Scarab-NG Plug-ins....................................................................................................68Table 25: B. Kochher, sample #7, [L36]...........................................................................................72Table 26: 2010 at a glance – Sorted by industry sectors [WHW11].............................................XVIIITable 27: JavaScript Coding patterns [S10].....................................................................................XLITable 28: Representatives of JavaScript Design patterns [S10]......................................................XLITable 29: List of Security patterns [S06]........................................................................................XLIITable 30: Listing 1, example of HTML input form, e-mail filtering via JavaScript.....................XLIIITable 31: Google search input filter escaping in 4 stages..............................................................XLVTable 32: Microsoft Bing input filter escaping in 5 stages..........................................................XLVIITable 33: Functional vs. Security testing [RL10]............................................................................LIIITable 34: Standards & Specifications of EFBs [RL10]...................................................................LIIITable 35: Basic EFD Concepts [RL10]............................................................................................LIIITable 36: Definition of Execution Flow Action and Action Types [RL10].....................................LIIITable 37: 0day DOM XSS Scanner vulnerable code fragment at flattr.com module....................LXV IV
  5. 5. List of FiguresFigure 1: XSS basic classification, derived from A.Klein [L3]..........................................................9Figure 2: XSS classification, 2007, R. Hansen et al...........................................................................10Figure 3: General attack strategy for Web-Applications....................................................................12Figure 4: DOMXSS Threat Model [L13]...........................................................................................16Figure 5: Client-side implementation of the Web-App Business logic Model...................................17Figure 6: Processing of Source and Sink ...........................................................................................18Figure 7: DOM-based cross-site scripting after stage 4.....................................................................25Figure 8: Application Flow walk-trough of real time scenario-AOL.................................................27Figure 9: AOL scenario stage 2 – using cURL (step 1)......................................................................28Figure 10: AOL scenario stage 2 – using cURL (step 2)....................................................................28Figure 11: AOL scenario stage 3........................................................................................................29Figure 12: Security-concerned Software Development deterministic state machine (DFA*)...........37Figure 13: Sanitization components, applied to the victim environment...........................................38Figure 14: Involved teams in the Web-Application production.........................................................39Figure 15: Structure of a security team..............................................................................................40Figure 16: Sanitization workflow.......................................................................................................41Figure 17: JavaScript Design Patterns, derived from [S10]...............................................................45Figure 18: Client-side Web-Application filtering...............................................................................49Figure 19: DOMXSS Tools................................................................................................................61Figure 20: DOMinator Architecture, Stefano Di Paola, [L12]...........................................................71Figure 21: Secured Web-Application, considering DOMXSS...........................................................74Figure 22: The Web Hacking Incidents DB 09 [BS09] .................................................................XVIFigure 23: Attack Pathways, 2011 [AE11]......................................................................................XVIFigure 24: Whitehat Security Top 10 [L6].....................................................................................XVIIFigure 25: Percentages of vulnerabilities resolved ( compared by extensions) [WHS10]............XVIIFigure 26: Top Ten Vulnerability Classes (compared by extension) [WHS10]............................XVIIIFigure 27: Basic architecture of DOM objects in HTML, derived from [L1]................................XIXFigure 28: ERM attack Model, NP-XSS..........................................................................................XXFigure 29: ERM attack Model, P-XSS............................................................................................XXIFigure 30: DOM Visualizer, DOM Tree for AOL.de.....................................................................XXIIFigure 31: DOM Visualizer, DOM Tree for RUB.de...................................................................XXIIIFigure 32: 3-Tier architecture [L16].............................................................................................XXIVFigure 33: Application Architectures are Evolving from 3-Tier to SOA [L17]...........................XXIVFigure 34: The 2 Top-level organizing principles in Modern Software continue to converge [L18].......................................................................................................................................................XXVFigure 35: Web 2.0 or SOA? [L19]................................................................................................XXVFigure 36: Technologies / standards used in a web oriented architecture [L20]..........................XXVIFigure 37: A view of WOA [L21].................................................................................................XXVIFigure 38: The high levels of success of Web 2.0 Models for creating Software Ecosystems helped"discover" WOA and inform SOA [L22]....................................................................................XXVIIFigure 39: More technical representation of Web 2.0 Architecture [L14]..................................XXVIIFigure 40: Browser [L15]..........................................................................................................XXVIIIFigure 41: Browser/Application View [L23].............................................................................XXVIIIFigure 42: Browser DOM [L15]...................................................................................................XXIXFigure 43: Technology Shift and Trend [L15]..............................................................................XXIXFigure 44: Cross DOM access [L23].............................................................................................XXXFigure 45: Double encoding result 1..............................................................................................XXXFigure 46: Double encoding result 2............................................................................................XXXI V
  6. 6. Figure 47: DOM-based cross-site scripting stage 1.....................................................................XXXIFigure 48: DOM-based cross-site scripting stage 2....................................................................XXXIIFigure 49: DOM-based cross-site scripting stage 3....................................................................XXXIIFigure 50: DOM-based cross-site scripting before stage 4........................................................XXXIIIFigure 51: DOM-based cross-site scripting after stage 5..........................................................XXXIIIFigure 52: AOL scenario stage 1...............................................................................................XXXIVFigure 53: AOL scenario stage 3 enhancement.........................................................................XXXIVFigure 54: Globo scenario stage 1..............................................................................................XXXVFigure 55: Globo scenario stage 2 – crafting the exploit (step1)...............................................XXXVIFigure 56: Globo scenario stage 2 – crafting the exploit (step2)...............................................XXXVIFigure 57: Web-Application complete Enterprise Security Model [L26]................................XXXVIIFigure 58: Microsoft Security Software Development Lifecycle (MS SSDLC) [L27]...........XXXVIIFigure 59: DOMXSS Scanner....................................................................................................XLVIIIFigure 60: WebGoat Browser Interface......................................................................................XLVIIIFigure 61: DOMScan Interface.....................................................................................................XLIXFigure 62: Drawback in DOMScan DOM calls detection............................................................XLIXFigure 63: DOMTracer incompatible with newest version of Firefox.................................................LFigure 64: Web Scarab Interface..........................................................................................................LFigure 65: Web Scarab-NG Interface.................................................................................................LIFigure 66: DOM Snitch activity log...................................................................................................LIFigure 67: S3 Meta-Model...............................................................................................................LIIFigure 68: Improving the Testing process of Web Application Scanners [RL10]...........................LIVFigure 69: Flow based Threat Analysis, Example [RL10]..............................................................LIVFigure 70: DOMXSS – aol.de on iOS v.5.0.1 (9A405).....................................................................LVFigure 71: DOMXSS – ma.la on iOS v.5.0.1 (9A405)....................................................................LVIFigure 72: Error response on safari with disabled JavaScript – aol.de, concerning SbO...............LVIIFigure 73: DOMXSS – aol.de on Android 2.3.5...........................................................................LVIIIFigure 74: DOMXSS – aol.de on Android 2.3.5 with diocument.cookie payload........................LVIIIFigure 75: DOMXSS – ma.la on Mozilla Firefox for Android 2.3.5..............................................LIXFigure 76: DOMXSS – student.mit.edu on Android 2.3.5................................................................LXFigure 77: Phase 2: Error response..................................................................................................LXIFigure 78: Phase 3: first Popup in Mozilla Firefox .......................................................................LXIIFigure 79: Phase 3: second Popup in Mozilla Firefox ..................................................................LXIIFigure 80: Phase 3: Popup in Safari.............................................................................................LXIIIFigure 81: Phase 3: second Popup in Opera..................................................................................LXIIIFigure 82: Persistent XSS in the source code after successful injection .....................................LXIV VI
  7. 7. List of Abbreviations0day Zero-day exploit/attackAFA Application Flow AnalysisBM Business ModelCSFU Cross-site File UploadCSRF Cross-site Reference ForgeryDB DatabaseDDoS Distributed denial-of-serviceDev-Team Developers TeamDFA Data Flow AnalysisDFA* Deterministic finite automatonDOM Document Object ModelDoS Denial-of-serviceDSTO Defensive STO Modele.g. for exampleESAPI Enterprise Security APIFFA Function Flow AnalysisFO-Team Forensics Teami.e. id estIR-Team Incident Response TeamISO International Organization for StandardizationLDA Linear Discriminant AnalysisMS MicrosoftMS SSDLC Microsoft Security Software Development LifecycleNP-DOMXSS Non-persistent DOMXSSNP-XSS Non-persistent XSSOOP Object-oriented programmingOS Operating SystemOSI Open Systems InterconnectionOWASP The Open Web Application Security ProjectP-DOMXSS persistent DOMXSSPoC Proof of ConceptPT-Team Pen-testing Team VII
  8. 8. QA-Team Quality Assurance TeamRegex Regular expressionRE Requirements engineeringRFI Remote File InclusionRIA Rich Internet ApplicationsROA Resource-oriented ArchitectureSbO Security by ObscuritySDLC Software Development LifecycleSE Social EngineeringSH Social HackingSOA Service-oriented ArchitectureSOP Same-Origin-PolicySQLIA SQL injection attackSSDLC Security Software Development LifecycleS3MM Sources/Sinks/Storage Meta-ModelSTO Strategical Tactical Operational ModelSVN SubversionTRRs Tools requirement rulesWAS Web Application scannersWASC Web Application Security ConsortiumWeb-Dev community Web developer communityWOA Web-oriented ArchitectureWOT Web of TrustW3C W3 ConsortiumXHR XMLHttpRequestXSS Cross-site Scripting VIII
  9. 9. 1 Introduction 1 IntroductionNowadays, the differences between Web Application Security and Web Services Security can behardly distinguished. On one hand their essence is still misunderstood, on the other these securityareas could not be strictly separated apart. Therefore, the attacks and more precisely the attackscenarios, related to these areas, should be evaluated as unique, respecting the aspects of: theirutilization and the approach to categorize them, which are prerequirements for a precise andcomplete examination and respectively for an effective sanitization.In this project thesis, we shall observe Cross-Site scripting attacks on the client-side of modern Webapplications, which consider exploits on the JavaScript implementations of the programming logic.Other representatives of such attacks on CSS and XML should not be discussed due to the scope ofthe paper, which is outlined in the section about the papers limitations.To achieve a taxonomic soundness of the thesis exposition, we feel obliged to give some shorthistorical facts about JavaScript in this introduction.In 1995 Netscape1 proposes LiveScript2 as an additional layer on top of the HTML. Thus, the staticHTML pages become interactive and furthermore this scripting language is directly integrated intothe Web-Browser. This methodology is well accepted and extended by two separated organizations.On one hand the Mozilla Foundation develops and maintains JavaScript3, on the other Microsoftsupports JScript4. Ironically, the so called “Browser Wars”5 6 reflects also on the standardization ofthis scripting language. Consequently to this fact, arises confusion in the Web Developerscommunities. First malicious attempts to exploit the LiveScript derivatives follow as an avalancheeffect respectively. These attacks designate a new Web-Application Attack Vector – Cross-SiteScripting, or shortly XSS. Nowadays, XSS injections are presented not only on JavaScript, but alsoon PHP, ASP, JSP etc. The strive for an adequate and completed standard, considering theLiveScript proposal and respecting the current development stages of JavaScript and JScript, ispresented by the evolution of ECMA-262 scripting language, or shortly ECMAScript7. For theinterested reader, please consider further reading on Section 4.4 False usage of filters. We shallreckon still JavaScript and JScript for not completely compliant to the Modern Standardsrepresented by ECMAScript.Lets proceed more detailed with the introduction of the attacks on JavaScript. As already mentionedabove, the most common and vigorous Web Application Attack Vector is considered to be theCross-Site Scripting, XSS8[AE11], [WHS10], [WHW11]. According to OWASP9 and WASC10, XSSrepresents a TOP 10 Web Application Attack Vector; statistically, see Appendix Figures 22, 23, 24,25, 26 and Table 26, designated on second place as most severe Web Application threat. XSS issophisticated, dynamically evolving and expanding as an attack vector. This justifies the fact for theexistence of wide range of XSS attack paradigms and the intensive occurrence of new ones.Moreover, we observe a general categorization of the XSS subclasses in two main branches –sever-side and client-side. The common and well-known Web-based attacks concern an1 http://www.scriptingmaster.com/javascript/javascript-history.asp2 http://javascript.about.com/od/reference/a/history.htm3 https://developer.mozilla.org/en/JavaScript4 http://msdn.microsoft.com/en-us/library/72bd815a.aspx5 http://blogs.law.harvard.edu/doc/2011/01/30/learnings-from-the-browser-wars/6 http://www.zdnet.com.au/a-history-of-web-browser-wars-339312301.htm7 http://www.ecmascript.org/8 http://www.crn.de/security/artikel-8538.html, http://www.cenzic.com/resources/hackinfo/owasp-top-10-2010/,http://www.troyhunt.com/2010/05/owasp-top-10-for-net-developers-part-2.html9 http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20-%202010.pdf10 http://projects.webappsec.org/w/page/13246920/Cross%20Site%20Scripting 1
  10. 10. 1 Introductionexploitation of Web-Application servers. Server-side XSS attacks are designated as follows –Persistent and Non-persistent XSS attacks. The research on these XSS subclasses in the securityand scientific communities is well established. In distinction to this, the other branch of XSSattacks, client-side XSS, is stated to be incomprehensively documented, imposed upon the fact thatthe research information: conventions, approaches, best practices, Cheat Sheets etc. are scatteredand discontinuously represented. As the major representative of client-side XSS attacks should beconsidered the DOM-based XSS attack. In this paper, we describe this subclass as follows:definition of the operational flow, areas of application, illustration on significant case studies,estimation of the impact factor of DOMXSS. Moreover, we illustrate some suggestions forsanitization approaches on specific implementations of DOMXSS.In order to scrutinize the basic features and behavior, as well as some existing scenarios forDOMXSS Attacks, the structure of this project thesis proceeds as it follows: Chapter 2 focuses onthe general structure of XSS Attack Vector, its separation on subclasses, including Persistent(stored), Non-Persistent (reflected) and DOMXSS attacks, and gives brief information about theirspecific characteristics and malicious nature. A complete analysis of the DOMXSS attacks, onbehalf of the Strategical/Tactical/Operational Model, will be performed in Chapter 3 . Furthermore,Subsection 3.2.5 illustrates some known examples and case studies of DOMXSS, together with thefactual course. Possible remediation techniques, such as implementation and extension of Regex(s),proper application of JavaScript patterns and filters etc., will be specified in Chapter 4 . Besides, itpresents a theoretical approach on what more could be applied to the problem, in account ofFunction Flow and Data Flow Analysis. Chapter 5 will propose some important aspects for futurework on the problem, while some of them will be outlined in appropriate parts in the exposition ofthe paper. In Chapter 6 , the conclusion on the topic will be presented. 2
  11. 11. 1 Introduction1.1 Limitations of the paperIn this project thesis, we should explicitly outline the following limitations in our research andthesis exposition: • Language requirements: • as given in RFC 211911 • For the purposes of this paper, we shall use He, His, which should be understood as she/he, her/his, respecting the lexicological relation to terms like intruder, attacker, user etc. • As we discuss DOM-based XSS on JavaScript client-side Web-Applications, we shall not evaluate DOMXSS implementations, including CSS and XML. • XML DOMXSS attacks require in most cases discussions on Web Services Security. • If we provide limited information on the mentioned above languages, this we should utilize only to respect the consistency of the exposition. • We use the term Web client to distinguish precisely the group of Web-Browsers, RSS Readers etc., from the other types of User Agents as: Robots, Crawlers, Spiders etc., respecting the RFC 2616, Section 14.4312; see also footnote13. • Note, that the proposals, described in our paper are not approved on strong mathematical level, which is considered as an appropriate scientific level, and are valuable topic for future work. • In some cases, we should outline conventions and patterns, with their appropriate references, without demonstrating them in exhaustive manner. • We should also allow us to demonstrate interesting and important techniques and taxonomies, as related works, which are considered by their developers as not completed. • Every aspect, which is a good candidate for a future work on the topic, should be outlined in the appropriate stage of the paper exposition and explicitly in Chapter 5.11 http://tools.ietf.org/html/rfc211912 http://tools.ietf.org/html/rfc2616#section-14.4313 http://www.user-agents.org/ 3
  12. 12. 2 General approach to DOMXSS and limitations of the paper2 General approach to DOMXSS and limitations of the paperIn this chapter, we explain, what is DOM, in order to define it as a term and how it associates withJavaScript. Furthermore, a taxonomy of the XSS attacks will be presented, as we divide the mainclass (XSS) on three general subclasses: Persistent, Non-Persistent and DOMXSS attacks.2.1 What is DOM?The development of JavaScript is as controversial as the Browser evolution on itself. The so called“Browser wars” arouses the utilization of two different formulations of the scripting language. Asmentioned in the introduction part, on one hand, Mozilla Foundation maintains JavaScript, whichimplementation is applicable almost everywhere, on the other, Microsoft supports the JScript,applicable only on the MS Internet Explorer. Furthermore, we outlined, that this paradigminevitably leads to lack of standardization, concerning the proper scripting language implementationby the Web-Dev community. For these reasons, the W3 Consortium decides to propose a unifyinglanguage-independent convention, a cross-platform model, more specific the Document ObjectModel14, which includes a solution, how to solve the gap between the two different scriptinglanguage dialects. DOM presents an interface between JavaScript and JScript. Moreover, in order touse both languages on behalf of HTML-enabling dynamic characteristics of the Web-content, DOMrepresents an instrument in the hands of the Web-Devs. The kernel in the structure of DOM is the“document” Object. Its methods grant the implementation and execution of functions in both of thescripting languages. This is well illustrated in Figure 27, see Appendix.Nevertheless, there are still differences between the realization of W3C DOM specification, whichprompts a challenge even today, to respect and to compound the specifications of JavaScript andJScript.The lack of standardized solution hampers the Web-Dev community to implement a proper scriptingcode in modern Web-Applications until nowadays. As already outlined JavaScript and JScript arenot fully compatible with the ECMA-262 Standard, please see Chapter 4 .This unavoidably arises the question about the security aspects of the released code in Productionenvironment.The other fact, that the complexity of the Web-Applications is vastly growing, stigmatizes modernWeb-Apps, as extremely attractive for malicious activities.In the next section, we should explain more detailed the different attack techniques on modernWeb-Applications and HTML based content.2.2 Types of XSS AttacksAs we outlined in the introduction section, the XSS attack vector splits into three main branches,mainly: Non-Persistent, Persistent and DOM-based XSS attacks. These types dispose, firstlyregarding their art of execution: server- or client-side. Secondly, they differ in their efficiency, aswell as their discoverability and countermeasures. So, before we proceed with the objectives of thisproject thesis, we will scrutinize in detail the basic features of the XSS attack subclasses as follows.14 http://www.w3.org/DOM/ 4
  13. 13. 2 General approach to DOMXSS and limitations of the paper2.2.1 Non-persistent XSS AttacksThe Non-Persistent XSS (NP-XSS) attacks should be illustrated in our papers exposition as the firstsubclass of the XSS attack vector. Since, we want to make clear how the NP-XSS works, weshould describe a simple attack scenario. It proceeds in few steps, as it follows: 1. In order to execute an attack, a malicious user (attacker) should find a potential vulnerability on a site. As a vulnerability input source should be designated for example a text box, search box etc., which gives the possibility, that one can enter string (text) or an HTML-based code, an image etc., considered as an appropriate Web-content on a dynamic Web-App: • Find a submitted on the Web and unsanitized XSS exploit, e.g. 0day NP-XSS. • Use a search engine, e.g. Google source15 and extract the URL of a currently running Web-Application, which still implements such exploit in its source code.16 2. In the second phase of this attack scenario, the attacker should try to force the Web server to process and execute the malicious code: • As the attacker locates a proper input source on the Web-App, such as input field or parameter of the GET-request, related to the URL of the unsecured site, He can start with a trial and error approach to inject malicious code. • Another alternative for the attacker is to launch an internal search within the site, if the specific Web-App has an integrated search engine. By simulation of a common search, the attacker can test the security filters, which are implemented on the search box, in order to sanitize the Web-Application input stream. At first, using the search engine, He does not produce any suspicious noise, but observes the error response of the system – assuming the fact, that no matter what search input is utilized, the security mechanisms on the web-server should be activated by default. 3. After completing this testing (sample-approach), the intruder gathers and organizes the feedback about the weaknesses in the security of the Web-App, with the goal of a possible attack utilization. 4. In order to increase vastly the impact of the attack, He advertises a link to the already exploited Web-App, by posting it on different blogs, forums, sending it as a spam e-mail, per VoIP (Skype) or other messenger software, such as Yahoo Messenger etc. This process can be automated and amplified, by using bots17 for this purpose. The attacker can fulfill furthermore two different actions: • to make the normal18 users to embody themselves as actual attackers (confused deputy19) and cause DoS/DDoS on the Web-App. • to achieve a data steal, such as: cookie theft, ID theft etc.15 http://code.google.com/16 Another approach is to deploy Web-Application scanners, e.g. Acunetix Web Vulnerability Scanner (Free Edition), Netsparker [Community Edition] , Qualys Freescan etc., on a particular domain (URL), which can automate the exploit detection process; this method utilizes the so called pointnscan technique, on behalf of a list with known exploits.17 http://cert.uni-stuttgart.de/doc/netsec/bots.html18 We specify the term “normal user” as – an inexperienced and not security concerned user, utilizing daily Internet activities on the Web. This user can become with greater likelihood a “Confused deputy”, see CSRF[KD10].19 http://www.cis.upenn.edu/~KeyKOS/ConfusedDeputy.html, see further:https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF) 5
  14. 14. 2 General approach to DOMXSS and limitations of the paperThis abstract scenario is presented more illustrative as a process flow diagram in the Appendix partof the paper, see Figure 28.2.2.2 Persistent XSS AttacksThe stored XSS attacks embody another subclass of the XSS attack vector. In order to clarify themethodology of the Persistent XSS (P-XSS), we will represent another simple attack scenario: 1. In the preparation phase, the attacker should find a Web site (Web-based content), on which He could post messages in HTML-based code such as: message boards, blogs, HTML-based e-mail forms etc. Before He can proceed with the implementation of a malware code, considering its proper20 execution, one should test the security filters on the site. If the Web- App is not properly sanitized against integration of malicious JavaScript code, the intruder could make (legitimate) HTML-conform postings, where vigorous script is integrated. Its proper execution should be considered with greater likelihood, because of the continuous operating of the compromised Web-Server, which acts as a propagation environment for the malicious JavaScript code and the existence of the Browser rendering engine – interpreting HTML-conform code by default. A normal user, who has no advanced security protection, integrated within His Browser, should not be able to ascertain, that a fraudulent script is executed in background. 2. As the attacker has completed the phase of preparation and script injection, He proceeds with the process of spreading out a specially prepared link, in order to increase the impact of the attack. As it was already described in Subsection 2.2.1 , the link distribution is achieved by a dispatch over e-mail or via different instant messengers, using fake/already stolen Ids/e- mail accounts.For the better illustration of the P-XSS workflow, refer to the process flow diagram in theAppendix, see Figure 29.As we have already presented two fundamental attack scenarios for NP-XSS and P-XSS, we wouldlike to describe in detail the design and general application purposes of the attacks, by discussingthe differences between them. The distinguishing approach is based on the following profoundcriteria21: • complexity of attack preparation, • complexity of attack deployment (Reproducibility), • application (affected entities), • impact (damage potential) and • discoverability.The complexity of the attack preparation by NP-XSS and P-XSS is almost the same: the attackerhas to find a currently running/0day exploit and further to search for a suitable Web-App candidate20 We define here „proper“, considering it from the attackers point of view, who also strives efficient and effective, intelligently implemented fraudulent code. In particular, this has nothing to do with the moral perspective, concerning the victims damages.21 https://www.owasp.org/index.php/Threat_Risk_Modeling 6
  15. 15. 2 General approach to DOMXSS and limitations of the paperto compromise it. The complexity of deployment includes the testing phase, the utilization of XSScode injection and the consecutive propagation/spread out. While by NP-XSS, the attacker tries tolocate input sources, such as: cookies, input fields (e.g. Web-App internal search engine) and GET-requests, by P-XSS, His goal is to exploit the ability to dynamically extend the HTML-basedcontent via posting. In both cases (NP-XSS, P-XSS), the cracker22 is proceeding further with thedeployment of the attack scenario, as detecting the sanitization filters on the Web-App. If suchfilters are implemented, the attacker tries to escape them, starting a blinded testing23. He refines thisiterative method, until He gains sufficient feedback, concerning the successful furtherimplementation of the malicious XSS injection. In case of no positive results, He applies thisscenario either to a different pattern in the directory structure of the same domain, a subdomain, oranother detected URL. Note, that these steps could be also applied concurrent on different Web-Apps. As He succeeds to avoid the input source sanitization, the cracker injects the XSS code andcan further improve the hack. Heretofore, we cannot observe extensive differences in thedeployment complexity. At last, we should take in account the end stage, concerning the spread outof the attack. In distinction to NP-XSS, by stored XSS, the intruder does not need implicitly toadvertise the compromised Web-App. Though, if He decides to do so, He propagates just a legalURL, because the host already includes the P-XSS in its HTML-source. This is not the case by NP-XSS, where the distributed URL implies the malicious code. On one hand, this designates thedifferences in the deployment complexity, on the other, it also denotes discrepancy by the level ofdiscoverability. A legal URL, without an injection payload, cannot be directly considered as amalicious one, which impedes the proper heuristic evaluation. Thus, the discoverability of the P-XSS is limited to observation of the Web-App source by security experts, who inevitably utilizestatic or dynamic code-checkers for automated feedback. On the opposite side, the discoverabilityof the NP-XSS could demand not only code inspection, but also a complete Function and Data FlowAnalysis [L2]. So, in order to detect and prevent a NP-XSS, only a source code investigation on theWeb-App is not sufficient. Moreover, the attack discovery demands an extensive forensicsinspection24 of the Web-application-sever log files, made by a security professional, utilizing semi-automated approaches. Taking these facts into count, the discoverability of the NP-XSS is morecomplex than this of the P-XSS. We should outline, that both of the attacks cover the followingserver-side injections – same origin XSS25, cross origin XSS. This designates the same level ofapplication. At last, concerning the impact or damage potential of the attacks, both XSS typespresent very severe security threat on Web-application platforms.Heretofore, we introduced the first two well-known subclasses of the XSS attack vector andclarified their differences and similarities, concerning their better illustration and understanding.Using the same pattern, we should represent the main objective of our paper – DOM-based XSSattacks, which concern especially Cross-Site Scripting injections on the client-side implementationof the Web-Application programming logic, in the next Chapter 3 .22 In our paper, we use the term „cracker“, describing an attacker with malicious intentions.23 In both cases, blinded testing could be utilized manually or using Web-Application scanners.24 By P-XSS, the Forensics professional correlates at least the following evidences: the persistence of malicious code within the Web-Application source, which is deterministic, and the log file entries on the server. In distinction to this, by NP-XSS, the malicious code is just reflected by the server. Therefore, evidence is stored at most in the log files. This enforces the professional to search for other evidences, which can be correlated to the log files, with the goal to strengthen the Forensics heuristics and thus predict properly the core of the reflected XSS attack.25 Samy Worm: http://namb.la/popular/ 7
  16. 16. 3 DOMXSS Attacks3 DOMXSS AttacksIn the previous chapter, we have paid attention to attacks, which exploit the technical abilities ofJavaScript, but require as a jump-start a running Web server. On the contrary, DOM-based XSSpresumes only the Browser engine for launching XSS attacks on JavaScript host objects[S10]. Theirmain representatives are the DOM-objects. These facts inevitably provoke the questions: Is acracker capable of exploiting such JavaScript objects? Are we capable as security professionals toharden those, predict and prevent future exploits on Object-oriented level, concerning JavaScriptWeb-apps?3.1 Historical reference workEven though, DOMXSS is thought to originate from 2004/2005, the first reports about the attackare arisen in the early 2002 by Thor Larholm. For the interested reader, please check [L8].In 2005, Amit Klein has publicized the first widespread paper on DOMXSS. The paper “DOMBased Cross Site Scripting or XSS of the Third Kind”[L3] considers the theme and make itaccessible for the general public. Furthermore, it points out not only properties of the third subclassXSS attacks, but also refers to some of the fundamental differences to the other XSS types (NP-XSS and P-XSS). Based on the information back then, Amit Klein has made a basic classification,mainly: a list of cases, concerning DOM-based XSS. Lets illustrate the general XSS structure withits subclasses in Figure 1:Figure 1: XSS basic classification, derived from A.Klein [L3]In 2007, this categorization is extended and precised by Robert Rsnake Hansen et al., see[JGETA07], by specifying the main DOMXSS subclasses: Persistent DOM-based XSS (P-DOMXSS) and Non-persistent DOM-based XSS (NP-DOMXSS). These inherit the features, whichDOMXSS proposes, and additionally designate the core for the technical implementation, thespecific DOMXSS attack is based on: if the prerequirement for the DOMXSS is P-XSS-based, wecategorize the P-DOMXSS subclass, in the opposite case – NP-DOMXSS subclass.The differentiation between NP-DOMXSS and P-DOMXSS, shown in Figure 2, is on hand of theutilized attack technique to achieve a DOMXSS exploit. In the first case, aiming an execution ofDOM-based XSS, the attacker uses the methodology, applicable for NP-XSS. By advertising aspecially crafted link to the potential victims, the cracker endeavors falsifying a property of a nodeor even extending the DOM structure with a new node with its own properties, within the document 9
  17. 17. 3 DOMXSS Attacksobject, loaded in the users Browser. If the client-side logic26 of the Web-Application is not properlysanitized, the forged document object will be conducted by the Browser engine. In the second case,utilizing P-DOMXSS, the attacker uses Persistent XSS approach. An example of stored DOMXSS,where we shall explain in detail the technical background of the attack, see Subsection 3.2.5 .Moreover, in combination with other attack techniques such as Cross-site Reference Forgery(CSRF)[KD10], Cross-site File Upload (CSFU)[L4], Remote File Inclusion (RFI)[L5][WASC10]etc., the impact of the NP-DOMXSS and persistent DOM-based XSS is vastly increasing.Figure 2: XSS classification, 2007, R. Hansen et al.As Amit Klein has pointed out the basic subclasses of the XSS attack vector, in “XSS Attacks –Cross Site Scripting Exploits & Defense”, the authors make classification based on themethodology, more exactly the essence and semantic of the attacks. Furthermore, they pay attentionfor the first time to the Function Flow Analysis (FFA) and Data Flow Analysis (DFA), consideringthe XSS vulnerabilities. In order to sanitize a Web-App, not only the input (input sources), but alsothe output (output sources) must be examined and properly defined (applying DFA), as well as thefunctional threads by the data processing must be carefully explored (applying FFA).In 2007, Shreeraj Shah gives a well-illustrated approach, abstract and multilayer schemata torepresent sufficient architectures of fundamental topics such as: Browser DOM engine, AJAXworkflow Model, Threat Model etc.[L11]. In next year, Stefano Di Paola and Kuza55 represent the“Attacking Rich Internet Applications”[L9] and introduce a classification of sinks and sources. Thisextends the definitions of DOMXSS and allows more precise modular approach, which becomes asubstantial part of the sanitization process.Rafal Los [RL10] puts forward, that the “point n scan”-scanning of Web-Apps is not sufficient forWeb-Application vulnerabilities analysis and represents a compete definition for Function FlowAnalysis and Data Flow Analysis. This extends the proposals, already given by Robert RsnakeHansen et al. in 2007.In 2011, Ory Segal [L10] enlarges the classification of Sources and Sinks by adding a newparameter, respecting the Persistent DOMXSS: Storage. On behalf of the evaluation of existing26 This should be explicitly explained in Section 3.2.1 10
  18. 18. 3 DOMXSS Attacksexample, concerning the DOM-based exploit of HTML527 localStorage API, he proves thecorrectness of the separation between DOMXSS subclasses, made in 2007 by R. Hansen et al.Moreover, Ori Segal illustrates the unabated impact of these attack techniques, respecting thenewest HTML Standard.Since the history of DOMXSS can be ascertained as sophisticated, which involves implicitdiscussions on the terms of source code analysis, Application Flow Analysis (AFA) and furtherdevelopment of classifications, we feel obliged to explain the technical background of the DOM-based XSS and represent methods for source code development and analysis, as well as preventiontechniques in the following sections.3.2 Explanation of the technical backgroundIn this section, we will describe the Threat Model, the environment, as well as the important cruxes,considering the DOMXSS attacks, in account of Sources and Sinks, URL obfuscation – encodingand decoding.3.2.1 Environment and Threat ModelBefore we depict the DOMXSS Threat Model, we should make clear, what is the general approachof an attacker and what are His main objectives, regarding Web-Applications. There are twodifferent types of Web-Apps, respecting the E-Commerce aspect: those with implemented BusinessModel (BM) and such without any. Taking this matter into count, it is easy to say, that Web-Applications with a BM will be more attractive for an intruder to be exploited.The Web-App E-Commerce deployment Model consists of two main interrelated levels – Technical(implementation) Model and Business Model. These elements can also be taken in the meaning ofperception, Business interpretation: as less strongly bound – low level, and strongly bound – highlevel, because of their significance and internal logic, concerning the deployment and evaluation ofa strong Business Plan. Considering this two layer architecture, an attacker wants to gain controlover both levels, as the Business Model is with highest priority.In order to explain the basic approach of an intruder, let us simplify the tactical scheme of the attackstrategy28: 1. The E-Commerce Web-Application Architecture is proposed as a two-nodes-graph with bijective conjunction between the nodes. 2. The main target of an attacker is the Business Model of the Web-Application, which is accessible29 only if the intruder controls the low level in the E-Commerce Web-App Architecture. 3. Taking both prerequirements into count, the attacker uses “divide and conquer”-approach (please, see Figure 3).The process can be described into several steps of the four stages, Figure 3. Lets enumerate themexplicitly, as follows:27 http://www.w3.org/TR/html5/28 Attack strategy - exploit the Business logic Model to disrupt the E-Commerce revenue.29 Accessible - Business logic Model experiences its realization on the Web via the Technical (implementation) Model 11
  19. 19. 3 DOMXSS Attacks 1. The attacker has to find and exploit vulnerabilities into the Technical Model of the platform. 2. He gains control upon the low level of the Web-Application. 3. The intruder should try to disrupt the proper communication with the “Business Model”- level. 4. The attacker mitigates the bijective conjunction between the two nodes, as conquering the directed edge (Technical Model to Business Model). He disrupts the proper workflow within the E-Commerce Architecture and consequently disarranges the “Business Model”- level. 5. As a result, the attacker controls the feedback edge – from Business Model to Technical Model, which makes the last one unusable. 6. In summary, He conquers the E-Commerce Web-App, and in great likelihood any other kind of Web-Application representations.Figure 3: General attack strategy for Web-ApplicationsAs the Business Model is getting more complex to meet the customers needs, but the periods for therelease of the Web-Applications in Production environment remain the same or become evenreduced, the technical implementation has to strive to keep these development rates. Thence, severalimportant drawbacks occur: • vastly growing load in the midrange systems – servers, due to the growing number of clients and requests to the Web-App; • escalating concurrency into the time-to-release deadlines; • unstructured enhancement of the existing programming code in the Production environment; • development of programming languages for speedy application build-up; • ignoring of established security, coding and Design patterns; • diverge-like operating development teams, to speedy fill in the coding gaps. 12
  20. 20. 3 DOMXSS AttacksThese strategical changes in the Web-Application design and implementation cause numeroustactical deployments and therefore more complex operative accomplishments. Like the furtherdevelopment of the Web-Application Model is getting more compound, so the attacks and theThreat Models consequently adapt to it. Moreover, back in the days the implementation of theBusiness logic was predominantly Server-side oriented. Nowadays, we experience a migration inthe Business logic implementation to the client-side, to mitigate the drawbacks enumerated above,which inevitably lead to server overload.So, how does the modern attacks look like?They hit on the enticing part of the Web-Application, more exactly the migrated Business logic onthe client-side, because there is no need to attack directly the server, as an advantageous way toabuse the Business Model, which was a winning strategy concerning the old way of BMimplementation.What makes these new attacks conceptually so different in contrast with the “old” well-establishedWeb attacks?First of all, they demand advanced programming skills, including explicit knowledge of: • Programming environment, • semantics of the programming languages, • programming conventions, • Coding/Security/Design/Anti-/DOM and Browser patterns.To summarize this briefly: the objective is not explicitly the client (user agent or end user), but theclient-side implementation of the Business logic Model.Second, a profound and complete analysis and understanding of the modules, their coherence andstructural representation within the client-side environment have to be assured.Please, check up the two examples of modern Web-Applications, demonstrating the complexity ofthe DOM Construction, which represent, on one hand – a modern E-Commerce B2C Portal30, andon the other – an educational Web site. These are illustrated in the Appendix part of the paper –Examples of HTML DOM Visualizer31, Figures 30, 31. As the reader experiences, both of the Web-Apps are highly complex. This inevitably leads to the conclusion, that a strong taxonomic approachhas to be conducted, in order to deploy the already proposed Web-Application analysis. Please note,that this is executed with greatly likelihood by the modern Intelligent32 attackers and is highlyrequired to be awaken in the consciousness of the security professionals, as follows [Enum1]: 1. understand the fundamental structure of multi-tier SOA, concerning RIA; 2. understand the coding Implementation environment; 3. understand the Function Flow of the Web-Application;30 http://www.akshayit.com/b2b-b2c-portals.html31 http://www.aharef.info/static/htmlgraph/32 In this paper, we shall propose the terms – Standard intruder (attacker) and Intelligent intruder (attacker), as follows:a Standard attacker doesnt possess personal know-how, but copies and applies well-known, published on the Web, attacks. Furthermore, He does not respect and evaluate the noise, created by the (iterative) attacks execution, and also does not consider taxonomic knowledge management. In distinction to this, an Intelligent intruder is able of creating and evaluating own attack scenarios, finding 0day-attacks and respecting the balance in the attack environment, considering minimization of the caused noise, during the (iterative) attacks execution. 13
  21. 21. 3 DOMXSS Attacks 4. understand the Data Flow of the Web-Application; 5. understand how to apply proper security policies to harden the preceding aspects, as mentioned in 1 – 4.The DOM-based XSS is a good representative of such modern attacks. Lets demonstrate this,taking into count the proposed conditions, enumerated above.At the beginning, we want to make a retrospective illustration on behalf of several figures, toexplain the migration of the Business logic to the client-side and demonstrate the tight and enduringconsolidation of the technical implementation with the sophisticated Business Model.The classic Technical Model, 3-Tier Model (Figure 32), which is still usable in many Web-Applications, denotes the starting point for Business logic realizations on the Web. As well-known,it consists of: the Client Tier, Application Tier and Data Tier. The complete Business logic isintegrated within the Application Tier, which explains the attack strategy – to conquer the BM, i.e.exploit the Application Tier. Some attack representatives are SQLIA[KD10], the already fullyexplained NP-XSS and P-XSS (please, see Section 2.2 ) and other, that involve as a prerequirementto exploit also the Client Tier – CSRF33, see further [KD10].With the reinventing of the Web34 – the Web 2.0 evolution, the 3-Tier Model becomes insufficient,which explains the need for more refined and feature-rich model – the Service-orientedArchitecture, SOA. This tendency is well-illustrated in Figure 33, where the main advantages of theSOA Model over the 3-Tier Model are enumerated.Moreover, the unabated demand for further development of SOA and Web 2.0, engendered by thevastly growing E-Commerce and ever and anon advancing Business Model, impose a convergencebetween these top-level organizing principles (Figure 34).At Figure 35 is shown the SOA Model. Compared to the 3-Tier Model (Figure 32), the readershould notice the differences between the Client Tier and the Presentation Layer – SOA implies themigration of the BM to the Presentation Layer, where the Web clients include not only HTML, butalso AJAX and RIA.The outlined migration of the BM on the client-side, is realized adequately on the level of Object-oriented programming (OOP) and DOM. Thus, the client-side coding layer is technicallyimplemented in SOA via the Presentation layer, e.g. AJAX and RIA, as shown in Figure 35. Exactlythese two components will be the main target of modern Intelligent intruder attacks. Please note, asalready stated in the limitation section of the paper, the scope of our research is AJAX-/JavaScript-based DOMXSS.To complete this retrospection, we should illustrate the end stadium, which we are aware of, andshould be most probably extended in the future. The complete convergence of Web 2.0 and SOAdefines a new term – Web-oriented Architecture, WOA. This definition proposes extensive features.For an instance, the Data Tier of the 3-Tier Model becomes Resource-oriented Architecture (ROA)in the WOA Model. The complete modern taxonomy is precisely illustrated in Figure 36.Concerning the basics in the technical implementation of WOA, Figure 37 gives a good overview.Finally, we would like particularly to demonstrate the complete emerging process of Web 2.0 andSOA with the explicit allocation of WOA as a derivative of this process (Figure 38).We shall extend these tendencies with more detailed schemes, related to our scientific research onthe problem. We shall proceed in top-down manner to reach the particular level of a correct33 http://shiflett.org/blog/2007/mar/my-amazon-anniversary34 http://www.oracle.com/us/products/applications/atg/b2b-ecommerce-reinventing-333314.pdf 14
  22. 22. 3 DOMXSS Attackstechnical explanation of DOMXSS.On behalf of Enum1, we completed Enum1.1. As next, we would like to cover Enum1.2.We should specify the SOA Web client, as the Web-Browser, due to the fact, that DOMXSS exploitsthe client-side Business logic via the Web-Browser DOM rendering engine. Furthermore, any kindof other SOA Web clients like RSS readers etc., based on Web-Browser rendering engines, reducesthe attack complexity to the level of DOM-based XSS on Web-Browsers. Lets designate explicitlythe Programming/attack environment, concerning Enum1.2, as follows: • all kinds of Web clients, implementing different DOM-able Browser engines, • JavaScript Programming language and AJAX, • any type AJAX-based frameworks, JavaScript libraries, • SOA Web-Applications based on AJAX.Shreeraj Shah proposes a simplified scheme of WOA, pointing out in particular the Web client as aBrowser with the SOA client-side BM implementations, AJAX and RIA. We shall call this scheme(Figure 39) sufficient for the technical exposition of DOM-based XSS. As next, Figure 40 gives ageneral overview of the Browser rendering engine and most of the integrated SOA-relatedimplementation techniques as components. Important in this scheme is the demonstration of thebasic attack workflow, following the top-down approach – DOMXSS can start35 even on thePresentation layer, e.g. exploiting an HTML5 APIs (such example, should be demonstrated in theSubsection 3.2.5 : Attack scenarios), and proceed further with its execution on the Process&Logiclayer, where we notice, that the Browser renders the JavaScript (AJAX) code and theDOM/Browser Events. If the DOM-based XSS attack scenario implies a Browser redirection to amalicious Phishing site(s), this could be achieved via the “XMLHttpRequest” (XHR) object in theNetwork&Access layer. In order to bypass the Same Origin Policy (SOP), the intruder shouldexploit the Core Policies layer.A comprehensive attack scenario with a prerequirement – Social Engineering (SE), could be alsoapplied to DOMXSS attacks. This is illustrated in the next Figure 41, which represents anotherdifferentiation of the Browser components, concerning the User Layer and Browser Internals layer.The AJAX and RIA, HTML/DOM Interface and UI Logic components belong to the User layer,which explains the fact, that the user is able to interact, change and modify these by His own.Therefore, a SE is possible and amplifies not only the impact of the attack, but also the complexityof the defense and sanitization process(es) against DOM-based XSS. Furthermore, thesecomponents implicitly interact with the DOM rendering engine, which abstract implementation in aWeb-Browser is demonstrated in Figure 42, from the Browser Internals layer. Hence, the alreadypresented basic workflow is feasible.We would like also to demonstrate the simplified DOMXSS Threat Model, see Figure 4.To complete the Enum1.2, we should outline the JavaScript/AJAX coding specifications, moredetailed in Section 4.3 JavaScript/AJAX patterns – false usage of patterns and conventions ,wherewe shall explain in particular the questions, concerning the related conventions and patterns. At last,lets illustrate a conclusive scheme (Figure 43), proving the proposed strategic differentiationbetween DOM-based XSS and the classic XSS variations, i.e. DOMXSS is accessing the client-sideimplementation of the Business logic Model. More precisely, the client-side components: DOM,35 This is related especially to stored DOMXSS attacks; though, NP-DOMXSS can start directly on the Process&Logic layer of the Browser engine. 15
  23. 23. 3 DOMXSS AttacksHTML5, RIA (Flash, Silverlight etc.), overlap the server-side components, as: Presentation layer,Business layer and the Data Access layer, from the Web-Application Business logic.Figure 4: DOMXSS Threat Model [L13]3.2.2 ClassificationsAs our goal is to represent a complete description of the technical background of DOM-based XSS,we utilize a well-known model – Strategical, Tactical and Operational Model (STO). In Subsection 3.2.1 , we covered the strategical level of the STO, explaining Enum1.1 and Enum1.2. Moreprecisely, we outlined the strategic discrepancy between the classic XSS attacks and DOMXSS.Lets proceed further with the exposition of the tactical level, covering Enum1.3 and Enum1.4: • understand the Function Flow of the Web-Application, • understand the Data Flow of the Web-Application,and how these are related to the technical implementation of DOM-based XSS.We should deploy this, by specifying and describing the fundamental abstract constructs,considering the following simple schema: • explaining what are Sources, Sinks and Storage (HTML5) and how are they relevant to DOMXSS • explaining the fundamental matter of URL encoding/decoding and how this applies to DOM-based XSS, concerning the aspects of attack payload obfuscation, as well as tainted input data filtering (please, see Section 4.4 )3.2.3 Sources and SinksWe demonstrate in Subsection 3.2.1 Environment and Threat Model, that the execution ofDOMXSS passes through multiple layers in the Browser engine, which corroborate the fact, that theevaluation and analysis of the attack is highly complex. So, is it possible to find a simplifiedrepresentation, a Meta-Model, which can give an answer to the basic questions, considering anattack [Enum2]: 1. Where are the vulnerabilities in the Web-Application? 2. How to exploit them? 16
  24. 24. 3 DOMXSS Attacks 3. Is the attack feasible or not?As already stated, the attack exploits the client-side implementation of the Web-App Business logicModel. Lets illustrate the client-side environment in Figure 5. It is obvious, that taking into countall related aspects of the Programming environment, will make this simplified representationunnecessary complicated. Though, a Meta-Model, which reproduces the Implementationenvironment, can give an answer to the questions from Enum2 and sustain its simplicity andcompactness. In general an attacker is essentially interested in – whether the attack works on thisparticular Web-App or not.In 2005, as already mentioned, Amit Klein proposes, that there should be a third subclass of theXSS attack vector (DOM-based XSS) and outlines different tactical implementations for thesuccessful completion of DOMXSS. In his online contribution (document), he enumerates thesetactical differences in a list, and points out the characteristic aspects, considering their separation.Nevertheless, he notes that, the list is not exhaustive and will be a subject of further improvementand extension. This should be considered as the starting point for the creation of a descriptive Meta-Model, related to the tactical implementation of DOM-based XSS (see Enum2).In 2007, the authors of [CW07] propose the terms: Source and Sink, according to the propermodular static code analysis.These two facts are used by Stefano Di Paola, who generalizes and completes the first fundamentalFigure 5: Client-side implementation of the Web-App Business logic Modelclassifications of DOMXSS Sources and Sinks, related to the Implementation environment of Web-Applications. Hence, we should propose his classification from 2008 [L7], as a foundation for theMeta-Model, explaining the tactical characteristics of DOM-based XSS, Enum2. We should call thismodel the Source/Sink/(Storage)36 Meta-Model, or S3 Meta-Model37 (S3MM). Lets enumerate itsmain parameters: a Prerequiremet(s); a Source, a Sink, a possible Storage; a Payload (or just a PoC-36 We should explain in the further exposition the existence of Storage in the S3 Meta-Model.37 A complete illustration of the S3MM is given in Figure 67, Appendix. 17
  25. 25. 3 DOMXSS AttacksPayload) and an Impact (factor). These S3MM parameters should be briefly explained in theAppendix. On behalf of these six parameters of the S3 Meta-Model, the workflow of the DOMXSSshould be completely described, according to its representation on the Implementation environmentof the client-side Web-App Business logic Model38, Enum2. Lets illustrate as a graph, the basicscheme of S3MM (Figure 6).Figure 6: Processing of Source and SinkBoth – Source and Sink, should be considered as an indispensable part of the Web-Application dataand function flow. In the Implementation environment (Figure 5), the Source denotes a codefragment, which embodies a vulnerable node from the DOM abstraction, implemented on the client-side of the Web-App. It represents the start node of a possible data flow, where an untrusted,malicious input data is collected and with greater likelihood acquired for processing of the Web-Application. The Sink determines the possible functional exploitability of a vulnerable source, e.g.how a processed tainted data could be exploited by an attacker and applied to the Source.On behalf of the Stefano Di Paolas proposed classification of Source/Sink, according to theirprocessing, there are specified three main types of Sources – direct, indirect and other objectSources, as shown in Table 1.Lets explain briefly, how Sources types differ from one another. The direct object Sourcesreference to the DOM objects instantly and can be modified by the user/attacker.As next, there are two different ways to induce indirect object Sources: • values of direct object Sources are stored and used later to cause vulnerabilities and incompleteness of the data, or • an already stored server side data from direct object Sources is exploited and executed by an attacker, causing a malicious input in the Web-App. [L7]A taxonomic overview of Sinks is represented in Table 2.As a most common and therefore dangerous type of Sinks are denoted the execution Sinks. Otherimportant representative, which will be described more detailed in 4.4 False usage of filters, is the“cssText” Sink.Further valuable type in this classification is the Location Sink. As stated in [L3], both“window.location”, “document.location” and all their representatives are Sinks and Sources.Moreover, the Location Sink can be divided into:38 http://blogs.msdn.com/b/simonince/archive/2008/07/18/wcsf-application-architecture-7-remote-logic-with-wcf- services.aspx 18
  26. 26. 3 DOMXSS Attacks • object assignment and • location methods .For further information, please visit [L7]. Main types Sub-types Representatives (Source) document.URL document.documentURI document.URLUnencoded (IE 5.5+) document.baseURI location/documentURI/URL Sources location location.hrefDirect sources location.search location.hash location.pathname Cookies Sources document.cookie Referrer Source document.referrer Window Name Source window.name History Sources history.pushState() history.replaceState() localStorageIndirect sessionStoragesources Storage Object IndexedDB Database (Safari Only) Server Response Sources opener (IE <= 7 Only)Other object parent/top/frames[i].objsources event.data of onmessage event for postMessage methodTable 1: Classification of sources39Table 1 as well as Table 2 are derivations of the Stefano Di Paolas domxsswiki [L7], a DOMXSSTest Cases Wiki Cheat Sheet Project. It is intended to be a central place, knowledge base, related tothe DOM-based XSS attack subclass. This project is still in development stage and not all Sinks and39 For more information, please visit http://code.google.com/p/domxsswiki/wiki/Sources 19
  27. 27. 3 DOMXSS AttacksSources are represented there, e.g. see Amit Kleins list. Furthermore, domxsswiki gives a greatopportunity for future work and Di Paola states, that contributions are welcome. Main types Sub-types Representatives (Sink) eval FunctionDirect Execution Sinks Browser JavaScript execution setTimeout sinks setInterval execScript crypto.generateCRMFRequest document.forms[0].action Collection document.forms[0].submit document.forms[0].reset ...Set Object SinksHTMLElement Sinks “document” object document.body document.title ...Style Sinks cssText Sink *XMLHttpRequest Sink XMLHttpRequest.open ...Set Cookie Sink “document” object document.cookie location location.href location.pathname location.searchSet Location Sink location.protocol location.hostname location.assign location.replaceControl Flow SinkUse of Equality And Strict EqualityMath.random SinkJSON SinkXML SinkTable 2: Classification of sinks [L7]Concerning the Storage in the S3 Meta-Model, we should point out, that this component is given inTable 1 and is specified as an indirect object Source. Though, in our proposed S3MM, it is treatedas a fundamental criterion for separation of NP-DOMXSS from P-DOMXSS (please, see Figure 2).An example of stored DOM-based XSS is demonstrated in Subsection 3.2.5 Attack scenarios. 20
  28. 28. 3 DOMXSS AttacksWhy is so important such separation?If a DOMXSS is represented in the S3MM and its Storage component matters for the proper attackexecution i.e. that the Browser stores persistent the malicious payload, for example in thelocalStorage object of the HTML5 Browser API plugin. This payload can be shared betweendifferent DOM-based XSS attack techniques, which represents a cross DOM access, as stated in[L23], illustrated in Figure 44.Thats why, we propose in S3MM a hard separation between the components Source and Storage.By this way, we give a sufficient description of the S3 Meta-Model and would like to outline, thatwe consider further refinement of the model, regarding its properties, represented in Table 1 andTable 2, as an interesting objective for future work.As the workflow description of DOM-based XSS, on behalf of our simplified Meta-Model iscompleted, we proceed with the next valuable topic for the technical evaluation of the DOMXSS ontactical STO layer in the following subsection.3.2.4 URL obfuscation – Encoding/DecodingIn JavaScript, there are three fundamental methods, which can be used to encode (Table 3) ordecode (Table 5) String values: • escape()/unescape() • encodeURI()/decodeURI() • encodeURIComponent/decodeURIComponentWe shall introduce them, respecting their enumeration order.The escape()-method returns a String in Unicode format, where all non-ASCII characters, spaces,punctuation40 etc. are replaced with “%XX”.41 Quite the contrary, the unescape()-method inverts aspecific hexadecimal value into an ASCII String.The encodeURI() returns an encoded String representation of an URI. In comparison to theescape()-method, it does not encode all characters42. An example for such characters can be seen inTable 3. In order to encode these specific characters the encodeURIComponent should be used.Please note, that the classification is not presented in the domxsswiki project [L7], which is anothertopic for future work.In the same manner, as Table 3 – Table 5 represents the general aspects, categorizing the URLdecoding differences. Note, that the table is incomplete and demonstrates only a few examples ofthe important special character list.40 With the exception of the following characters: * @ - _ + . /41 The XX is equivalent to the hexadecimal value in the ASCII table.42 The following characters are not escaped: , / ? : @ & = + $ # 21
  29. 29. 3 DOMXSS Attacks Char ASCII Number escape encodeURI encodeURIComponent ! 33 %21 ! ! # 35 %23 # %23 $ 36 %24 $ %24 & 38 %26 & %26 39 %27 … ... … … ...Table 3: Encoding Differences, derived from [L13]43How URL encoding and URL decoding are related to the tactical utilization of DOMXSS?Via the URL encoding, an intruder can obfuscate successfully the payload of the DOM-based XSSand thus pass through implemented Web-Application input filters. This increases the impact factorof the attack and also impedes the client-side Forensics, if such is applicable. For furtherinformation, please see Section 4.4 . A more advanced technique for payload obfuscationdemonstrates the double URL encoding44. To illustrate this, we want to represent the following casestudy: a double encoding on non-WebKit-based Web-Browsers, see Figure 45 and Figure 46.In [L24] is explained the principle of double encoding and a standard payload is presented in thecontext: %253Cscript%253Ealert(XSS)%253C%252Fscript%253EWe applied the payload directly into the address bar of the current version of the top Browsers,which caused a NP-XSS in the following ones, see Table 4. Browser Tested Browser engine Attack successful? Browser versionMozilla Firefox v.10.045 Gecko Yes, produces at least 2 Popups.IE v.9.0.8112.16421 Trident Yes, produces 4 Popups.Chrome v.16.0.912.77 m WebKit No, sanitized.Opera v.11.61 Presto No, sanitized.Safari v.5.1(7534.50) WebKit No, sanitized.Table 4: Address bar double encoded XSSThis explains, that NP-XSS is feasible in recent non-WebKit-based Browsers, because of the doubleURL encoding and automated URL completion. If such payload is applied to DOMXSS, as a value43 We present an incomplete list.44 https://www.owasp.org/index.php/Double_Encoding45 In the most current version of Mozilla Firefox – v.11.0, this matter is sanitized. 22
  30. 30. 3 DOMXSS Attacksof the XHR-object, most probably a large group of Web clients,specified as default for the clientOS, will reproduce the demonstrated in Figures 45 and 46 attack.It inevitably leads to the conclusion, that this issue should be discussed in detail in Chapter 4, wherefiltering mechanisms on behalf of URL decoding and Regexes will be proposed. At last, weencourage the testing of this exploit on mobile Web-Browsers as a future work.Thus, we completed the discussion, concerning the tactical STO layer of DOMXSS. We would liketo proceed further with the operational layer of its technical description, which is considerably moredemonstrative for the reader, as some interesting examples and case studies of DOM-based XSS areexplained. Char ASCII Number decodeURI decodeURIComponent # 35 %23 # $ 36 %24 $ & 38 %26 & , 44 %2C , … ... … ...Table 5: Decoding differences, derived from [L13]463.2.5 Attack scenariosBefore we proceed further with the detailed exposition of the attack scenarios, we want to give abrief overview of the treated case studies and examples, shown in Table 6, in a reasonably arrangedformat. Scenario name Scenario type Scenario description Web-Goat case study Testing environment and educational scenario AOL case study Real time scenario Stored DOMXSS example Exploit on HTML5 localStorage object JavaScript private functions example Ignoring the JavaScript conventionsTable 6: Scenario types3.2.5.1 Case study: Testing environment and educational scenarioThe OWASP WebGoat47 Project framework provides a testing environment (under Windows/46 We present an incomplete list.47 https://www.owasp.org/index.php/Category:OWASP_WebGoat_Project 23
  31. 31. 3 DOMXSS AttacksLinux/UNIX) in which different types of attacks can be executed. It is developed and can be usedfor educational purposes. We will describe more detailed this tool in Subsection 4.5.2 Tools, whereall utilities relevant for this paper are presented. Lets advance to the DOMXSS educational scenarioon behalf of the paradigm: AJAX Security::Lab:DOM-based cross-site scripting.This scenario is presented in 5 simple steps, which are meant to be fundamental and should beconsidered as crucial for the security of every Web-Application, that uses/implements JavaScript.In the first step, the goal is to use the input field, which is unsanitized, in order to embed an imageelement into the DOM of the Browser. In the input box, concerning the user name, is inserted thecode as shown in Figure 47, which enforce the Web-Application to show a picture from theaddress– “http://localhost:8080/WebGoat/images/logos/owasp.jpg”. Here, we should mention, thatan intruder can manipulate, specify arbitrarily the image URL. Among the billions of pictures on theWeb, there are many with different inappropriate content, which can ruin the reputation of a Web-App (E-Commerce, Educational etc.). Furthermore, the attacker can even alter the “src” attributevalue, to redirect the request to a Phishing Web site. <img src="http://localhost:8080/WebGoat/images/logos/owasp.jpg" />The modified DOM can be seen in Figure 47.Going further with the “adjustment” of the DOM Construction, the second stage is about theexecution of an alert screen (Pop-up). This is accomplished, as we keep on exploiting the input fieldof the vulnerable Web-App and modifying the <img> tag (shown in the code box below). Therefore,in the “onerror” attribute is implemented the JavaScript function “alert()”, e.g. “alert(P0Wnd)”.Please, note that the “src” attribute is not given in W3L-comform style in order to impel theBrowser engine to produce an error and consequentially to execute the “onerror” attribute. <img src=P0Wnd onerror="alert(P0Wnd)"/>The result after stage 2 is represented in Figure 48.In the third stage, the goal is to exploit the <iframe> tag (see next code box) and execute the“alert()” function. Please, note that, it is not even necessary to close the <iframe> tag in order totrigger the malicious code (Figure 49). <iframe src=javascript:alert("P0Wnd")>Stage 4 denotes, how an unsanitized input field can be concealed as a fake one via JavaScript, andused by an attacker to steal passwords. By inserting the code, given in the following code box, theDOM is changed and a common Web end user could easily walk straight into the trap (Figure 50). 24
  32. 32. 3 DOMXSS AttacksPlease enter your password:<BR><input type = "password" name="pass"/><buttononClick="javascript:alert(I have your password: +pass.value);">Submit</button><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR><BR>As the user enters His password, the “alert()” function causes the opening of a pop-up window,showing the concrete value of the “pass” variable, in this example it is "P0Wnd" (Figure 7). Please,note that in this case, a cracker can modify the “onClick” attribute so, that the password can be sentto a malicious server. Moreover, He can also induce other improper behavior of users Browser.Figure 7: DOM-based cross-site scripting after stage 4In the fifth stage, the sanitization of the input field, used in the previous four phases of this scenario,has to be initiated. For this purpose, the code of the JavaScript-file (see the code box below), whichis responsible for the sanitization, has to be changed. As next, lets represent the unsanitized code.function displayGreeting(name) { if (name != ){ document.getElementById("greeting").innerHTML="Hello, " + name+ "!"; }}After short observation of the source code, we notice that the variable “name” is not properlysanitized and can be used for the malicious execution of JavaScript. To prevent this, we should use 25
  33. 33. 3 DOMXSS Attacksthe “escapeHTML()” function48, as shown in the next code fragment.function displayGreeting(name) { if (name != ){ document.getElementById("greeting").innerHTML="Hello, " + escapeHTML(name) + "!"; }}After completing stage 5, we try to execute one of the attacks, that we applied in the previousphases, but as shown in Figure 51, it doesnt work anymore.Lets denote the S3 Meta-Model for this particular case study:S3 Meta-Model: WebGoat case studyPrerequirements: none Source: HTML DOM Text Object – textObject.name, in this case study – person.value Sink: document.getElementById("greeting").innerHTML Core: Storage: none Payload: Please enter your password:<BR><input type = "password" name="pass"/><button onClick="javascript:alert(I have your password: + pass.value);">Submit</button><BR><BR><BR><BR><BR><BR><BR><BR ><BR><BR><BR><BR><BR><BR><BR><BR>Impact: educational attack exampleWhat is valuable in this case study?First of all, the transition from the classic NP-XSS to DOMXSS is demonstrated and a securityconcerned user should be able to notice the difference – by injecting the malicious code, the DOMConstruction dynamically changes and triggers the execution of the attack via the DOM renderingengine in the Browser. Secondly, an example of DOM-based XSS attack technique is presented withvisual feedback on the testing environment. At last, a sanitization technique is proposed, whichdesignates the WebGoat tool as an educational, respecting the Web Application Security.As next, we will pay attention to the second scenario – real time attack scenario-AOL.3.2.5.2 Case study: Real time scenario – AOLWhat is crucial in this example?The Aol. B2C portal still utilizes an outdated AJAX framework to auto complete the users search48 Please note, that the “escapeHTML()“ function is not predefined JavaScript function, but a method in JavaScript Framework prototype. 26

×