We recently had a third-party cybersecurity team conduct an audit of a custom Glide app we developed for a client. The audit revealed several potential security issues, and we’re seeking your expertise to understand these findings better and determine what can be addressed within Glide’s framework.
Key findings from the audit include:
Vulnerabilities in X-Glide-Attempt and glideCommit parameters, potentially allowing for code injection (Python, SQL, OS commands).
OTP (One-Time Password) related issues:
No limit on OTP entry attempts, making it vulnerable to brute force attacks.
Lack of restrictions on OTP sending, which could be exploited for spam or DoS attacks.
CORS (Cross-Origin Resource Sharing) configuration: Access-Control-Allow-Origin header set to “*”, allowing access from any domain.
Session management concerns:
No automatic session timeout.
Multiple simultaneous sessions allowed for the same user.
Possible page access after logout.
We’d greatly appreciate your insights on:
Which of these issues are inherent to Glide’s platform and which might be due to our custom configurations?
Are there built-in Glide features or best practices we can implement to address these vulnerabilities?
For issues that can’t be directly solved within Glide, what workarounds or alternative approaches would you recommend?
Thank you in advance for your time and expertise. We’re committed to ensuring the security of our Glide apps and value any guidance you can provide.
IMO, these are enterprise requirements that can be addressed by Glide with an enterprise plan. You should contact sales for this, and expect your client to sign up for an enterprise plan as well.
We’ve gone through 2-3 super lengthy processes with Fortune 500 companies, and at the end, they approved Glide.
Sharing Glide’s SOC-2 certification might also help.
Repeated OTP attempts get longer and longer pins with exponentially longer delays on sending you the pin, so your testing firm may not have conducted a thorough test.
Glide conducts regular penetration tests with a top firm, so I am skeptical of some of these other claims as well.
Thanks David
I want to share the comprehensive report complete with screenshots. However, it includes sensitive information that is classified. Could you please advise on a secure platform or method through which I can transmit this data safely?
@Vitor_Guimaraes you can see yourself by trying the wrong pin a few times. These measures are meant to make it infeasible to try hundreds or thousands of pins. If you make a few mistakes, you will still be able to try again.
We always take credible security reports seriously and have started reviewing the claims in this particular one. When we’ve finalized our evaluation we will post our conclusions here to close the loop.
At first glance some of the claims seem a bit far-fetched, in particular the remote code execution ones. As already mentioned, Glide works with top security experts on regular audits, and we’ve also been pen tested by customers multiple times, but we won’t take this lightly.
For those interested in our security posture, we’d encourage you to review our certifications and documentation on the matter: Data Privacy and Security | Glide
We looked at all the reports with severity Medium or higher, and we are confident that they don’t point to any serious vulnerability. Most importantly, the vulnerabilities described concerning code injection are in fact a misinterpretation of how Glide protects the service’s OTP endpoints - i.e. Glide is not subject to code injection vulnerabilities in any way for theX-Glide-AttemptandglideCommitheaders.
As you can imagine, the OTP endpoints have been and will continue to be a topic of discussion for nearly all penetration testing performed by Glide and our 3rd party auditors. These endpoints are continuously hardened and improved to combat abuse.
Our engineering team understands that we should be continuously vigilant in maintaining a secure platform. As with all penetration test results we evaluate, the results of this 3rd party audit have prompted additional discussion on how we might further protect our end users. We will continue to discuss and improve upon several facets of this audit in the upcoming weeks.
Here are our explanations for all the Medium or higher issues from the report:
Section
Explanation
2.1
Injecting code into X-Glide-Attempt did not cause the service to sleep 20. In this case, their attempts to do so happened when the app had backed off sending PIN emails because of excessive requests. This header is only used in logging.
2.2
Injecting code into glideCommit did not cause the service to sleep 20. In this case, their attempts to do so happened when the app had backed off sending PIN emails because of excessive requests. This header is only used in traces.
2.3
We have a backoff algorithm in place to protect against this. Three wrong pin entries causes us to invalidate the PIN and go into a 45 second cool down period where we won’t send any new PIN requests. Continued attempts entering the wrong PIN cause the service to add more digits to the PIN length.
2.4
While they are correct that OTP emails could be sent as an abuse mechanism, given the controls around sendPinForEmail and the fact that the only variable components of an email message can only be altered by the App’s creator, we find the utility of abusing this highly questionable. We don’t have any internal evidence of it being used that way.
2.5
In Glide, private data traveling between the FE and BE processes is locked down to a single domain by Firebase Auth, so we are not vulnerable to this. Still, we will implement this control just in case.
2.6
The user is disconnected after 30 days of inactivity. However, we have opened an issue to discuss whether we should make the timeout period configurable.