I have a page the uses a form to pass a postcode to another page and I
want to test it against an SQL Injection. What would be a safe (i.e NO
DELETING of data ) statement to try and how would I format this to try
in the form.
I have limited the field to 10 chars so I know i would have to test it
with a larger field because a hacker could just rewrite the form and
use a lerger field for the attempted attack.

Many thanks in advance

VoodooJai

Voodoo Jai wrote:

I have a page the uses a form to pass a postcode to another page and I
want to test it against an SQL Injection. What would be a safe (i.e NO
DELETING of data ) statement to try and how would I format this to try
in the form.
I have limited the field to 10 chars so I know i would have to test it
with a larger field because a hacker could just rewrite the form and
use a lerger field for the attempted attack.
>
Many thanks in advance
>
VoodooJai
>

You need to test against the same things a hacker does - i.e. DELETE.
And you should NEVER be testing on a live system anyway - always test on
a development system, after backing up your databases.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

On Oct 11, 1:27*pm, Jerry Stuckle <jstuck...@attglobal.netwrote:

Voodoo Jai wrote:

>

>

>
You need to test against the same things a hacker does - i.e. DELETE.
And you should NEVER be testing on a live system anyway - always test on
a development system, after backing up your databases.
>
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstuck...@attglobal.net
==================

I have backed up my db but dont know the syntax to use in the form,
could someone show me an example.

On Oct 11, 9:06*am, Voodoo Jai <voodoo...@btinternet.comwrote:

On Oct 11, 1:27*pm, Jerry Stuckle <jstuck...@attglobal.netwrote:
>
>
>
>
>

>

>

>

>

>
I have backed up my db but dont know the syntax to use in the form,
could someone show me an example.- Hide quoted text -
>
- Show quoted text -

