Please explain why cookies are considered not safe? I think that this is quite a safe thing, I just want to make sure of it. Cookies on the slipped link from the desired site can not be pulled out. Ways to start a sniffer on the client’s computer are also no longer necessary for this issue because you need to climb the computer to get the user’s cookie to the JS site that the attacker needs. The JS code should be executed on this site, and this will hack the hosting itself. In the general case, a cookie for two people distant from each other where one wants to steal the cookie from the other is quite a safe thing. If a client is sent a link to a free hosting where document.cookie is executed and sent to whoever needs via ajax, then the cookies of all sites will not be sent, a cookie will go to that domain where the client got.

Hacking hosting, getting on the client's computer does not apply to the question, otherwise (slip the link) and anything else except the two conditions above is possible, in this variant the cookie is completely safe, isn't it?

  • Where did you read that they are considered unsafe? - tutankhamun
  • Cook is safe provided that it is installed by the server (and not the browser via javascript) with the secure and httponly flags enabled and the site only works using the https protocol. When you receive a cookie on the server, you need to check it, as it may contain absolutely not the data that you expect. - Visman
  • tutankhamun, to be honest, I just heard that everyone scolded the kuppi just from the general opinion, and the opinions of friends, and from the articles here, habrahabr.ru/post/272187 , I just want to make sure that the cookie just does not work out to get it just confirmed and there really aren't any vulnerabilities in the general simple case, and softtime.ru/forum/read.php?id_forum=4&id_theme=64900 , but that’s just stealing cookies from the site itself :) - Konstantin Alekseev

2 answers 2

The question of whether cookies are safe is incorrect. Cookies themselves do not pose any threat.

This or that scheme of their use can be safe or vulnerable.

For example, a specific implementation of an authentication or authorization system that uses cookies may well be insecure. There are just a lot of common mistakes that developers make using cookies. These errors cause vulnerabilities in systems that use cookies (and not in the cookies themselves).

The article mentioned by you in no way states that the "cookies are bad and unsafe", and it is not proposed to abandon them. This article discusses the specific cases of errors and omissions in the implementations of the systems working with cookies . And a combination of certain shortcomings already creates a vulnerability that can be exploited.

Now about the typical threats.

You argue that it is not so easy to get cookies out.

First, in order to run JS on the site, it is not necessary to "hack hosting". Often it’s enough to find an XSS vulnerability , a great many techniques.

Tip: Using Content Security Policy greatly facilitates protection against XSS, CSSI, and clickjacking.

Indeed, as Konstantin Alekseev mentioned, it is useful to use httpOnly-cookies, for those cases when access from JS is not needed, so that even if a malicious script is executed, it does not have access to the value of the cookie.

But, again, this is not 100% protection against reading cookies. The cookie information with the "httpOnly" flag comes in the http header. If the site is subject to HTTP Response Splitting , the response from the server can be modified (to disable the httpOnly flag), and the old cookie values ​​are shifted into the response body. Here is a minimalistic example .

Please note that not only the theft of cookies with secret data is dangerous .

Cookies also have inter -site request forgery (CSRF) vulnerabilities. In this case, “theft of cookies” is not supposed: an attacker simply needs some of the methods to force the user's browser to make one or another request to the attacked server (and the user's browser will substitute the cookie itself, the attacker does not need to know them). If the server is vulnerable to a CSRF vulnerability, then an attacker can perform an action (buying, changing data, post) on behalf of the user, without knowing the meaning of the cookie itself.

Therefore, when performing requests to change a state, cookies are usually used in conjunction with csrf tokens. There are different types of security implementations with csrf-tokens (including sometimes not very successful: in the article you cited from the habr, a vulnerability was shown in the double submit cookies scheme, which appeared because of the features of the third-party system).

Look also at such vulnerabilities as session fixation , which are also indirectly related to cookies, but do not require their “theft”.

In the end, even some kind of SQLi attack vector can be inserted by an attacker directly into the value of cookies, manually creating a request to your site. And, if you do not filter / do not screen the contents of cookies, and then substitute it in this form in the sql query string, it turns out "unsafe": the base of your resource may go, in some cases sqli lead to remote code execution.

Are all cookies guilty? Not. But, as you see, it is also impossible to relax, the dangers are literally everywhere. :)

    In modern browsers, cookies are a fairly safe place to store small amounts of data if your site is not subject to XSS attacks. In addition, it is possible to write data to cookies that cannot be read using Javascript.

    • Absolutely, too, I think so, there is still the possibility to send cookies after installing the extension in the browser, but this also needs to be tried, here any cookie will go where it is needed, for this, some sites check the ban on creating directories in the extensions folder - Konstantin Alekseev