在Java中，如何在不生成String对象的情况下从HttpServletRequest标头中提取密码？ [英] In Java, how do I extract a password from a HttpServletRequest header without generating a String object?
问题描述
处理敏感数据（==密码）的常见Java安全准则建议永远不要使用String对象来存储数据，而是使用字节或字符数组。我试图在HttpServlet处理程序中应用此指南。特别是，我使用类似于基本身份验证的方法，其中凭据在标头中传入（这是一个GET请求，因此没有正文）。
A common Java security guideline for handling sensitive data (== passwords) recommends never using a String object to store the data, and instead using an array of bytes or chars. I am trying to apply this guideline in a HttpServlet handler. In particular, I am using a basic-authentication-like approach where the credentials are passed in in a header (this is a GET request, so no body).
我遇到的问题是，在没有生成String对象的情况下，似乎无法获取头数据，这违反了从一开始就遵循的准则。我已经彻底搜索了一个解决方案，但没有找到任何相关的讨论。有没有人对此问题有任何见解？
The issue I'm running into is that it seems impossible to get to the header data without generating a String object, which violates the guideline from the get-go. I've searched for a solution pretty thoroughly, and didn't find any relevant discussion. Does anybody have any insight into this issue?
注意：这是通过HTTPS进行的，因此这里没有连接安全问题。
NOTE: this takes place over HTTPS, so there is no connection security problem here.
推荐答案
简单的答案是你不能以String之外的任何形式获取参数。至少，不使用标准的servlet API。但是有一些可能的出局。
The simple answer is that you can't get the parameter in any other form than a String. At least, not using the standard servlet APIs. But there are a couple of possible "get outs".
-
如果你准备变得非常丑陋，你实际上可以打破String对象的抽象，并覆盖并覆盖字符。 （如果你准备违反规则，字符串实际上是可变的。这是少数可能证明这一点的情况之一。）
If you are prepared to get really ugly, you can in fact break the abstraction of the String object, and reach in and overwrite the characters. (Strings are in fact mutable if you are prepared to break the rules. This is one of the few situations where this might be justified.)
可能存在用于执行此操作的Web容器的（例如） HttpServletRequest 的实现中的非标准API扩展。如果没有，您可以获取源代码并添加一个。 （假设您使用的是开源Web容器。）
There might be a nonstandard API extension in your web container's implementation of (say) HttpServletRequest for doing this. If not, you may be able to get hold of the source code and add one. (Assuming you are using an open-source web container.)
话虽如此，IMO对Java安全的无字符串方法是错误的，或者至少在它实现的目标方面被高估了。
Having said that, IMO the "no strings" approach to Java security is misguided, or at least over-rated in terms of what it achieves.
无字符串方法防止某些东西可以通过应用程序的地址空间进行搜索，找到看起来像字符串的东西，并嗅出可能的密码。从理论上讲，这可以通过以下方式完成：
The "no strings" approach guards against the possibility that something can trawl through the address space of your application, locate things that look like strings, and sniff out possible passwords. In theory, this could be done by:
- 打破JVM执行模型并查看原始内存的黑客，
- 附加Java调试器并遍历可到达的对象，
- 使用/ dev / mem或类似的从外部读取进程内存，
- 访问硬盘驱动器上程序交换映像的剩余部分，或者
- 以某种方式导致它进入核心转储并读取转储。
- a hack that breaks the JVM's execution model and looks at the raw memory,
- attaching a Java debugger and trawling through the reachable objects,
- using "/dev/mem" or similar to read process memory from the outside,
- accessing the remains of a program's swap image on the hard drive, or
- somehow causing it to core dump and reading the dump.
然而，除了第一个之外的所有要求都要求坏人已经破坏了系统的安全性。如果坏人已经这样做了，还有其他（可能更简单的）方法从你的程序中窃取密码......无字符串方法无法阻止。
However, all but the first of these requires that the bad guy has already broken security on the system. And if the bad guy has done that there are other (probably simpler) ways to steal passwords from your program ... which the "no strings" approach won't prevent.
如果你担心利用Java安全漏洞来读取原始内存，那么这个漏洞可能会以其他方式使用;例如注入代码以改变代码处理密码的方式。
And if you are worried about a hack that exploits a Java security flaw to read raw memory, that flaw could probably used in other ways; e.g. to inject code to alter the way that the passwords are handled by the code.
总而言之，无字符串可以防止真正困难的黑客攻击或针对案例您的安全已经的地方。 IMO，不值得努力......除非你要求实施军事级安全。
So in summary, "no strings" is protecting against either really difficult hacks, or against cases where your security is already blown. IMO, it is not worth the effort ... unless you are required to implement military grade security.
这篇关于在Java中，如何在不生成String对象的情况下从HttpServletRequest标头中提取密码？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
