1

Topic: Protection at date transmission on GET.

Hello.
I on pages of the site do pass of several variables on GET, that is in URL...?aa=3&bb=4&cd=100
Value of variables is defined either the program or actions of the user, but the user anywhere does not enter anything, only selects the link-picture (value of variables thus changes). Variables only numerical and their size from 0 to 100, i.e. no more than 3 characters.
1 : how to me normally to be protected from any SQL-injections, etc.?
I rummaged on the Internet and while decided to make so:
1) All variables coming on GET undertake through mysql_real_escape_string ();
2) Then variables transit through htmlspecialchars ();
3) Then variables transit through htmlentities ();
4) Then I check variables for the length strlen (). Check: if there are more than 3 characters the variable is equal NULL.
5) Can be to make also check for the size URL. If too big, the user something means entered independently and all variables to equate NULL.
2 : whether normal this protection?
IN ADDITION : At me users enter nothing, only click on different pictures-references, values of variables are as a result formed. But at line URL somebody can import something in addition. On pages of my site in code PHP there are requests to basis MYSQL of type: $zapros=mysql_query ("SELECT * FROM aaa WHERE bb ='cc '); or UPDATE.

2

Re: Protection at date transmission on GET.

pash358 wrote:

as to me normally to be protected

Use PDO and parametric requests.
Whether

pash358 wrote:

normal this protection?

Is not present.

3

Re: Protection at date transmission on GET.

It is necessary to write to basis POST-inquiries

wrote:

2) Then variables transit through htmlspecialchars ();
3) Then variables transit through htmlentities ();

Through these functions it is not necessary to pass variables, before record in basis. Through both functions a variable too never pass (look in a manual that they do).

wrote:

4) Then I check variables for the length strlen (). Check: if there are more than 3 characters the variable is equal NULL.

Abruptly you check a string function that on idea expect as number.

wrote:

But at line URL somebody can import something in addition.

That such was not in basis write POST-inquiries

4

Re: Protection at date transmission on GET.

POST request too not the panacea, after all is the same curl
As already correctly told use prepared statements with parameters, before it  the data.
If at you PHP it is correct  integer by means of a following code

filter_var ($value, FILTER_VALIDATE_INT)! == false;

5

Re: Protection at date transmission on GET.

POST requests decided not to do, since searchers most likely on them do not pass.

6

Re: Protection at date transmission on GET.

Into usage account strlen () for numerical variables:
Tried so:
<? php
$asdfq1=1;
$asdfq2=23;
$asdfq3=100;
$asdfq11=strlen ($asdfq1);
$asdfq22=strlen ($asdfq2);
$asdfq33=strlen ($asdfq3);
echo $asdfq11;
echo $asdfq22;
echo $asdfq33;
?>
The Total: 123
It turns out that strlen () perfectly works and with numerical variables.
Whether it is possible to crack basis through URL if I make check of length of all variables and also I will make check of length URL that the length was within my limit of length?

7

Re: Protection at date transmission on GET.

wrote:

POST request too not the panacea, after all is the same curl

About  heard?

wrote:

POST requests decided not to do, since searchers most likely on them do not pass.

To searchers generally * on POST-inquiries, they index pages.

8

Re: Protection at date transmission on GET.

Kapcha - I in the question wrote that at me users enter nothing, only select the link-picture, from it variables change.
Risk in what break basis can through URL since in it I transfer variables and I collect them through GET:
if (isset ($ _GET [' aaa '])) {$aaa = $ _ GET [' aaa '];} else {$aaa=NULL;}
The Last my question: whether it is possible to crack basis through URL if I make check of length of all variables (my variables numerical and no more than 3 signs), and also I will make check of length URL that the length was within my limit of length?

9

Re: Protection at date transmission on GET.

GET-inquiries are not provided for record in basis. They therefore also are called GET. I initially tried to hint you that you not correctly do a site. In which at passage under the link-picture, something is written to basis. It is necessary to eliminate possibility on a site to the user to write to basis without . And that he sent all c , already it is possible to write, BUT ONLY  this all yours mysql_real_escape_string (); or pdo, looking that use.

10

Re: Protection at date transmission on GET.

I did not understand Something.  is a check that the user not a bot - like so.
YOUR TEXT - "It is necessary to eliminate possibility on a site to the user to write to basis without ."
In my site the user cannot write anything, only if the HACKER writes something in URL. I do not understand as they it do, but like so - that they in URL in a variable instead of automatically generated digit specify any hacker code. Here I also want to learn, if I am simple all variables received on GET I will check up for the length (no more than 3 characters) and I will check up length URL - approximately on my limit that there was no possibility to the hacker to write the big cracking code, whether that will be my basis is protected?

11

Re: Protection at date transmission on GET.

GET or POST has no value.
One only in some cases has not enough check of length for the business logic. For example, in compliance with usage, the variable $ _GET [' action '] should accept values from the list "add", "remove", "edit", and remaining variants with which the user decides to print with dirty hands in an address line of the browser, should cause passage to the error report. How it is possible to replace this check with check of length? Length of length of the text data the most bad (only in the most bad!) an execution variant it is possible and not to do at all - the DBMS produces the error report at attempt to write down more than the data, than the field (try to write down one hundred characters in the field VARCHAR (10), for example) allows.

pash358 wrote:

It turns out that strlen () perfectly works and with numerical variables.

