Problems with Penetration Tests

Page: 1

Author Post
Member
Registered: Mar 2015
Posts: 5
We are using v4.24 and have had a few issues with some recent third-party penetration tests and code scans. A couple of the issues reference Webinspect detecting the existence of archive files with the extension of .gz. They also complain about there be references to flash objects and URLs in some other file.

Have you had any of this type of testing done against your code and resolved these issues in newer versions? If not, is it set in stone that all of the files in your package have to be deployed to our server or can we remove the .gz files and possibly other files that are triggering the failures?
Administrator
Registered: Aug 2008
Posts: 3382
The .gz files can be removed if you want. Serving gzip versions of javascript and css files reduces files size, speeds up page loading, and is considered best practice. To use the .gz files, you need to specifically activate them on your server, as described in the docs at http://floatboxjs.com/instructions#gzip.

It is bogus of WebInspect to complain about the presence of gzip files. These are not archive files and are not encrypted or password protected. A security scanning tool should simply uncompress the files (as all browsers do) and run the scan against the uncompressed code - a trivial and helpful procedure.

In fact, it's probably a good idea for folks using gzip files provided by a 3rd party to uncompress those files and confirm that they are the same as the uncompressed script files provided by doing a file comparison.


There are no flash (.swf) files in the Floatbox package, nor any references to any .swf files. Floatbox supports the showing of flash content if you want to use it for that. Consequently, it does have code in it for creating HTML <object> elements to display user-provided flash content, which of course will not get triggered unless your using the Flash functionality. Any security vulnerabilities in this scenario will be in the .swf Flash files used, which are not provided by nor part of Floatbox (and which are easily be scanned by security tools).


The Floatbox code interacts with the YouTube and Vimeo javascript APIs to fetch thumbnail images and other info for videos shown in Floatbox. Hence it contains the external URL paths of these API services. This functionality, like the ability to create Flash objects if you want to, is part of the core package and can be removed only by removing the Floatbox package itself.
Member
Registered: Mar 2015
Posts: 5
Thank you for that detailed information. The entire penetration test is full of bogus results that has been killing me for months, but I guess that is how they make their money.

We are .NET on IIS. I see from the info in your link that IIS doesn't utilize the gzip files anyway, so I'll just remove them.

I'll find exactly what they are complaining about as far as Flash and other URLs and post back here - if you are interested in that.

Thank You.
Administrator
Registered: Aug 2008
Posts: 3382
Security vulnerability scanners are certainly a mixed blessing for IT shops. They are great for shining a light into your site and possibly revealing potential problems that would have gone unnoticed otherwise. Necessarily, they are going to flag "issues" that could, under certain circumstances, be used in an exploit. It takes a tech with understanding of the issues to determine if the flagged items are of legitimate concern. The nightmare begins when a manager gets involved who sees the vulnerability reports and, with all good intentions, insists that each line item must be addressed until the scanner comes back with no potential issues found.

External URL references are a good example. Vulnerability scanners should report all that they find so that site admins can confirm that only known and trusted sources are on the list. A misguided attempt to remove all external references results in an inability to use basic modern www functionality such as loading fonts from google, or fetching jquery from a common source, or any APIs such as geo-IP information lookup, weather widgets, video services, etc., or anything to do with content distribution systems - all best practices denied.

Thanks, but no I don't need to see the details of the flash object code or external URLs. I already know exactly where and what they are.

Cheers...

Page: 1