I've always wanted to be the one that says google is your friend. Use
your subject title and google it. 1st hit contains tools for testing
it (http://www.zubrag.com/tools/sql-injection-test.php), with about
640,000 other hits also.

Bill H

Voodoo Jai wrote:

I have a page the uses a form to pass a postcode to another page and I
want to test it against an SQL Injection. What would be a safe (i.e NO
DELETING of data ) statement to try and how would I format this to try
in the form.

There are automated tools for testing against SQL injection attacks, and
what they usually do is to perform a query that pauses for 15 seconds or so
before continuing.

Therefore, if the software detects that fetching a page took 15 seconds more
than the average, the injection was successful.


Cheers,
--
----------------------------------
Iván Sánchez Ortega -ivan-algarroba-sanchezortega-punto-es-

Buying Microsoft anymore is like saying: Please, treat me like a two year
old, stifle my creativity and learning, keep me in the dark and feed me
crap, and whatever you do, don't let me question your 'authority'.

>I have a page the uses a form to pass a postcode to another page and I

>want to test it against an SQL Injection. What would be a safe (i.e NO
>DELETING of data ) statement to try and how would I format this to try
>in the form.

As a quick and non-destructive test, if putting a single quote or
double quote in a field provokes a SQL error (you need to be logging
SQL errors or output any such errors on the page. Reporting SQL
errors to the web user (hacker) is *NOT* something you should leave
in production code.), you've potentially got trouble. (Plus, Mr.
O'Brian won't like it when he can't buy from your store). A backslash
at the end of a field is another thing to test. So is a semicolon.
If, instead of a SQL error, you get an error from the input-checking
portion of your code, (e.g. "Quantity must be a number"), you're
catching at least some of the bad input.

>I have limited the field to 10 chars so I know i would have to test it
>with a larger field because a hacker could just rewrite the form and
>use a lerger field for the attempted attack.

Voodoo Jai wrote:

I have this piece of code that was created in conjunction with
Dreamweaver and myself but I'm now a little lost as to what is what.
Could someone enlighten me a little.
>

Do you have any idea what this code does? Or is it just something you
let DreamWeaver create for you? From the looks of it, it's the latter.

You should NEVER trust another package like this to generate secure code
for you. You need to ALWAYS understand what it is doing.

In this case there is way too much extraneous code.

You need to learn PHP and forget about code generators like DreamWeaver.
They're okay for rapid prototyping, but not for a production system,
IMHO.

And if you know PHP, you can generate the correct code faster than you
can in DreamWeaver - and be assured it's safe, because you understand
what's going on.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

On 11 Oct, 10:38, Voodoo Jai <voodoo...@btinternet.comwrote:

I have a page the uses a form to pass a postcode to another page and I
want to test it against an SQL Injection. What would be a safe (i.e NO
DELETING of data ) statement to try and how would I format this to try
in the form.
I have limited the field to 10 chars so I know i would have to test it
with a larger field because a hacker could just rewrite the form and
use a lerger field for the attempted attack.
>
Many thanks in advance
>
VoodooJai

Nice you asked, most people do not bother - they just put magic code
on production servers and hope that no one tries to inject toxic
queries into their system.

That said, if you're unsure of how to protect your system, I'd suggest
you contract it to a professional to sort out.

Good luck!

--
Evans
http://www.jroller.com/evans

"Evans" <onyxtic@gmail.comwrote...
: That said, if you're unsure of how to protect your system, I'd suggest
: you contract it to a professional to sort out.
: Good luck!

Your reply amounts to...

I don't have an answer. Get help from someone else. Good luck.

--
Jim Carlock
You Have More Than Five Senses
http://www.associatedcontent.com/art...ve_senses.html

Jim Carlock wrote:

"Evans" <onyxtic@gmail.comwrote...
: That said, if you're unsure of how to protect your system, I'd suggest
: you contract it to a professional to sort out.
: Good luck!
>
Your reply amounts to...
>
I don't have an answer. Get help from someone else. Good luck.
>

Not at all. His answer is right on the money. SQL injection is a
complicated subject - and way longer than can be handled in a few
newsgroup messages.

We can provide some *guidance* - but not the *understanding* needed to
protect a system.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

I am trying to learn from the code produced by DW and improve on it I
do understand a little about the code but would like some help. Why
cant anyone just try and explain instead of just hindering my learning
process, when I read the PHP manual it all seems a bit daunting and a
more simpler explanation would help yes IDIOT PROOF or laymans terms.

Forever hopeful

Message-ID:
<2a1bd50a-3f1a-4624-aad6-3c409428fe36@m36g2000hse.googlegroups.comfrom
Voodoo Jai contained the following:

>I am trying to learn from the code produced by DW and improve on it I
>do understand a little about the code but would like some help. Why
>cant anyone just try and explain instead of just hindering my learning
>process,

Well, to do that we'd have to spend considerable time looking through
the code and then considerably more time explaining it to you. At the
same time we have no idea of your level of expertise. That kind of
thing is simply not possible in a newsgroup. You need to get a handle
on th basics of programming first and there really is no short cut to
that

>when I read the PHP manual it all seems a bit daunting and a
>more simpler explanation would help yes IDIOT PROOF or laymans terms.

As I said, without the proper grounding it can't be done. I used to
teach an 'Introduction to PHP' course over 30 hours. That was just the
basics, I would have considered database connectivity to be a stage up
from that. Of course, you may pick it up more quickly, but it's still
beyond the scope of this group.

I don't teach the course any more (government cutbacks grr...) but you
are welcome to look at the course notes for the first five lessons which
should give you a better idea of what is going on.

http://www.4theweb.co.uk/phpcourse/
--
Geoff Berrow 0110001001101100010000000110
001101101011011001000110111101100111001011
100110001101101111001011100111010101101011
http://slipperyhill.co.uk - http://4theweb.co.uk

"Geoff Berrow" wrote...
: As I said, without the proper grounding it can't be done...
: ...
: Of course, you may pick it up more quickly, but it's still beyond
: the scope of this group.

Nothing is beyond the scope of any newsgroup. That's just making up
a quick excuse and it probably was stated too quickly.

So to prove that this is NOT beyond the scope of any news group we
need to start by breaking things up into different topics and then
we can go from there. This information should help everyone here,
but please take not, I am NOT a PHP professional, I make no such
claim and the information that I'm about to post I need to learn
and relearn myself and it's to be of benefit to you, to me and to
anyone else that is willing to participate and help out.

In the rhythms of some not so old but popular British singers...

All you need is love,
Everybody,
All you need is love,
Love PHP...

Yeah, yeah, yeah...

Paricipate, anticipate and try
Participate, anticipate, apply

....

Ok, so much for my musical talent. <g>

We need to define things first.

What is "SQL Injection"?

It's an SQL string or some other sort of string which compromises
access to data files. It can be javascript or some other client
side scripting which calls or runs a server-side SQL query. It can
be server-side scripting which does the same but delivers to some-
one that's not supposed to get it. It can be the actual SQL query
itself which either does improper updates, deletions, et al.

So, given those facts, you need to find ways to limit these types
of attacks. I believe the best ways to limit these attacks, involves
making sure the queries you run are the queries you set up and
configured to run and no other type of query.

Most SQL queries end up as dynamic queries, meaning most of the
SQL string is a static string, but there may be a WHERE clause or
a FROM clause that varies depending upon the table and the data
needed.

Try something along the lines of:

1) Identify ALL the query strings you will run. Create a valid list.
Put this list of information into an array of strings to check.

