ASP.NET MVC - 信用卡数据的安全临时存储 [英] ASP.NET MVC - Secure Temporary Storage of Credit Card Data

查看:91
本文介绍了ASP.NET MVC - 信用卡数据的安全临时存储的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一个购物车,目前正在存储信用卡数据在会话中进行检索,一旦用户最终完成购买结帐过程。购买过程中设置使得用户输入信用卡,认为一个确认页面,然后最终确定的顺序。确认和完成动作是需要获得信用卡数据是安全的所有其他行动应该放弃它仅有的两个动作。

在一个基本控制器来检查当前操作的用户呼吁做反射短,我想不出一个优雅的方式丢弃在不允许请求的数据。此外,如果用户未能输入将在会话中徘徊,直到他们回来每当这种情况发生的网站 - 数据后,使另一个请求。我提供一个建议是将数据加密成一个隐藏字段,并依靠SSL票prevent缓存标记。这似乎是一个相当安全的方法,但我不太喜欢把信用卡数据加密或没有用户可访问的位置的想法。在数据库中存储的,因为客户不希望信用卡数据被保存。

什么是跨多个页面请求暂时坚持像信用卡信息敏感数据理想的方法?


也许有人可以告诉我,如果这是一个足够的办法。我已经设置存储在会话我的购物车有一个唯一的GUID生成的每一次的对象是newed和GUID是作为一个密钥来加密和解密对此我用的Rijndael算法。然后,将加密卡的数据传递到一个隐藏字段用户,并单击敲定后,反序列化。最终的结果是一个字符串,就像这样:

<$p$p><$c$c>VREZ%2bWRPsfxhNuOMVUBnWpE%2f0AaX4hPgppO4hHpCvvwt%2fMQu0hxqA%2fCJO%2faOEi%2bX3n9%2fP923mVestb7r8%2bjkSVZDVccd2AJzCr6ak7bbZg8%3d


 公共静态字符串EncryptQueryString(对象的queryString中GUID的encryptionKey)
{
    尝试
    {
        字节[]键= Encoding.UTF8.GetBytes(ShortGuid.En code(的encryptionKey).Truncate(16)); //必须为16个字符
        VAR Rijndael算法=新RijndaelManaged的
                           {
                               BLOCKSIZE = 128,
                               IV =键,
                               密钥大​​小= 128,
                               键=键
                           };        ICryptoTransform的变换= rijndael.CreateEncryptor();        使用(VAR毫秒=新的MemoryStream())
        {
            使用(VAR CS =新的CryptoStream(MS,转换CryptoStreamMode.Write))
            {
                字节[]缓冲= Encoding.UTF8.GetBytes(queryString.ToString());                cs.Write(缓冲液,0,buffer.Length);
                cs.FlushFinalBlock();
                cs.Close();
            }
            ms.Close();
            返回HttpUtility.UrlEn code(Convert.ToBase64String(ms.ToArray()));
        }
    }
    抓住
    {
        返回null;
    }
}


解决方案

要处理这种情况的最好方法是使用支持两件事支付服务:


  1. 授权 - >完成语义

  2. 标记化

授权允许你在收到付款信息的时间预留指定的收费金额,然后完成允许您一次付款/订单确认充电承诺的付款批。如果订单被取消,您不必发出完成,你也可以尝试删除授权为好。

关于支持处理费将返回一个记号,通常是数字ID,对于未决事务前述方法标记化,最网关。但是你想令牌然后可以处理,因为它没有价值,没有任何人在网关访问您的身份验证凭据。这个传送安全网​​关的负担以及

存储比中继充电到网关/处理器的其它任何方式的实际的信用卡信息是一个坏主意。除了保护数据的问题,这也将使你的应用程序转化为PCI / PABP,这需要很多的,你不会希望在你的应用程序处理的规章制度卡信息存储范围。我相信也有将在来年被处以兼容的应用程序,据说$ 10,000美元的监管费。所有这一切都可能是不值得麻烦您或您的客户端。

最后,中间处理过程中(在页/事件/路由处理程序),您可以使用SecureString的保存数据的内容,直到你不再需要他们。

SecureString的类(System.Security)@ MSDN

I have a checkout process for a shopping cart that is currently storing credit card data in the session for retrieval once the user finalizes the purchase. The purchase process is set up such that the user inputs the credit card, views a confirmation page, and then finalizes the order. The confirmation and finalization actions are the only two actions that need access to the credit card data and to be safe all other actions should discard it.

Short of doing reflection in a base controller to check the current action the user is calling, I cannot think of an elegant way to discard the data on the disallowed requests. Additionally, if the user fails to make another request after entering the data it will linger in the session until they come back to the website- whenever that happens. One suggestion I was offered was encrypting the data into a hidden field and relying on the SSL ticket to prevent caching the markup. This seems like a fairly safe approach, but I don't much like the idea of placing the credit card data in a user-accessible location encrypted or not. Storing in the database is out because the client does not want credit card data saved.

What is the ideal approach to temporarily persisting sensitive data like credit card information across more than one page request?


Perhaps someone can tell me if this is a sufficient approach. I have set my Shopping Cart which is stored in the session to have a unique Guid generated every time the object is newed and that Guid is used as a key to encrypt and decrypt the credit card data which i am serializing with the Rijndael algorithm. The encrypted card data is then passed to the user in a hidden field and deserialized after finalize is clicked. The end result is a string much like this:

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;
    }
}

解决方案

The best way to handle this scenario is to use a payment service that supports two things:

  1. Authorization -> Completion semantics.
  2. Tokenization

Authorization allows you to reserve the designated charge amount at the time the payment information is received, and then Completion allows you to commit the charge to the payment batch once the payment/order is confirmed. If the order is canceled, you don't have to issue a Completion and you can also attempt to delete the authorization as well.

Regarding tokenization, most gateways that support the aforementioned method of handling payments will return a token, typically a numeric id, for the pending transaction. The token may then be handled however you wish, as it has no value to anyone without access to your authentication credentials at the gateway. This transfers the burden of safety to the gateway as well.

Storing the actual credit card information in any way other than relaying a charge to a gateway/processor is a bad idea. Beyond the problems of securing the data, this will also put your application into card information storage scope for PCI/PABP, which entails a lot of rules and regulations that you won't want to deal with in your application. I believe there is also a regulatory fee that will be imposed in the coming year for compliant applications, reputedly $10k USD. All of this is likely not worth the trouble to you or your client.

Last, during intermediate processing (in-page/event/route handlers), you can use a SecureString to hold the contents of the data until you no longer need them.

SecureString class (System.Security) @ MSDN

这篇关于ASP.NET MVC - 信用卡数据的安全临时存储的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