Free Support Forum - groupdocs.com

Security Practices


#1

Do you have any documentation related to security practices when using GroupDocs.Viewer’s Java libs? E.g. what security settings can be made, how does the library protect against corrupted or malicious files, which external libraries are used to render the documents, etc.?



Do you have penetration test reports that show that malicious files don’t harm the system where GroupDocs.Viewer’s Java libs are used?


#2

Hi Thomas,


Thanks for getting in touch!

You’ll be glad to hear that GroupDocs.Viewer for Java when used in Image based mode is immune to all malicious document attacks. I need to check with the team to confirm if our HTML based rendering mode is also immune.

GroupDocs.Viewer for Java does not depend on any external libraries for rendering documents to images outside of our own internal rendering engine libraries.

In general JS is never evaluated by our internal rendering engine. If you have some malicious documents that you’d like to share with us, we’d gladly setup a demo for you to show Image based and HTML based modes of GroupDocs.Viewer for Java?

I look forward to hearing from you,

Take care,

Derek

#3

Thanks for the quick feedback.



It’s good to know that JS is never evaluated. Does this also apply to the .msg format?



How about other embeddable languages like VBA in MS office documents, or Excel functions like WEBSERVICE that pull date from external sources.



Are linked images displayed from external sources?



Basically we need to make sure that no embedded code from viewed documents is executed, no data is pulled from the web or disk, no data is sent to disk or web and that only whitelisted functions are executed or at least dangerous functions are blacklisted.



How are corrupted files handled that try to trigger a buffer overflow or other attack to inject code?


#4
Hi Thomas,

Yes, this is also applied to .msg and other formats. No embedded functionality is executed. The GroupDocs.Viewer for Java library is the viewing software. It means that the Viewer is only rendering document contents and does not execute internal scripts/functions/macroses. Also no data is retrieved using some internal document connection strings, etc.

Corrupted files should be handled with raising appropriate exception. But we did not test it. Do you have some files to check this use-case? It would be nice if you provide some test files, so we can check this particular situation.