Secure set

Содержание

Как сделать ваш код на Python быстрым и асинхронным с Sanic

Secure set

В преддверии старта курса “Python Developer. Professional” подготовили традиционный перевод полезной статьи.

Всем привет, в этой статье я расскажу о создании простых асинхронных проектов на фреймворке Sanic.

Введение

Sanic – это очень похожий на Flask открытый веб-сервер и веб-фреймворк на Python с более чем 10К звездами, который быстро развивается. Он позволяет использовать синтаксис async/await, который был добавлен в Python 3.5, помогая делать ваш код неблокирующим и быстрым.

У Sanic очень хорошая документация, которая пишется членами сообщества для самого сообщества.

Цель проекта – предложить простой способ запуска высокопроизводительного HTTP-сервера, который легко создавать, расширять и в конечном итоге масштабировать.

Требования

Перед тем, как начать, давайте установим несколько пакетов и убедимся, что у нас есть все необходимое для создания проекта.

Примечание:Исходный код есть на моем github. Каждый шаг отражен в отдельном коммите. 

Предустановки

  • Python3.6+
  • pipenv (или любой другой установщик пакетов)
  • PostgreSQL (для баз данных, можно также взять MySQL или SQLite)

Пакеты

  • secure – это легкий пакет, который добавляет заголовки безопасности и атрибуты файлов cookie для веб-фреймворков Python.
  • environs – библиотека Python для синтаксического анализа переменных окружения. Она позволяет хранить конфигурацию отдельно от кода, в соответствии с методологией приложения двенадцати факторов.
  • sanic-envconfig – это расширение, которое помогает вам переносить командную строку и переменные окружения в вашу конфигурацию Sanic.
  • databases – это пакет Python, который позволяет создавать запросы с использованием мощного языка выражений SQLAlchemy Core и обеспечивает поддержку PostgreSQL, MySQL и SQLite.

Давайте создадим пустой каталог и инициализируем пустой Pipfile.

pipenv  – python python3.6

Установите все необходимые пакеты, используя приведенные ниже команды pipenv.

pipenv install sanic secure environs sanic-envconfig

Для базы данных:

pipenv install databases[postgresql]

На выбор postgresql, mysql, sqlite.

Структура

Теперь давайте создадим несколько файлов и папок, где мы будем писать код.

├── .env├── Pipfile├── Pipfile.lock├── setup.py└── project ├── __init__.py ├── __main__.py ├── main.py ├── middlewares.py ├── routes.py ├── settings.py └── tables.py

Мы будем использовать файл setup.py, чтобы сделать папку project доступной как пакет в нашем коде.  

from setuptools import setup setup( name='project',)

Установка…

pipenv install -e .

В файле .env мы будем хранить глобальные переменные, такие как строку подключения к базе данных. 

_main_.py создан для того, чтобы наш пакет project мог выполняться из командной строки.

pipenv run python -m project

Инициализация

Давайте сделаем первый вызов в файле main.py

from project.main import init init()

Это начало нашего приложения. Теперь нам нужно создать функцию init в файле main.py.

from sanic import Sanic app = Sanic(__name__) def init(): app.run(host='0.0.0.0', port=8000, debug=True)

Просто создав app из класса Sanic, мы можем запустить его, указав хост, порт и необязательный аргумент с ключевым словом debug.

Запускаем…

pipenv run python -m projectSanic console output

При успешном запуске приложения Sanic вывод будет выглядеть именно так. Если в браузере вы откроете http://0.0.0.0:8000, то увидите:

Error: Requested URL / not found

Мы еще не создали никаких маршрутов, так что все в порядке. Мы займемся этим дальше.

Настройка

Теперь мы можем модифицировать среду и настройки. Нам нужно добавить некоторые переменные в файл .env, прочитать их и передать в файл конфигурации приложения Sanic.

Файл .env

DEBUG=TrueHOST=0.0.0.0POST=8000

Конфигурация…

from sanic import Sanicfrom environs import Envfrom project.settings import Settingsapp = Sanic(__name__)def init(): env = Env() env.read_env() app.config.from_object(Settings) app.run( host=app.config.HOST, port=app.config.PORT, debug=app.config.DEBUG, auto_reload=app.config.DEBUG, )

Файл settings.py

from sanic_envconfig import EnvConfig class Settings(EnvConfig): DEBUG: bool = True HOST: str = '0.0.0.0' PORT: int = 8000

Обратите внимание, что я добавил необязательный аргумент auto_reload, который активирует или деактивирует автоматическую перезагрузку.

База данных

Сейчас самое время настроить базу данных.

Одно замечание о базе данных прежде, чем мы пойдем дальше. 

Пакет databases использует asyncpg, который является асинхронным интерфейсом библиотеки для работы с PostgreSQL. Работает достаточно быстро. Результаты вы можете посмотреть ниже.

Мы будем использовать двух слушателей Sanic, для которых укажем операции подключения и отключения от базы данных. Вот слушатели, которых мы будем использовать:

  • afterserverstart
  • afterserverstop

Файл main.py

from sanic import Sanicfrom databases import Databasefrom environs import Envfrom project.settings import Settingsapp = Sanic(__name__)def setup_database(): app.db = Database(app.config.DB_URL) @app.listener('after_server_start') async def connect_to_db(*args, **kwargs): await app.db.connect() @app.listener('after_server_stop') async def disconnect_from_db(*args, **kwargs): await app.db.disconnect()def init(): env = Env() env.read_env() app.config.from_object(Settings) setup_database() app.run( host=app.config.HOST, port=app.config.PORT, debug=app.config.DEBUG, auto_reload=app.config.DEBUG, )

