COBOL 应用程序开发安全 | Secure Code Warrior

2019 年还在谈论使用 1959 年发明的计算机语言，这听起来几乎有些滑稽。如今，很少有研讨会或大会专门讨论如何重新装配经典的胜家缝纫机，或者更换雪佛兰 Parkwood 或凯旋 Herald 的油底壳。大多数老旧工具早已退役，升级为更新、更高效的型号。然而，在理应比其他行业更具前沿性的科技领域，我们却仍在沿用 COBOL 这种与上述工具诞生于同一时代的语言。

当然，这背后有非常充分的理由。通用商业语言 (COBOL) 虽然已有 60 年历史，但其架构极其出色，以至于至今仍具有现实意义并被广泛使用。

COBOL 的初衷是提供一种相对简单的方法，通过将通俗语言组合成特定的句子和语法，来编写后端系统以执行数学和公式化任务。为什么它能延续至今？简单来说，因为它非常胜任自己的工作。在某种意义上，它已成为金融和制造业等多个行业中许多大型机和核心系统的计算基础。

多年来，COBOL 经历了增量更新，最显著的是在 2002 年被改造为面向对象的语言，使新应用程序的编程更加流畅。但总的来说，COBOL 至今仍保持着当年的风采：一位默默无闻的英雄，一种在后端支撑着许多现代大型机级应用程序的“工作马”式编程语言。

COBOL 的安全性如何？

遗憾的是，COBOL 在最初创建时并没有太多安全方面的考量。例如，许多 COBOL 应用程序虽然有密码程序保护，但几乎从未针对暴力破解等攻击进行加固。再加上许多监控网络流量的现代安全工具无法处理或评估用 COBOL 等商业语言编写的程序内部的功能，这就埋下了巨大的隐患。不少现代安全漏洞的成功利用，正是因为缺乏对运行经典计算机语言系统的安全监管。2015 年，美国人事管理局 (OPM) 遭到黑客攻击，导致超过 400 万联邦雇员的数据泄露，原因被归咎于他们对 COBOL 的使用，并指出在如此陈旧的系统上无法实施现代安全措施。

多年前，安全工作由一大批精通 COBOL 和当时热门语言的程序员负责。在 20 世纪 60 年代，COBOL 就像今天的 Java 或 .Net，精通它的人是部门里的明星。到了 2019 年，这些人很可能早已退休，尽管他们所保护的系统依然在运行。

扩展 COBOL 的防御前线

不少这些所谓的“老法师”被组织以合同工的形式请回，继续维护他们曾经工作过的大型机。在很多地方，他们显得有些格格不入：一群在办公室角落里神秘兮兮的资深专家，他们奇怪的着装（宽领带和三件套西装）和彬彬有礼的举止，与那些穿着紧身牛仔裤、留着发髻的现代潮人显得有些不搭。然而，他们绝对是不可或缺的，因为很少有现代程序员会使用 COBOL 和其他古老语言编写代码。可悲的是，即使是这些最后的守望者也在逐渐老去，最终告别职场，前往博卡拉顿享受真正的退休生活。

因此，迫切需要了解旧语言及其所含安全漏洞的人才。即使年轻人不会用经典语言编写代码，也至少应该了解它们的工作原理及其潜在漏洞。因为虽然 COBOL 的开发保持相对静态，但针对网络的威胁却在不断演变。试图使用 60 年前编写的古老网络安全技术（如前述的 COBOL 密码应用）来防御现代攻击者，无异于部署一队手持长矛的士兵去对抗一排太空陆战队——除非出现好莱坞式的奇迹，否则手持长矛的一方注定会惨败。

无论新旧，都必须确保安全。

这就是为什么我们坚信一套涵盖广泛编程语言和框架的高级培训系统至关重要。很多安全培训选项的一个明显问题是，内容过于笼统，甚至在开发者的日常工作中完全不适用。花半天时间学习仅适用于 Java 的漏洞，并不能帮助 COBOL 开发者加固系统，这只会让“安全”沦为一种走过场的形式，在完成强制课程后就被抛之脑后。我还要补充一点，针对 Java 安全漏洞的培训并不总是适用于 Java Spring 开发者。安全编码在每种语言中都是不同的，甚至细化到框架层面也是如此。

我们的使命是赋能所有开发者成为安全超级英雄，我们不会忽视任何一种仍在全球最关键、最易受攻击的设施中使用的有效计算机语言。在我们的平台上，您会发现与 COBOL 相关的现代实操挑战和培训，以及当今最先进的编程工具（如 Google 的 Golang）。这种灵活性确保了培训与个人相关且具有情境感，通过模拟工作环境实现最大的参与度和有效性。毕竟，建立强大的安全文化是应对网络威胁的重中之重，因此培训必须实用（当然，还要有趣！）。

我们希望行业能达到这样一种阶段：无论安全威胁是针对运行老旧语言的系统，还是针对最现代的移动应用，都无关紧要。我们希望每位开发者都能掌握关于这些漏洞的最佳信息，了解攻击者利用这些漏洞所使用的工具和技术，并知道如何彻底阻止它们。面对网络安全威胁，我们绝不投降，绝不退缩。无论威胁或漏洞是现代的还是久远的，您都可以随时求助于 Secure Code Warrior，学习如何每一次都战胜它们。

附言：认为古老语言就能免受 SQL 注入攻击？再想想吧。看看你现在能否 定位并修复一个 COBOL 中的漏洞。