How to protect your users
$ 100 billion is a huge amount, isn't it? That is how many estimate the global online advertising market in 2012. No need to go far to understand who will get most of this money. Of course, companies like Google, Facebook, Yahoo! etc. But approximately 20% of this amount will receive spammers. This huge amount of money attracts very well-organized business and talented people.
Before Facebook, Odnoklassniki, VKontakte and other social networks, mail was the most popular way to spread spam. But now social networks offer a huge range of tools for the distribution of annoying ads bypassing official channels. I will not go into details about each of them, this is not the topic of this post, I will simply list those that we encounter in Odnoklassniki.
')
The first, and perhaps most important, is spam through private messages. There is nothing easier than sending a message to the social network, is not it?
The second is through comments on various objects (photos, videos, etc.).
The third is invitations to spam groups, or the creation of relevant news and topics in regular groups.
The fourth is spam in the photos, i.e. when the advertising message is written on the photo and then uploaded to the site.
The fifth type is conventionally called “Eroklassnitsa”. They set up an account for a photo of an attractive person in a semi-nude form, set an appropriate status, or add photos with junk ads, and begin to visit.
Given the mass nature of social networks, it is not surprising that the main value for spammers is no longer email addresses, but activated accounts with the right to send messages, post photos and set statuses. How can a spammer get so many accounts? After all, automatic registrations in all major social networks do not work, because the activation of the account requires a phone number. The answer to this question is simple - use the accounts of ordinary people. But how to get access to them?
Unfortunately, many of the problems associated with the illegal use of accounts cannot be solved on the side of the service developers, since they are caused by a low level of user training. Many simply do not know that it is not safe to put simple passwords, that you shouldn’t download and install software from unknown manufacturers, that you don’t need to press the “remember password” checkbox when logging in from publicly available computers. The only thing that a developer can do is to force the use of complex passwords and make security recommendations, increasing the level of user training. But all these problems are only the tip of the iceberg, and they will never lead to massive theft of accounts. There are problems that are much more dangerous for users - for example, the low level of qualifications of the programmer who developed the service, or the testing process that is not well established. Just about such problems and will be discussed in this post.
Some time ago, we seriously attended to the problems of web security by standardizing the internal development and testing processes of the functional to meet the requirements for protecting client data, we managed to greatly reduce the number of vulnerabilities in the portal. Further in the post I want to share with you some of the problems that we faced, and talk about how we solved them.
Cross-site scripting
One of the most common vulnerabilities, allowing you to embed your own code in the body of the document.
How to use it:
Unfortunately, this trouble has not bypassed our resource: a number of vulnerabilities of this type have been found, but all of them are already closed. Such errors occur when neglecting the output of data provided by the user.
Example 1:
The data entered by the user:
How data is output:
When we output custom content directly into the body of a DOM document, we can easily get into a situation in which the browser will perceive the HTML code in the output string as code, and not as a string.
The figure shows that the caption to the photo is depicted as an HTML select object (I replaced the script tag with a select for clarity). The victims of this bug could be anyone who opened the photo, specially signed by the burglar.
Way to fight:
Carefully treat user data, everywhere when displaying in the body of the document, escape dangerous characters. Substitute & <> "'for & amp; & lt; & gt; & quot; & # 39;
Example 2:
The data entered by the user:
How is the data output:
The effect will be the same as in the first example, the methods of protection are the same.
Example 3:
User input:
How is the data output:
The problem was in the musical status: when clicking on the name of the artist, you could substitute your own code.
Way to fight:
As in the two examples before, you need to escape dangerous characters, but for JavaScript they are slightly different. It is necessary to substitute \ / '"for \\ \ / \' \" when outputting
The main rule is to never trust user data.
Cookies
Cookies are the key / value storage in the browser that is used to store user data between sessions and the session ID. By default, JavaScript has access to cookies, which, in the presence of the above vulnerabilities, makes them quite a dangerous place to store data. But before telling you how to protect cookies, I want to pay attention to how they are set.
So, cookies can be set for a specific domain, for all subdomains, and in general for all domains. Almost always you need to set cookies for a specific domain. But sometimes there are cases when it is necessary to be able to use data from cookies during the transition between domains. For example, on Odnoklassniki, when switching between the main site and the mobile version, there is no need to enter the password again. This is done by setting the session cookie to the domain ".odnoklassniki.ru". But for this convenience you can pay dearly. If suddenly a vulnerable subdomain appears at odnoklassniki.ru, then it will be possible to access the cookie of the main portal through this domain.
The best way to protect cookies is to set the HttpOnly attribute to them. This attribute denies access to cookies through JavaScript. Such protection will work in 99% of cases, except when an attacker can send an XMLHttpRequest and receive a response setting cookies. Then, using the getAllResponseHeaders method, you can access them.
But let's continue the conversation about user data. Data can be not only textual, but also in the form of files. If your service allows you to upload files to yourself, then be extremely careful: it is necessary to clearly define those file formats that you allow to upload to your servers, and return these files to the correct headers. Then I will tell you why.
Svg
SVG vector graphics format is one of the dangerous formats for uploading to servers. The file itself may contain javascript. There are 5 ways to connect it validly on the page.
The first 3 ways to connect will execute contained in the JavaScript file. The mere fact of finding such a file on the server entails a certain danger. After all, an attacker with a personal message can send a direct link to a file, opening which, the user will execute the script inside the file.
SVG is not the only potentially dangerous format. Any Flash or HTML document loaded by the user should be added to a separate domain that does not have access to your portal cookies.
Content and character set sniffing
Browsers have such an interesting feature: if the content of the file sent is different from the Content-Type specified in the header, the browser will search for the file internals, what is the actual format. If suddenly the browser finds inside HTML, then it interprets the file as HTML. Those. if your service allows you to upload files in the JPEG and PNG format, and when outputting for any reason exposes the Content-Type: image / jpeg, then returning PNG-files, the browser will look inside to see what the actual file format is. Even if you are optimizing images on the server, this absolutely does not guarantee you that after optimization, HTML will no longer be valid or will somehow change. There are tools that allow you to create an image in such a way that after optimizing the HTML inside the file remains unchanged.
In order to avoid problems, it is necessary to adhere to 3 basic rules:
Clickjacking
We encountered this problem about six months ago, but it is not known how old it really is. We learned about it from posting on one popular blog. The meaning of the attack on Classmates was that our site was embedded in the iframe on a page with a very similar domain to the original. The frame is stretched to full screen. Then the user, having come to a malicious site and being authorized on our site, saw his profile and was completely confident that he was on Odnoklassniki. At that moment, he was shown either a window asking to enter personal data (login and password), or a payment order to transfer money. On many very popular sites on the Internet, this vulnerability is to this day. On Classmates, we closed it as soon as we heard about it.
There are two means of dealing with this problem:
An example of JavaScript that is used on Odnoklassniki:
In our case, we cannot use the header due to some architectural features of the portal, therefore we are protected with JavaScript.
Cross-site request forgery
This is one of the easiest vulnerabilities. It allows you to perform actions on behalf of the user, for example, to send messages, set ratings for photos, etc. Of course, there are no similar problems on Odnoklassniki, but they are observed on some other known resources. For the safety of these resources, I will not voice their names. Let me explain the essence of this problem with an example: let's say you have a very popular forum, and you want to know exactly who goes to your site. You can register an account on Odnoklassniki and embed a link to your profile in an invisible iframe. Then, when logging into your forum, all users authorized on Odnoklassniki will automatically visit you, i.e. perform the action of a visit to the guests, without even realizing it.
On this I, perhaps, finish my rather big post. If someone is interested in this topic, here are a couple of good sources of information:
Book - The Tangled Web by Michal Zalewski
www.owasp.org
Team Odnoklassniki
Before Facebook, Odnoklassniki, VKontakte and other social networks, mail was the most popular way to spread spam. But now social networks offer a huge range of tools for the distribution of annoying ads bypassing official channels. I will not go into details about each of them, this is not the topic of this post, I will simply list those that we encounter in Odnoklassniki.
')
The first, and perhaps most important, is spam through private messages. There is nothing easier than sending a message to the social network, is not it?
The second is through comments on various objects (photos, videos, etc.).
The third is invitations to spam groups, or the creation of relevant news and topics in regular groups.
The fourth is spam in the photos, i.e. when the advertising message is written on the photo and then uploaded to the site.
The fifth type is conventionally called “Eroklassnitsa”. They set up an account for a photo of an attractive person in a semi-nude form, set an appropriate status, or add photos with junk ads, and begin to visit.
Given the mass nature of social networks, it is not surprising that the main value for spammers is no longer email addresses, but activated accounts with the right to send messages, post photos and set statuses. How can a spammer get so many accounts? After all, automatic registrations in all major social networks do not work, because the activation of the account requires a phone number. The answer to this question is simple - use the accounts of ordinary people. But how to get access to them?
Unfortunately, many of the problems associated with the illegal use of accounts cannot be solved on the side of the service developers, since they are caused by a low level of user training. Many simply do not know that it is not safe to put simple passwords, that you shouldn’t download and install software from unknown manufacturers, that you don’t need to press the “remember password” checkbox when logging in from publicly available computers. The only thing that a developer can do is to force the use of complex passwords and make security recommendations, increasing the level of user training. But all these problems are only the tip of the iceberg, and they will never lead to massive theft of accounts. There are problems that are much more dangerous for users - for example, the low level of qualifications of the programmer who developed the service, or the testing process that is not well established. Just about such problems and will be discussed in this post.
Some time ago, we seriously attended to the problems of web security by standardizing the internal development and testing processes of the functional to meet the requirements for protecting client data, we managed to greatly reduce the number of vulnerabilities in the portal. Further in the post I want to share with you some of the problems that we faced, and talk about how we solved them.
Cross-site scripting
One of the most common vulnerabilities, allowing you to embed your own code in the body of the document.
How to use it:
- You can steal cookies or other user data;
- You can change the appearance and behavior of the site;
- You can perform actions on behalf of the user (open windows, send messages, etc.).
Unfortunately, this trouble has not bypassed our resource: a number of vulnerabilities of this type have been found, but all of them are already closed. Such errors occur when neglecting the output of data provided by the user.
Example 1:
The data entered by the user:
name = “ /> ”;How data is output:
${name}When we output custom content directly into the body of a DOM document, we can easily get into a situation in which the browser will perceive the HTML code in the output string as code, and not as a string.
The figure shows that the caption to the photo is depicted as an HTML select object (I replaced the script tag with a select for clarity). The victims of this bug could be anyone who opened the photo, specially signed by the burglar.
Way to fight:
Carefully treat user data, everywhere when displaying in the body of the document, escape dangerous characters. Substitute & <> "'for & amp; & lt; & gt; & quot; & # 39;
Example 2:
The data entered by the user:
name=” '>/ ”;How is the data output:
The effect will be the same as in the first example, the methods of protection are the same.
Example 3:
User input:
name=”Madonna'); doSomeKillingAndStealing(' ”; name=”Madonna'); doSomeKillingAndStealing(' ”;How is the data output:
SearchThe problem was in the musical status: when clicking on the name of the artist, you could substitute your own code.
Way to fight:
As in the two examples before, you need to escape dangerous characters, but for JavaScript they are slightly different. It is necessary to substitute \ / '"for \\ \ / \' \" when outputting
The main rule is to never trust user data.
Cookies
Cookies are the key / value storage in the browser that is used to store user data between sessions and the session ID. By default, JavaScript has access to cookies, which, in the presence of the above vulnerabilities, makes them quite a dangerous place to store data. But before telling you how to protect cookies, I want to pay attention to how they are set.
So, cookies can be set for a specific domain, for all subdomains, and in general for all domains. Almost always you need to set cookies for a specific domain. But sometimes there are cases when it is necessary to be able to use data from cookies during the transition between domains. For example, on Odnoklassniki, when switching between the main site and the mobile version, there is no need to enter the password again. This is done by setting the session cookie to the domain ".odnoklassniki.ru". But for this convenience you can pay dearly. If suddenly a vulnerable subdomain appears at odnoklassniki.ru, then it will be possible to access the cookie of the main portal through this domain.
The best way to protect cookies is to set the HttpOnly attribute to them. This attribute denies access to cookies through JavaScript. Such protection will work in 99% of cases, except when an attacker can send an XMLHttpRequest and receive a response setting cookies. Then, using the getAllResponseHeaders method, you can access them.
But let's continue the conversation about user data. Data can be not only textual, but also in the form of files. If your service allows you to upload files to yourself, then be extremely careful: it is necessary to clearly define those file formats that you allow to upload to your servers, and return these files to the correct headers. Then I will tell you why.
Svg
SVG vector graphics format is one of the dangerous formats for uploading to servers. The file itself may contain javascript. There are 5 ways to connect it validly on the page.
- Object
- Iframe
- Embed
- Img
- CSS background
The first 3 ways to connect will execute contained in the JavaScript file. The mere fact of finding such a file on the server entails a certain danger. After all, an attacker with a personal message can send a direct link to a file, opening which, the user will execute the script inside the file.
SVG is not the only potentially dangerous format. Any Flash or HTML document loaded by the user should be added to a separate domain that does not have access to your portal cookies.
Content and character set sniffing
Browsers have such an interesting feature: if the content of the file sent is different from the Content-Type specified in the header, the browser will search for the file internals, what is the actual format. If suddenly the browser finds inside HTML, then it interprets the file as HTML. Those. if your service allows you to upload files in the JPEG and PNG format, and when outputting for any reason exposes the Content-Type: image / jpeg, then returning PNG-files, the browser will look inside to see what the actual file format is. Even if you are optimizing images on the server, this absolutely does not guarantee you that after optimization, HTML will no longer be valid or will somehow change. There are tools that allow you to create an image in such a way that after optimizing the HTML inside the file remains unchanged.
In order to avoid problems, it is necessary to adhere to 3 basic rules:
- always return files with a Content-Type that it actually has
- do not use text / plain and application / octet-stream, since for these formats, browsers always look inside
- set the X-Content-Options: nosniff header. This header prevents browsers from looking into the content.
Clickjacking
We encountered this problem about six months ago, but it is not known how old it really is. We learned about it from posting on one popular blog. The meaning of the attack on Classmates was that our site was embedded in the iframe on a page with a very similar domain to the original. The frame is stretched to full screen. Then the user, having come to a malicious site and being authorized on our site, saw his profile and was completely confident that he was on Odnoklassniki. At that moment, he was shown either a window asking to enter personal data (login and password), or a payment order to transfer money. On many very popular sites on the Internet, this vulnerability is to this day. On Classmates, we closed it as soon as we heard about it.
There are two means of dealing with this problem:
- header prohibiting the opening of the site in the frame (X-FRAME-OPTIONS = DENY)
- Javascript code
An example of JavaScript that is used on Odnoklassniki:
try{ top.location.toString(); if(top != self) { throw new Error(''); } } catch(e){ top.location = location; } In our case, we cannot use the header due to some architectural features of the portal, therefore we are protected with JavaScript.
Cross-site request forgery
This is one of the easiest vulnerabilities. It allows you to perform actions on behalf of the user, for example, to send messages, set ratings for photos, etc. Of course, there are no similar problems on Odnoklassniki, but they are observed on some other known resources. For the safety of these resources, I will not voice their names. Let me explain the essence of this problem with an example: let's say you have a very popular forum, and you want to know exactly who goes to your site. You can register an account on Odnoklassniki and embed a link to your profile in an invisible iframe. Then, when logging into your forum, all users authorized on Odnoklassniki will automatically visit you, i.e. perform the action of a visit to the guests, without even realizing it.
On this I, perhaps, finish my rather big post. If someone is interested in this topic, here are a couple of good sources of information:
Book - The Tangled Web by Michal Zalewski
www.owasp.org
Team Odnoklassniki
Source: https://habr.com/ru/post/150439/
All Articles