Security researchers have found a cross-site scripting (XSS) vulnerability on the Salesforce website, that could be exploited by malicious hackers to conduct phishing attacks and hijack the accounts of users.
The researchers at Elastica report that they uncovered the weakness on one of Salesforce’s subdomains, admin.salesforce.com.
Elastica summarised potential ways in which the XSS flaw could be exploited:
- The attacker could have forced Salesforce users to visit phishing sites to potentially extract credentials via social engineering tricks. The attacker could have also also injected pop-up windows to facilitate Phishing attacks, which we are going to demonstrate in this blog post.
- The attacker could have forced the users to download malicious code on their machines by executing unauthorized scripts in the context of the browser running a vulnerable application.
Perhaps the simplest, and most effective attack, would be to trick users into visiting a link to the legitimate admin.salesforce.com site, only to be greeted by a phishing dialog stealing their username and password:
Of course, no company wants to have a security flaw like this on its website, which could leave its customers at risk, and it’s good to see that Salesforce has now fixed the issue responsibly.
That’s a much better approach than putting your head in the sand, and hoping the problem will go away, or claiming that the threat is not serious or has not yet been exploited.
In the past we’ve reported on similar cross-site scripting vulnerabilities being found on popular sites such as Uber and TripAdvisor.
Whether you are running a website used by millions of people, or only get a few dozen visitors a month, it is essential that your site has been built carefully and doesn’t contain flaws that could be exploited by malicious hackers.
And, of course, if the worst does happen and you do find that your site has a security problem, to fix it as soon as possible.
Editor’s Note: The opinions expressed in this and other guest author articles are solely those of the contributor, and do not necessarily reflect those of Tripwire, Inc.