PaperCut uses an embedded web server called Jetty. Although the out-of-the box security related settings should suit most sites, in some situations there site-specific options that may improve security. For general security related questions be sure to see Common Security Questions and Tell me about PaperCut’s security.
Q: Can I use/install my own SSL certificate?
Yes, see the user manual section , which includes instructions for both generating a new SSL certificate and installing an existing SSL certificate.
Q: Can PaperCut NG and PaperCut MF ensure that connections to the web server are made over HTTPS using SSL?
Most definitely; the application can be configured to automatically redirect access attempts made over plain HTTP over to secure HTTPS. Furthermore, PaperCut NG and PaperCut MF 17.1 and beyond support HSTS, or HTTP Strict Transport Security, reinforcing our ability to keep connections routed over HTTPS. In conjunction with supported web browsers, HSTS allows for automatic HTTPS redirections to be enforced at the client level, with the browser itself repointing HTTP requests over to HTTPS at the behest of our web server.
Check out the relevant Knowledge Base article for instructions towards configuring these features in your environment.
Q: I’m running a highly secure deployment, and notice that the application uses session cookies. How can I be sure these are being handled safely?
As of version 17.1 of PaperCut NG and PaperCut MF, a session cookie generated for access originating over a secure connection is automatically provided alongside both the “Secure” and "HttpOnly" flags within the HTTP response header. The “Secure” flag ensures that the details of a session cookie will not be disclosed if a browser subsequently requests the information over a plain HTTP connection, whilst the "HttpOnly" flag dictates that the cookie can only be accessed by the server itself, minimising the chance of it being intercepted and interpreted by a third party. For sites with particularly rigorous concerns around cookies, additional configuration can allow these flags to be included uniformly for all other cookie types issued by the web server; contact the PaperCut Support team for more information along these lines.
Q: I use a NAT, and I can forge/create an HTTP request that exposes PaperCut’s “internal” IP address. How can I prevent this?
(This question also applies to security audit software that may report something like “Web Server HTTP Header Internal IP Disclosure”)
PaperCut’s web server requires the ability to redirect users to new pages. When performing a redirect, the target location is based on the Host header that the web browser requested. If the host header is omitted (e.g. by manually crafting an HTTP request), the target location is based on the server’s own hostname or IP address. In a NAT environment this may not be ideal if the server’s IP address is considered private.
As of PaperCut version 11.3, the web server may be “forced” to redirect to a defined host name. If this option is used, it is important that all users access PaperCut via this defined host name, and that this host name is accessible to all users. To enable this option:
[app-path]/server/server.properties in a text editor.
2. Add the line:
printing.uni.edu is the fully qualified host name that all users will access PaperCut on.
3. Restart the service
PaperCut Application Server
4. Test access to the web interface (using both HTTP and HTTPS if applicable).
Keywords: web security, security audit, IP address leak