|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
Re: Web Application Penetration Testing Methodology Patent
From: cdowns (cdowns
drippingdead.com)
Date: Fri Jan 16 2004 - 11:05:40 CST
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Its a legit patent #
http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=/netahtml/search-bool.html&r=1&f=G&l=50&co1=AND&d=ptxt&s1=6,584,569&OS=6,584,569&RS=6,584,569
Snip ---->
*United States Patent * * */6,584,569/* ** Reshef , et al.* * June 24,
2003*
It has had a patent # for quit a while... Im not shure how this affects
other companies as Im not a patent attorney, do we have one aboard ?
~!>D
Matthew Wagenknecht wrote:
>Wow, Jeff.. Where did that come from?
>
>I think that this request is quite legitimate. It has much more to do with
>pen-test and web application security than legal issues.. Truth is Sanctum's
>patent request is an attampt to own common sense. The methodology detailed
>in the patent request is not the result of an internal think tank at Sanctum
>that came up with a new thought process for web app penetration testing. The
>details basically describe the equivilent of walking up to every house on a
>street and rattling the dorr knobs. If the dorr doesn't open easily, try
>every key-like object in their possesion to jimmy the lock.
>
>It's like me trying to patent how I pay bills and not allowing anyone else
>to do it that way.. It's just silly..
>
>-----Original Message-----
>From: Levenglick, Jeff [mailto:JLevenglick
fhlbatl.com]
>Sent: Friday, January 16, 2004 8:43 AM
>To: webtester
hushmail.com; webappsec
securityfocus.com;
>pen-test
securityfocus.com
>Subject: RE: Web Application Penetration Testing Methodology Patent
>
>"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. "
>
>Yea, sure pal. If I was doing anything illegal, I'll tell you so you can sue
>me.
>I'm assuming that your close to being out of money and are looking for a
>cheap way to find and sue people?
>
>Listmaster:
>
>That had nothing to do with the list. Is your list now becoming a spam list?
>(ie: this should be on some legal list)
>
>Jeffrey
>
>-----Original Message-----
>From: webtester
hushmail.com [mailto:webtester
hushmail.com]
>Sent: Friday, January 16, 2004 09:38 AM
>To: webappsec
securityfocus.com; pen-test
securityfocus.com
>Subject: Web Application Penetration Testing Methodology Patent
>
>
>===========================
>
>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.
>
>
>
>
>
>Concerned about your privacy? Follow this link to get FREE encrypted email:
>https://www.hushmail.com/?l=2
>
>Free, ultra-private instant messaging with Hush Messenger
>https://www.hushmail.com/services.php?subloc=messenger&l=434
>
>Promote security and make money with the Hushmail Affiliate Program:
>https://www.hushmail.com/about.php?subloc=affiliate&l=427
>
>-----------------------------------------
>This e-mail message is private and may contain confidential or privileged
>information.
>
>
>
>
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]