The following article provides answers to questions that may come up in cyber security audit reports conducted by third-party organisations.
Some of the reports that you may receive may not be an accurate representation of the security provisions in place on your Juniper Education website(s), as some reports include false positives.
Answers to the following areas are provided in the report:
Application Security
- Redirect Chain Contains HTTP.
- Content Security Policy (CSP) Missing.
- Content Security Policy Contains Broad Directives.
- Unsafe Implementation Of Subresource Integrity.
DNS Health
Content Security
- Site Does Not Use Best Practices Against Embedding Of Malicious Content.
- Website Does Not Implement X-Content-Type-Options Best Practices.
- Website Does Not Implement HSTS Best Practices.
Web Server Configuration
- SSL Version 2 And 3 Protocol Detection.
- SSL Medium Strength Cipher Suites Supported (SWEET32).
- HSTS Missing From HTTPS Server (RFC 6797).
- SSL RC4 Cipher Suites Supported (Bar Mitzvah).
- SSLv3 Padding Oracle On Downgraded Legacy Encryption Vulnerability (POODLE).
- TLS Version 1.1 Protocol Deprecated.
- HTTP TRACE / TRACK Methods Allowed.
JavaScript Security
Application Security
Redirect Chain Contains HTTP
Report from third parties: Site redirects through URLs that are not secured with HTTPS; this leaves users vulnerable to being redirected to a spoofed/ malicious version of the intended destination site.
Resolution suggestion from third parties:
- Ensure all URLs involved in the redirect chain use HTTPS to encrypt the communication between the user and the server.
- Review and update any outdated or unsecure redirects, replacing HTTP with HTTPS where necessary.
- Use relative paths in redirects to avoid specifying the protocol, allowing the browser to maintain the current secure connection.
- Verify that server configurations and web server settings are appropriately configured to enforce HTTPS throughout the redirect chain.
- Periodically review and update redirects to align with security best practices and accommodate changes in website structure or requirements.
Answer: Regarding the "Redirect Chain Contains HTTP" flagged in the report, we want to assure you that this issue has already been addressed and resolved some time ago. We took immediate action to secure the redirect URLs with HTTPS, eliminating any potential vulnerability that could have left users at risk of being redirected to a spoofed or malicious version of the intended destination site.
We understand your concern about false positives in online security audits, but rest assured that we take the security of your website seriously and have taken all necessary measures to safeguard it against potential threats.
Content Security Policy (CSP) Missing
Report from third parties: A Content Security Policy (CSP) directive tells a web browser what locations it can load resources from when rendering a webpage. This helps prevent mistaken or malicious resources from being injected into a webpage (and then executed by a user’s browser).
Our websites do not implement CSP (see Content Security Policy (CSP) for further information).
Additional Information:
The report accurately notes the absence of a Content Security Policy (CSP) on our websites. It's important to clarify that our websites intentionally do not implement a CSP universally. This decision is made to maintain the flexibility you enjoy when adding content to your website.
Instead of a CSP, we've implemented a comprehensive set of security measures to ensure the safety of both you and your website visitors. These measures are designed to guard against the same types of attacks that a CSP typically protects against.
Rest assured, your website's security remains a top priority for us, and we're committed to providing you with a safe and flexible platform.
Content Security Policy Contains Broad Directives
Report from third parties: When a Content Security Policy (CSP) is configured with overly broad settings, it opens the door to potential security vulnerabilities. In such cases, directives like 'script-src', 'object-src', or 'default-src' may be defined with permissive values like 'http:', '', or 'http://'. This allows the browser to load resources from a wide range of sources, including potentially malicious domains. This lack of specificity compromises the intended protection against Cross-Site Scripting (XSS) attacks as adversaries could inject and execute malicious scripts.
Resolution suggestion from third parties:
- Specify exact domains for trusted sources in directives like 'script-src' and 'style-src' instead of using overly broad values like '', 'http:', or 'http://'.
- Minimize the use of wildcard characters and avoid permissive settings to enhance the precision of the Content Security Policy (CSP).
- Utilize HTTPS to secure connections and minimize risks associated with loading resources from untrusted or potentially unsecured sources.
Implement nonce or hash values for inline scripts to maintain security while allowing specific exceptions.
- Regularly review and update the CSP configuration to adapt to changes in the application and address emerging security concerns.
- Test and monitor the CSP to ensure its effectiveness,
identifying and addressing any unexpected behaviour or attempts to bypass security measures. - Educate development teams on the importance of a well defined and specific CSP to strengthen overall web security.
Answer: Our websites do not implement CSP (see Content Security Policy (CSP) for further information).
Additional Information: Juniper websites do not currently apply a Content Security Policy across the board, doing so would remove some of the freedoms you currently have when adding content to your website. Instead, we have taken extensive measures to protect you and your website visitors from the kind of attacks that the CSP protects against.
Unsafe Implementation Of Subresource Integrity
Report from third parties: Without SRI, externally loaded resources, like scripts and stylesheets, lack integrity verification. This makes them susceptible to tampering. This creates a potential avenue for attackers to inject malicious scripts, which leads to Cross-Site Scripting (XSS) vulnerabilities, unauthorized data access, and other security threats.
Resolution suggestion from third parties:
- Ensure accurate cryptographic hashes are specified for all externally loaded resources using SRI attributes in the HTML.
- Routinely review and update cryptographic hashes to align with changes in resource content.
- Implement robust input validation and sanitization practices to prevent injection attacks.
- Use CSP to restrict resource sources. This adds an extra layer of control over content execution.
- Conduct regular security audits and penetration testing to promptly identify and address vulnerabilities.
Answer: The Juniper Websites platform takes the following measures to protect the platform and its users from CDN supply chain attacks:
- Where possible, we will not load libraries from an external CDN, but include them in the Juniper Websites platform to ensure reliability.
- In the rare cases where it is necessary to use an external CDN, we only use reputable providers that are known for reliability and robust security measures. This includes payment providers such as Stripe and PayPal, as well as trusted companies such as Google and Facebook.
- The Juniper Websites platform is regularly audited and monitored using trusted vulnerability detection software to detect any potential vulnerabilities.
To strengthen our security posture we audit the platform's use of external CDNs and, where the CDN provider supports it, implement Sub-Resource Integrity (SRI). SRI verifies that the code we receive from these providers hasn't been tampered with. This additional layer will further help to safeguard your website by preventing compromised library code from loading and potentially causing harm.
We can provide a list of external CDNs that do not support SRI, such as Stripe, with reasons why we trust the external source and are unable to utilise an SRI for that external CDN.
DNS Health
SPF Record Contains A Softfail without DMARC
Report from third parties: The risk of an SPF record soft fail without DMARC is the potential for email spoofing and phishing attacks to go undetected. Without strict authentication policies in place, malicious actors can send emails that appear to originate from legitimate domains. This can lead to compromised systems, data breaches, and damage to the affected domain's reputation. Additionally, without clear guidance on how to handle SPF failures, recipients may lack consistent protection against fraudulent emails, increasing the likelihood of successful phishing attempts and other forms of cybercrime.
Resolution suggestion from third parties:
- Implement a DMARC policy with an enforcement action (p=quarantine or p=reject) to specify how to handle SPF failures.
- Regularly review and update SPF records to accurately reflect authorized sending sources.
- Consider implementing additional email security measures such as DKIM (DomainKeys Identified Mail) and DMARC to enhance email authentication and protection.
- Monitor email traffic and analyze SPF alignment to identify and respond to unauthorized senders or anomalies in email authentication.
- Educate users about phishing risks and encourage vigilance when handling suspicious emails.
Answer:
If your Juniper Website attempts to send email that comes from your domain, to ensure email deliverability your domain controller should implement email authentication methods such as SPF, DKIM and DMARC for the domain. At least one of SPF or DKIM is required for deliverability to some providers such as GMail. Implementing these three methods will protect your organisation and your email recipients from email spoofing. It will also help email providers to verify the authenticity of the emails sent by the website, ensuring that your messages are not filtered or marked as spam.
If your Juniper Website uses the Secure Email module to send emails out to mailing lists we recommend your domain controller enables all three of these methods (SPF, DKIM and DMARC) for the sending domain, as email providers such as GMail require bulk senders to implement all three of these email authentication methods. Different email providers have different requirements, but enabling these authentication methods will help ensure the deliverability of your emails to different inboxes.
Content Security
Site Does Not Use Best Practices Against Embedding Of Malicious Content
Report from third parties: We observed that this organisations website does not use best practiced to prevent threat actors from embedding its content in a frame on untrusted or malicious websites. Threat actors can take advantage by staging clickjacking attacks, which involves tricking site visitors into clicking malicious objects that cause them to reveal confidential information. For example, a user may click a "Like" on a clickjacked page and then their browser or computer is compromised.
Answer: Our websites do not implement CSP (see Content Security Policy (CSP) for more information).
Additional Information: Juniper Websites does not apply a Content Security Policy across the board. Doing so would remove some of the freedoms you currently have when adding content to your website. Instead, we have taken extensive measures to protect you and your website visitors from the kind of attacks that the CSP protects against.
Website Does Not Implement X-Content-Type-Options Best Practices
Report from third parties: A MIME type is an HTTP Header that indicates the type of content returned in a response and how it should be handled and displayed by the browser.
Browsers will sometimes analyse the content themselves and handle it counter to the MIME type header: this can lead to security issues and execution of malicious code.
The X-Content-Type-Options header indicates that browsers should always trust the declared MIME type from the server and not attempt to analyse the content themselves.
Answer: Our websites implement X-Content-Type-Options best practices.
Website Does Not Implement HSTS Best Practices
Report from third parties: Even if a website is protected with HTTPS, most browsers will still try first to connect to the HTTP version of the website unless explicitly specified. At that moment, visitors to the website are vulnerable to a man-in-the-middle attacker that can prevent them from reaching the HTTPS version of the website they intended to visit and instead divert them to a malicious website. The (expand) HSTS header ensures that, after a user's initial visit to the website, that they will not be susceptible to this man-in-the-middle attack because they will immediately
connect to the HTTPS-protected website.
Answer: Our websites implement HSTS best practices.
Web Server Configuration
SSL Version 2 And 3 Protocol Detection
Resolution suggestion from third parties: Use TLS 1.2 (with approved cipher suites) or higher instead.
Answer: LS 1.0 and 1.1 are both disabled for our websites. All cipher suites are current and we do not support any cipher suites that use RSA key exchange.
SSL Medium Strength Cipher Suites Supported (SWEET32)
Resolution suggestion from third parties: Reconfigure the affected application if possible to avoid use of medium strength ciphers.
Answer: TLS 1.0 and 1.1 are both disabled for our websites. All cipher suites are current and we do not support any cipher suites that use RSA key exchange.
HSTS Missing From HTTPS Server (RFC 6797)
Resolution suggestion from third parties: Configure the remote web server to use HSTS
Answer: Our websites follow HSTS best practices. If you have received reports indicating otherwise, please let us know which tool you are using to generate the report, so we can investigate further.
SSL RC4 Cipher Suites Supported (Bar Mitzvah)
Resolution suggestion from third parties: Reconfigure the affected application, if possible, to avoid use of RC4 ciphers, Consider using TLS 1.2 with AES-GCM suites subject to browser and web server support.
Answer: TLS 1.0 and 1.1 are both disabled for our websites. All cipher suites are current and we do not support any cipher suites that use RSA key exchange.
SSLv3 Padding Oracle On Downgraded Legacy Encryption Vulnerability (POODLE)
Resolution suggestion from third parties: Disable SSLv3. Servers that must support SSLv3 should enable the TLS Fallback SCSV mechanism until SSLv3 can be disabled.
Answer: TLS 1.0 and 1.1 are both disabled for our websites. All cipher suites are current and we do not support any cipher suites that use RSA key exchange.
TLS Version 1.1 Protocol Deprecated
Resolution suggestion from third parties: Enable support for TLS 1.2 and/or 1.3, and disable support for TLS 1.1.
Answer: TLS 1.0 and 1.1 are both disabled for our websites. All cipher suites are current and we do not support any cipher suites that use RSA key exchange.
HTTP TRACE / TRACK Methods Allowed
Resolution suggestion from third parties: Disable these HTTP methods. Refer to the plugin output for more information.
Answer: HTTP TRACE and TRACK methods are not supported by Juniper Websites.
JavaScript Security
SECURE JavaScript Libraries
Report from third parties: Intruders can exploit outdated JavaScript libraries.
Resolution suggestion from third parties: Using the latest version of each library and updating it regularly will help keep you safe.
To address the potential security risks related to JavaScript libraries, we recommend the following actions:
- Update JavaScript Libraries: Ensure that you are using the latest versions of all JavaScript libraries employed in your web development projects. Developers frequently release updates to fix bugs and address security vulnerabilities.
- Regularly Check for Updates: Implement a process to regularly check for updates to JavaScript libraries and apply them promptly. This will help keep the websites protected against emerging security threats.
- Security Code Review: Conduct a thorough code review of the JavaScript libraries utilized in your projects. Look for any known vulnerabilities or potential weaknesses and address them accordingly.
- Monitor Security Advisories: Stay informed about security advisories and announcements from the developers of the JavaScript libraries we use. This will help us proactively respond to any reported vulnerabilities.
- Consider Alternative Libraries: If any of the currently used libraries pose significant security risks and there are safer alternatives available, evaluate the possibility of migrating to more secure options.
- Implement Content Security Policy (CSP): Deploy a Content Security Policy (CSP) to mitigate the risk of Cross-Site Scripting (XSS) attacks. This policy will specify which sources of content are considered legitimate, helping prevent malicious script execution.
- Educate Developers: Ensure that your development team is aware of best practices and security guidelines when working with JavaScript libraries. Encourage secure coding practices and provide training if necessary.
Answer: This was updated at the beginning of 2023.
jQuery 1.2 <3.5.0 Multiple XSS
Report from third parties: The remote web server is affected by multiple cross site scripting vulnerability.
Resolution Suggestion: Upgrade to JQuery version 3.5.0 or later.
Answer: To avoid disrupting the integrity of your website our approach is to actively monitor and directly squash the root cause of XSS issues. We have applied modern jQuery XSS protection practices to our existing codebase.
Updated