翻译：ResoLutiOn
预估稿费：200RMB（不服你也来投稿啊！）
投稿方式：发送邮件至linwei#360.cn，或登陆网页版在线投稿
完整的研究报告：http://t.cn/Rfrsdki
前言
近日，Mohammed Aamir Ali，Budi Arie以及Martin Emms等多位网络安全研究人员共同发布了一篇名为《信用卡在线支付系统是否即将成为又一互联网诈骗的重灾区》的研究报告。其中详尽阐述了当前信用卡在线支付系统存在的安全隐患、黑客实施暴力破解信用卡的攻击方式及攻击过程等问题。Mohammed Aamir Ali，Budi Arie等几位专家将在明年举行的2017 IEEE Security&Privacy大会上，向公众细细讲述这一针对信用卡的攻击方式。而在此之前，我们则可通过阅读这篇报告来先睹为快。
什么是信用卡在线支付系统？
信用卡在线支付系统，顾名思义，即用户在使用互联网购买某种商品或某种服务时，通过自己的信用卡或借记卡向商家支付费用的转账支付系统，用户将消费金额从自己的帐户转入卖家的银行帐户。
为了能够完成这一支付过程，系统要求用户在结算时，应向开户银行提供自己准确的信用卡信息（包括：持卡人姓名、预留密码、电话、以及开户银行名称等）。银行据此来判断用户身份的真实性，并对交易过程进行授权。
在转账过程中，涉及到了买家支付系统、支付软件，信用卡支付网络以及支付受理银行等多方的交易系统，如下图所示：
在线支付系统所包含的信用卡信息
由于在线支付是一种"买卖双方均不见卡"的转账方式，这就要求卖家在进行交易之前，需确认买家所提供的信用卡的真实性和有效性。因而，信用卡信息的保密性（是否只有持卡人了解相关私密信息，且并未遭到窃取）便决定了在线支付系统的安全性。在进行在线支付时，系统要求用户提供的信息为以下5类：
1. 持卡人的姓名：通常在办理信用卡时，持卡人的姓名都会被印在信用卡上。但经我们调查后发现，没有一家网站会对持卡人姓名进行查验。
2. 16位信用卡号码：开户银行对信用卡进行唯一标识认证的号码。而这16位号码有别于用户的主账户编号（PAN：Primary Account Number），它只用于信用卡的识别。而PAN则是连接信用卡与用户帐户之间的纽带。
3. 信用卡到期时间：在信用卡的正面标识有此信息。到期时间和PAN构成了用户身份验证信息的最小模块。
4.信用卡身份验证值（Card Verification Value-CVV）：一个3位的数字组合，通常置于信用卡背面的磁条内，用于辨别卡片真伪。它仅限于持卡人所持有，并且不允许以任何电子方式进行保存。
5.持卡人地址：该地址不在信用卡上进行标识，有时被用于支付授权过程中，是一种身份验证的辅助手段。
"让开发者爱上安全测试"系列之源码安全测试谁负责？ 阅读原文»
前言
顺着应用安全的发展，对于源代码安全测试，在源代码层面是进行安全漏洞的测试与防范，避免产生所谓的"0-day"漏洞，现在已是大家的共识，成为构建软件安全保障体系中必备环节。但我也常常听到有人抱怨"源代码安全测试很难开展，总是遇到这样那样的问题，分工不明，权责不清，配合变成对抗，最后导致虎头蛇尾，甚至是执行不下去，留以形势，无法产生实际作用。
那么今天我们就来讨论一下，企业内部怎样开展源代码安全测试？到底谁来负责源代码安全测试，才能使其有效地执行，事半功倍？
源代码安全测试归准？
我们把今天这个话题，变成一个相对具体的问题来讨论吧：
软件源代码安全测试工作到底应该归属于哪个部门？是测试部门？是安全部门？还是开发部门？
作为一直致力于为用户提供最佳的软件源代码安全测试解决方案的我，这个问题是我必须思考和解决的。因为只有真正弄明白这个问题，才能清楚地根据用户的实际需求，为用户提供真正有效的帮助。
乍一看，这个问题看上去不难回答，但在实际工作分配的时候，你会发现好像交给谁，他们都会说"不太合适"。我们一一来分析一下：
- 答案1：测试部门。既然是测试嘛，当然属于测试部门的工作范畴。当你把工作交给测试部门的时候，他们会告诉你："对不起，我们只懂测试。功能和性能测试交给我们没有问题，可是我们不太懂安全和安全漏洞，还是源代码级别的安全漏洞，我们一是看不懂代码，二是不明白什么是安全漏洞，这是安全工作，你还是找安全部门人员"。
- 答案2：安全部门。安全测试嘛，我们所熟知的一些测试，如漏扫，基线安全扫描，渗透测试等都是属于安全工作职责嘛。可安全人员却会说："这是源代码安全，属于代码安全优化和加固，我们安全人员90%的人员来自于网络安全背景，基本上看不懂代码，更不会编写代码。同时，软件源代码我们一般也很少拿得到源代码，拿到了也不会构建测试环境。这还是开发部门做比较合适。"
- 答案3：开发部门。既然前两个部门的人员都共同指出了他们看不懂代码，不会编码，所以做不好代码安全测试。那就由开发部门来做吧。可开发部门做源代码安全测试，他们能同意吗？从经验上看，一般他们会以"开发时间紧、任务重；功能开发都无法按时完成；安全问题是安全部门考虑的"等等一系列"借口"给你推掉。要是遇到较为"强势"的开发部门，他们会说："安全测试的活都要我们做，那还要安全部门和测试干什么？"不过在我看来，即使开发人员做了源代码安全测试，他们也都会以"各种各样的理由，而将"问题"判定为'误报'，不去修复"。这种即作"选手"，又作"裁判"的情况，也很难真正发挥源代码安全测试的功能。
完整的源代码安全测试体系
那到底该谁来负责实施源代码安全测试工作？以我们多年对服务的经验来看，这项工作需要安全、测试和开发三个部门有效地配合才能真正执行下去。我将其总结如下图：
以上图所见，我们将四个相互独立四个部门，在源代码安全上进行地贯穿，相互牵动，形成一个上通下达的有效的整体，各个部门分工明确，权责清楚，再加以积极配合即可实现源代码安全保障。具体上讲，就是建立以"源代码安全测试标准"中心，"审计式测试和开发者测试"为两个基本点的源代码安全测试制度，以"安全测试与安全开发"两手都要抓，两手都硬的原则来开展源代码安全工作，并最终形成"有法可依，有法必依，执法必严，违法必究"的管理格局。具体要点如下：
"源代码安全测试标准"为中心。在以安全部门为主，开发和测试为辅的方式下，合理地制定出源代码安全测试标准。该标准要即能满足安全部门安全防范的要求，又要能让测试和开发部门能够执行得下去，避免矫枉过正。然后由管理部门制定和发布执行。形成"有法可依"。
"审计式测试"一个基本点。在以测试部门为主选择业界最佳的安全解决产品解决方案（如思客云公司的"找八哥"云安全测试系统），以此建立尽可能全自动化的源代码安全测试平台。来实现测试成本最小的"审计式测试"和"开发者测试"。其中"审计式测试"是指在系统阶段性版本发布或者系统发布之前的安全测试，由测试部门完成。安全部门执行监督。确保任何一个系统在发布之前都执行了安全测试，并符合"源代码安全测试标准"。形成"有法必依"和"执法必严"。
"开发者测试"第二个基本点。开发部门在经过几次安全问题测试和修复过程后，就会发现"与其被动测试，被动修复问题，不如主动防范错误"。这样一方面开发人员就会进行安全编码方面的学习和实践，达到尽量不出错。另一方面，如果安全测试产品授权上是允许的，并测试过程也基本上是全自动化的，测试成本很低的情况下，开发人员会主动地在开发程中进行源代码安全测试。开发者测试还带来的另一个好处是，及时地发现安全问题，修复成本变化极低。这样一来，形成了"违法必究"。
结束语
通过上面详细的分析和总结，我相们大家已经明白了软件源代码安全测试工作的特点以及对实施这项目工作的工作重点。那么就形成统一的测试整体体系，各部门有效地积极配合才能让整个企业安全开发水平、测试水平、理水平得到提高，真正达到事半功倍的效果。
相关阅读
软件安全漏洞谁之错? ――我为软件开发者正名
"源码安全测试"――开发者之伤
作者：思客云
黑客技术官网地址：http://www.hackdig.com/
没有评论:
发表评论