Cross-Site Scenario Attack Prevention

Cross-Site Scenario Attack Prevention

Today we will answer the common question of customers, which is gaining popularity every day. What is an intersite scenario attack? And let's look at ways to prevent cross-site scripted attacks.

What is an intersite scenario attack?

A cross-site scripting attack is the injection of malicious code into a web page that will be secretly executed on the user's computer. The specificity of the intersite scenario attack is that with the help of the embedded code segment you can get access to the session or authorized user data. With the subsequent access to manage the data of this user.

Examples of intersite scenario attack

Suppose we need to give the opportunity to comment on a blog or article, without worrying that the JS or Html code contained in the comment will create problems. We cannot restrict user input, because with this form, he must freely express his thoughts about the article. But, we can remove the possibility of inserting sections with HTML + JS because, in fact, no one except the attackers will need to insert parts of the code into the comment. We could create a check for the availability of these sites and just not allow them to be published. But think about how many conditions we would have to use. Heaps of!

Ways to prevent cross-site scripting attacks

How to prevent cross-site scripted attack? The standard PHP method comes to the rescue. With the help of the htmlentities () function we will be able to film the sections of the malicious insert. More information about this feature can be found in the PHP documentation.
In standard PHP methods, there are a couple of functions with which you can screen HTML. The simplest is htmlspecialchars () - it emits four characters (<> “and &). But it is the htmlentities () function that converts any characters that have an equivalent HTML entity. There is one caveat, when converting, this function is wielded by the UTF-8 character set, so we will get a section of ordinary characters instead of inserting malicious code. Thus, we will be able to limit the introduction of malicious code sections in the comments of our blog. But do not forget that this is only one of the possible cross-site attacks of the “code injection” type. There are still DDOS attacks, in this article we tried to explain how to check the server site for vulnerabilities.

  • Ihor FIlippov

    Привет все очень круто!


  • Add a comment