SquishIt vulnerabilities

185 views
Skip to first unread message

dharshini.s...@gmail.com

unread,
Nov 13, 2013, 8:33:21 AM11/13/13
to squi...@googlegroups.com

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? 


Alex Ullrich

unread,
Nov 16, 2013, 9:44:16 AM11/16/13
to squi...@googlegroups.com
0.7 is extremely out of date at this point. If you upgrade to a newer version (preferably the current beta release from nuget) and post the report results I will see if the issues can be fixed without limiting functionality.

dharshini sathiyendran

unread,
Dec 4, 2013, 4:59:21 AM12/4/13
to squi...@googlegroups.com

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?

Paul Bravey

unread,
Dec 4, 2013, 6:01:21 AM12/4/13
to squi...@googlegroups.com
The last 'issue' came up recently for me - its probably just HPFortify complaining because you're using MD5 which is generally considered an insecure algorithm. The tool isn't intelligent enough to realise that MD5 is just being used to generate a (semi-)unique file name and not for any cryptographic purposes. The only way to stop it complaining would be to switch to a stronger hashing algorithm (e.g. SHA256) but, of course, you have to pay the performance penalty associated with that.


On Wed, Dec 4, 2013 at 9:59 AM, dharshini sathiyendran <dharshinis...@gmail.com> wrote:

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.

Alex Ullrich

unread,
Dec 4, 2013, 8:11:53 AM12/4/13
to squi...@googlegroups.com
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.

Alex Ullrich

unread,
Dec 4, 2013, 8:20:28 AM12/4/13
to squi...@googlegroups.com
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:

Reply all
Reply to author
Forward
0 new messages