A security researcher has found, reported and now disclosed a dozen bugs that made it easy to steal sensitive information or take over any customer’s account from some of the largest web hosting companies on the internet…Some of the biggest web hosting sites were vulnerable to simple account takeover hacks | TechCrunch
1 Like
I’m actually not sure whether WHMCS does any CSRF protection…
When I see things like this, it reinforces what I tell myself every day: That I cannot allow myself to feel bad, no matter how upset someone gets, at being a brick wall to prevent social engineering attacks from being successful through me.
1 Like
It’s strange that none of them used something that works pretty well at stopping these kinds of attacks and something that has been supported in the browsers for a while: Content-Security-Policy and Cross-Origin Resource Sharing.
Edit: https://www.websiteplanet.com/blog/report-popular-hosting-hacked
Looks like some of them did use these mechanisms but the rules were either too loose or were misconfigured.
I’m actually not sure whether WHMCS does any CSRF protection…
I just checked a few forms (account details, new ticket, ticket replies) and they all appear to have CSRF tokens
It’s strange that none of them used something that works pretty well at stopping these kinds of attacks and something that has been supported in the browsers for a while: Cross-Origin Resource Sharing or simply put: CORS.
A site vulnerable to CSRF via GET requests can be attacked using <img> tags regardless of CORS headers. Additionally, sites without a proper X-Frame-Options header that are vulnerable to CSRF on POST requests can be attacked by an invisible <form> that posts into an <iframe>. AFAIK, neither of these are blocked by CORS.
There’s also the case where the CORS settings are not strict enough.
That’s correct but I didn’t say that it stops all of the attack vectors. I was glancing over the blog post and saw that most of the attacks used the XSS vector which a properly configured CORS and CSP would stop. Different attack vectors require different protection approaches and as seen in case of HostGator, even the PHP’s 0 == NULL can lead to a fatal mistake:
HostGator normally uses anti-CSRF tokens with any form submits. However, the server can be tricked to ignore anti-CSRF tokens by changing the POST parameter token to token= and leaving it empty – this lets the CSRF check pass as true. I suspect this might be a Type Juggling vulnerability, with a pseudo code sample:
if (strcasecmp($_GET[‘token’],“$csrf_token”) == 0) {
The above function might look sufficient for most programmers, especially if they migrated from C/C++ to web development. While the function looks as if it would only evaluate true if the strings are the same, it is also the case that if an array is given into the variable, then a NULL response is given back. According to PHP’s comparison, for instance, NULL is actually 0. So, it will pass as valid!