$sSQLStrings = array(
array(0, 'SELECT * FROM MyTable;'),
array(1, 'SELECT PLAYER, TEAM, HOMERS FROM NATIONAL WHERE HOMERS >= '),
array(2, ' GROUP BY TEAM;'),
array(3, 'SELECT PLAYER, TEAM, HOMERS FROM AMERICAN WHERE HOMERS >= '),
array(4, ' GROUP BY TEAM, PLAYER, HOMERS;')
);

Now someone else can help out by providing string comparisons. I'm
weak in my string comparison help, so that will benefit myself.

2) Validate each query you plan to run to make sure it...
a) Comes only from your server,
b) Is a valid query for the server by comparing the SQL string
to predefined lists of strings.

You can use the PHP strstr() function to help you out, and if a
mismatch is found, use the header() function to redirect to some
other site or to a predefined page.

1) Your normal valid regular customers WILL NEVER try such things.
IF they do, perhaps log the details and send it to proper auth-
orities.

2) The people that try such things you don't want at your website,
so redirect them to another website, possibly the FBI or a local
police agency. If you know the local police folks you might be able
to work something out them to see if anything can be enforced.

3) There may be some agencies that identify unscrupulous IP addresses
so this may help, but be careful when using such lists, as you do
not want to make "your real customers" angry, meaning you do not
want to blacklist a real customer.

Something that may make processing faster, includes knowing the maximum
string length of any SQL query and then using that as the first test for
validation, as comparing numbers works a lot faster than comparing char-
for-char sequences. Use PHP's strlen() function to get the length of the
SQL statements.

It requires knowing your SQL queries, knowing about the various cross-site
scripting attacks, and knowing your PHP code.

The PHP documentation seems to discourage regular expressions. So if
anyone can supply "regular expression" string comparisons to run through
such an array as above, or provide some recommended string comparisons
using strcmp or whatnot, and perhaps a comment on if they tested the
results, how they tested the results, this should get this topic started
and be of benefit to everyone here. We can all work through this by
going through each step listed above. I'll be happy to put the details
onto a webpage if no one else wants to do such.

The information here is placed into the public domain.

--
Jim Carlock
You Have More Than Five Senses
http://www.associatedcontent.com/art...ve_senses.html

Jim Carlock wrote:

"Geoff Berrow" wrote...
: As I said, without the proper grounding it can't be done...
: ...
: Of course, you may pick it up more quickly, but it's still beyond
: the scope of this group.
>
Nothing is beyond the scope of any newsgroup. That's just making up
a quick excuse and it probably was stated too quickly.
>

Incorrect. There are some thing which you just can't do in a newsgroup.

