I know I missed the 7 day deadline, but I couldn't hold back.

The Header Manipulation focuses on standard HTTP headers as defined in the
RFC. We've seen people use HTTP for other reasons and have had a lot of
success modifying HTTP Headers because App designers didn't anticipate these
types of attacks.

1. As an IPC mechanism between ISAPI/Apache filters and ISAPI extensions or
JSPs.
A common design is for authorization/authentication to be performed in a
filter, and once that is checked, an HTTP Header field is set using
SetHeader to specify a UserID or other important information. For example,
the filter may set a header CustomerID, or UID equal to a 100 so that the
CGI program just has too lookup the UID in the HTTP headers. These
non-standard HTTP headers can be spoofed to bypass authorization and
authentication. **NOTE** This would usually not be found in a black box
test, unless it was a Shrink-wrapped product that you could throw a debugger
on or had source code. The headers don't get sent back to the client, but if
the clients sends it, the server DOES parse it.

2. MS .NET web services uses custom HTTP headers that can be tampered with.

I haven't had much success modifying Referrer or UserAgent fields, but
modifying Application specific headers are a gold mine.

Dave

-----Original Message-----
From: Mark Curphey [mailto:markcurphey.com]
Sent: Sunday, November 18, 2001 8:34 PM
To: webappsecsecurityfocus.com
Subject: OWASP-PM-HH-1 (HTTP Header Manipulation)

The following OWASP DRAFT for the Classification of
Vulnerabilities(COV)project has been submitted by Sverre Huseby, and can be
found at http://www.owasp.org. We very much welcome your technical comments
and input. To comment on this write-up please reply to the mailing list
using "reply to all" to this email within 7 days.

HTTP Header Manipulation

http://www.owasp.org/projects/cov/owasp-pm-hh-1.htm

Thanks.

owaspowasp.org

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]