程序员无意/恶意访问敏感用户信息的问题有多严重？
例如，在 Web 应用程序中，即使在对密码和其他敏感信息进行哈希处理并保存到数据库之前，也可以通过某种其他方式记录或访问密码和其他敏感信息。
有时，对于非常大的应用程序，可能并不总是能够检查所有代码以防止这种情况发生。恶意程序员可以轻松地在日志文件中打印用户的私人信息。
我想知道这是否是真正的威胁，以及是否存在防止此类信息泄露的标准方法。
我是一个网络新手，所以如果这听起来像是一个微不足道的问题，请原谅我。
In a web application, for example, the password and other sensitive information could be logged or accessed in some other way even before it is hashed and saved to the database.
Soemtimes, with very large applications, it may not always be possible to review all the code to prevent this from happening. A malicious programmer could easily print user's private information in a log file.
I would like to know if this is a genuine threat and if there exist standard ways to prevent this type of information compromise.
I am a web newbie so pardon me if this sounds like a trivial question.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
在银行和保险公司等大型企业环境中，开发人员不应有权登录实时服务器、数据库等。
开发人员应仅具有对测试环境的完全访问权限。这实际上构成了年度外部审计的一部分，以检查谁有权访问生产数据。
但事实上，只有代码审查才能真正发现这些问题，因为聪明的开发人员能够解决这个问题。
In large enterprise environments such as banks and insurance companies, developers should not have access to log onto live servers, databases etc.
Developers should only have full access to test environments. This actually forms part of the annual external audit to check who has access to production data.
I reality though, only a code review would be able to actually catch these issues, since a clever developer would be able to get around this.
您需要信任您的开发人员。如果你不信任他们，你就会遇到比这更大的问题。
最终你无法阻止它，但如果发生这种情况，应该有途径向他们追索以追回损失，在某些情况下可能会发生刑事诉讼。
这有点像“防破解软件”问题。您可以将所有安全防护措施落实到位，但最终，有才华的开发人员会找到一种方法来以足够的动力规避它们。
公司文化也发挥着重要作用，如果员工有奉献精神并感受到自己是大局的一部分，那么不影响公司未来的成功就符合他们的利益。
You need to trust your developers. If you don't trust them you've got bigger issues than this.
Ultimately you can't prevent it, but if it happens there should be avenues of recourse against them to recover damages, and in some instances criminal proceedings could occur.
It's kinda like the 'crack proof software' question. You can put all the safe guards in place, but at the end of the day a talented developer will find a way to circumvent them with enough motivation.
Company culture plays a part too, if employees are committed and feel a part of the bigger picture, its in their interests not to screw around with the company's future success.
一个简单的解决方案是输入您的用户名和密码，然后 grep 所有服务器日志以查找该密码。
如果您的某些程序员存在恶意，那么您的团队就会出现问题。
编写大型应用程序需要程序员的信任，当我说信任时，我的意思是：“你相信你的团队不会犯恶意错误”。
A trivial solution would be to enter your username and password, and then grep all server logs for that password.
If there is malicious intent by some of your programmers, then you've got problems in your team.
Writing large applications requires trust from programmers, and when I say trust, I mean: "you believe in your team not to make manevolent mistakes".
不要向您不信任的程序员授予对敏感应用程序中使用的任何代码的写入权限。或者在部署之前检查所有代码。我认为你没有什么可以做的。
确保所有代码更改都经过版本控制，这样有罪的程序员可能会留下痕迹。但即便如此也不是真正安全。他可以从另一个程序员工作站检查更改。或者他可以以一种无法与无心错误区分的方式在应用程序中添加一个安全漏洞。然后利用这个安全漏洞。
Don't give programmers you don't trust write access to any code used in a sensitive application. Or review all code before it is deployed. I don't think there is anything else you can do.
Make sure all code changes go through version control, that way the the guilty programmer might leave a trace. But even that's not really secure. He could check in the change from another programmers workstation. Or he could add a security hole into the application in a way that can't be distinguished from a honest mistake. And then just exploit that security hole.
如果存在恶意访问，您无能为力。程序员总会找到另一种方法来规避你所做的预防措施。
通过测试可能会发现无意的访问。
避免将调试信息打印在屏幕上或文件中。
部署时经常会出现调试线未被删除的情况。
使用 LOG4J 等库可以防止这种情况发生。
If there is malicious access there is not much you can do about it. The programmer will always find another way to circomvent the precautions you made.
Unintentional access may be found by testing.
Avoid debug information being printed on screen or to files.
It often happens that debug lines are not removed when deployed.
Using libraries as LOG4J and others can prevent this from happening.