To avoid XSS injections, you need to use strip_tags() , htmlspecialchars() , htmlentities() when displaying user input. I think it's better to use strip_tags() and \ or htmlentities() .

If this output is read from the database, then the data must first be written to the database and then questions arise:

What and in what sequence to apply to the data that will be written to the database?

2.1 About stmt requests I know and understand http://ua2.php.net/manual/ru/mysqli.quickstart.prepared-statements.php

2.2 I want to know the approximate variants of the data processing order before saving to the table.

2.2.1 First, stip_tags() and \ or htmlentities() -> (if you want to keep some html formatting in safe mode)

2.2.2 then mysqli_real_escape_string() -?

2.2.3 Replacing % and _ ( $more_escaped = addcslashes($escaped, '%_'); )

2.2.4 "tags", type [b] [code] [i] [url] to use for processing BEFORE data output.

  1. The network was a wonderful article about sql-injections using \ based on multibyte encodings. Who knows about this method of sql injection?

Yes, one more thing, single quotes are two types:

`and '

some of them are not screened, need to check?

If it is not screened, then it is necessary to screen separately (as with _ and % )?

Closed due to the fact that the question is too general for the participants Dmitriy Simushev , Visman , PashaPash ♦ 16 May '16 at 9:01 .

Please correct the question so that it describes the specific problem with sufficient detail to determine the appropriate answer. Do not ask a few questions at once. See “How to ask a good question?” For clarification. If the question can be reformulated according to the rules set out in the certificate , edit it .

  • one
    Possible duplicate question: Competent protection against SQL-Injection - Visman
  • In your question, XSS and SQL-Injection are considered simultaneously. These are two completely different problems. Decide which one you will fight. The first is repaired by screening (encoding) the text in the output (and has no relation to the database at all). The second is using parameterized queries (well, or crutches in the form of sql screening), and, accordingly, has no relation to HTML. - PashaPash ♦
  • me and that and that interests. But I already figured it out. - root_x Povierennyy

1 answer 1

If possible, the entire text is recorded in the database without any changes, at least so that you can restore the order of events, who, what, for what purpose, downloaded and what effect you wanted to achieve. Therefore, before recording, the text is, if possible, not filtered (even if it contains frankly destructive information), but is only screened. If you insert strings or numbers directly into a SQL query string, the strings must be escaped, and the digits lead to a numeric value in order to avoid SQL injections.

True, the extensions mysqli and PDO, which allow to insert parameterized queries, prepare or stmt-queries, have recently become widespread. for example

 $query = "SELECT * FROM catalogs WHERE catalog_id = :catalog_id"; $cat = $pdo->prepare($query); $cat->execute(['catalog_id' => 1]);

In this type of query you do not insert a SQL injection. In principle, the problem of SQL injections is solved by such queries as a class — use and you may not know anything about them (just do not insert interpolation parameters into a string).

Otherwise, in the request form

 SELECT name FROM users WHERE id = $id

You can insert a $id view

 $id = '0 UNION SELECT password WHERE id = 432';

As a result, a request will be generated.

 SELECT name FROM users WHERE id = 0 UNION SELECT password WHERE id = 432

Which, instead of the username, displays the password of the user with the identifier 432. This is not the only type of SQL injection, but I repeat the problem is solved as a class by using prepare-queries. Those. in this case, it is not even necessary to screen and somehow specially process the data - the extension will take care of this itself.

Back quotes are typical mainly for the SQL dialect of MySQL, they frame the table and column names so that the optimizer is not confused if the name of the column or field matches the keyword - it is almost impossible to do anything with them. At least, the SQL injections with their participation are not known - they can not be specially escaped - only problems with editing when you can escape them several times. There is no danger from them, at least for the database.

Similarly, relative to % and _ in text fields, they are completely safe. These are LIKE search patterns and they are not on the template side, but in the text.

  • Parameterized queries completely solve the problem of scl-inge? But I think that this is not enough. --- - root_x Povierennyy
  • one
    @root_xPovierennyy Why do you think so? Parameterized queries exclude editing in the SQL source specified in principle. - Mike
  • dont know. I can’t believe (hardly believe) that this "danger" is so easily solved. In addition to the skl-introduction there are many other ways to program yourself a big hassle (at least the same xss). BUT i'm going to ipirodt :). Something is being created ... - root_x Povierennyy
  • In matters of security, it is better not to rely on return, but to check everything explicitly. And it would be good to write automatic tests to be sure that with further support of the project you will not be broken by the defense. - cheops