DeepCode的主要发现#2:Java / Python硬编码密码

本文探讨了在软件开发中硬编码密码的常见安全性问题,包括CWE259和CWE798在内的多个弱点分类,以及OWASP列出的安全实践。文章分析了硬编码密码可能带来的风险,如密码泄露和更新困难,并介绍了DeepCode如何识别此类问题及其提供的解决方案,如使用.dcignore文件或代码注释来避免误报。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

嘿,

语言: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

from: https://dev.to//deepcode/deepcode-s-top-findings-2-java-python-hard-coded-password-1a4

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值