So to prove that this is NOT beyond the scope of any news group we
need to start by breaking things up into different topics and then
we can go from there. This information should help everyone here,
but please take not, I am NOT a PHP professional, I make no such
claim and the information that I'm about to post I need to learn
and relearn myself and it's to be of benefit to you, to me and to
anyone else that is willing to participate and help out.
>
In the rhythms of some not so old but popular British singers...
>
All you need is love,
Everybody,
All you need is love,
Love PHP...
>
Yeah, yeah, yeah...
>
Paricipate, anticipate and try
Participate, anticipate, apply
>
...
>
Ok, so much for my musical talent. <g>
>
We need to define things first.
>
What is "SQL Injection"?
>
It's an SQL string or some other sort of string which compromises
access to data files. It can be javascript or some other client
side scripting which calls or runs a server-side SQL query. It can
be server-side scripting which does the same but delivers to some-
one that's not supposed to get it. It can be the actual SQL query
itself which either does improper updates, deletions, et al.
>
So, given those facts, you need to find ways to limit these types
of attacks. I believe the best ways to limit these attacks, involves
making sure the queries you run are the queries you set up and
configured to run and no other type of query.
>
Most SQL queries end up as dynamic queries, meaning most of the
SQL string is a static string, but there may be a WHERE clause or
a FROM clause that varies depending upon the table and the data
needed.
>
Try something along the lines of:
>
1) Identify ALL the query strings you will run. Create a valid list.
Put this list of information into an array of strings to check.
>
$sSQLStrings = array(
array(0, 'SELECT * FROM MyTable;'),
array(1, 'SELECT PLAYER, TEAM, HOMERS FROM NATIONAL WHERE HOMERS >= '),
array(2, ' GROUP BY TEAM;'),
array(3, 'SELECT PLAYER, TEAM, HOMERS FROM AMERICAN WHERE HOMERS >= '),
array(4, ' GROUP BY TEAM, PLAYER, HOMERS;')
);
>
Now someone else can help out by providing string comparisons. I'm
weak in my string comparison help, so that will benefit myself.
>
2) Validate each query you plan to run to make sure it...
a) Comes only from your server,
b) Is a valid query for the server by comparing the SQL string
to predefined lists of strings.
>
You can use the PHP strstr() function to help you out, and if a
mismatch is found, use the header() function to redirect to some
other site or to a predefined page.
>
1) Your normal valid regular customers WILL NEVER try such things.
IF they do, perhaps log the details and send it to proper auth-
orities.
>
2) The people that try such things you don't want at your website,
so redirect them to another website, possibly the FBI or a local
police agency. If you know the local police folks you might be able
to work something out them to see if anything can be enforced.
>
3) There may be some agencies that identify unscrupulous IP addresses
so this may help, but be careful when using such lists, as you do
not want to make "your real customers" angry, meaning you do not
want to blacklist a real customer.
>
Something that may make processing faster, includes knowing the maximum
string length of any SQL query and then using that as the first test for
validation, as comparing numbers works a lot faster than comparing char-
for-char sequences. Use PHP's strlen() function to get the length of the
SQL statements.
>
It requires knowing your SQL queries, knowing about the various cross-site
scripting attacks, and knowing your PHP code.
>
The PHP documentation seems to discourage regular expressions. So if
anyone can supply "regular expression" string comparisons to run through
such an array as above, or provide some recommended string comparisons
using strcmp or whatnot, and perhaps a comment on if they tested the
results, how they tested the results, this should get this topic started
and be of benefit to everyone here. We can all work through this by
going through each step listed above. I'll be happy to put the details
onto a webpage if no one else wants to do such.
>
The information here is placed into the public domain.
>

Which only barely scratches the surface of the subject.

Again - this is way too complex to try to handle in a newsgroup. If you
want to try it on a web page, fine.


--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

"Geoff Berrow" wrote...
: it can't be done...

Jim Carlock wrote:

Nothing is beyond the scope of any newsgroup.

"Jerry Stuckle" wrote:
: Incorrect.

Fee fi fo fum...

--
Jim Carlock
Ralph Nader Only Has A Chance If YOU Vote For Him
http://www.votenader.org/
Want To Install mod_perl?
http://www.microcosmotalk.com/tech/mod_perl/

Jim Carlock wrote:

"Geoff Berrow" wrote...
: it can't be done...
>
Jim Carlock wrote:

>
"Jerry Stuckle" wrote:
: Incorrect.
>
Fee fi fo fum...
>

Yep, you again proved you have no idea what you're talking about.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Jim Carlock wrote:

"Geoff Berrow" wrote...
: it can't be done...
>
Jim Carlock wrote:

>
"Jerry Stuckle" wrote:
: Incorrect.
>
Fee fi fo fum...
>

Oh, and I didn't mention it before - but you have no real understanding
of SQL injection and how to prevent it, either.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

"Jerry Stuckle" wrote...
: Oh, and I didn't mention it before - but you have no real
: understanding of SQL injection and how to prevent it, either.

I make no claims to knowing what SQL injection is. So I agree.
I wanted to help the OP out and get something started discussing
this in an appropriate manner.

: We need to define things first.
:
: What is "SQL Injection"?
:
: It's an SQL string or some other sort of string which compromises
: access to data files. It can be javascript or some other client
: side scripting which calls or runs a server-side SQL query. It can
: be server-side scripting which does the same but delivers to some-
: one that's not supposed to get it. It can be the actual SQL query
: itself which either does improper updates, deletions, et al.

