„Втвърдяване“ на бисквитките в OpenCart

Никой не обича твърди бисквитки, но що се касае до сигурността в интернет, все повече внимание се отделя на cookies — малките текстови файлове, които се съхраняват в паметта на браузера на потребителя, за да улеснят работата на сайта.

Работата е там, че тези бисквитки понякога се използват, за да съхраняват важна информация — например, информация за потребителската сесия. Ако не бъдат обезопасени по подходящия начин, неразрешен достъп до бисквитките може да доведе до копиране на потребителската сесия и оттам до теч на информация.

В контекста на електронните магазини на платформата OpenCart, бисквитките се използват за следните неща:

• установяване на PHP сесия
• запаметяване на валутата на магазина
• запаметяване на езика на интерфейса на магазина
• маркиране на съгласие с общите условия и политиката на поверителност на сайта през т.н. ‘cookie notice’ поле

Изброените по-горе бисквитки, с изключение на тази за PHP сесията, представляват прости флагове и не биха могли да се използват за извличане на особено полезна информация. PHP сесията обаче е важна, понеже ако нейната бисквитка бъде открадната, неупълномощеното лице би могло да възпроизведе сесията на нищо неподозиращия потребител, да разгледа неговия профил, история на поръчките и т.н.

Ако сайтът разполага с механизъм за съхранение на разплащателни средства, копирането на сесия на теория може да позволи на нападателя да направи поръчка, да заплати за нея със записаната карта и да посочи различен адрес за доставка. Въпреки че няма да може да открадне самата информация за картата (тя се съхранява в сайта само под формата на токен), подобна атака ще причини финансови щети и репутационни загуби на търговеца.

Европейското и националното законодателство, както и добрите административни практики изискват от собствениците на web сайтове да полагат всички разумни усилия, за да обезопасяват подопечните си сайтове от всякакви течове на информация. Все повече инструменти за проверка на сигурността на сайтовете като Hardenize.com и SecurityHeaders.com включват и тестове относно сигурността на бисквитките.

Тези мерки не са сложни за изпълнение. Към момента на писане на тази статия, бисквитките могат да се защитят по няколко начина, описани подробно в статията ‘Tough Cookies’ в сайта на популярния експерт по информационна сигурност Скот Хелми. Резюмирано накратко от там, мерките са следните:

Установяване на бисквитката в режим HttpOnly

Този флаг служи да инструктира браузера, че достъпът до съдържанието на бисквитките трябва да бъде забранен за скриптове, които се изпълняват локално (в браузера на клиента). Тази защита предпазва от атаки тип Cross-Site Scripting (XSS), които имат за цел именно да откраднат сесията на потребителя, както писахме по-горе. Флагът HttpOnly се поддържа от всички съвременни браузери и когато той е вдигнат, при опит за прочитане на бисквитката с JavaScript, браузерът ще върне празен стринг, вместо нейното съдържание.

Установяване на бисквитката в режим Secure

Този флаг инструктира браузера, че бисквитките могат да се изпращат само по криптирана връзка (https), за да не може тяхното съдържание да бъде прихванато по време на преноса. Също както HttpOnly, този флаг се поддържа от всички съвременни браузери.

Установяване на бисквитката в режим Same-Site

За разлика от HttpOnly и Secure, спецификацията Same-Site все още е в режим на разработка (draft), но въпреки това поддръжката за нея е достатъчно разпространена, така че има смисъл да се внедри. Нейната функция е да предпазва потребителите от атаки тип Cross-Site Request Forgery (CSRF) и Cross-Site Script-Inclusion (XSSI).

CSRF позволява на атакуващия да използва браузера на потребителя, за да изпраща заявки към друга страница. Ако посетите компрометирана страница, е възможно браузерът ви да получи заявка да се свърже с Facebook, при което той ще отвори връзка с www.facebook.com и ще изпрати всички бисквитки, принадлежащи на Facebook. Нападателят няма достъп до съдържанието на вашите бисквитки, нито може да види реакцията на Facebook, но тази информация дори не му е необходима, за да постигне своята цел (например, без ваше знание да кара браузера ви да like-ва някаква страница…)

XSSI атаките са сходни на CSRF, но позволяват да се зареждат ресурси чрез таговете <script> и <link> и да предизвикват различен отговор в зависимост от съдържанието на бисквитките.

Флагът Same-Site има две положения: Lax и Strict, като Strict се подразбира. Разликата между двата метода е, че при Lax съдържанието на бисквитката не се изпраща при употреба на несигурни методи като POST, докато при Strict бисквитки не се изпращат при никакви заявки между домейните. При определени ситуации настройката Strict може да създаде проблеми, но в контекста на OpenCart и WooCommerce е окей да се използва именно тя за максимална сигурност.

Префикси на бисквитките