И еще кое-что. Нам нужно указать DB_URL в настройках проекта и среде.

Файл .env

DEBUG=TrueHOST=0.0.0.0POST=8000DB_URL=postgresql://postgres:postgres@localhost/postgres

И файл settings.py:

from sanic_envconfig import EnvConfig class Settings(EnvConfig): DEBUG: bool = True HOST: str = '0.0.0.0' PORT: int = 8000 DB_URL: str = ''

Убедитесь, что DB_URL верный и ваша база данных запущена. Теперь вы можете получить доступ к базе данных с помощью app.db. Более подробную информацию можно получить в следующем разделе.

Таблицы

Теперь у нас есть подключение к нашей базе данных, и мы можем попробовать сделать несколько SQL-запросов.

Давайте объявим таблицу в файле tables.py с помощью SQLAlchemy.

import sqlalchemy metadata = sqlalchemy.MetaData() books = sqlalchemy.Table( 'books', metadata, sqlalchemy.Column('id', sqlalchemy.Integer, primary_key=True), sqlalchemy.Column('title', sqlalchemy.String(length=100)), sqlalchemy.Column('author', sqlalchemy.String(length=60)),)

Сейчас я предполагаю, что вы уже сделали миграцию базы данных с таблицей books в ней. Для создания миграций баз данных я рекомендую использовать Alembic – легкий и простой инструмент, который можно использовать вместе с инструментарием базы данных SQLAlchemy для Python.

Теперь мы можем использовать любые запросы SQLAlchemy. Ниже представлены несколько примеров.

# Executing manyquery = books.insert()values = [ {“title”: “No Highway”, “author”: “Nevil Shute”}, {“title”: “The Daffodil”, “author”: “SkyH. E. Bates”},]await app.db.execute_many(query, values) # Fetching multiple rowsquery = books.select()rows = await app.db.fetch_all(query) # Fetch single rowquery = books.select()row = await app.db.fetch_one(query)

Маршруты

Теперь нам нужно настроить маршруты. Давайте перейдем в routes.py и добавим новый маршрут для books.

from sanic.response import jsonfrom project.tables import books def setup_routes(app): @app.route(“/books”) async def book_list(request): query = books.select() rows = await request.app.db.fetch_all(query) return json({ 'books': [{row['title']: row['author']} for row in rows] })

Конечно же, чтобы все работало, нам нужно в init вызвать setup_routes.

from project.routes import setup_routesapp = Sanic(__name__)def init(): … app.config.from_object(Settings) setup_database() setup_routes(app) …

Делаем запрос…

$ curl localhost:8000/books{“books”:[{“No Highway”:”Nevil Shute”},{“The Daffodil”:”SkyH. E. Bates”}]}

Middleware

Может проверим заголовки ответов и посмотрим, можем ли мы добавить или исправить там что-нибудь?

$ curl -I localhost:8000Connection: keep-aliveKeep-Alive: 5Content-Length: 32Content-Type: text/plain; charset=utf-8

Как видите, в вопросах безопасности нам есть что улучшить. Есть несколько пропущенных заголовков, таких как X-XSS-Protection, Strict-Transport-Security и т.д. Поэтому давайте разберемся с ними с помощью дополнительного ПО и пакетов secure.

Файл middlewares.py

from secure import SecureHeaders secure_headers = SecureHeaders() def setup_middlewares(app): @app.middleware('response') async def set_secure_headers(request, response): secure_headers.sanic(response)

Настройка middleware в файле main.py:

from project.middlewares import setup_middlewaresapp = Sanic(__name__)def init(): … app.config.from_object(Settings) setup_database() setup_routes(app) setup_middlewares(app) …

А вот и результат:

$ curl -I localhost:8000/booksConnection: keep-aliveKeep-Alive: 5Strict-Transport-Security: max-age=63072000; includeSubdomainsX-Frame-Options: SAMEORIGINX-XSS-Protection: 1; mode=blockX-Content-Type-Options: nosniffReferrer-Policy: no-referrer, strict-origin-when-cross-originPragma: no-cacheExpires: 0Cache-control: no-cache, no-store, must-revalidate, max-age=0Content-Length: 32Content-Type: text/plain; charset=utf-8

Как я и обещал в самом начале, для каждого раздела этой статьи есть отдельный репозиторий на github. Надеюсь, этот небольшой туториал поможет вам начать работу с Sanic. В фреймворке Sanic есть еще много неисследованных функций, с ними вы можете познакомиться в документации.

Подробнее о курсе. Посмотреть запись открытого урока “Расширение Python на C: заставляем Python ползти быстрее” можно здесь.

Источник: https://habr.com/ru/company/otus/blog/529420/

HTTP cookie

Secure set

HTTP cookie — это небольшой фрагмент данных, отправляемый сервером браузеру пользователя, который тот должен сохранить и отсылать обратно с каждым новым запросом этому серверу.

Это, в частности, позволяет узнать, с одного ли браузера пришли оба запроса (например, для аутентификации пользователя).

Они запоминают информацию о состоянии для протокола HTTP, который сам по себе этого делать не умеет.

Cookie используются, главным образом, для:

  • Управления сеансом (логины, корзины для интернет-магазинов)
  • Персонализации (пользовательские предпочтения)
  • Мониторинга (отслеживания поведения пользователя)

До недавнего времени cookie принято было использовать в качестве хранилища информации на стороне пользователя. Но из-за того, что cookie пересылаются с каждым запросом, они могут сильно снижать производительность (особенно в мобильных устройствах). Теперь качестве хранилищ данных на стороне пользователя вместо них можно использовать localStorage, sessionStorage и IndexedDB.

Создание cookie

