IV97281: Malicious file uploads by bypassing JavaScript validation


Malicious file uploads are possible by bypassing the JavaScript validation, even after the appropriate properties are set to restrict EXE files.

Moving forward, we resolved an issue where malicious files can be uploaded via document upload by bypassing the client side validation.

[Admin: This post is related to the 01.25.16 post and 07.18.15 post about restricting the upload of certain file types. To see other related posts, use the Vulnerability tag or CVE tag.]

Continue reading

Advertisements

Having an issue with restricting the upload of certain file types


In the TRIRIGAWEB.properties file, I’m using the following variables to restrict .exe files from being uploaded to TRIRIGA: IMPORT_CONTENT_EXCLUDE_EXTENSIONS and IMPORT_CONTENT_INCLUDE_EXTENSIONS. I want to “protect” Document Manager and Notes & Documents on the triWorkTask form from .exe files.

I tried to limit .exe files using the exclude extension only property, and even when I included “.exe”, it doesn’t stop that type of file from being uploaded. Then, I tried using the include extension property, setting it to accept only “.txt” files, but TRIRIGA still allows .exe files to be uploaded on Document Manager and the triWorkTask form. Has anyone tried to use that setting on 3.4.2.1? Was it successful? Any advice to prevent TRIRIGA from uploading .exe files?

Please apply 3.4.2.3 fix pack. This is caused by APAR IV82434.

[Admin: This post is related to the 07.18.15 post about using TRIRIGAWEB.properties to restrict certain file types from upload.]

Continue reading

Are you having trouble installing CAD Integrator 12.1.x?


CI versions 12.1.0 and 12.1.1 only support Java 7. However, a client may have Java 8 installed for other applications. On some machines, the CI installer will not run, and instead, output this error message…

There are a few ways to resolve this, but the best method is this one: (1) Go to C:\Windows\System32, (2) Find the java.exe, javaw.exe, and javaws.exe files, and move them to some unused folder (or delete them). This appears to be a bug in InstallAnywhere, combined with the behavior of the Java 1.6 and 1.8 installers.

Continue reading