How do I test safe form input?

[Reply Via Newsgroup]

Folks,

I am using Apache 1.3.x with PHP 4.3.x and MySQL v4.

Short question:
Before I put my web form available on the internet, how can I test it
from mis-use in such that special characters are ignored? I have tried
entering data such as `/bin/date > /tmp/1234` and this does not create a
temporary file (which is what I would expect, meaning that my form is safe).

Same question at greater length:
I understand how form input can be misused, and I understand that I can
clean the data input using addslashes() or by having magic_quotes turned
on. I have decided on the latter but want to ensure my form is safe and
that storeing my data in my mysql database isn't open to hacking by
CGI/Form manipulation. I have tried entering data such as `/bin/date >
/tmp/1234` and this does not create a temporary file (which is what I
would expect, meaning that my form is safe).

Have I tested it successfully against Form/CGI hacking?

Thanks in advance, replies please, via the newsgroup,

randell d.

[Aggro]

Reply Via Newsgroup wrote:

Have I tested it successfully against Form/CGI hacking?

No you haven't.

There are many ways to brake in to webservers, trying only one gives you
only a fealing that you are secure. There are even books written about
this subject, so this isn't as simple as one could think.

Even people who teach or sell security services or products get
sometimes their websites hacked. Most of it happens via forms or by
using known security holes in software they use.

[Reply Via Newsgroup]

Aggro wrote:

Reply Via Newsgroup wrote:

Have I tested it successfully against Form/CGI hacking?

No you haven't.

There are many ways to brake in to webservers, trying only one gives you
only a fealing that you are secure. There are even books written about
this subject, so this isn't as simple as one could think.

Even people who teach or sell security services or products get
sometimes their websites hacked. Most of it happens via forms or by
using known security holes in software they use.

Thanks - I'm aware of what you have said and know there are several
methods of gaining unauthorised access to a webserver - Firewalls and
correct web server configuration can help with a more secure
environment, however when one receives data in a form, it too can be a
weakness if the data is stored and not cleaned before storing.

This is the area I want to test - I am specifically concerned with
testing that passing 'bad' data in my form won't corrupt my server.

Can you confirm that entering something like `/bin/date > /tmp/1234`
would create a temp file /tmp/1234 if I hadn't cleaned my data properly
- whereas the lack of a file confirms that I have cleaned the data.

Yes/No?

[Aggro]

Reply Via Newsgroup wrote:

Can you confirm that entering something like `/bin/date > /tmp/1234`
would create a temp file /tmp/1234 if I hadn't cleaned my data properly
- whereas the lack of a file confirms that I have cleaned the data.

Yes/No?

No.

Like I said, you have only tested one case. And much depends on where
you use your input. One could use it for file attack, database attack,
operating system attack, attack to another server, attack to clients
that use the server, ...

I know cases where people have used flash animations as their
user-images and gained passwords from other users which have viewed
those flash animations.

I have personally tested (with permission) to use sql-injection to do
unwanted actions into database. For example to delete data, get
passwords and usernames, etc.

I have also tested the same as what you are currently trying to stop.
i.e. not to allow user to run programns in the shell.

I also know cases when there have been nothing wrong with the php script
itself, but there has been another script on the same server that has
had a security hole. So you have been able to view the secure code via
the another script and the secure code has become unsecure.

I have also tested the famous problem with php and globals. i.e.

You have a form where you ask for $username and $password and you have a
script like this:

<?php
if( $username == "correct" && $password == "correct" )
$login = 1;

if( $login )
{
// give user permission to anything
}
?>

call the php script like this: script.php?logi n=1
And boom, you are in.

And this is not all, this is not even all I know. And I don't even work
with the security, it is just a hobby for me.

It might even be possible that `/bin/date > /tmp/1234` doesn't do any
harm, but if you add a few more special characters to it, it might be
harmfull again. It can also be possible that you can't write anything,
but you can read something, and that is almost as bad.

[news]

Here are a couple pages, do some searching on google and you will finde more
info.

http://httpd.apache.org/docs/misc/security_tips.html
http://www.devarticles.com/c/a/Perl/...e-CGI-scripts/

"Reply Via Newsgroup" <re************ ****@please.com > wrote in message
news:Vfz3c.1139 5$Up2.3469@pd7t w1no...

Folks,

I am using Apache 1.3.x with PHP 4.3.x and MySQL v4.

