What threatens your site after installing an online consultant and how we deal with it
The services we develop - the online RedHelper consultant and the RedConnect callback work with the personal data of visitors, and therefore require a very careful approach to the security of both the client part of the widget and the server part. In this article, we will talk a little about what types of threats your company can expect after installing various widgets, and how we ensure security in our products.
Disclaimer: If you understand the types of threats and counteract them, you can safely flip the tape further, as you most likely will not learn anything new. But if the abbreviations MITM, XSS or XFRS mean nothing to you, and you have one or more widgets on your site, today you can learn a lot.
Often the site owner may not even realize that the pages of his website on the Internet are infected with something. Of course, recently hosters have successfully started to solve this problem, constantly checking their clients' files for malicious code, but this, as you know, is not a panacea.
To protect the client side, RedHelper widgets are loaded through an iframe. Those who are aware of how this technology works have already understood the essence. But still give an analogy. Iframe can be compared with the embassy. No matter how terrible things happen behind the fence of the embassy, the laws of the state whose flag is developing above the entrance are inside. In the same way, for the RedHelper iframe widget it doesn’t matter what threats and security holes are present on the site - all data is entered into protected input fields, the security of which is ensured by the server part.
We tried to protect RedHelper in the highest category from all available threats. But in order not to relax, we regularly ask well-known Internet security companies to audit our system. To our credit, the results are always at a high level, and we quickly eliminate all the vulnerabilities found.
More specifically, widgets for online consultants and callbacks are subject to 5 types of Internet threats. And below we will tell you how RedHelper confronts them.
The most understandable analogy for this type of vulnerability is wiretapping. But the fact that someone can read or delete messages from the operator and the client is only half the trouble - an attacker can change them of his own free will. Moreover, neither the operator nor the client will be aware of the presence of a "third extra" in the channel.
To protect ourselves from this threat, we use a secure https protocol with mandatory ssl encryption. And even if an attacker somehow gets access to the site’s files and changes the connection of our script from https to http, nothing bad will happen. RedHelper uses Comodo's SSL certificate. This company is one of the world leaders in network security, and its certificates have always been distinguished by good security.
To make it clear how this works, let's turn again to the magic of analogies. Suppose you need to send a parcel to your client by Russian Post. You go to your office, pack the package and send it. But suspecting the postman Pechkin of unfair play, you first hang up the castle on the premise. The key remains with you. Despite his natural curiosity, Pechkin has no choice but to deliver the parcel to the addressee without knowing the contents.
But the addressee also can not open the package, because does not have a key. Therefore, your client hangs his own lock on the parcel, and sends it back. Again without a key. Pechkin, seeing that now there are already two locks on the parcel, grieves, but brings the parcel back. After making sure that both locks are in place and have no signs of hacking, you remove your lock and send the package for the third time. This time the client will be able to open it - with his own key.
Pechkin, of course, had to run, but the contents of the package remained a mystery to him.
The implementation of dangerous SQL code is one of the most dangerous vulnerable sites on the site. The possibility of a successful “parasitism” of an attacker on your site in the event of a successful SQL injection exceeds 99%.
This is a fairly common way of hacking programs and sites that work with databases (databases), and it is based on adding any SQL code to the request.
By injecting the SQL code, an attacker can gain full access to any part of the site - whether it be FTP (threatens with loss or modification of files), email services (the ability to send letters from your domain), the administrative panel of the site (changing any information on the site), or any other components . Not to mention the fact that all information stored in the Database can be stolen.
RedHelper is protected from this threat simply, but very effectively - any executable code that an attacker tries to transfer is converted to plain text, without the possibility of its execution.
The reverse situation is when malicious code is embedded in a web page issued to a visitor. When you open this page, the code will be executed on the client’s computer and will begin interaction with the attacker’s web server.
This is also a very dangerous vulnerability. With its help, an attacker can not only steal cookies (and sometimes even the username and password from the visitor’s personal account on this site), but also arrange a real DDoS attack on your site. This is especially dangerous for sites with high traffic - each new visitor, by the will of the attacker, will create a whole bunch of requests that sooner or later “put” the server.
The protection in this case is exactly the same as with SQL-injection - all the data necessary for the application, widget and server part to be transmitted is transmitted in the form of text, without the possibility of executing commands.
A dangerous attack, which leads to the fact that an attacker can perform a ton of different actions on an unprepared site on behalf of other registered visitors.
What these actions are - whether sending messages, transferring money from one account to another, or changing passwords - depends on the site, but in any case, do not expect anything good.
This attack on site visitors exploits the flaws of the HTTP protocol. When the owner of the online consultant’s account logs into the infected site, a request is sent secretly on his behalf to another server (in our example, to ours), which performs some malicious operation. For example - changing a password or deleting an account.
But to implement this action, you need many factors:
Therefore, any action that may lead to undesirable consequences requires confirmation by the user and is encrypted with a secret key to verify requests, which eliminates the possibility of an attack.
We are very jealous of the security of our product and personal data of customers, and therefore we try to ensure reliability from all sides - on the customer’s website, on our server, and in the operator’s application. Many times we asked companies specializing in Internet security audits to check our services, and each time we passed these tests with honor, getting only a small list of non-critical comments that we fixed in the shortest possible time.
For this we are making great efforts. Our experts constantly take timely necessary measures to improve security - regularly update software and security certificates, monitor all possible options for hacking the system and introduce new degrees of protection. Thanks to which we can proudly say that at the momentRedHelper's online consultant and RedConnect callback are some of the most secure customer feedback systems.
Disclaimer: If you understand the types of threats and counteract them, you can safely flip the tape further, as you most likely will not learn anything new. But if the abbreviations MITM, XSS or XFRS mean nothing to you, and you have one or more widgets on your site, today you can learn a lot.
Widget security
Often the site owner may not even realize that the pages of his website on the Internet are infected with something. Of course, recently hosters have successfully started to solve this problem, constantly checking their clients' files for malicious code, but this, as you know, is not a panacea.
To protect the client side, RedHelper widgets are loaded through an iframe. Those who are aware of how this technology works have already understood the essence. But still give an analogy. Iframe can be compared with the embassy. No matter how terrible things happen behind the fence of the embassy, the laws of the state whose flag is developing above the entrance are inside. In the same way, for the RedHelper iframe widget it doesn’t matter what threats and security holes are present on the site - all data is entered into protected input fields, the security of which is ensured by the server part.
Server side security
We tried to protect RedHelper in the highest category from all available threats. But in order not to relax, we regularly ask well-known Internet security companies to audit our system. To our credit, the results are always at a high level, and we quickly eliminate all the vulnerabilities found.
More specifically, widgets for online consultants and callbacks are subject to 5 types of Internet threats. And below we will tell you how RedHelper confronts them.
MITM - Man In The Middle - The Man in the Middle
The most understandable analogy for this type of vulnerability is wiretapping. But the fact that someone can read or delete messages from the operator and the client is only half the trouble - an attacker can change them of his own free will. Moreover, neither the operator nor the client will be aware of the presence of a "third extra" in the channel.
To protect ourselves from this threat, we use a secure https protocol with mandatory ssl encryption. And even if an attacker somehow gets access to the site’s files and changes the connection of our script from https to http, nothing bad will happen. RedHelper uses Comodo's SSL certificate. This company is one of the world leaders in network security, and its certificates have always been distinguished by good security.
To make it clear how this works, let's turn again to the magic of analogies. Suppose you need to send a parcel to your client by Russian Post. You go to your office, pack the package and send it. But suspecting the postman Pechkin of unfair play, you first hang up the castle on the premise. The key remains with you. Despite his natural curiosity, Pechkin has no choice but to deliver the parcel to the addressee without knowing the contents.
But the addressee also can not open the package, because does not have a key. Therefore, your client hangs his own lock on the parcel, and sends it back. Again without a key. Pechkin, seeing that now there are already two locks on the parcel, grieves, but brings the parcel back. After making sure that both locks are in place and have no signs of hacking, you remove your lock and send the package for the third time. This time the client will be able to open it - with his own key.
Pechkin, of course, had to run, but the contents of the package remained a mystery to him.
SQL-injection - SQL injection.
The implementation of dangerous SQL code is one of the most dangerous vulnerable sites on the site. The possibility of a successful “parasitism” of an attacker on your site in the event of a successful SQL injection exceeds 99%.
This is a fairly common way of hacking programs and sites that work with databases (databases), and it is based on adding any SQL code to the request.
By injecting the SQL code, an attacker can gain full access to any part of the site - whether it be FTP (threatens with loss or modification of files), email services (the ability to send letters from your domain), the administrative panel of the site (changing any information on the site), or any other components . Not to mention the fact that all information stored in the Database can be stolen.
RedHelper is protected from this threat simply, but very effectively - any executable code that an attacker tries to transfer is converted to plain text, without the possibility of its execution.
XSS - Cross Site Scripting - Cross Site Scripting
The reverse situation is when malicious code is embedded in a web page issued to a visitor. When you open this page, the code will be executed on the client’s computer and will begin interaction with the attacker’s web server.
This is also a very dangerous vulnerability. With its help, an attacker can not only steal cookies (and sometimes even the username and password from the visitor’s personal account on this site), but also arrange a real DDoS attack on your site. This is especially dangerous for sites with high traffic - each new visitor, by the will of the attacker, will create a whole bunch of requests that sooner or later “put” the server.
The protection in this case is exactly the same as with SQL-injection - all the data necessary for the application, widget and server part to be transmitted is transmitted in the form of text, without the possibility of executing commands.
XSRF - Cross Site Request Forgery - Cross-Site Request Forgery
A dangerous attack, which leads to the fact that an attacker can perform a ton of different actions on an unprepared site on behalf of other registered visitors.
What these actions are - whether sending messages, transferring money from one account to another, or changing passwords - depends on the site, but in any case, do not expect anything good.
This attack on site visitors exploits the flaws of the HTTP protocol. When the owner of the online consultant’s account logs into the infected site, a request is sent secretly on his behalf to another server (in our example, to ours), which performs some malicious operation. For example - changing a password or deleting an account.
But to implement this action, you need many factors:
- the victim must be authenticated on our server
- the request should not require any confirmation from the user.
- confirmation can be ignored or faked by an attacking script
Therefore, any action that may lead to undesirable consequences requires confirmation by the user and is encrypted with a secret key to verify requests, which eliminates the possibility of an attack.
Finally
We are very jealous of the security of our product and personal data of customers, and therefore we try to ensure reliability from all sides - on the customer’s website, on our server, and in the operator’s application. Many times we asked companies specializing in Internet security audits to check our services, and each time we passed these tests with honor, getting only a small list of non-critical comments that we fixed in the shortest possible time.
For this we are making great efforts. Our experts constantly take timely necessary measures to improve security - regularly update software and security certificates, monitor all possible options for hacking the system and introduce new degrees of protection. Thanks to which we can proudly say that at the momentRedHelper's online consultant and RedConnect callback are some of the most secure customer feedback systems.