RE: XSS, SQL injection etc - permutations of input strings

["Scovetta, Michael V" <Michael.Scovetta () ca com>]

Keith,
   A few comments:
1. The *only* difference between GET and POST is the "average" user
thinks that POST means the client can't see it. This is totally untrue.
If your site is secure, then it shouldn't matter whether it's GET or
POST. If it's not, then relying on POST to make it seem secure is
Security Through Obscurity (a Bad Thing(TM)).

2. Using select boxes might make your job creating the site more
organized, but you could just as easily have a text box with a message
to the user to "type in Y or N", and validate against Y|N server-side.
Using a select box will not prevent the user from passing in whatever
they want.

3. Generic validation routines based on regexps are a Good Thing.

4. If you're merely validating, then there's no difference between the
$_POST data and the $v_ data (otherwise it wouldn't have passed
validation. If you're scrubbing, then the $v_ data is the right one to
use. Be wary, however, of not getting the scrub exactly right. (remember
double-encoding vulnerabilities, and the continued existence of xss
attacks)

My $0.02.

Mike Scovetta

-----Original Message-----
From: focus () karsites net [mailto:focus () karsites net] 
Sent: Sunday, September 19, 2004 4:57 PM
To: webappsec () securityfocus com
Subject: Re: XSS, SQL injection etc - permutations of input strings


Hi there - I'm  fairly new to this web server security
stuff - please try not to rotfl ;-).

The way I see it as regarding evaluating user input
submitted via forms is:

There are basically two types of user submitted input -

1> known input from select options.

2> Unknown input from text entry fields.

(not taking into account: file, password, checkbox or radio,
input types)

So if a programmer can try to use drop down select boxes for
known user input as much as possible, the expected input at
the server end can then be validated for what options the
user may choose from, in the select option fields of the
form submitted to the server. Anything other than expected
values should terminate the script.

Obviously, this also eliminates spelling mistakes and any
ambiguities that may occur as the user types values into a
text entry field - which should also help in well formed
database queries, as the user input to the SQL query is
within a well defined range of expected values.

For unknown user I/P in a plain <input type ="text" ... or
type ="hidden" ... (type = "password can be treated as known
user input), then you could use a set of server-sided
validation scripts, to cheque for known hacking strings.

As new hacks become made known, update the string checking
functions to detect the new hacks.

I use php on my server, and do not allow passing of values
in the URL query string - probably a bit to restrictive for
most sites that like to pass the session ID in the URL.

However, the URL query string can also be checked for values
other than a valid session ID using Regular Expressions.

(I just terminate my scripts if there are any values found
in the php $_SERVER["QUERY_STRING"] as my first site does
not use session ID's for passing values between pages).

The other thing I like to do is to check ALL INPUT from
submitted forms at the start of each called script like
this:

  $v_ref_number      =  $_POST["v_ref_number"];
  $v_wants_property  =  $_POST["v_wants_property"];
  $v_wants_area      =  $_POST["v_wants_area"];
  $v_wants_careline  =  $_POST["v_wants_careline"];
  $v_wants_pics      =  $_POST["v_wants_pics"];

  string_check($v_ref_number, 'v_ref_number');
  property_check($v_wants_property, 'v_wants_property');
  area_check($v_wants_area, 'v_wants_area');
  Y_N_check($v_wants_careline, 'v_wants_careline');
  Y_N_check($v_wants_pics, 'v_wants_pics');

Once all the inputs have been checked at the start of the
script, then I only refer to the checked and validated
values in the php variables. I do not refer to the values in
$_POST["v_name"] , as these contain the unchecked values.

You may like to check out my site at www.karsites.net and
see if you can hack into it with dodgy values set into some
home-made attack forms. The main homepage has not been
protected in any way, so that is vulnerable to XSS attacks.

Just follow the link to Kings Lynn Mutual Exchange Register,
and see what you can do from there.

HTH

Kind Regards - Keith Roberts


On Sat, 18 Sep 2004, Mike Andrews wrote:

> To: webappsec () securityfocus com
> From: Mike Andrews <mike () se fit edu>
> Subject: XSS, SQL injection etc - permutations of input strings
>
> Over the past few days I've seen many posts about different ways of
encoding
> XSS/SQL injection strings, as well as leveraging a discovered
vulnerability
> in order to get more information about the target (other DB
fields/schema).
> The question I'd like to ask the list is once you know a particular
input
> vector is vulnerable, why are people trying to push the exploit
further,