Получив HTTP-запрос, вместе с ответом сервер может отправить заголовок Set-Cookie. Cookie запоминаются браузером и посылаются серверу с каждым новым запросом. Можно задать срок действия cookie, а также срок его жизни, после которого cookie не будет отправляться. Также можно указать ограничения на путь и домен, то есть указать, в течении какого времени и к какому сайту оно отсылается.

Заголовки Set-Cookie и Cookie

Заголовок Set-Cookie используется для отправки cookie с сервера на клиентское приложение (браузер). Этот заголовок с сервера дает клиенту указание сохранить cookie.

Set-Cookie: = HTTP/1.1 200 OKDate: Sun, 07 Oct 2018 13:31:17 GMTServer: Apache/2.4.34 (Win64) mod_fcgid/2.3.9X-Powered-By: PHP/7.1.10Expires: Thu, 19 Nov 1981 08:52:00 GMTCache-Control: no-store, no-cache, must-revalidatePragma: no-cacheSet-Cookie: PHPSESSID=m2iut9i59p73ld1c5q9j49c6t0; path=/Set-Cookie: visitor=0d3749f09d222bea3b8f163937eb9bf1; Max-Age=31536000; path=/Set-Cookie: lastvisit=1538919655; path=/Vary: Accept-EncodingContent-Encoding: gzipKeep-Alive: timeout=5, max=100Connection: Keep-AliveTransfer-Encoding: chunkedContent-Type: text/html; charset=utf-8 ……….

Теперь, с каждым новым запросом к серверу, при помощи заголовка Cookie браузер будет возвращать серверу все сохраненные ранее cookies:

GET /catalog HTTP/1.1Host: www.server.comUser-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:62.0) Gecko/20100101 Firefox/62.0Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.5,en;q=0.3Accept-Encoding: gzip, deflateReferer: http://www.server.com/Cookie: PHPSESSID=m2iut9i59p73ld1c5q9j49c6t0; visitor=0d3749f09d222bea3b8f163937eb9bf1; lastvisit=1538919655Connection: keep-aliveUpgrade-Insecure-Requests: 1

Сессионные, постоянные и безопасные cookie

Сессионные cookie, установка которых выглядит так:

Set-Cookie: lastvisit=1538919655

удаляются при закрытии клиента, то есть существуют только на протяжении текущего сеанса, поскольку атрибуты Expires или Max-Age для них не задаются.

Постоянные cookie удаляются не с закрытием клиента, а при наступлении определенной даты (атрибут Expires) или после определенного интервала времени (атрибут Max-Age):

Set-Cookie: visitor=0d3749f09d222bea3b8f163937eb9bf1; Max-Age=31536000 Set-Cookie: visitor=0d3749f09d222bea3b8f163937eb9bf1; expires=Mon, 07-Oct-2019 13:44:02 GMT

Безопасные cookie отсылаются на сервер только если запрос выполняется по протоколу SSL и HTTPS. Начиная с Chrome 52 и Firefox 52, незащищенные сайты (HTTP) не могут создавать куки с флагом secure.

Set-Cookie: PHPSESSID=m2iut9i59p73ld1c5q9j49c6t0; Secure

HttpOnly cookie не доступны из JavaScript через свойство document.cookie и через XMLHttpRequest, что помогает избежать межсайтового скриптинга (XSS).

Рекомендуется устанавливать этот флаг для тех cookie, к которым не требуется обращаться через JavaScript.

В частности, если куки используются только для поддержки сеанса, то в JavaScript они не нужны, так что в этом случае следует устанавливать флаг HttpOnly:

Set-Cookie: PHPSESSID=m2iut9i59p73ld1c5q9j49c6t0; Secure; HttpOnly

Область видимости cookie

Директивы domain и path определяют область видимости куки, то есть те URL, к которым куки могут отсылаться.

  • Атрибут domain указывает хосты, к которым отсылаться куки. Если он не задан, то по умолчанию берется доменная часть документа (но без поддоменов). Если домен указан явно, то поддомены всегда включены. Например, если задано domain=server.com, то куки включены и в поддоменах, например, в blog.server.com.
  • Атрибут path указывает URL, который должен быть в запрашиваемом ресурсе на момент отправки заголовка. Символ «/» интерпретируется как разделитель разделов, подразделы также включаются. Если задано path=/docs, то подходят и такие пути, как /docs, /docs/web, /docs/web/http.

Работа с cookie из JavaScript

Куки можно создавать через JavaScript при помощи свойства document.cookie. Если флаг HttpOnly не установлен, то и доступ к существующим cookies можно получить через JavaScript.

// получить cookieconsole.log(document.cookie); PHPSESSID=m2iut9i59p73ld1c5q9j49c6t0; visitor=0d3749f09d222bea3b8f163937eb9bf1; lastvisit=1538919655 // установить cookiedocument.cookie = “some_name=some_value”;console.log(document.cookie); PHPSESSID=m2iut9i59p73ld1c5q9j49c6t0; visitor=0d3749f09d222bea3b8f163937eb9bf1; lastvisit=1538919655; some_name=some_value

Функция getCookie()

Следующая функция возвращает cookie с именем name:

// возвращает cookie с именем name, если есть, если нет, то undefinedfunction getCookie(name) { var matches = document.cookie.match( new RegExp(“(?:|; )” + name.replace(/([\.$?*|{}\(\)\[\]\\\/\+])/g, '\\$1') + “=([;]*)”) ); return matches ? decodeURIComponent(matches[1]) : undefined;}

Функция setCookie()