in general yes, works. Only at first, before check, the number from your example will be transformed at line. Esteem about implicit conversions.
And in general that, from GET all comes in the line, so, in a situation strlen ($ _GET [' number ']) conversions it is not required. Can check up with the help var_dump ().
By the way, how strlen' will check numbers on correspondence to a range from-999 to 999 including fractional values, for example? ;-)
In general, do not subtilize in this place. Numbers to compare mathematical methods much easier and more economically - it is more, less, equally etc.

12

Re: Protection at date transmission on GET.

machetero wrote:

it is necessary to write To basis POST-inquiries

has no value. It generally to operation from a DB of the relation has no. And to protection against SQL-injections too.
On a subject - either screening, or parametrized Prepared Statement (or both).
Here only mysql_real_escape_string concerns out-of-date mysql extension and it is remote in the modern versions PHP.
Particulars see here - http://php.net/manual/ru/function.mysql … string.php

13

Re: Protection at date transmission on GET.

pash358 wrote:

In my site the user cannot write anything

cannot write anything to basis?  as idle time though and a bit left method - to leave to the mysql-user through whom the site works, only minimum necessary privileges, and all remaining which records/updates/removals concern - to select. Even, happens, sites work as years in this situation (there was an indescribable case when the customer at all refused to update through full of holes dzhumlu-poltorashku). smile)) smile)) smile))

14

Re: Protection at date transmission on GET.

vkle wrote:

the DBMS produces the error report at attempt to write down more than the data, than the field (try to write down one hundred characters in the field VARCHAR (10), for example) allows.

It will be cut off and will be Warning.
Though, of course, and Warning it is necessary to check.

15

Re: Protection at date transmission on GET.

miksoft wrote:

it is passed...
It will be cut off and will be Warning.

Depending on sql_mode . With STRICT_TRANS_TABLES and-or STRICT_ALL_TABLES - the normal error will be included.

16

Re: Protection at date transmission on GET.

Melkij wrote:

it is passed...
Depending on sql_mode . With STRICT_TRANS_TABLES and-or STRICT_ALL_TABLES - the normal error will be included.

I here too so thought and read this page, but fluently about length of string fields did not find.
And in dock about INSERT about this "truncating" it is written without sending to SQL Mode.

17

Re: Protection at date transmission on GET.

miksoft;
Evidently it is not written (possibly it is meant besides other in "or it might be out of range"), I simply checked up behavior

mysql> set @@ sql_mode ='strict_all_tables';
Query OK, 0 rows affected (0.00 sec)
mysql> create table foo (p varchar (10));
Query OK, 0 rows affected (0.07 sec)
mysql> insert into foo values (' 111oooooooooo1 ');
ERROR 1406 (22001): Data too long for column ' p ' at row 1
mysql> select * from foo;
Empty set (0.00 sec)

18

Re: Protection at date transmission on GET.

Melkij wrote:

evidently it is not written

Well, means, documentation flaws.
Thanks that checked up.

19

Re: Protection at date transmission on GET.

Big all thanks for so numerous answers, BUT all the same I did not receive the full answer to my question:
So, I transfer numerical variables (2 - 5 ) through URL (URL: "... .com/catalog1/page_2.php?aaa=1&bb=100") from one page on another. On accepting page I take the data: if (isset ($ _GET [' aaa '])) {$aaa = $ _ GET [' aaa '];} else {$aaa=NULL;}
All variables numerical and no more than 3 signs (from 0 to 100).
I on accepting page PHP the code put in the beginning check of length of each variable with the help - strlen () (with numbers it works), that is in a condition will be - if less than 3 characters and value is equal from 0 to 100 I appropriate variable value $aaa = $ _ GET [' aaa ']; differently I do a redirect on principal page, i.e. everything that the hacker  in URL - it will be destroyed. Also with the help strlen () I will make check of length URL ($ _SERVER [' REQUEST_URI '] wink, if too big, too most - a redirect on principal page.
the QUESTION: these actions protect from SQL injections, etc. or not? After all check will be in the top of code PHP, as a result at hacker record in URL like is not possible executions of hacker request with SQL-inektsiej type $request=mysql_query ("SELECT aaa FROM bbb WHERE ccc ='bb '"); etc.

20

Re: Protection at date transmission on GET.

In the given specific case (restriction on length of value of any parameter in three characters) quite working variant. Conceptually - the approach rather strange.

21

Re: Protection at date transmission on GET.

pash358 wrote:

BUT all the same I did not receive the full answer to my question

To you already wrote the full answer three times: prepared statements.
Never concatenate the text of request dataful. All. It is all that is required for an exception of SQL-injections.
About check of the data in php I wrote some composition here , I do not want to retell all the same

pash358 wrote:

differently I do a redirect on principal page

There where should be 404 or a redirect on  the page address if is.

22

Re: Protection at date transmission on GET.

pash358 wrote:

So, I transfer numerical variables (2 - 5 ) through URL (URL: "... .com/catalog1/page_2.php?aaa=1&bb=100") from one page on another. On accepting page I take the data: if (isset ($ _GET [' aaa '])) {$aaa = $ _ GET [' aaa '];} else {$aaa=NULL;}
All variables numerical and no more than 3 signs (from 0 to 100).

If you want   - check variables so - if (is_number ($aaa = $ _GET [' aaa ']) && $aaa> = 0 && $aaa = <100) {...}

And it solves your problems.

miksoft wrote:

has no value. It generally to operation from a DB of the relation has no. And to protection against SQL-injections too.

To operation with  it really has no relation. But in a web development GET-inquiries do not use, when it is necessary to write down something in basis is a philosophy of a web.