嘿,
语言:Java / Python 缺陷:密码/登录(类别安全性2) 诊断:硬编码字面量在已知受密码保护的函数中用作参数
See an example in Java here.
UPDATE (1/7/2020): CI小号CO hard-coded credentials here CVE-2019–15977 and here CVE-2019–15975.
背景: DeepCode从开放源代码存储库学习。 例如,我们知道应用程序中典型的密码或机密来源是什么。 通常,从受保护的配置存储中读取的功能。 我们跟踪这些数据通过开源应用程序所经过的流程,并能够识别这些机密的典型接收者或用户(例如,数据库或API登录名)。 在确定了这些接收器之后,我们现在可以强制执行以下操作:未保护的源(例如源代码中的硬编码常量)不会产生秘密数据。
Obviously, having your passwords hard-coded in your application is a bad practice. The Common Weakness Enumeration lists it twice: Both CWE 259 Use of Hard-Coded Passwords and CWE 798 Use of Hard-Coded Credentials. OWASP also lists it.
除了将密码信息泄露给您的开发团队或有权访问您的源代码的任何其他人的风险之外,这也使得更改操作端的密码非常困难。 我猜想不将秘密密钥粘贴到不属于它们的文件中是不费吹灰之力的。
但这还有另一个有趣的方面。 我们发现此错误有很多误报。 原因是在测试中或默认情况下两个交互的系统相互信任时,使用带有硬编码密码的功能可能是合法的。 是的,我们现在可以讨论这种做法是否合法。 但是,让我们暂时接受它。 显然,误报是我们要尽可能防止的事情。 那么,我们该怎么办?
We decided on the strict side of things. We accept some false positives but rather report possible issues. If you want to prevent false positives, we offer two ways: (1) With the .dcignore file (see here ) or (2) by adding a comment in your file (see here ). Better safe than sorry. So, give it a run at deepcode.ai …
铜
0xff