Reporting New Security Problems with Apache JSPWiki#

The Apache Software Foundation takes a very active stance in eliminating security problems and denial of service attacks against its products.

We strongly encourage folks to report such problems to the private security mailing list first, before disclosing them in a public forum.

Please note that the security mailing list should only be used for reporting undisclosed security vulnerabilities and managing the process of fixing such vulnerabilities. We cannot accept regular bug reports or other queries at this address. All mail sent to this address that does not relate to an undisclosed security problem in our source code will be ignored.

If you need to report a bug that isn't an undisclosed security vulnerability, please use the project's JIRA issue tracker.

The private security mailing address is: security@apache.org.

The process of handling a possible vulnerability is described here.

Asking Questions About Known Security Problems#

Questions about:

• if a vulnerability applies to your particular application
• obtaining further information on a published vulnerability
• availability of patches and/or new releases

should be addressed to the users mailing list. Please see the mailing lists page for details of how to subscribe.

Known Security Vulnerabilities#

Known security vulnerabilities fixed in released versions of Apache JSPWiki are listed at the CVE page.

If you have encountered an unlisted security vulnerability or other unexpected behavior that has security impact, or if the descriptions in one of the pages are incomplete, please report them privately to the Apache Security Team. Thank you.

Errors and Omissions#

Please report any errors or omissions to the dev mailing list.

Related Articles#

• JSPWikiFeatures
• Wiki.Admin.Security
• AdminPages

Hardening Guidance#

The term Hardening in the software industry is effectively ensuring that your installation is as secure as possible against attack, i.e. hardened from attackers. That said, we've have attempted to keep the default settings secure by default (specifically starting with version 3.0.0, however security is always a trade off between making the system useful for your users and making it secure.

That said, here's some guidance to get you going.

• Use TLS/SSL with currently known safe algorithms.
• Review your jspwiki-custom.properties and the default jspwiki.properties. Specifically look for unsafe or dangerous settings that are flipped, such as jspwiki.translatorReader.allowHTML=true. It is false by default. Enabling it well let users inject html and javascript into your wiki pages. This can be useful but it is generally not worth the security risk.
• After installation, delete Install.jsp. It's only accessible to administrators, but could provide some sensitive information to an attacker. It's safer to remove it since it's not normally used unless something went wrong.
• Keep your JDK and container (i.e. Tomcat) update to date
• Subscribe to the JSPWiki Mailing list for security advisories, software update notifications, as well as the container (i.e. Tomcat)
• Set the file permissions to the recommended file permissions set for your container. There's tons of guidance in the Security Technical Implement Guides (STIGs)
• Restrict access to JSPWIki for only the users that need access. This can be done via IP Filtering in tomcat, firewalls, and of course via access controls.
• Use an antivirus software with on write scanning. This is specifically for file attachment uploads (assuming you're using the file system based attachment provider)
• Restrict file uploads to only what is required for your user base and use a reasonable size limit for them.
• Use TLS/SSL communications with your mail server (if in use) and with your JDBC connections (if in use).
• Don't install plugins if you don't trust the source.
• Disable any plugins that you don't want your users to use.
• Use Page access control lists to control who can read or write to critical pages.
• Set the jspwiki-custom.property setting for jspwiki.workDir to a path and secure it's access. It should be owned by the same user as the container (i.e. Tomcat), read/write access and deny all to everyone else.
• New Features in v3.0.0
  • Use the Audit Logger and wire it up to a mail server to get real time alerts of out of the ordinary behavior
  • If using JSPWiki's authentication mechanisms (XML or JDBC database user stores), use an appropriate password policy for your environment.

Threat Models#

Known threat models for JSPWiki

Managing spam on public facing servers#

TODO - more content is needed here.

Use Captcha plugins

Use the rate limiting plugin

Disk space allocation#

Wiki pages do not currently have any way to restrict the total number of attachments, or the total size of attachments. Monitor disk space usage as needed and beat up your users with high disk space usage. Attachments by default are version controlled, so each version of an uploaded file is retained.

Injection attacks#

JSPWiki will let you NOT let you inject javascript into a wiki page, assuming jspwiki.translatorReader.allowHTML=false which is the default however cascading style sheet content can be inserted wiki pages. This is primarily used to stylize or override specific parts of the UI's styling, but some malicious activity could be possible here.

Wiki plugins also have protections built in to help stop all known attack vectors for injection attacks, however 3rd party plugins may not have those safe guards in place. Do not install untrusted 3rd party plugins without performing a security assessment.

Ports Protocols and Services#

• JSPWiki is a web application and does web application like things. It can run on any port that you configure, HTTP or HTTPS/TLS, etc.
• JSPWIki can optionally send emails through whatever ports are required for your email setup.
• JSPWiki needs to be able verify user credentials and get user attributes from some where. It can handle it stand alone (XML file) or optionally connect to a database, but often times you may wish to integrate into some other type of user store, such as LDAP, Active Directory, Keycloak, etc. There are multiple ways to do this but are generally container (i.e. Tomcat/Jboss) specific or involve the integration of Keycloak's Java libraries. What they do is outside of our control.
• JSPWiki stores wiki content and attachments somewhere. Default is to disk, however there are plugins in the wild that will use a database to store this information. This is a potential outbound connection.
• JSPWiki uses Log4j2 for logging, which can be redirected to a syslog type server or to a variety other services. For details on this, see the Log4j website. Configuration and the "PPS" part of this is outside of the scope of JSPWiki.

Other than that, JSPWiki really does NOT connect to anything else (i.e. there's no reach back to Apache or the Internet for that matter).

Some plugins may reach out to other servers to pull information and format it for display. Once such is the JiraPlugin.

To summarize:

• Input bound on a port of your choice for HTTP/HTTPS web traffic.
• No SOAP services are used, just REST like interfaces.
• Outbound is configuration dependent but may include databases, SMTP for sending mail