虽然威利·萨顿从未说过，但事实是，人们抢劫银行是因为那里有钱。今天的罪犯不会带着上膛的枪和逃跑的司机走进银行。相反，他们通过浏览器远程连接，并配备黑客工具和间谍软件。
旧的犯罪分子以柜台后面的出纳员为目标，今天的攻击者以银行和电子商务应用程序为目标。所以，尽管目标基础设施有所改变，但从威胁的角度来看，自威利·萨顿抢劫银行以来，其他方面并没有什么真正的改变。问一个黑客“钱在哪里?”他们会告诉你:在编写和保护都很差的银行和电子商务软件应用程序的背后和内部。
针对银行和支付应用程序的威胁及其灾难性后果似乎无穷无尽。身份盗窃,数据泄漏钓鱼、SQL注入、蠕虫、应用程序拒绝服务(DoS)攻击,僵尸网络攻击虽然只是浅尝辄止，但这些都是关键应用程序目前必须保护的威胁。最大的问题是，威胁的数量以及需要受到保护的应用程序的数量都在定期增加。
PCI与应用安全
到目前为止，该行业对……的需求一直不屑一顾App 保护我们都为此付出了代价，持续的数据泄露。考虑这个问题,微软最终在2002年开始认真考虑应用程序安全问题值得信赖的计算(TWC)倡议。TWC是用“红色代码”和“Nimda”等蠕虫病毒对微软操作系统进行毁灭性攻击的结果。
TWC是在微软负责人发给全体员工的电子邮件中宣布的比尔盖茨。他重新规定微软所有的软件开发活动都要包括全面的安全审查。即使有了这个指令，微软的代码也花了数年时间才开始变得安全。在PCI领域，有多少商家让他们的创始人告诉大家要安全编码，并且他们会停止所有的开发，直到完成为止?现在的问题是，应用程序安全性需要被认真对待，这意味着要投入时间、精力和资源来正确地实现它。
应用程序安全性是应用程序的核心支付卡行业(PCI)安全标准和要求。在过去的几年里数据泄露已经导致数亿的数据记录被破坏。在大多数情况下，防火墙、加密和日志都能正常工作，但应用程序中包含的安全漏洞大大降低了安全性。这就像把银行的前门关起来，却让后窗开着一样。
那么为什么PCI开始关注web和支付应用程序呢?正是因为这些应用程序是攻击者访问包含大量信用卡数据的后端数据库最明显的入口点。
在数据安全标准，要求6.6(2008年6月30日成为强制要求)要求基于web的应用程序具有经过验证的安全性。PCI DSS要求6.6要求处理信用卡交易的组织解决web应用程序的安全性，通过手动或自动源代码审查或漏洞扫描，或通过安装在客户端和应用程序之间的web应用程序防火墙。
PCI DSS要求6.6
虽然在PCI DSS第6.6节中的应用程序安全性要求仅包含44个字，但不要认为应用程序安全性遵从性是不重要的或小意思。要求6.6的具体内容如下:
使用下列方法之一，确保所有面向web的应用程序免受已知攻击:
- 拥有由专门从事应用安全的组织审查了常见漏洞所有自定义应用程序代码
——在面向web的应用程序前面安装应用层防火墙
首先，什么叫应用层防火墙?它也被称为web应用程序防火墙，它是放置在web应用程序前面以防止应用程序攻击的网络设备。应用层防火墙可以查看和消化所有应用程序流量，但是增强了实时过滤会话、表示和应用层网络流量(OSI模型)的能力。这使它具有保护应用程序和所有相关敏感数据不受非法访问和未经授权使用的优点。
由应用层防火墙减轻的安全威胁是非常真实的。为了让您对事情有一个感觉并真正地处理业务风险，请注意软件安全风险的范围是显著的。他们可以分为两种不同的类型;编码漏洞和设计缺陷/策略违反。根据一家领先的软件应用安全公司的说法，他们认为等级是:
编码漏洞:
——缓冲区溢出
——格式字符串漏洞
——竞争条件
——资源泄漏
——输入/输出验证和编码错误
* SQL注入
*跨站点脚本编制
*操作系统注入
设计缺陷和违反政策
——密码
——网络通信漏洞
——应用程序配置漏洞
——访问控制
数据库和文件系统使用
——动态代码
——访问控制和认证错误
——错误处理和日志漏洞
*不安全的错误处理
不安全或不充分的日志记录
*本地代码加载
*数据存储漏洞
——不安全组件
恶意代码
*不安全的本地方法
*不支持的方法
自定义cookie /隐藏字段
虽然这是许多可能的威胁编码尝试之一，但应该清楚的是，软件安全是一个多方面的努力，采取了直接和正式的方法。
不安全的银行应用程序
坐落在海平面以下50英尺，在华尔街坚实的基岩上联邦储备金库包含价值数千亿美元的黄金。除了在周围和内部实施了奢华的层层安全措施之外，这个设施的现实是，黄金非常沉重、笨重，很难移动。即使攻击者进入，也很难带着大量的黄金出去。
虽然提取黄金很困难，但数据很轻，流动性很强。今天传输一个十亿字节的数据几乎是微不足道的。如今的银行应用程序中包含的数据价值堪比黄金，但也足够轻便，便于访问和移动。这些应用程序将包含数万到数亿条记录。应用程序将连接到一个数据库，该数据库用作敏感个人数据的存储库。黑客的战利品将包含在这些应用程序中，货币可以采取多种形式;但通常是由客户账户信息和其他个人识别码组成的，现代的威利萨顿可以利用这些信息来获取不义之利。而把这些货币取出来，只不过是把一串串的1和0从一台电脑转移到另一台电脑，几乎不像尝试大量的金条。
在PCI数据安全标准(DSS)的情况下，“钱”或货币，即最需要保护的敏感信息，包括:
——主账号(PAN)
——持卡人的名字
——各种服务代码
——截止日期
——在适当保护的情况下，允许以数字方式存储的其他物品
——磁卡条纹数据，包括安全码和个人密码
事实上，基于商家的妥协，Visa已经发现存储被禁止的数据(完整跟踪，CVV2, PIN块等)是大多数持卡人信息数据泄露的主要原因。通常，在请求的信用卡交易获得授权之后，这些数据库中存储的数据根本就不应该存储在那里。但是一次又一次地出现了专有和商业现成(COTS)应用程序被破坏的实例，因为它们没有按照PCI DSS和安全编码需求进行开发。在某些情况下，报告的代码缺陷仅仅违反了普通的应用程序开发标准，比如OWASP。
作为安全专业人士PCI合格的安全评估人员(QSA)[链接到。pdf]，基于我们自己的经验和对市场的洞察力，作者惊讶地发现，在2008年，仍然有银行应用程序在部署时没有一个正式的基于安全的SDLC和安全代码审查。除此之外，很少有组织对他们的开发人员进行过安全开发实践方面的有效培训。在2008年底，创建这种支付处理应用程序的开发人员甚至不知道适当处理和存储敏感信息的PCI DSS要求是什么，这几乎是一种犯罪。
质量保证人员应该提供额外的保护，他们应该测试这些应用程序。它们应该考虑在整个信息生命周期中如何处理敏感信息的所有方面，以及由此产生的事务的历史记录。然而，许多应用程序测试团队继续将他们的工作重点放在测试功能、可伸缩性和应用程序功能的加载需求上。
值得赞扬的是，一些应用程序测试人员实际上可能使用通用漏洞扫描程序扫描各种组件，但缺乏正确解释扫描程序输出结果的技能。它们还可能依赖于应用程序的部署方式或其他外部控件来提供必要的安全性。在很久以前，这些任务在非internet连接的系统上还可以接受，但当应用程序运行在开放的、可公开访问的网络上时，这些任务就远远不够了。
幸运的是那些谁依靠这样的商业，这是每个人都用信用卡，该PCI安全标准委员会(PCI SSC)，主要的卡品牌，卡发行者，和合格的安全评估横跨行业正在共同努力永久地改变事情向更好。如果你愿意的话，这个组织已经形成了，如果必要的根本变革能够实现，那么现代的威利·萨顿和他的孩子们的日子就不多了。支付应用程序的安全性最终可能会变得无处不在，并被视为与任何其他系统功能一样重要。
PCI应用程序安全性要求
目前，有自定义内部或外包应用程序和软件的需求，这些应用程序和软件没有商业转售，以符合PCI DSS的所有相关要求，所有自定义应用程序必须根据这些需求开发、部署、支持和刷新。
其中包括以下内容:
1.应用程序必须作为定义良好的软件开发生命周期(SDLC)的一部分进行开发，并将安全原则纳入开发过程。
2.应用程序应该驻留在坚固的操作系统上，并对不必要的功能有明确定义的限制。
3.应用程序不应该存储敏感的身份验证数据(卡片磁条、安全码、pin等)。
4.应用程序不应干扰网络安全控制，如防病毒、防火墙、加密保护、安全认证方案、id /IPS等。
5.基于Web的应用程序开发必须符合打开Web应用程序安全项目(OWASP)安全编码指南。
6.面向web的应用程序(即面向internet的应用程序)必须通过授权实体的源代码审查加以保护，或者由应用程序防火墙加以保护。
7.除了由实际代码的作者进行功能测试之外，还应该由其他人对应用程序进行安全漏洞测试。
应用程序安全操作项
一些业务和IT领导可能刚刚开始考虑其银行或商业应用程序的安全影响。首先该做什么，可能仍存在不确定性。下面的5个步骤是一个好的开始:
1.更新POS应用程序。Visa维护了一个符合POS应用程序的支付应用程序最佳实践列表。确保您正在运行一个兼容的POS版本。
2.识别编码糟糕的Web应用程序。对已知的编码缺陷进行代码检查。随后进行漏洞扫描和应用层渗透测试，以确保应用程序代码是PCI投诉和安全。
3.每季度进行漏洞扫描。如DSS节11.2所述，在网络发生任何重大变化(如新系统组件安装、网络拓扑变化、防火墙规则修改、产品升级)后，至少每季度运行内部和外部网络漏洞扫描。
4.每年进行渗透测试。处理“敏感”数据的内部和外部(面向公众的)应用程序应该至少每年进行一次渗透测试，并在它们进行重大修改时进行渗透测试。
5.创建正式的SDLC流程。微软通过“可靠的计算”理解了这一点。确保您形式化了在整个生命周期中包含安全分析的软件开发生命周期。
请注意，这五个步骤将使您的开发团队忙碌一段时间。确保你有一个优秀的项目经理，让所有的任务和团队保持同步。
用PCI PA-DSS代替Visa PABP