​你的代码泄露了吗

教程大全 2025-07-07 14:24:25 浏览

就在几周前,每个安全分析师都在谈论一个名为 Lapsus$ 的勒索组织:他们窃取并泄露了一些大型科技公司的源代码,其中包括来自三星的近和微软 必应、必应地图以及Cortana 项目 的部分源代码。而就在几个月之前,也遭遇了同样的命运。

过去几年中,我们目睹了企业数据库在线泄露事件的激增。虽然所有提到的泄密都属于恶意行为——黑客的动机是通过表明他已经入侵了公司并可以访问数据来向公司施加压力——但我们不要忘记,错误发生的频率确实比我们想象的要多,而且悄无声息:当开发人员以为在私有环境中工作却无意中推送到公共数据库就足够了。

不幸的是,除了明显的声誉损害之外,源代码泄露的问题有时会被误解。因此,本文将总结源代码泄漏导致的风险,但最重要的是,为您提供了解您的公司是否成为受害者的方法。今天将邀请您使用专用的免费工具来评估您的 GitHub 足迹。

源代码和知识产权

在一个 95% 的 IT 部门都会以某种方式依赖开源软件 的世界里,人们很容易忘记,从编写第一行代码的那一刻起,源代码就被视为知识产权,它受版权保护。事实上,包含说明版权所有者和权限的源代码文件很常见。

从本质上讲,源代码是一种有漏洞的资产。分布式版本控制系统和代码共享平台极大地促进了整个代码库在互联网上的扩展和应用。与此同时,这又推动了开源社区的发展,并取得了巨大的成就。但对于越来越多将源代码作为核心价值资产的公司来说仍然存在问题。因此,确保在全球范围内尊重源代码版权已成为一项几乎不可能完成的任务。

源代码还可能包含版权、专利或商标无法保护的商业秘密。在一个创新和速度至关重要的行业中,如果不能对这些信息保密,对于一些初创公司来说可能就是游戏的终结。而对于较大的企业来说,更好地监控和控制源代码的哪些部分已共享以及与谁共享的目的则是为了避免诉讼费。

另一个层面,公开的源代码让黑客可以深入了解生产环境中部署的工作负载,有时会服务于数百万用户。这也可能是个问题的。

源代码中的潜在威胁

代码相当于实物产品的模型。对于精通技术的人来说,完全了解大型系统或软件的内部工作原理意味着他们可以轻松地发现硬编码凭据等漏洞。例如,GitGuardian 在扫描三星代码时发现了 6600 多个密钥:

“在三星源代码中发现的 6,600 多个密钥中,大约 90% 用于三星的内部服务和基础设施,而另外 10% 至关重要的是,可以授予对三星外部服务或工具(如 AWS、GitHub、Artifactory 和 Google)的访问权限。”GitGuardian 的开发者权益倡导者 Mackenzie Jackson 说。

这并不一定意味着黑客可以在泄漏后立即利用机密、访问控制缺陷和其他安全漏洞。但是,它仍然是他们工具箱中的另一项资产。对于攻击者来说,一些微弱的信号甚至可能比业务逻辑本身更有价值,例如开发人员的个人身份信息 (PII)、习惯、语言,以及更全球化的公司文化。数千行代码可以揭示比我们想象的更多的信息。

如何确定您的源代码是否泄露?

如前所述,无论您的企业过去是否遭受过数据泄露,您的专有代码都可能在您不知情的情况下公开出现在 GitHub 上。即使您的企业在该平台上没有正式亮相,您的开发人员也有可能参与开源项目或使用个人存储库来共享代码。

因此,应该认真对待您公司在 GitHub 上的信息。威胁情报应该可以解答以下问题:互联网上可以公开哪些资产?它们包括用户数据吗?它们是否提供了攻击者可以利用的关键且有效的信息?是否仍然可以控制泄露的资产(例如,通过启动 DMCA 删除流程)?

从技术层面讲,识别源代码泄漏的唯一解决办法是对专有代码进行指纹识别,并将其与公共文件数据库进行比较。这正是 HasMyCodeLeaked 的目的,这是提供的免费工具,可帮助任何人快速识别与知识产权相关的最关键匹配项。该工具的工作原理就是在 GitHub 的公共历史记录中精确查找您的代码指纹(识别文件的校验和,包括所有修订版本)。

