Хранение Номеров кредитных карт на СЕССИИ - пути вокруг этого?

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

Взлома сеанса
Фиксация сеанса

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

Обратите внимание:

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

Вы можете найти этот рефлексивно полезным, поскольку хорошо :)

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

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

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

РЕДАКТИРОВАТЬ: Подумайте только об этом:

1. Сгенерировать случайный 128-битный ключ. Сохраните это в сеансе.
2. Зашифруйте данные с помощью ключа. Отправьте его клиенту в
3. После подтверждения расшифруйте данные и отправьте транзакцию.

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

РЕДАКТИРОВАТЬ: И я забыл подробности.Для всех этих схем (не только моей) вам также понадобится MAC для предотвращения атак повторного воспроизведения (или Ева отвлекает Алису, изменяет корзину покупок и адрес для выставления счетов и нажимает страницу «подтверждения» ...). В общем, вы хотите иметь MAC для всех данных транзакции, которые у вас есть (CC, CVV, идентификатор транзакции, сумма транзакции, адрес для выставления счетов ...).

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

Например, во многих ответах здесь говорится об использовании шифрования. Это легкое дело.Они не говорили об управлении ключами, которое значительно сложнее

, поэтому я думаю, что лучшим подходом было бы отправить данные карты в платежный шлюз, как только они будут собраны. Многие платежные шлюзы позволят вам выполнять транзакцию в стиле «только для магазина», которая будет выполнять базовую проверку данных карты и сохранять номер карты на своем (уже совместимом с PCI) сервере и вместо этого возвращать вам идентификатор токена. Этот метод означает, что вы НЕ храните полный номер карты / cvv2 где-либо на своих серверах, а соблюдение требований PCI значительно упрощает .

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

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

В какой-то момент позже при обработке платежа (последняя часть шага 3) вам нужно будет зашифровать CC # (и CVC), чтобы иметь возможность отправить его обработчику платежа. (Я предполагаю)

Почему бы не сделать это шифрование прямо при получении информации, рядом с запутыванием, необходимым для страницы подтверждения. (это последняя часть шага 1)

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

Храните данные карты на любом постоянном носителе (база данных, что угодно), но шифруйте номер карты уникальным и случайным ключом, который вы храните в сессии. Таким образом, если сессия будет потеряна, ключ тоже будет потерян - что даст вам достаточно времени для очистки просроченных/заброшенных данных.

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

Редактировать: Ключевой бит для минимизации риска - убедиться, что вы избавились от этой информации как можно скорее. Сразу после проведения транзакции удалите запись из базы данных. Вам также необходимо периодическое задание (скажем, каждые 5 минут), которое удаляет все записи старше, чем таймаут сессии (обычно 20 минут). Также, если вы используете базу данных для этих очень временных данных, убедитесь, что она не находится в системе автоматического резервного копирования.

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

Вот для чего нужна база данных. Я не уверен в юридических последствиях (они зависят от страны и региона), но один из подходов заключается в том, чтобы зашифровать номер CC и хранить его в базе данных, как только вы получите его от пользователя. Возможно, вы захотите сохранить последние 4 цифры в отдельном поле, чтобы при необходимости показать их пользователю. Когда вам понадобится взаимодействовать с процессором карт на сервере, получите и расшифруйте номер карты из вашей базы данных.

Похоже, что как бы вы к нему ни прикоснулись, вам нужно будет обеспечить возможность безопасного хранения номеров кредитных карт. Если сервер будет скомпрометирован, в любой момент он будет содержать достаточно информации для расшифровки сохраненных номеров кредитных карт (т.е. ключей и зашифрованных номеров). Возможное решение - использовать внутренний сервер, который действует как «шифровальщик / дешифратор», и ничего больше. Таким образом, компрометация одного компьютера не приводит к раскрытию номеров кредитных карт.