function setCookie(name, value, options) { options = options || {}; var expires = options.expires; if (typeof expires == “number” && expires) { var d = new Date(); d.setTime(d.getTime() + expires * 1000); expires = options.expires = d; } if (expires && expires.toUTCString) { options.

expires = expires.toUTCString(); } value = encodeURIComponent(value); var updatedCookie = name + “=” + value; for (var propName in options) { updatedCookie += “; ” + propName; var propValue = options[propName]; if (propValue !== true) { updatedCookie += “=” + propValue; } } document.

cookie = updatedCookie;}

Функция deleteCookie()

function deleteCookie(name) { // удаляем вызовом setCookie() с датой в прошлом setCookie( name, “”, {expires: -1} )}

Работа с cookie из PHP

Для сохранения cookie в браузере пользователя используется функция setcookie():

bool setcookie( string $name, string $value, int $expire, string $path, string $domain, bool $secure, bool $httponly);

Может принимать следующие параметры:

  • name: имя cookie, которое будет использоваться для доступа к его значению.
  • value: значение или содержимое cookie — любой алфавитно-цифровой текст не более 4 кБайт.
  • expire (необязательный параметр): срок действия, после которого cookie уничтожаются. Если данный параметр не установлен или равен 0, то уничтожение cookie происходит после закрытия браузера.
  • path (необязательный параметр): путь к каталогу на сервере, для которого будут доступны cookie. Если задать «/», cookie будут доступны для всего сайта. Если задать, например, /docs, cookie будут доступны из этого каталога и всех его подкаталогов (/docs/web, /docs/web/http). По умолчанию значением является текущий каталог, в котором устанавливаются cookie.
  • domain (необязательный параметр): задает домен, для которого будут доступны cookie. Если это домен второго уровня, например, server.com, то cookie доступны для всего сайта server.com, в том числе и для его поддоменов типа blog.server.com. Если задан поддомен blog.server.com, то cookie доступны только внутри этого поддомена.
  • secure (необязательный параметр): указывает на то, что значение cookie должно передаваться по протоколу HTTPS. Если задано true, cookie от клиента будет передано на сервер, только если установлено защищенное соединение. По умолчанию параметр равен false.
  • httponly (необязательный параметр): если равно true, cookie будут доступны только через HTTP протокол. То есть cookie в этом случае не будут доступны из JavaScript. По умолчанию параметр равен false.

Чтобы получить cookie, можно использовать глобальный массив $_COOKIE. Для удаления cookie достаточно в качестве срока действия указать какое-либо время в прошлом:

setcookie('lastvisit', '', time() – 3600);

Чтобы к идентификатору сессии PHPSESSID не было доступа из JavaScript, нужно отредактировать файл php.ini:

; Name of the session (used as cookie name).; http://php.net/session.namesession.name = PHPSESSID ; Whether or not to add the httpOnly flag to the cookie, which makes; it inaccessible to browser scripting languages such as JavaScript.; http://php.net/session.cookie-httponlysession.cookie_httponly = 1

Можно также использовать функцию ini_set(), чтобы установит флаг HttpOnly уже во время выполнения приложения:

ini_set('session.cookie_httponly', 1);session_start();

Еще одни способ изменить флаг HttpOnly — вызов функции session_set_cookie_params() перед session_start():

session_set_cookie_params(/*…*/);session_start();

Установить флаг Secure для PHPSESSID из php.ini:

; http://php.net/session.cookie-securesession.cookie_secure = 1

Установить флаг во время работы приложения:

ini_set('session.cookie_secure', 1);session_start(); session_set_cookie_params(/*…*/);session_start();

Поиск: Cookie • HTTP • HTTPS • JavaScript • PHP • Web-разработка • expire • httponly • localStorage • php.ini • secure • sessionStorage • setcookie

03.05.2020

Утилита tcpdump

Утилита tcpdump есть практически в любом дистрибутиве Linux. Она позволяет перехватывать все пакеты трафика и сохранять их в файл для дальнейшего анализа. Если утилита вызвана для прослушивания некоторого интерфейса, она переводит его в «неразборчивый режим». В этом режиме интерфейс ловит вообще все пакеты…

Источник: https://tokmakov.msk.ru/blog/item/200

Secure Electronic Transaction (SET) Protocol

Secure set

Secure Electronic Transaction (SET) Protocol

Secure Electronic Transaction or SET is a system which ensures security and integrity of electronic transactions done using credit cards in a scenario. SET is not some system that enables payment but it is a security protocol applied on those payments.

It uses different encryption and hashing techniques to secure payments over internet done through credit cards.

SET protocol was supported in development by major organizations Visa, Mastercard, Microsoft which provided its Secure Transaction Technology (STT) and NetScape which provided technology of Secure Socket Layer (SSL).

SET protocol restricts revealing of credit card details to merchants thus keeping hackers and thieves at bay. SET protocol includes Certification Authorities for making use of standard Digital Certificates X.509 Certificate.

Before discussing SET further, let’s see a general scenario of electronic transaction, which includes client, payment gateway, client financial institution, merchant and merchant financial institution.

Requirements in SET :
SET protocol has some requirements to meet, some of the important requirements are :

  • It has to provide mutual authentication i.e., customer (or cardholder) authentication by confirming if the customer is intended user or not and merchant authentication.
  • It has to keep the PI (Payment Information) and OI (Order Information) confidential by appropriate encryptions.
  • It has to be resistive against message modifications i.e., no changes should be allowed in the content being transmitted.
  • SET also needs to provide interoperability and make use of best security mechanisms.

Participants in SET :
In the general scenario of online transaction, SET includes similar participants:

  1. Cardholder – customer
  2. Issuer – customer financial institution
  3. Merchant
  4. Acquirer – Merchant financial
  5. Certificate authority – Authority which follows certain standards and issues certificates( X.509V3) to all other participants.
  • Provide Authentication
    • Merchant Authentication – To prevent theft, SET allows customers to check previous relationships between merchant and financial institution. Standard X.509V3 certificates are used for this verification.
    • Customer / Cardholder Authentication – SET checks if use of credit card is done by an authorized user or not using X.509V3 certificates.
  • Provide Message Confidentiality : Confidentiality refers to preventing unintended people from reading the message being transferred. SET implements confidentiality by using encryption techniques. Traditionally DES is used for encryption purpose.
  • Provide Message Integrity : SET doesn’t allow message modification with the help of signatures. Messages are protected against unauthorized modification using RSA digital signatures with SHA-1 and some using HMAC with SHA-1,

Dual Signature :The dual signature is a concept introduced with SET, which aims at connecting two information pieces meant for two different receivers :

Order Information (OI) for merchant

Payment Information (PI) for bank

You might think sending them separately is an easy and more secure way, but sending them in a connected form resolves any future dispute possible. Here is the generation of dual signature:

Where, PI stands for payment information OI stands for order information PIMD stands for Payment Information Message Digest OIMD stands for Order Information Message Digest POMD stands for Payment Order Message Digest H stands for Hashing E stands for public key encryption KPc is customer's private key || stands for append operation Dual signature, DS= E(KPc, [H(H(PI)||H(OI))])

Purchase Request Generation :

The process of purchase request generation requires three inputs:

  • Payment Information (PI)
  • Dual Signature
  • Order Information Message Digest (OIMD)

The purchase request is generated as follows:

Here, PI, OIMD, OI all have the same meanings as before. The new things are : EP which is symmetric key encryption Ks is a temporary symmetric key KUbank is public key of bank CA is Cardholder or customer Certificate Digital Envelope = E(KUbank, Ks)

 
Purchase Request Validation on Merchant Side :The Merchant verifies by comparing POMD generated through PIMD hashing with POMD generated through decryption of Dual Signature as follows:Since we used Customer private key in encryption here we use KUc which is public key of customer or cardholder for decryption ‘D’. 

Payment Authorization and Payment Capture :

Payment authorization as the name suggests is the authorization of payment information by merchant which ensures payment will be received by merchant. Payment capture is the process by which merchant receives payment which includes again generating some request blocks to gateway and payment gateway in turn issues payment to merchant.

Attention reader! Don’t stop learning now. Get hold of all the important CS Theory concepts for SDE interviews with the CS Theory Course at a student-friendly price and become industry ready.

Источник: https://www.geeksforgeeks.org/secure-electronic-transaction-set-protocol/

Обеспечение безопасности платежных систем на основе протокола SET

Secure set

Как было показано в предыдущей главе, одним из основных недостатков протокола SSL с точки зрения возможности его использования в платежных системах с применением пластиковых карт является система сертификации, не позволяющая аутентифицировать покупателя, а также аутентифицирующая продавца исключительно по URL. Кроме этого для осуществления платежей покупателю необходимо высылать продавцу свои платежные реквизиты, что позволяло недобросовестному продавцу осуществить мошенничество по отношению к покупателю.

Для устранения указанных недостатков VISA International совместно с MasterCard был разработан протокол SET – Secure Electronic Transaction[3GPP TR 21.905: Vocabulary for 3GPP Specifications.], ориентированный на платежные системы с использованием пластиковых карт.

Протокол SET помимо четырех сущностей, характерных для любой платежной системы – покупателя, продавца, банка-эмитента и банка-эквайера, вводит две новые – центр сертификации (ЦС, CA – Certificate Authority) и платежный шлюз (Payment Gateway) ( рис. 11.1).

Рис. 11.1. Взаимодействие участников платежной транзакции при помощи протокола SET

Функция центров сертификации заключается в формировании, распространении, поддержке и аннулировании сертификатов; платежный шлюз обеспечивает поддержку сертификатов и взаимодействие с платежной системой.

Перед началом транзакции покупатель, продавец и платежный шлюз должны получить сертификаты, чтобы быть аутентифицированными в системе.

Все данные передаются по открытым каналам связи в зашифрованном виде, при этом непосредственного считывания информации с пластиковой карты не происходит – держатель карты аутентифицирует себя при помощи соответствующего сертификата.

Взаимодействие эмитента и эквайера осуществляется при помощи защищенной межбанковской сети.

Система сертификации[3GPP TR 21.905: Vocabulary for 3GPP Specifications.] в протоколе SET представляет собой пятиуровневую структуру, представленную на рис. 11.2.
Рис. 11.2. Система сертификации в протоколе SET

Головной центр сертификации (RCA – Root CA) выполняет следующие функции:

  • формирование сертификатов для брендовых ЦС;
  • генерация сертификатов для собственных открытых ключей;
  • формирование и рассылка списка отозванных сертификатов (CRL – Certificate Revocation List) для брендовых ЦС.

Брендовые центры сертификации (BCA – Brand CA) являются ЦС платежных систем. По аналогии с головным ЦС они формируют сертификаты для ЦС более низкого уровня и помогают в рассылке CRL. Геополитические центры сертификации (GCA – Geo-Political CA) предназначены для упрощения процедуры взаимодействия брендового ЦС и географически распределенных центров сертификации владельцев карт, а именно:

  • ЦС держателя карты (CCA – Cardholder CA);
  • ЦС продавца (MCA – Merchant CA);
  • ЦС платежного шлюза (PCA – Payment Gate CA).

Центры сертификации владельцев карт занимаются формированием, распространением, поддержкой и аннулированием сертификатов.

Сертификат представляет собой электронный документ, удостоверяющий подлинность указанного в нем открытого ключа. В соответствии со стандартом X.509.

3 (ISO/IEC 9594-8[EMV ICC Specification for Payment Systems.]) сертификат имеет определенные поля, представленные в табл. 1.1.

Таблица 11.1. Основные поля сертификата

ПолеОписание
Versionверсия протокола Х.509 (равна 3)
Serial Numberуникальный серийный номер сертификата
Algorithm Identifierалгоритм, используемый для подписи сертификата
Issuer Nameимя ЦС, выпустившего сертификат
Validity.NotBeforeдата начала действия сертификата
Validity.NotAfterдата окончания действия сертификата
Subject Nameимя владельца сертификата
Algorithmалгоритм, в соответствии с которым сгенерирован открытый ключ
Subject Public Key Infoзначение сертифицируемого открытого ключа
Signatureподпись

Кроме указанных полей в сертификате присутствуют значения, необходимые для применения перечисленных в сертификате алгоритмов.

В протоколе SET предусмотрено четыре типа ключей, используемых участниками платежных транзакций:

  • ключ для подписи сообщения (Digital Signature Key);
  • ключ для шифрования данных (Data Encipherment Key);
  • ключ для подписи сертификата (Certificate Signature Key);
  • ключ для подписи списка отозванных сертификатов (CRL Signature Key).

Право на обладание определенным ключом предоставляется участникам протокола, перечисленным в табл. 11.2.

Таблица 11.2. Принадлежность ключей участникам протокола SET

Участник протоколаТип ключаКлюч для подписи сообщенияКлюч для шифрования данныхКлюч для подписи сертификатаКлюч для подписи CRL
Держатель карты+
Продавец++
Платежный шлюз++
ЦС держателя карты+++
ЦС продавца+++
ЦС платежного шлюза++++
Геополитический ЦС++
Брендовый ЦС++
Головной ЦС++

Так же как и SSL, SET является надстройкой над транспортным уровнем, однако, в отличие от SSL, шифрует не все данные, предаваемые транспортному уровню, а только те, что относятся к платежным транзакциям. Все остальные данные, передаваемые транспортному уровню, проходят без изменений ( рис. 11.3).

увеличить изображение
Рис. 11.3. Структура протокола SET

Для осуществления подобного взаимодействия используется специальная программа электронной коммерции, на которую возлагаются следующие функции:

  • поиск товаров и услуг в Интернете;
  • согласование параметров заказа (цена, срок доставки);
  • формирование заказа;
  • подготовка и передача параметров, необходимых SET для организации защищенного взаимодействия участников платежной транзакции.

Как было сказано ранее, протокол SET разрабатывался для того, чтобы исключить передачу платежных реквизитов в открытом виде продавцу.

Однако любой заказ предполагает передачу инструкций как продавцу, так и банку. При этом обе инструкции должны быть подписаны единой подписью для исключения конфликтных ситуаций.

Решение данной задачи представлено в SET в виде механизма двойной электронной подписи.

При совершении транзакции покупатель С формирует два сообщения:

  • – описание заказа для продавца С, содержащее все необходимые данные для отгрузки товара или предоставления услуги;
  • – инструкции платежному шлюзу G, содержащие в том числе платежные реквизиты покупателя.

сообщения не должно быть доступно продавцу, содержание , в принципе, не обязательно для платежного шлюза. При этом покупатель заинтересован в том, чтобы платежные инструкции были выполнены только после того, как с условиями заказа будет согласен продавец.

Для достижения поставленной задачи покупатель формирует сообщение , представляющее собой объединение хеш-образов сообщений и :

.

Затем покупатель применяет хеш-функцию к сообщению и зашифровывает результат на своем секретном ключе , получая тем самым двойную электронную подпись:

После этого покупатель формирует сообщение:

состоящее из инструкции продавцу, оригинала и хеш-образа инструкции платежному шлюзу, зашифрованных на открытом ключе платежного шлюза, и двойной электронной подписи. Данное сообщение покупатель отсылает продавцу.

Продавец, получив указанное сообщение, проверяет подпись покупателя. Для этого он извлекает из сообщения и  и вычисляет значение

Затем продавец вычисляет  и сравнивает его со значением , которое он получает из DoubleSign, зашифровав последнее на открытом ключе покупателя :

В случае совпадения и  продавец убеждается в целостности сообщения и при согласии с условиями сделки извлекает предназначавшиеся ему данные и из , формируя тем самым сообщение

которое отсылает платежному шлюзу.

Получив данное сообщение, платежный шлюз извлекает из него фрагмент , расшифровывает его на своем секретном ключе и получает платежные инструкции

После этого шлюз извлекает из полученного от продавца сообщения и вычисляет значение

Затем платежный шлюз вычисляет  и сравнивает его со значением , которое он получает из DoubleSign, зашифровав последнее на открытом ключе покупателя :

Совпадение и  означает, что, во-первых, платежные инструкции подписаны действительно покупателем, а во-вторых, что продавец согласен с условиями сделки.

Удостоверившись в корректности подписи, шлюз осуществляет предписанные ему платежные инструкции.

Процесс защищенного взаимодействия двух абонентов показан на рис. 11.4.

Абонент А формирует сообщение p, затем хеширует его и зашифровывает на своем секретном ключе , получая тем самым подпись сообщения Sign. Объединив оригинал сообщения и подпись, абонент А получает сообщение Order, которое шифрует на сеансовом ключе Key, сгенерированном случайным образом.

Полученное сообщение c является одной из частей отправляемого сообщения Datagram. Второй частью Datagram является Ciphered Key – сеансовый ключ, зашифрованный на открытом ключе абонента B. Сообщение Datagram передается на транспортный уровень и отправляется абоненту B.

Получив указанное сообщение, абонент B извлекает из него зашифрованный сеансовый ключ Ciphered Key и расшифровывает его на своем секретном ключе . Затем абонент B извлекает из Datagram фрагмент c и расшифровывает его при помощи сеансового ключа, получая тем самым сообщение Order.

Далее следует проверка подписи абонента А путем расшифрования sign с использованием – открытого ключа абонента А и сравнения полученного хеш-образа h (p) с хеш-образом сообщения p.

Протокол SET поддерживает четыре криптографических алгоритма:

  • RSA – для формирования и проверки электронной цифровой подписи передаваемого сообщения, а также для зашифрования и последующего расшифрования сеансового ключа;
  • DES – для зашифрования и последующего расшифрования инструкций продавцу и платежному шлюзу с прикрепленной двойной цифровой подписью;
  • SHA- для хеширования информации;
  • HMAC-SHA-1 — для формирования кода аутентификации сообщения.

Источник: https://intuit.ru/studies/courses/3580/822/lecture/30603

Как изменения в Chrome могут сломать ваш сайт: подробный гид по обновленному атрибуту SameSite для обработки cookie

Secure set

Разработчики Google Chrome постепенно внедряют новые стандарты безопасности пользователей, меняя подход к обработке cookie и поддержке атрибута SameSite. Подробно рассказываем, что это за атрибут и как он может изменить работу сайтов и приложений.

Что такое SameSite и как он работает?

В мае 2019 года разработчики Chrome объявили о внедрении новой модели безопасности для обработки файлов cookie. Теперь у каждого пользователя по умолчанию будет включен флаг «same-site-by-default-cookies».

При этом, если в файле не будет атрибута SameSite, браузер все равно самостоятельно поставит значение «SameSite=Lax» —это ограничит отправку сookie для вставок со сторонних сайтов.

Однако владельцы сайтов смогут снимать это ограничение, прописывая в настройках сookie параметр «SameSite=None, Secure» — последний параметр означает, что такой запрос вдобавок должен приходить на сервер только по защищённому каналу.

Изначально, по стандарту HTTP, браузер отправлял cookies при любом запросе на соответствующий им домен.

Однако такие механизмы открывали возможности для проведения CSRF-атак — мошенники могли при определенном стечении обстоятельств получить доступ к разным ресурсам, пользуясь сookie.

Поэтому в 2016 году появился атрибут SameSite, позволяющий контролировать, как браузер будет отправлять cookies в случае, если страница сайта посылает запрос на другой домен.

При этом первоначально, когда Chrome только начали разрабатывать SameSite, атрибуту нужно было присвоить явное значение Strict или Lax (подробнее о них мы расскажем ниже). Отсутствие SameSite было эквивалентно «SameSite=None», то есть по умолчанию cookies всё так же передавались при любых запросах.

Основной целью изменения работы атрибута SameSite является повышение прозрачности и безопасности для пользователей — люди смогут узнавать, кто отслеживает и использует информацию из сookie, которой они делятся. Кроме того, изменение в SameSite повлияет как на поведение пользователей, так и на рекламодателей, медиа и любых компаний, которые используют файлы сookie для анализа поведения своей аудитории.

Что такое межсайтовый запрос?

Когда вы посещаете какой-либо сайт, в браузере сразу же создается и сохраняется файл cookie.

Этот cookie-файл затем используется для идентификации пользователя и обеспечения персонализированного просмотра. Существует два типа файлов cookie — first-party and third-party.

 Оба типа могут содержать одну и ту же информацию: однако к ним обращаются в разных случаях и и создаются они немного разными путями.

Если вы посещаете какой-нибудь сайт, например, a.com, и собираетесь получить доступ к услуге с того же доменного имени, сгенерированные файлы cookie будут считаться файлами cookie типа first-party.

Поскольку файлы cookie были созданы одним и тем же сайтом, вы сможете наслаждаться персонализированным подходом — в том числе настройкой окружения, сохраненной информацией для входа в систему, элементами корзины покупок и так далее.

В случае, если вы посещаете сайт с условным названием b.com, который содержит разный контент — например, изображения или iframe из другого доменного имени, cookie будут считаться сторонними — third-party, поскольку они происходят от другого адреса, чем в строке URL.

Эти файлы cookie будут созданы другим сайтом, а доступ от одного к другому будет представлять собой межсайтовый запрос. Страница сайта a.com с запросом b.com позволят таким службам, как , Google Analytics, Doubleclick, отслеживать пользователей и предоставлять им онлайн-рекламу. В таком случае все эти сайты являются b.

com — при помощи этой технологии Google показывает пользователям целевую рекламу на сайтах, которые он посещает.

И вот как раз отправку файлов cookie типа third-party прекратит Google Chrome в межсайтовых запросах в случае, если они не защищены и не помечены с использованием стандарта IETF SameSite. Другими словами, контент со страницы b.com, который расположен на сайте a.com, больше не сможет получить доступ к файлам cookie, если они не защищены и не помечены специальными флагами.

Почему Google совершает такие радикальные изменения?

Обмен межсайтовыми cookie-файлами не всегда является проблемой, но у этой технологии есть потенциал для злоупотребления. Текущее поведение Google Chrome позволяет сторонним веб-сайтам получать доступ ко всем файлам cookie по умолчанию. Это создает возможность проведения CSRF-атак, при которых мошенники могут использовать сохраненные cookie-файлы пользователей на сторонних сайтах.

Например, пользователь является залогиненым в Хекслете и у него есть сессия в cookie.

Пользователь случайно перешел на какую-то зараженную страницу, через которую мошенник может получить доступ к файлам cookie пользователя на Хекслете, перейти в уже аутентифицированный сеанс и сделать несколько запросов на сайте вместо человека, поскольку пользователь уже прошел проверку подлинности, поэтому сайт не планирует проводить дополнительные проверки. Таким образом мошенник может решить все курсы пользователя на сайте и пройти все упражнения.

Есть несколько способов создать такие вредоносные команды: теги изображений, теги ссылок, скрытые формы и запросы JavaScript XMLHttpRequest.

 При текущем состоянии Chrome запрошенный файл cookie будет отправлен по умолчанию, и хакер получит доступ к сеансу пользователя, что означает, что он фактически вошел в систему как пользователь.

 Чтобы бороться с этой уязвимостью, фреймворкам часто требуются уникальные токены/идентификаторы, которые недоступны для злоумышленников и не будут отправляться с запросами.

Давайте рассмотрим на примере, каким образом это работает. Предположим, вы вошли на свой банковский счет.

Просматривая историю транзакций, вы получаете письмо на электронную почту с информацией о недавней подозрительной операции.

Для того, чтобы продолжить изучать эту транзакцию, письмо предлагает вам войти в свой банковский счет и даже вставляет удобную ссылку для перехода. При этом ваш банковский счет все еще открыт в соседней вкладке.

HTML-код ссылки из письма выглядит следующим образом:

Хакер уже изучил банк пользователя и знает, как имитировать переводы с аккаунта. Например, обычно этот банк создает таким образом команды для денежных переводов:

Этот хакер отправил это электронное письмо большому количеству клиентов банка, и он знает, что по крайней мере один человек нажмет эту правдоподобную ссылку.

На первый взгляд письмо выглядит настоящим — там нет никаких подозрительных данных, которые явно говорят о том, что это мошенники.

Пользователь нажимает на логотип банка, а поскольку он уже прошел проверку подлинности в соседней вкладке, переход по ссылке в итоге создает неавторизованную транзакцию.

За несколько секунд у пользователя со счета списывается много денег — и с этим практически ничего невозможно сделать.

При этом, если бы этот банк разрешал только Post-запросы на денежные переводы, то мошенник бы не смог создать вредоносный запрос, используя тег . Мошеннику бы пришлось уже создавать тег  с автоматическим выполнением встроенного JavaScript.

Этот код бы выглядел так:

Однако в жизни этот сценарий бы не был реализован, поскольку банки предотвращают такие CSRF-атаки, используя динамически генерируемые токены сеансов, тайм-ауты сеансов и другие превентивные методы.

И теперь — с использованием атрибута Strict — у банков появилась еще одна возможность для киберзащиты.

Однако такие механизмы защиты обычно есть у крупных компаний, тогда как небольшому интернет-бизнесу намного сложнее получить подобную систему, поэтому часто такие сайты становятся жертвами кибермошенников.

Как Chrome защищает пользователей от CSRF-атак?

Именно для устранения этой проблемы в 2016 году инженеры из Chrome представили концепцию атрибута SameSite, с помощью которого разработчики сайтов смогут устанавливать правила для совместного использования и доступа к файлам SameSite. Значение атрибута может устанавливаться в трех диапазонах — Strict, Lax или None.

Strict — самое строгое значение атрибута. К файлам cookie с таким параметром можно получить доступ только при посещении домена, с которого он был изначально установлен. Другими словами, «SameSite= Strict» полностью блокирует передачу cookie с a.

com, когда страница сайта b.com отправляет запрос. При этом передача cookie не произойдет даже в том случае, если пользователь щелкнет ссылку верхнего уровня в стороннем домене.

Такой вариант лучше всего подходит для сервисов, требующих высокой безопасности, например, для банковского сектора.

Lax — это значение позволяет всем типам сайта, которые принадлежат к одному и тому же домену, получить доступ к cookie. В отличие от None, где cookie отправляются всегда по умолчанию, это значение, как и Strict, отправляется только по запросу определенного сайта.

Однако Lax разрешает доступ к навигации верхнего уровня с помощью безопасного метода HTTP, такого как HTTP GET.

 Файл cookie не будет отправляться с POST-запросами между доменами или при загрузке сайта во фрейме с несколькими источниками, но он будет отправляться при переходе на сайт по стандартной  ссылке верхнего уровня.

None — это значение позволяет отслеживать пользователей на разных сайтах. Файлы cookie с этим параметром будут работать так же, как они работают сегодня.

При этом для установки этого значения атрибута необходимо не просто указать None, но и выбрать тип — Secure, который гарантирует, что запрос передается по безопасному соединению.

В случае, если пользователь не станет указывать Secure, то запрос будет отклонен браузером.

Реальный пример разницы между значением атрибута Strict и Lax

Если со значением None все более или менее понятно — оно будет работать так же, как cookie передаются сегодня, то с Strict и Lax все немного сложнее. Допустим, вы является гендиректором компании TalkToMe, Inc.

— многофункциональной системы объяснения сложных вопросов на простых примерах.

Вы позволяете своим пользователям встраивать вашу плашку на собственные сайты — они получают интеграцию в соцсети, расширенные возможности модерации и другие широкие функции сообщества.

Источник: https://zen.yandex.ru/media/hexlet/kak-izmeneniia-v-chrome-mogut-slomat-vash-sait-podrobnyi-gid-po-obnovlennomu-atributu-samesite-dlia-obrabotki-cookie-5eda340e8f5caa5ea4d49127

Поделиться:
Нет комментариев

    Добавить комментарий

    Ваш e-mail не будет опубликован. Все поля обязательны для заполнения.