ASP.NET MVC - Защитите временное хранение данных кредитной карты

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

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

Что идеальный подход к временному сохранению уязвимых данных как данные кредитной карты через запрос больше чем на одну страницу?


Возможно, кто-то может сказать мне, если это - достаточный подход. Я установил свою Корзину, которая хранится на сессии, чтобы иметь уникальный Гуид, генерировал каждый раз, когда объект является newed, и тот Гуид используется в качестве ключа, чтобы зашифровать и дешифровать данные кредитной карты, которые я сериализирую с алгоритмом Rijndael. Зашифрованные данные карты затем передаются пользователю в скрытом поле и десериализовываются, после завершают, нажат. Конечным результатом является строка во многом как это:

VREZ%2bWRPsfxhNuOMVUBnWpE%2f0AaX4hPgppO4hHpCvvwt%2fMQu0hxqA%2fCJO%2faOEi%2bX3n9%2fP923mVestb7r8%2bjkSVZDVccd2AJzCr6ak7bbZg8%3d

public static string EncryptQueryString(object queryString, Guid encryptionKey)
{
    try
    {
        byte[] key = Encoding.UTF8.GetBytes(ShortGuid.Encode(encryptionKey).Truncate(16));//must be 16 chars
        var rijndael = new RijndaelManaged
                           {
                               BlockSize = 128,
                               IV = key,
                               KeySize = 128,
                               Key = key
                           };

        ICryptoTransform transform = rijndael.CreateEncryptor();

        using (var ms = new MemoryStream())
        {
            using (var cs = new CryptoStream(ms, transform, CryptoStreamMode.Write))
            {
                byte[] buffer = Encoding.UTF8.GetBytes(queryString.ToString());

                cs.Write(buffer, 0, buffer.Length);
                cs.FlushFinalBlock();
                cs.Close();
            }
            ms.Close();
            return HttpUtility.UrlEncode(Convert.ToBase64String(ms.ToArray()));
        }
    }
    catch
    {
        return null;
    }
}

9
задан SwDevMan81 24 January 2010 в 19:41
поделиться

3 ответа

Лучший способ работы с этим сценарием - использование платежного сервиса, поддерживающего две вещи:

  1. Авторизация -> Семантика завершения.
  2. Токенизация

Авторизация позволяет зарезервировать указанную сумму сбора в момент получения платежной информации, а затем Completion позволяет зафиксировать сбор в платежном пакете после подтверждения платежа/заказа. Если заказ отменен, вам не нужно оформлять Completion, вы также можете попытаться удалить авторизацию.

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

Хранение фактической информации о кредитной карте любым другим способом, кроме передачи оплаты шлюзу/процессору, является плохой идеей. Помимо проблем защиты данных, это также помещает ваше приложение в область хранения информации о карте для PCI/PABP, что влечет за собой множество правил и норм, с которыми вы не захотите иметь дело в вашем приложении. Я полагаю, что в следующем году будет также установлен регуляторный сбор за совместимые приложения, который, по некоторым оценкам, составит $10k USD. Все это, скорее всего, не будет стоить вам или вашему клиенту проблем.

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

Класс SecureString (System.Security) @ MSDN

11
ответ дан 4 December 2019 в 15:20
поделиться

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

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

.
2
ответ дан 4 December 2019 в 15:20
поделиться

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

Готов ли ваш клиент нарушить коллективные правила Visa/MasterCard/AMC/Discover по обработке кредитных карт онлайн (PCI DSS)? Вашему клиенту может быть запрещено совершать операции с крупными компаниями, выпускающими кредитные карты. В целом, это очень плохая идея - попробовать прокат собственного решения для онлайн обработки кредитных карт - это хуже, чем прокат собственного криптографического алгоритма, так как к вашему клиенту могут быть применены серьезные штрафы (мелкий шрифт в их торговом соглашении). Настоящее решение PCI DSS требует сертификации и аудита в десятки тысяч долларов, чтобы убедиться, что оно действительно безопасно обрабатывает данные кредитных карт - вот почему почти каждый использует существующий онлайн-процессор

.
0
ответ дан 4 December 2019 в 15:20
поделиться
Другие вопросы по тегам:

Похожие вопросы: