Hi Andrew, Sorry for the delay in response here. Been busy these past few days.
On 1/27/2014 10:53 AM, Andrew Reid wrote: > Yes -- it happens both for my soon-to-deploy test system and > my mostly-clean DSpace 3.2 prototype. It's mod_jk from an Apache > front end to Tomcat in the back. There's a sym-link trick, > the actual app is behind a symlink with a "#" in it, which Tomcat > converts to a slash. > Long way to say that, yes, the base URL is <host>/dspace/xmlui. > > The actual URL that our security folks' scanner picked up was > "<host>/dspace/xmlui/static/js/discovery/badfile123.js", which is > apparently some kind of likely penetration vector. The actual > error is, "An error has occurred", which is apparently an HTTP 500 > response. > > Without the "static" (for > "<host>/dspace/xmlui/js/discovery/badfile123.js"), > I get a different error, it's a "Resource not found", again with the > stack-traces. > > Since Friday, I have also subsequently heard that my security folks > are unhappy with the 500 response -- can you (or anyone) offer them > some assurances that this is benign? I noticed, while poking around, > that other public-facing DSpace installations do the same thing -- > I won't mention any names, since it's at least possible it's some > kind of security issue. I am able to replicate the 500 response you are seeing. It *only* seems to occur for URLs of this structure: [dspace-xmlui-url]/static/*/*.js [dspace-xmlui-url]/static/*/*.css [dspace-xmlui-url]/static/*/*.json In other words, the XMLUI path must start with "/static/", and it must end with either ".js", ".css" or ".json". So, it's a very specific URL structure that throws this 500 response (all others will return 404 responses). The underlying error *IS BENIGN*. Essentially, what is going on here is that we have some special processing to allow institutions to easily add custom Javascript or CSS files to their themes. Those custom files become available on the "/static" path. Currently, if someone attempts to reference a .js/.css/.json file which does NOT exist, DSpace code is unfortunately is throwing a Java NullPointerException (as it's failing to check if the file actually exists). Here's the line where the NullPointerException is thrown: https://github.com/DSpace/DSpace/blob/master/dspace-xmlui/src/main/java/org/dspace/app/xmlui/cocoon/ConcatenationReader.java#L174 While this error is annoying and should be caught (and a proper 404 returned), it is a benign error. No javascript is being executed, and no problems are being caused in your DSpace instance..it's just a minor bug in the code. That all being said, I've opened up a bug ticket to report this benign issue. It seems like it shouldn't be too hard to fix, so hopefully we can get someone to resolve it in the near future. Please feel free to forward this bug ticket on to your security folks if it helps: https://jira.duraspace.org/browse/DS-1896 > > The prototype system is the one where I have tried putting the > error-handling code in the webapps/xmlui/themes/Mirage/sitemap.xmap > file -- I see the same behavior both with and without this code. > After making changes to this file, I am restarting Tomcat, and > I am frequently clearing my browser cache, so hopefully I am > avoiding simple statefulness mistakes. I'm still not entirely sure what could be the difference here. I will admit however that I'm *not* using mod_jk/Apache in my testing. I'm going directly against Tomcat (version 7) on port 8080. You also should obviously make sure that the sitemap.xmap you are changing is the one in the xmlui/ directory that Tomcat is actually using. So, if Tomcat is loading the [dspace.dir]/webapps/xmlui/ directory, then you should edit the sitemap in that location (and not the one under your [dspace-source] directory). I've also done some further work in the ticket yesterday, which may be of interest. https://jira.duraspace.org/browse/DS-1596 I'm now attempting to get common errors (404, even 500) to display within your existing DSpace theme (e.g. Mirage or whatever), rather than displaying that ugly stacktrace page (which is the default). I've linked to a GitHub pull request off that ticket, which is the first attempt (only works for Mirage so far, but will be updated for all Themes). So, that may also be of interest. I'm still not sure what the difference is with the static error pages. I may need to look at this closer to figure out the difference, or just create an "easily installable patch" to ensure we are doing the same thing. - Tim ------------------------------------------------------------------------------ WatchGuard Dimension instantly turns raw network data into actionable security intelligence. It gives you real-time visual feedback on key security issues and trends. Skip the complicated setup - simply import a virtual appliance and go from zero to informed in seconds. http://pubads.g.doubleclick.net/gampad/clk?id=123612991&iu=/4140/ostg.clktrk _______________________________________________ DSpace-tech mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
