README-background.txt 7.02 KB
Newer Older
1 2
# Copyright (c) 2007 University of Utah and the Flux Group.
3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
# This file is part of the Emulab network testbed software.
# This file is free software: you can redistribute it and/or modify it
# under the terms of the GNU Affero General Public License as published by
# the Free Software Foundation, either version 3 of the License, or (at
# your option) any later version.
# This file is distributed in the hope that it will be useful, but WITHOUT
# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
# FITNESS FOR A PARTICULAR PURPOSE.  See the GNU Affero General Public
# License for more details.
# You should have received a copy of the GNU Affero General Public License
# along with this file.  If not, see <>.
# }}}
22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158

See README-FIRST.txt for a top-level overall outline.

 - Background on SQL Injection vulnerabilities: Ref "The OWASP Top Ten Project"

   . "The OWASP Top Ten represents a broad consensus about what the most
     critical web application security flaws are."

   . The first flaw on the list (many others are consequences of this one.)
       "A1 Unvalidated Input -
	Information from web requests is not validated before being used by a
	web application. Attackers can use these flaws to attack backend
	components through a web application."

   . One of the consequences:
       "A6 Injection Flaws -
	Web applications pass parameters when they access external systems
	or the local operating system. If an attacker can embed malicious
	commands in these parameters, the external system may execute those
	commands on behalf of the web application."

   . More details:
     - The OWASP Guide Project

     - Guide Table of Contents

       . Data Validation
	 - Data Validation Strategies
	 - Prevent parameter tampering
	 - Hidden fields

       . Interpreter Injection
	 - SQL Injection

 - Automated vulnerability scan tools, search and conclusions

   . In July 2006, I surveyed 29 available free and commercial tools,
     categorized as site mappers, scanners, http hacking tools, proxies,
     exploits, and testing tools.  9 of them were worth a second look.

     Many were Windows-only, or manual tools for "penetration testing" to find
     a single unchecked query hole and then attack a database through it.
     Some had automation specific to Microsoft SQL server, which is easy
     because it reports SQL error messages through query results that can leak
     onto HTML pages.  These can easily be used to locate injection holes and
     spill the internal details of the database schema; then the DB data is
     siphoned out and/or mischief is done through the hole.

     None of the tools targetted MySQL, but I verified that MySQL is still
     vulnerable to SQL injection attack from any unchecked or unescaped inputs
     to GET or POST forms.  Trivially, just include an unmatched single-quote
     in any input string that goes into a dynamically-built SQL query that has
     argument strings delimited by single-quotes.

     This is of course only useful if you have another way to know the
     database schema.  Such as an open-source distribution of our software,
     which would also allow finding input checking holes by inspecting the PHP
     code.  Hence the goal to locate, plug, and verify *all* such holes before
     open-source distribution.

     Some site mappers are combined with plugins to generate "blind" SQL
     injection probes against the input fields of forms.  They might be
     effective against a suicidal site with very little sanity checking on

     Our PHP code checks "almost all" inputs serially, so the first input that
     is rejected short-circuits checking the rest of the inputs and generating
     queries.  But a clever penetrator could generate reasonable inputs and
     get past that to find a hole and exploit it.  We need an automated way to
     provide some assurance that there are no holes to find.

   . I selected several of the tools to try:

     - Screaming Cobra - Mapper with form vulnerability "techniques".  (Perl)

       I tried it in the insulation of an Emulab-in-Emulab, with various
       combinations of arguments.  Not surprisingly, its blind thrashing
       didn't penetrate any of the public Emulab pages.

       But one could go much further with an Emulab login uid and password,
       after adding necessary login session cookie logic.  And further still
       if admin mode were breached...

     - Spike Proxy, an HTTP Hacking / Fuzzing proxy
       (Open Source, Python, Windows/Linux) w/ SQL injection.

       This is a good example of what a manual "penetration tester" (black or
       white hat) would use to attack a web site.

       I used it to record browsing sessions while manually operating the
       Emulab web site.  It also allows editing inputs and replaying attacks
       but I didn't try that.

       It was useful to determine exactly what POST arguments were passed and
       their values.  This broke a chicken-and-egg bootstrapping problem: I
       had to script "activation" of the DB (creating "one of everything")
       before I could spider the web site and enumerate the full set of forms

     - WebInject - Free automated test tool for web apps and services.
       Perl/XML, GPL'ed.

       This sounded perfect at first, particularly since it presents a GUI of
       the test results.  But to do that, it has to be provided with a
       complete set of success and failure match strings, expressed along with
       the URL's to probe in an XML file.

       Unfortunately, it's made for monolithic runs, where everything is in a
       single session.  That's not useful for incremental development,
       particularly since the the web pages are not retained to help
       understand what happened.

       Maybe this will be useful at some point though, so I kept it under
       sec-check with some stubs in the makefile for generating the XML.

       Meanwhile, I found that the (new version of the) venerable "wget"
       command has the necessary options to retain login cookies, set
       traversal limits for recursive spidering, and convert pages so they are
       browsable from local directories.  Far more convenient.

       I wound up implementing logic similar to WebInject in a much simpler
       way (but without a GUI.)