0

say i have a working spring mvc web app which includes the following,

<context:component-scan base-package="com.my_company.my_prj.my_controller_pkg" />

apparently this project depends on a few 3rd open source libraries including spring framework, etc,

how can i make sure the vendors of those libs will never release a new version of jars which secretly (or accidentally) includes a @Controller annotated class which is like e.g. com.my_company.my_prj.my_controller_pkg.Format_C_Drive_Controller.java, and BOOM!, my web site new release will open a door to anyone to format my c drive in the server.

is there any way to let spring component scan only load beans from some predefined jar files or classpath directories which are fully under my control?

thanks

zhoubig
  • 23
  • 1
  • 4
  • 1
    If they did, anyone could find the class in the jar file, decompile it, see the attack, and sue them. Or make them lose all their credibility. Your whole app is executed by Spring. Do you really think they would need a class in your package to format your drive? – JB Nizet Dec 15 '14 at 23:03
  • so i interprete your answer as there is *NO* way to control spring "auto component scan" to only scan a configurable restricted area of the jvm classpath. however, i don't think there is a huge technical difficulty for spring framework vendor to implement this feature for the sake of security. then why they don't? – zhoubig Dec 16 '14 at 18:37
  • Because it doesn't bring any security. If you include a libary in the classpath, the goal is to have some of its code executed, and this code might do anything, with or without spring help or component scanning: `StringUtils.isNullOrEmpty(s)` might formt your drive. No need for component-scanning for that. If you're worried about a library being malware, then don't use it. Nobody forces you. – JB Nizet Dec 17 '14 at 06:29
  • your answers are appreciated. however, this is another typical "all or none" scenario a user has to forcibly accept. according to the same theory, there should have had no need to introduce the "java policy" for jvm. – zhoubig Dec 24 '14 at 16:40
  • it is not necessarily about the trust on spring library. e.g., if another team may contribute another jar in the classpath, how can you make sure you don't accidentally initiate their controller bean? i knew naming convention of package names is helpful here, but at least your security previously not relying on package names now have to rely on them which is effectively making your security more fragile. – zhoubig Dec 24 '14 at 16:47

0 Answers0