There is a certain site, the input data from the user of which is checked, say, by regexp'om.
For responsiveness of the web interface, data is checked by Javascript on the client side, to prevent hacking - additionally on the server side(php).Regexp is the same.There is an idea to put it into a json file, accessible via http, and load it into Javascript.
How dangerous is it, because there is no 100% confidence in the full coverage of all possible XSS?
Those.knowing regexp imkho easier to pick up malicious input parameters than not knowing.But most of the CMS, forums, etc.open source for some reason are not very afraid of this.
  • Maybe I for nothing on XSS mentioned. More precisely, it is necessary to check the input data on the client side and also on the server side and give an error message if they are not in the expected format, go beyond the limits, etc. Because the check parameters are the same, there is no point in duplicating them in php and Javascript (you can forget something during corrections). Therefore, it is thought to put these parameters into a separate file. In any case, these parameters will be on the client... – Rural Tetris Feb 22 '14 at 11:12

4 Answers 4

Do not be afraid to show the user how you are checking the input data.Hiding them in no way enhances security.
What is the relationship between regular and XSS?
On the user side, logic validation.On the server side, the logic is re-validated and the corresponding screening/conversion for the integrity and safety of this data.If in the database the saving is prepared statements, the output in HTML is htmlspecialchars, the output in JSON is json_encode, the output is still somewhere — the corresponding conversions for this particular format.
  • For example, validity of e-mail, links, checking that a number is entered. Regexp is taken as a general case. Something like the options parameter in filter_var – Rural Tetris Feb 22 '14 at 10:38
You have a mess in your head.

There is an idea to put it into a json file, accessible via http, and load it into Javascript.
Bad idea.

How much is it dangerous, because there is no 100% confidence in full coverage of all possible XSS?
Those.knowing regexp imkho easier to pick up malicious input parameters than not knowing.But most of the open source CMS, forums, etc., are not very afraid of this for some reason.
If the data is displayed in the form that was entered, the protection is elementary(roughly speaking, protection is not needed at all, it’s just enough output data).
If the data will be processed(BB, markdown, HTML), then there is the possibility of a mistake in the handler.Therefore, it is necessary to use the popular open source implementation - bugs are quickly found and fixed.
  • Maybe inaccurately expressed, clarified the question. – Rural Tetris Feb 22 '14 at 11:12
Like most hamsters, aftor confuses data validation and output formatting.

As correctly noted by the post above, these two things have nothing to do with each other.At all.Is it only the fact that if you rely on validation of incoming, then you can fly into a second-order injection, just like in the case of SQL.

Therefore, the validation should be left as it is, and the formatting should be carried out on an automatic basis, by means of the template engine.At the same time, considering the environment in which the data is output.For SQL, HTML, JS and many other different output options, the formatting should be DIFFERENT
  • I apologize for the mistake in terminology, the question is not in output filtering, but in input validation. – Rural Tetris Feb 22 '14 at 11:27
  • and thanks for the hamster – Rural Tetris Feb 22 '14 at 11:27