问题描述
我想拦截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是必要的，请注意你不能使用执行（* .new（..））用于JDK类，因为默认情况下会从方面编织中排除这些类。为了编织JDK类（执行连接点在逻辑上是在被调用者代码中），您需要修改JDK的rt.jar或者至少将修改后的JDK类放在JDK本身之前的bootclasspath中。这是可能的，但不是那么简单。
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的忠实粉丝，但我想强调一点，我也是清洁代码和重构的坚定支持者。任何体面的IDE，如IntelliJ IDEA或Eclipse都应该让重构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的构造函数？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！