Short question:
Before I put my web form available on the internet, how can I test it
from mis-use in such that special characters are ignored? I have tried
entering data such as `/bin/date > /tmp/1234` and this does not create a
temporary file (which is what I would expect, meaning that my form is safe).
Same question at greater length:
I understand how form input can be misused, and I understand that I can
clean the data input using addslashes() or by having magic_quotes turned
on. I have decided on the latter but want to ensure my form is safe and
that storeing my data in my mysql database isn't open to hacking by
CGI/Form manipulation. I have tried entering data such as `/bin/date >
/tmp/1234` and this does not create a temporary file (which is what I
would expect, meaning that my form is safe).

Have I tested it successfully against Form/CGI hacking?

Thanks in advance, replies please, via the newsgroup,

randell d.

[Reply Via Newsgroup]

Aggro wrote:

Reply Via Newsgroup wrote:

Can you confirm that entering something like `/bin/date > /tmp/1234`
would create a temp file /tmp/1234 if I hadn't cleaned my data
properly - whereas the lack of a file confirms that I have cleaned the
data.

Yes/No?

No.

Like I said, you have only tested one case. And much depends on where
you use your input. One could use it for file attack, database attack,
operating system attack, attack to another server, attack to clients
that use the server, ...

I know cases where people have used flash animations as their
user-images and gained passwords from other users which have viewed
those flash animations.

I have personally tested (with permission) to use sql-injection to do
unwanted actions into database. For example to delete data, get
passwords and usernames, etc.

I have also tested the same as what you are currently trying to stop.
i.e. not to allow user to run programns in the shell.

I also know cases when there have been nothing wrong with the php script
itself, but there has been another script on the same server that has
had a security hole. So you have been able to view the secure code via
the another script and the secure code has become unsecure.

I have also tested the famous problem with php and globals. i.e.

You have a form where you ask for $username and $password and you have a
script like this:

<?php
if( $username == "correct" && $password == "correct" )
$login = 1;

if( $login )
{
// give user permission to anything
}
?>

call the php script like this: script.php?logi n=1
And boom, you are in.

And this is not all, this is not even all I know. And I don't even work
with the security, it is just a hobby for me.

It might even be possible that `/bin/date > /tmp/1234` doesn't do any
harm, but if you add a few more special characters to it, it might be
harmfull again. It can also be possible that you can't write anything,
but you can read something, and that is almost as bad.

I'm pretty sure you're trying to help me - but you're giving me answers
not directly related to the question I asked.

I'm not asking about
- flash animations,
- security access or bugs related to GLOBALS being switched on
- security weakness available to clients on the same network
- or sql-injection type vunerabilities
- file uploads

I want to test that when data is transported from my HTML form, to my
MySQL database that the data does not get some form of ability to
execute code which I believe could be made possible via hooks or some
other special character. I am pretty sure I clean my data, but I would
like to test it with the hack.

I am not going to take comfort in the fact that by confirming this hole
is closed that I am safe - I merely want to test for this specific weakness.

Can you help?

[Reply Via Newsgroup]

news wrote:

Here are a couple pages, do some searching on google and you will finde more
info.

http://httpd.apache.org/docs/misc/security_tips.html
http://www.devarticles.com/c/a/Perl/...e-CGI-scripts/

That should help - thanks.

randelld

[Joshua Beall]

You should also keep in mind that the things you want to be careful for very
with the context of the form. If it is something you are going to echo back
to the browser, you do not care if somebody uses a semicolon; the semicolon
is a legitimate punctuation mark. On the other hand, if this is getting
passed to MySQL or something else that attributes special meaning to the
semicolon, then need to be careful.

What I am saying is, in order to make sure your form is safe, you have to
consider the context. So, what are you trying to do with this form? Is it
going to be a used in a SQL query or what?

[Reply Via Newsgroup]

Joshua Beall wrote:

You should also keep in mind that the things you want to be careful for very
with the context of the form. If it is something you are going to echo back
to the browser, you do not care if somebody uses a semicolon; the semicolon
is a legitimate punctuation mark. On the other hand, if this is getting
passed to MySQL or something else that attributes special meaning to the
semicolon, then need to be careful.

What I am saying is, in order to make sure your form is safe, you have to
consider the context. So, what are you trying to do with this form? Is it
going to be a used in a SQL query or what?

Yes Yes Yes!

At last - someone who seems to know where I am comming from - This is
specifically what I am concerned about (that characters might be
mis-interpreted as a command as opposed to ordinary data). I believe I
have managed to cover my ass but I'd like to test, safely.

Any ideas?