问题描述
我想拦截 File、FileReader、FileWriter、FileInputStream 和 FileOutputStream 的构造函数，并防止任何文件名包含.."(以防止路径遍历攻击)或\0"(以防止文件名空字符攻击).
I want to intercept the constructor of File, FileReader, FileWriter, FileInputStream and FileOutputStream and prevent any filenames from containing ".." (to prevent path traversal attacks) or "\0" (to prevent filename null character attacks).
关于如何使用 SecurityManager 做同样的事情，我还有另一个悬而未决的问题，但还没有人回答它，所以我希望这种替代方法能奏效.
I have another open question about how to do this same thing using SecurityManager, but no one has answered it yet, so I was hoping this alternate method would work.
这是针对 tomcat 上的 spring webapp.
This is for a spring webapp on tomcat.
我知道我可以通过创建自己的 SafeFile、SafeFileReader 等类并修改代码以使用这些类来手动执行此操作.然而，我们的代码中有 960 个地方使用了这些对象的构造函数，所以我宁愿避免这种情况，除非这是唯一的方法.
I know that I could manually do this by making my own SafeFile, SafeFileReader, etc., classes and modifying the code to use those instead. However, there are 960 places in our code that use the constructors for those objects, so I'd prefer to avoid that unless it's the only way.
推荐答案
即使 Sotirios Delimanolis 链接到这里的答案是正确的(我自己写的)，只要 AspectJ 而不是基于代理的 Spring AOP 是必要的，请注意您不能将 execution(*.new(..)) 用于 JDK 类，因为默认情况下这些类被排除在方面编织之外.为了织入 JDK 类(执行连接点在逻辑上在被调用者代码中)，您需要修改 JDK 的 rt.jar 或至少将修改后的 JDK 类放在 JDK 本身之前的引导类路径上.这是可能的，但不是那么简单.
Even though the answer linked to here by Sotirios Delimanolis is correct (I wrote it myself) insofar as AspectJ instead of proxy-based Spring AOP is necessary, please note that you cannot use execution(*.new(..)) for JDK classes because those are excluded from aspect weaving by default. In order to weave into JDK classes (execution joinpoints are logically in the callee code) you need to modify the JDK's rt.jar or at least put the modified JDK classes on the bootclasspath before the JDK itself. This is possible, but not so trivial.
但是有一个更简单的选择:通过 call(*.new(..)) 编织到调用者(你自己的代码)，而不是被调用者 - 注意 call 之间的区别() 和 execution().这反过来意味着您无法拦截对不是由您自己的编织代码或 JDK 本身进行的 JDK 类的调用.因此，如果您需要一个 100% 的解决方案，即使对于不受您自己控制的代码，您也将最终编织 JDK.如果您只想保护自己的课程，这可能不是必需的.:-)
But there is a simpler option: weave into the callers (your own code), not the callees via call(*.new(..)) - note the difference between call() and execution(). This in turn means that you cannot intercept calls to JDK classes not made from your own woven code or from the JDK itself. So if you need a 100% solution even for code not under your own control, you will end up weaving the JDK. Probably this is not necessary though if you just want to secure your own classes. :-)
尽管我是 AspectJ 的忠实粉丝，但我想强调的是，我也是干净代码和重构的坚定支持者.任何像 IntelliJ IDEA 或 Eclipse 这样像样的 IDE 都应该可以非常简单地重构 960 次调用以使用您建议的安全包装器类.如果它如此重要，你为什么不这样做呢?IDEA 的结构搜索和替换可以在几分钟内完成，如果不是几秒钟的话.AOP 可以，但不应该用于修补您自己代码的缺陷.所以请去重构，之后你会更快乐.
As much as I am a huge fan of AspectJ, I want to highlight that I am also a firm proponent of clean code and refactoring. Any decent IDE like IntelliJ IDEA or Eclipse should make it quite simple to refactor 960 calls to use a safe wrapper class like you suggested. Why do you not do this if it is so important? IDEA's structural search and replace does that for you in minutes, if not seconds. AOP can, but should not be used to patch up your own code's deficiencies. So please go refactor, you will be much happier afterwards.
这篇关于如何使用AOP拦截File、FileReader、FileWriter、FileInputStream和FileOutputStream的构造函数?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！