它将为您生成包含源代码的所有存储库的可搜索报告,并通过智能过滤来识别高风险存储库。

结论

源代码泄漏需要被认真对待。它们正在损害您的品牌声誉,还可能使公司的核心资产面临风险。虽然 DMCA 删除请求可以确保从公共平台撤回受版权保护的内容,但商业机密仍有可能被泄露,并危及您业务中的创新点。在安全方面,它们提供了攻击者最重视的东西:一个软件内部工作的完整图景,包括它的缺陷、流程和所涉及的人员。

随着代码共享平台 GitHub 的爆发式发展,监控一个公司的公共足迹已成为威胁情报分析师最具挑战的任务之一。这也是的由来,专门用于帮助您确定知识产权是否已泄露的免费工具。


怎样发现内存泄露?

这里的客户端软件包括C/S系统的客户端和B/S系统中的客户端控件,当用户使用客户端软件时,如果发现我们的软件会吃内存,那是很丢面子的事,有哪些好的测试方法呢?希望大家能踊跃提出自己的看法。

如何发现客户端软件中的内存泄露?我的看法是:检测内存泄漏的问题应该尽早进行,它绝不应该是系统测试时的主要目标。 也就是说,检查是否存在内存泄漏,应该从编码时就要考虑,单元测试和集成测试时要重点检查。 如果前期没有考虑,等到了系统测试才想起检查或者才发现泄漏,为时已晚,此时再去定位泄漏的位置,太难太难了,它可能会让你的交付日期delay不确定的时间。

最近看了一些自动错误预防(AEP)的理论,我深受启发。 作为测试人员的我们,从“发现错误”转变到“帮助开发人员预防错误”,这将是一个巨大的转变。 所以说,下面我的答案中的第一点,我先说如何预防内存泄漏的问题,然后再讲如何发现。

1 如何在开发过程中有效预防内存泄漏?

第一步:遵循“好”的编程规则

“好”的编程规则是各位前辈经验和教训的集合,好的编程规则堪称开发者的“圣经”。 遵循统一的编程规则,可以让开发新手少走好多弯路,可以让项目整体的质量维持一个起码的“质量底线”。

有关内存泄漏方面的规则主要是“内存管理”方面的,举几个简单的,如下

×用malloc或new申请内存之后,立即检查指针值是否为NULL(防止使用指针值为NULL的内存)

×动态内存的申请与释放是否配对(防止内存泄漏)

×malloc语句是否正确无误?例如字节数是否正确?类型转换是否正确

×是否出现野指针,例如用free或delete释放了内存之后,忘记将指针设置为NULL

第二步:积极主动检测“内存泄漏”

严格遵循好的编程规则,可以让程序员在代码中尽量少的引入bug,但一旦不小心引入了,怎么办?这就要求我们在单元测试和集成测试中严格把关。

在这个阶段,单靠程序员或者测试员通过“代码走查”的方式检查内存泄漏,客户的实践和我的经验告诉我,这将是“不切实际”的,无论效率还是时间。 如果能够借助于一些专业的工具的话,情况可能就不一样了。

如果你的程序是用Visual C++ 6.0开发,那么Numega的BoundsChecker将是你检测“内存泄漏”最好的选择,如果是Visual C++,可以试一下Compuware的DevPartner。

如果你的程序基于Unix或者Linux平台,使用C或者C++,可以考虑一下开源的工具valgrind,我的朋友跟我说,它在一定程度上比Rational的Purify更出色。

上面的工具都要求程序能够动态运行起来,而且测试用例需要你自己准备。

如果你正处于单元测试或集成测试阶段,程序代码量已经足够大,而且还不能够动态运行,要尽早检测代码中的“内存泄漏”问题,该怎么办?此时你可以试用一下目前最新的静态分析技术:

×它不要求代码能够动态运行

×也不需要你来编写测试用例

×只需要代码能够正常编译,就可以发现代码只有在执行过程中才出现的错误,当然也包括内存泄漏。

这方面的工具有Klocwork的K7,Coverity的SQS,以及C++test中的BugDetective,其中最“物美价廉”的就是c++test的BugDetective。

