Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Web-App-Sec
[Top] [All Lists]

Re: GET and POST Methods Accepted

Subject: Re: GET and POST Methods Accepted
Date: Thu, 13 Oct 2005 07:36:52 +0100
My current methodology is this:

(i) every script (I'm using PHP) that is accessed determines all the
$_GET and $_POST variables that the user is trying to feed it;
(ii) it examines these against a list of allowed variables, allowed
methods for those vars, allowed characters, lengths, types, encodings
etc;
(iii) only input that conforms to my whitelist is defined as variables
in the script, everything else is blacklist, and I / sysadmin can be
alerted to this effect and /or the relevant IPs blocked.

I think this conforms to OWASP guidelines, but please tell me if
there's a big security hole that I'm missing (I'm preparing myself for
alot of screaming and kicking of self in the shins).  It does, of
course,  require that I rigourously maintain my list of allowed
variables.

From what I can tell, some sites do something similar thing to (i) and
(ii) but use $_REQUEST (ie. both $_GET and $_POST) and don't check for
correct methods, which might explain what you're seeing.

If you do a loop over the $_REQUEST variables and don't check them for
allowed methods then you'ld end up with a situation like you mention.

Damien


On 12/10/05, Welsh, Ed <Ed.Welsh@fishnetsecurity.com> wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

I have begun stating this as an issue during assessments and wonder what you 
folks think of it.

Web sites are allowing a switch in method for requests and still processing 
the input.  I have been
able to analyze a site login form which is specified to use POST method and 
craft a URL (GET of
course) that the web server will still accept and process.  If the site will 
accept the GET method for
form data and is vulnerable to XSS, the attack surface greatly increases over 
a site that is
vulnerable to XSS but only accepts the POST method.  POST is still 
attackable, but it becomes more
complicated than simply emailing a link.

There used to be a substantial difference in how variables received via GET 
vs POST were stored.  That
difference had to be accounted for in the server code and would not lend 
itself to arbitrary method
switching.  This may disclose some of my ignorance, but it seems something 
has changed and application
systems are treating input values the same regardless of the method.

I have seen this recently on J2EE sites and CGI (PERL, PYTHON, Binary).

Do any of you test for this issue - what are your results?

Any other discussion is valued.

Ed Welsh
-----BEGIN PGP SIGNATURE-----
Version: PGP Desktop 9.0.2 (Build 2424)

iQEVAwUBQ01sNlcLJH9lmXCIAQgowAgAz4eUyEgXKIk7aveM09znkQVy4rUm640w
7M9XwRC2XnHo49MIc2CLsBa6d2yFbBsfhjw0L+hNRhWVnWRZsBv1Z+k61slZK0QU
qeQS4f3+6iVgqesLsRtFG6d7DI50tDuVFpIkrwosLL4OkVLFHrA56x3BkrByverx
pYa6SMihDMrVRl5dvIGecijObexHLM03gEembyTB2XJC5h+5Z3UNaGqt6kf4X0Dz
Y3pfBdQ5OH8XdVReW+AZJAimd40g/+qiiYhMbeKJzC0p3/7Yw1VOG9//OPKFi/wY
q79op1KikDcZ7l29YdI323gfI2G5WS3rJsdP00wM9X2IFEsdYR7n3A==
=zb7v
-----END PGP SIGNATURE-----


<Prev in Thread] Current Thread [Next in Thread>