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

[Devdas Bhagat <devdas () dvb homelinux org>]

On 19/09/04 14:18 +0000, Keith Roberts wrote:
> 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)

Actually, there are two types of user input, untrusted and untrusted.
You are assuming that the only input possible is via the browser
interface.
What happens if that is bypassed? 

> 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.

Agreed. This is the right thing to do.

> 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.

$input =~ s/[^valid]//g

> 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.

So you block http get?

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

Who cares? The language/library should already have a input processing
method. Just use that.  Don't reinvent the wheel.

With Perl:
#!/usr/bin/perl -T
use strict;
use warnings;
use CGI;

and use the CGI->param() method to get your values.

> (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.

A good way of doing things. Personally, I would prefer an interface like
$untainted_variable = check(type, variable)
where the check method knows about the appropriate bounds for 'type'.

Devdas Bhagat