Последният защитен механизъм, който ще обсъдим, е префиксът към името на дадена бисквитка. Възможни са два вида префикси, като всеки от тях диктува определено поведение спрямо бисквитката.

Ако името на бисквитката започва със __Secure-
Браузерът ще създаде такава бисквитка само ако едновременно: е вдигнат флагът Secure (описан по-горе) и самата бисквитка се транспортира по надежден канал (т.е. https). В противен случай браузерът ще откаже да съхрани бисквитката, със съответните последствия за зареждането на сайта.

Ако името на бисквитката започва със __Host-
Браузерът ще създаде бисквитка при условията за ползване на префикса __Secure-, като допълнително ще ограничи изпращането на бисквитката само до конкретния хоста (т.е. ако хостът от адрес https://example.com генерира Host бисквитка, нейното съдържание ще се изпраща обратно само при заявки, постъпващи от конкретния хост (заявки от https://subdomain.example.com например, ще бъдат отхвърляни).

Настройване на флаговете за бисквитките

Вдигането на флаговете HttpOnly, Secure и Same-Site може да стане по няколко начина:

Чрез web сървъра: посредством Set-Cookie header в общия config файл на сървъра, или за всеки виртуален хост чрез неговия индивидуален config файл, например ето така:

Header always edit Set-Cookie ^(.*)$ $1;HttpOnly;Secure;SameSite=strict

Този начин е препоръчителен за използване, понеже настройва глобално хоста за всички бисквитки. Ако обаче използвате споделен хостинг, е твърде вероятно да не можете да променяте конфигурационния файл на vhost-а и затова ще трябва да „пипнете“ всяка бисквитка по отделно чрез корекция на командата, използвана за нейното създаване.

Чрез PHP: с помощта на функцията setcookie.

В платформата на OpenCart бисквитките се установяват по различен начин в зависимост от това коя версия се ползва:

OpenCart 2.0.x до 2.2.x

language: чрез index.php файла в кореновата директория на сайта.
currency: чрез файла system/library/currency.php

OpenCart 2.3.x и 3.0.x

language | currency: чрез файла catalog/controller/startup/startup.php

Независимо от това кой файл редактирате, самата команда за генериране на бисквитките language и currency е еднаква. Най-напред търсите този код:

setcookie('language', $code, time() + 60 * 60 * 24 * 30, '/', $request->server['HTTP_HOST']);

и го променяте така:

setcookie('language', $code, time() + 60 * 60 * 24 * 30, '/', $request->server['HTTP_HOST'], true, true);

По идентичен начин се коригира командата, с която се генерира бисквитката за валута:

setcookie('currency', $code, time() + 60 * 60 * 24 * 30, '/', $request->server['HTTP_HOST']);

става на

setcookie('currency', $code, time() + 60 * 60 * 24 * 30, '/', $request->server['HTTP_HOST'], true, true);

Коригиране на сесийните бисквитки

Бисквитката за PHP сесия също се установява по леко различен начин в зависимост от версията на платформата.

OpenCart 2.0.x до 2.2.x

Редактира се файлът system/library/session.php. Търсите този код:

if (isset($_COOKIE[session_name()]) && !preg_match('/^[a-zA-Z0-9,\-]{22,40}$/', $_COOKIE[session_name()])) {

и го променяте така:

if (isset($_COOKIE[session_name('__Secure-PHPSESSID')]) && !preg_match('/^[a-zA-Z0-9,\-]{22,40}$/', $_COOKIE[session_name()])) {

OpenCart 2.3.x и следващи версии

Считано от версия 2.3, OpenCart преустановява използването на бисквитки за следене на PHP сесиите и вместо това ги записва в базата данни на магазина. Като цяло това е по-надеждно и производително решение, особено за магазини с по-голяма посещаемост, но задължава администратора на сайта да следи големината на таблицата sessions, понеже платформата не извършва garbage collection система за автоматично изтриване на изтекли сесии, както прави PHP.

Редактира се файлът system/framework.php. Търсите този код:

setcookie($config->get('session_name'), $session->getId(), ini_get('session.cookie_lifetime'), ini_get('session.cookie_path'), ini_get('session.cookie_domain'));

и го променяте така:

setcookie($config->get('session_name'), $session->getId(), ini_get('session.cookie_lifetime'), ini_get('session.cookie_path'), ini_get('session.cookie_domain'), true, true);

Краен резултат

Ако сте свършили всичко, както трябва, би трябвало Hardenize.com и SecurityHeaders.com да докладват, че бисквитките са сигурни.

Както написахме в самото начало, тази мярка сама по себе си не е панацея за информационната сигурност, но въпреки това смятаме, че тези настройки попадат в графата „задължителни“. Минималните подобрения на сигурността на различни места водят до по-добър кумулативен ефект и ни позволяват да бъдем по-уверени, че сме направили максимума, за да защитим своите потребители от неприятности.