2 如何发现客户端软件的“内存泄漏”?

如果开发过程中已经按照我上面提到的去做,相信发布后的程序存在“内存泄漏”的可能性几乎为零。

如果开发过程已经到了后期,系统测试已经开始做了,还要发现内存泄漏,这个时候我希望你能够拿到源代码。 如果有源代码,你还可以考虑1中的第二步,借助于专业的工具协助,虽然可能效果不一定特别理想,但总比下面我提到的方法更好一些。

当然作为测试人员,我当然也理解事情总没有想像那么完美。 我们通常会碰到“需要在系统测试阶段检测是否有内存泄漏,而且没有源代码”的难题。 我曾经也遇到过。

记得那还是2002年的事情了。 当时我承接的项目是一个电力行业的自动化系统,分为server端和client端,典型的c/s模式,老板要求在测试功能的同时顺便检查内存泄漏的问题,因为这个client端在客户那里可能是长时间不间断运行的,虽然客户很少操作。 我当时很为难,因为没有源代码,我甚至无法做“代码走查”。 在做功能测试的同时,我一直在琢磨...... 采用什么手段呢?

最后,借助于WinRunner,我出色的完成了任务,起码我的老板相信我的测试是可信的。 我的方法是这样的。

×首先咨询开发方,了解到关于内存操作频繁的功能点和模块

×从我的功能测试用例中挑选出和这些功能点和模块相关的测试用例

×找到一个“纯净”的机器,上面除了操作系统和被测的client端外,没有任何其他应用,这样做是为了排除其他应用可能存在的干扰。

×借助于WinRunner,自动化这些用例,形成自动化的脚本;在脚本的最后,添加“切换到Windows任务管理器”“记录该client进程所占用内存数据到文件”的操作脚本。

×连续运行N个小时

×最后我打开这个数据文件,可以发现在该客户端运行过程中,每次执行完特定的测试用例后,记录的内存占用数据。 当时我得出的结论是该client程序有“少许”的内存泄漏,因为在连续运行了72小时后,内存使用增加了近百分之十几。 我会把这些数据导入到Excel中绘成了一个图表,这样更直观一些。 经过简单的计算(内存的增量/用例循环次数),得到用例每次执行后增加的内存使用值,即泄漏的内存数量,然后把操作过程和这个结果一起交给开发方,最后开发方根据我的信息,真的找到了一处有内存泄漏的地方,虽然泄漏的数量很少。

以上就是我有过的一个类似的经历,我觉得可以提供给大家参考,同时也可以“举一反三,融会贯通”。 如B/S的客户端控件,可以用QTP协助完成。

​你的代码泄露了吗

在测试的最后阶段要去发现甚至定位内存泄漏挺难的,但只要发挥我们测试人员的主观能动性,总是找到一些“旁门左道”的测试手段。

最后,我个人认为,从时间成本和各种风险考虑,要避免内存泄漏的问题,还是要回到前期的预防,即编程过程的规则检查和单元测试阶段主动的检测。

一家之言,欢迎讨论。

如何用C/C++实现让自己编译的程序开机自启动?自己的代码写在哪里?

1。 自己在注册表的Run项中添加调用你的程序的注册信息。 2。 自己写程序,操作注册表,同13.把自己的程序写成服务形式,加在系统服务之中。 4.在开始->所有程序>启动(是叫这个名字吧,我是英文系统,中Startup)中添加你的程序的调用。

windows下用命令符运行php脚本,提示:php could not open input file

可能有两个原因,一个是文件格式的问题,另一个就是环境变量中的PATH变量没有设置好,或者你可以尝试着把php文件移动到php5即所在的文件夹下下通过命令提示符运行php脚本 cmd运行php通过cmd执行php进入php安装目录。C:\Users\ALBERT>d:D:\>cd wamp\bin\php\php5.3.10\D:\wamp\bin\php\php5.3.10>php d:\web\kefu\ worldD:\wamp\bin\php\php5.3.10>如上 进入php安装目录 ,使用php命令 加上php文件存放路径 即可执行php脚本 php d:\web\kefu\ 这个php文件的代码就是echo hello world;

本文版权声明本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容,请联系本站客服,一经查实,本站将立刻删除。

发表评论

热门推荐