This is seriously affecting our IT Security compliance efforts as it appears to our regulators and auditors that our service provider is not taking security seriously, and we may be forced to switch to an alternative supplier.
I know these problems have been reported to Hubspot previously and yet no action has been taken.
Can you please provide an update on Hubspot's intention to either ignore security standards and best practice so we can make a quick decision to move supplier, or state when you intend to resolve these issues.
Continued security weaknesses being ignored by Hubspot
We also are experiencing similar issues and we believe security parameters must be a default. Our site is badly scored because of this by many third parties.
Continued security weaknesses being ignored by Hubspot
After performing scans for our site just this month I am seeing those same issues and others that shouldn't be there. Most issues are simple fixes they can make to their servers and site base header templates.
HubSpot needs to fix these issues or risk losing customers to another CRM that takes security seriously.
"
No Anti-CSRF tokens were found in a HTML submission form. A cross-site request forgery is an attack that involves forcing a victim to send an HTTP request to a target destination without their knowledge or intent in order to perform an action as the victim. The underlying cause is application functionality using predictable URL/form actions in a repeatable way. The nature of the attack is that CSRF exploits the trust that a web site has for a user. By contrast, cross-site scripting (XSS) exploits the trust that a user has for a web site. Like XSS, CSRF attacks are not necessarily cross-site, but they can be. Cross-site request forgery is also known as CSRF, XSRF, one-click attack, session riding, confused deputy, and sea surf.
CSRF attacks are effective in a number of situations, including: * The victim has an active session on the target site. * The victim is authenticated via HTTP auth on the target site. * The victim is on the same local network as the target site.
CSRF has primarily been used to perform an action against a target site using the victim's privileges, but recent techniques have been discovered to disclose information by gaining access to the response. The risk of information disclosure is dramatically increased when the target site is vulnerable to XSS, because XSS can be used as a platform for CSRF, allowing the attack to operate within the bounds of the same-origin policy.
Continued security weaknesses being ignored by Hubspot
Regarding this:
"
1. X-Frame-Options
The challenges with these kinds of HTTP headers are that it is easy to break expected website functionality. Unexpected behavior related to the headers takes expertise to troubleshoot; and the header construct needs to be updated regularly as content structure is changed. This header is designed to prevent HTML or javascript from working in certain (and possibly intended) cases. For instance, if X-frame-options was implemented by default, then customers would need to pre-identify all domains on which they wanted to frame landing pages and other content. This would add complexity to the customer experience without appreciably lowering the risk of clickjacking.
With that said, it is possible to embed mechanisms like frame busting (i.e., equivalent to X-frame-options) into the HTML header of your sites where you deem appropriate. Those options give you control over how additional protections are implemented. If you decide to implement the functions in HTML, please be aware that domain-agnostic frame-busting javascript will interfere with typical use of content editing features in your HubSpot portal. In particular, the preview pane you see when you're editing a blog post, email, or website is presented within a frame. If you configured that page (or the design layout) to prevent iframes, it's possible that you won't be able to use the content editing tools that are available in your portal."
Is Hubspot acquiring any "expertise" to fix these issues? This issue was reported early this year and Hubspot is still regurgitating the same info(above). I think customers just want to know if Hubspot is doing anything to fix the issue other than telling customers to frame-bust in exchange for content editing functionality.
Continued security weaknesses being ignored by Hubspot
What if Hubspot writes some logic that allows customers to implement these headers if we want... and disables the headers when the customer is logged in and has access to the inline editing features?
Continued security weaknesses being ignored by Hubspot
We agree. Our automatically generated security score from sites like securityscorecard.io is lowered due to this issue (X-Frame-Options). It would be great if we had a toggle to activate these on demand.
Thank you for your feedback! I appreciate you bringing these questions to the Community. I wanted to share the following status updates with you:
1. X-Frame-Options
The challenges with these kinds of HTTP headers are that it is easy to break expected website functionality. Unexpected behavior related to the headers takes expertise to troubleshoot; and the header construct needs to be updated regularly as content structure is changed. This header is designed to prevent HTML or javascript from working in certain (and possibly intended) cases. For instance, if X-frame-options was implemented by default, then customers would need to pre-identify all domains on which they wanted to frame landing pages and other content. This would add complexity to the customer experience without appreciably lowering the risk of clickjacking.
With that said, it is possible to embed mechanisms like frame busting (i.e., equivalent to X-frame-options) into the HTML header of your sites where you deem appropriate. Those options give you control over how additional protections are implemented. If you decide to implement the functions in HTML, please be aware that domain-agnostic frame-busting javascript will interfere with typical use of content editing features in your HubSpot portal. In particular, the preview pane you see when you're editing a blog post, email, or website is presented within a frame. If you configured that page (or the design layout) to prevent iframes, it's possible that you won't be able to use the content editing tools that are available in your portal.
2. X-XSS
Most modern browsers default to 'X-XSS-Protection: 1'. That means that the browser will prevent a detected cross-site scripting attack by default, and doesn't require a header from the visited website to protect itself.
3. X-Content Type-Options
The HubSpot platform does not set the X-Content-Type-Options header to 'nosniff'. Rather, we set a MIME type so sniffing does not occur in general. The HubSpot platform automatically sets a MIME type for javascript and CSS files, in particular.
HubSpot will not be modifying these policies for the reasons outlined above.
Thanks for your answer, however in our case it is not valid. According to this page you can only make these security settings on the CMS Hub. We however, don't use the CMS Hub, but we do use the landingpages.
And in my opinion landingpages can be extra vulnerable since they always ask for information from the visitor.
Will it be added as an option? Or as a basic setting? Otherwise we will be forced to move our landingpages away from Hubspot.
Continued security weaknesses being ignored by Hubspot
I was directed here by HubSpot support after asking about the X-Frame-Options header.
I understand that using the header can break things, but my objection to the response given here is that HubSpot already has multi-domain X-Frame-Options configuration as a feature in Enterprise. It isn't a new feature request -- you already solved it. My organization doesn't need Enterprise, and we don't want to configure the header for multiple domains. We feel that in our simple case, it should be possible to enable this basic protection for our single domain, and advanced users can pay for the advanced usage if they need it.
Secure defaults should be HubSpot's defaults wherever possible, and best practices shouldn't require an Enterprise license, in my opinion.
