Message-ID: <32893.141.156.186.68.1074266869.squirrel@www.mccammon.org>
From: keith-list at mccammon.org (keith-list@...ammon.org)
Subject: Ummm...Sanctum Patents Web App Pen Testing?

Anyone know anything about this?  Looks like yet another information
security firm trying to patent some shit that people have been doing for
years...

-------- Original Message --------
Subject: Web Application Penetration Testing Methodology Patent
Date: Fri, 16 Jan 2004 06:37:36 -0800
From: <webtester@...hmail.com>
To: webappsec@...urityfocus.com, pen-test@...urityfocus.com

===========================

As many of you know, Sanctum, Inc. has a been granted a patent (United
States Patent No. 6,584,569) describing a process for automatically detecting
potential application-level vulnerabilities or security flaws in a web
application.  What you may not know is that this patent is a "method"
patent which means that it describes the way something works rather than
a "product" patent which describes an actual product.  A method patent
is the broadest form of a patent which covers not just products but also
the process or way people work.

The Sanctum patent is very broad and virtually everyone who is involved
with web application security is in violation of this patent.  This is
because the patent basically describes the process of penetration testing.
 The patent can be broken down into four elements.  They are:

1. The process to traverse a web application in order to discover and
actuate the links therein.  This is also called a web crawler.  Something
that explores the entire code for a website and discovers all the links,
 or URLs, contained on the website.  The process then actuates each link
found on the website to generate HTTP requests for transmission to the
web server (i.e., exercises the links).  If the discovered link requires
user input, such as when the discovered link includes a form, the process
also provides fictitious values as input based on the field or data type.

2. The process to analyze messages that flow or would flow between an
authorized client and a web server in order to discover elements of the
web application's interface with external clients and attributes of these
elements (e.g., links, forms, fixed fields, hidden fields, menu options,
 etc.).  Here, the process sends the HTTP requests generated above for
each of the discovered links and receives the associated responses from
the web server.  The responses are then analyzed, in the same manner
in which the original website was analyzed, to discover all of the links
contained therein.  The responses are also scanned for other application
interface elements, such as data parameters, and their attributes (such
as links, fill-in forms, fixed fields, hidden fields, menu options, etc.).
 Up to this point, the process essentially explores and exercises all
of the links on a website by sending authorized requests, then analyzes
the responses for more links and interface elements (explores multiple
layers of the web application).

3. The process then generates unauthorized client requests in which these
elements are mutated, sends the mutated client requests to the web server,
 receives server responses to the unauthorized client requests.  The
process creates and sends unauthorized or mutated requests (also called
"exploits") to the server.  The process creates a mutated request for
each interface element discovered above.  The mutated request created
by the process depends on the type of interface element at issue.  For
example, if the interface element is a numeric field, the scanner will
create a mutated request that contains text as input, or if the interface
element is a link, the scanner will create a mutated request that appends
".bak" to the link's path.

4. The process evaluates the results of the mutated requests.  Finally,
 the process evaluates the response to the mutated request to ensure
that the web server did not accept the unauthorized input value.  One
example of such an evaluation would be to look for responses containing
keywords, such as "error," "sorry" or "not found."  If such words are
not returned, the process would conclude that the mutated request was
accepted and that the web application is vulnerable to attack (i.e.,
that the website contains a security flaw).

As you can see, this patent is very broad and covers everything from
security products to penetration testing.  Unless someone can develop
a way to perform web application security without violating one of the
four points mentioned above everyone is in violation of this patent.
 Obviously, such a patent gives Sanctum an unfair competitive advantage
within our market.  However, there is a way to challenge this patent.
 First and foremost is to find something that addresses all the above
points 1 year prior to when Sanctum submitted the patent.  Sanctum submitted
for the patent on March 3, 2000 so the material must be dated on or before
March 2, 1999.  If you know of something that has been made public (e.g.,
 article, posting, product, etc.) that contains all of the above elements
post your findings to the list.  A critical aspect is that is must contain
all 4 elements from above.  Anything less will not suffice.

Powered by blists - more mailing lists