I admit, I concocted that definition out of thin air. I admit I
do not understand the full scope of SQL injection. I admit
there's nothing wrong with that. I accept.

"It's easier to fight for one's principles than to live up to them."
- Alfred Adler (1870 - 1937)

"Tis better to be silent and be thought a fool, than to speak and
remove all doubt."
- Abraham Lincoln (1809 - 1865)

"Ignorance of certain subjects is a great part of wisdom."
- Hugo De Groot (1583 - 1645)


Please correct what's wrong and advise what's right.

--
Jim Carlock
Vote Ralph Nader
(George Bush Groupies: Sarah Palin And John McCain Say So)
http://www.votenader.org/

Jim Carlock wrote:

"Jerry Stuckle" wrote...
: Oh, and I didn't mention it before - but you have no real
: understanding of SQL injection and how to prevent it, either.
>
I make no claims to knowing what SQL injection is. So I agree.
I wanted to help the OP out and get something started discussing
this in an appropriate manner.
>
: We need to define things first.
:
: What is "SQL Injection"?
:
: It's an SQL string or some other sort of string which compromises
: access to data files. It can be javascript or some other client
: side scripting which calls or runs a server-side SQL query. It can
: be server-side scripting which does the same but delivers to some-
: one that's not supposed to get it. It can be the actual SQL query
: itself which either does improper updates, deletions, et al.
>
I admit, I concocted that definition out of thin air. I admit I
do not understand the full scope of SQL injection. I admit
there's nothing wrong with that. I accept.
>
"It's easier to fight for one's principles than to live up to them."
- Alfred Adler (1870 - 1937)
>
"Tis better to be silent and be thought a fool, than to speak and
remove all doubt."
- Abraham Lincoln (1809 - 1865)
>
"Ignorance of certain subjects is a great part of wisdom."
- Hugo De Groot (1583 - 1645)
>
>
Please correct what's wrong and advise what's right.
>

As others have said - this is much too complicated a subject for usenet.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

On Oct 11, 2:38 pm, Voodoo Jai <voodoo...@btinternet.comwrote:

I have a page the uses a form to pass a postcode to another page and I
want to test it against an SQL Injection. What would be a safe (i.e NO
DELETING of data ) statement to try and how would I format this to try
in the form.
I have limited the field to 10 chars so I know i would have to test it
with a larger field because a hacker could just rewrite the form and
use a lerger field for the attempted attack.

http://htmlpurifier.org/

--
<?php echo 'Just another PHP saint'; ?>
Email: rrjanbiah-at-Y!com Blog: http://rajeshanbiah.blogspot.com/

I am trying to learn from the code produced by DW and improve on it I

do understand a little about the code but would like some help. Why
cant anyone just try and explain instead of just hindering my learning
process, when I read the PHP manual it all seems a bit daunting and a
more simpler explanation would help yes IDIOT PROOF or laymans terms.
>
Forever hopeful

If you are willing to learn, I can suggest a clear book on web security:
"Innocent Code" (see http://innocentcode.thathost.com/ )

Others also told you that there are tools for injection testing. For
instance, there are a few firefox plugins that do so. But that does not
take away the fact that you should have a development environment that
can be restored. Try real mayhem on your development PC. Nothing beats
learning from the real thing (and seeing it happen and the experience in
restoring a site).

If you want to see what happens to the database (assuming MySQL here),
enable the query log and use a log viewer (baretail, for instance). You
can then see what is really sent and injected to the database.

Good luck,
--
Willem Bogaerts

Application smith
Kratz B.V.
http://www.kratz.nl/

Betikci Boris wrote:

Use PDO - Php Data Object Class , then forget about sql injection

The right way to say it is "use prepared statements and bound variables".
Remember that PDO allows you to use raw SQL, and that you can use prepared
statements with other database libraries.

Besides that, yes, I'd recommend the original poster to learn how to use
prepared statements using PDO, and forget about scaping SQL ever again.

--
----------------------------------
Iván Sánchez Ortega -ivan-algarroba-sanchezortega-punto-es-

Un ordenador no es un televisor ni un microondas, es una herramienta
compleja.

Simple try the possible way that your page can hack. tip avoid the
special character......










Thanks
Vm