We have used SquishIt Framework 0.7.0 to compress the CSS files in our webpage. And when the HPFortify tool is run on the application, it shows the following vulnerabilities
Vulnerability Category Code causing the vulnerability
Injection - SquishIt/SquishIt.Framework/JavaScript/Minifiers/ClosureMinifier.cs:42 CompressFile()
Insecure Direct Object Reference - SquishIt/SquishIt.Framework/Utilities/CssAssetsFileHasher.cs:30 AppendFileHash()
Insecure Direct Object Reference - SquishIt/SquishIt.Framework/Css/Compressors/CssCompressorRegistry.cs:21 <static>()
Insecure Direct Object Reference - SquishIt/SquishIt.Framework/FileResolvers/HttpResolver.cs:16 TryResolve()
Insecure Cryptographic Storage - SquishIt/SquishIt.Framework/Utilities/Hasher.cs:24 GetHash()
Please suggest a way to resolve these vulnerabilities. Or is there an upgraded version of SquishIt with these vulnerabilities resolved?
Thanks Alex. Got the latest SquishIt version 0.9.5 and when we run the HPFortify tool, we get the same issues I have mentioned in my previous post. Could you help us on this?
Thanks Alex. Got the latest SquishIt version 0.9.5 and when we run the HPFortify tool, we get the same issues I have mentioned in my previous post. Could you help us on this?
--
You received this message because you are subscribed to the Google Groups "SquishIt" group.
To unsubscribe from this group and stop receiving emails from it, send an email to squishit+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Yeah the MD5 issue is definitely a false alarm (really they all are). As Paul said MD5 is not being used for cryptographic storage, its being used to generate a hash for cache invalidation. As for the others, there is no plan to stop directly accessing files or web resources - it is kind of central to our goal :)I would expect the CssCompressorRegistry to disappear from the list of issues though, since that class no longer exists.The only one that I see as a real vulnerability is the ClosureMinifier - since that starts a separate process there is a chance of injection, though you would have to mess up pretty badly to get user input in there. I doubt many people use the Closure minifier so I will consider removing it when we go to version 1.0 - and possibly making it available as a separate package.I would think you should be able to talk your way out of these 'issues' fairly easily, as SquishIt is only there to work with assets and shouldn't have any access to sensitive data. But if you can't you should probably look elsewhere for your asset optimization needs. I suspect you would need to move to build-time optimization using something like bundler (https://github.com/ServiceStack/Bundler) if you want to fully eliminate this kind of thing, because you simply can't do this kind of work without directly accessing the files at some point.
Just to close the loop I put an issue up on github to discuss removing the closure minifier from the core library in version 1: