This page has been robot translated, sorry for typos if any. Original content here.

Навіщо Cookie потрібен?

Справа в тому, що HTTP-протокол - одноразовий, якщо так можна висловитися. Тобто кожен раз заходячи на сторінку, користувач починає спочатку, що б він не вводив, і які зміни б не робив. Cookie допомагає створити ілюзію, що користувача пам'ятають на сайті. Користувачеві не потрібно вводити сотню раз одну і ту ж інформацію від сторінки до сторінки, і навіть від сесії до сесії, вона зберігається у нього на диску. До зручності можна віднести ще й те, що цю інформацію користувач завжди зможе змінити у себе на диску "на льоту". В Cookie також можуть зберігатися інші різноманітні дані. Наприклад, кількість відвідувань якийсь сторінки, час відвідувань. За допомогою cookie не складає труднощів зробити маленький органайзер або кошик у віртуальному магазині.

Cookie багато хто не люблять через її небезпечність. Багато аналітиків говорять, що це не проблема, і нічого поганого з допомогою даної технології зробити не можна. Я з цим глибоко не згоден, якщо хтось може читати інформацію з файлу (ів) cookie, то це вже небезпечно. Наведу чисто теоретичні приклади, які, при бажанні, не важко втілити в реальність.
1. Припустимо, користувач зайшов на поштову сайт, заповнив форму з login'ом і паролем, які записалися в cookie, нехай навіть через Secure Socket Level. Зломщик написав листа користувачу в форматі HTML з параметрами читання cookie з паролями. Прочитавши cookie, HTML-файл або запитує у користувача дозвіл відіслати інформацію зломщикові, де користувача можна обдурити помилкової написом а ля "Помилки в сценаріях Javascript!". Навіть досить досвідчений користувач не замислюючись натисне OK, після чого login і пароль відішле зломщикові. Або зломщик може додати 0-ой фрейм, де буде тимчасово міститися інформація з cookie, яка при відповіді на лист, вставлятиметься в кінець листа. Все це неважко зробити за допомогою FORM і Javascript.
2. Приклад з віртуальним магазином. Припустимо, ми маємо гіпотетичний магазин shop.provider.com. Здійснюючи покупки в даному магазині, користувач зберігає інформацію в cookie. Паралельно або до заходу в магазин, користувач зайшов на гіпотетичну сторінку зломщика hacker.provider.com, де змінено установки cookie віртуального магазину. Зломщик може змінити кількість покупок, ім'я, адреса, і все те, що зберігається в даному cookie. Я думаю, вам би не сподобалося, якщо до ваших покупок додали пару моніторів або відвезли ваші покупки не тому користувачеві. Зробити це досить просто, якщо мати сторінку в домені магазину другого або третього рівня.

Отже, для користувача технологія cookie є кілька файлів в папці% WINDOWS% \ Cookies (за замовчуванням в Internet Explorer), або всього один файл cookie.txt (якщо це Netscape Navigator і інші браузери). Сайти періодично додають інформацію в cookie і її ж забирають. Природно, в специфікаціях Cookie передбачені деякі елементи захисту.

- Всього Cookies може бути не більше 300.
- Кожен Cookie не може бути більше 4kb.
- З одного домену другого рівня (плюс підрівні) не може бути отримано більше 20 Cookies.
- Інформація з Cookie одного домену другого рівня (плюс підрівні) не може бути прочитана іншими доменами.
- Якщо документ кешується, то інформація про cookie НЕ кешується.
- Інформація в \ з Cookie може передавати за допомогою протоколу SSL.
- Якщо ліміт вичерпується, перші записи видаляються. Якщо Cookie стає більше 4kb, перші байти вирізаються.

Для того щоб контролювати запис і читання cookie можна використовувати спеціальні утиліти, але ця функція є майже у всіх Firewall наприклад Agnitum Outpost, так само в проге A4Proxy можна двома клацаннями миші заборонити всі cookie.