Hacker News Reader

Comment by datalopers | Hacker News Reader

They've got something a bit more fucked up than just an exposed .gitignore

    $ curl -si https://www.tesla.com/ | grep generator
    x-generator: Drupal 9 (https://www.drupal.org)

    $ curl -si https://www.tesla.com/authorize.php | grep generator
    x-generator: Drupal 7 (http://drupal.org)

So they have at least two versions running at the same time. The /authorize.php [1] uri also yields a 500 (instead of a 403 like most of the other resources), which implies Apache is most likely passing the request off to PHP and the script has a fatal or unhandled error.

The webroot appears to be a Drupal 7.x installation and Apache is serving that content directly (e.g. https://www.tesla.com/MAINTAINERS.txt same as [2]) and trying to run some of it (authorize.php), while happy-path requests are being reverse-proxied to a Drupal 9.x installation.

[1] https://github.com/drupal/drupal/blob/7.x/authorize.php

[2] https://github.com/drupal/drupal/blob/7.x/MAINTAINERS.txt

View on HN

"Support migration from existing Drupal 7 to the new Drupal 9 site"

https://www.tesla.com/careers/search/job/sr-software-enginee...

polite chuckling

My knee-jerk reaction is that this looks like a marketing/eng split, or even just marketing/marketing. The main "corp" website of every org I've ever worked for is managed by marketing, not by engineering, and it usually shows in the quality. Usually drives someone in engineering (like me) slightly crazy, but honestly there are a million other larger fish driving me more crazy.

IME they're almost always completely separated from the "real" systems that engineers are working on / managing. A compromise wouldn't go far, in the backend. Something like XSS would be worse.

Always seems to come from some push to "running a website isn't our 'core focus' so we should vendor that" … or something. I've also encountered immense push-back on eng-managed corp websites: all those pesky best practices get in the way of just shoveling "content" (i.e., PR) out. And so it ends up separated from eng.

FWIW, a 500 doesn't imply the server is crashing. More likely just throwing a generic error, e.g. unexpected input –probably because it's expecting some form/data parameters– and failing the request early. It'd more correct to return a 400 in this case, but the /authorize.php endpoint may only be used by tesla.com frontend, so they don't care if it's used in unexpected ways.

What's the distinction between the server crashing and the server throwing an error?

Usually, a server throwing an error would mean that it is aware there was an unexpected state, and is itself consciously not fulfilling the request by returning a 500 error, for example. It remains available to handle the next incoming request.

A server crashing implies that the server program or process itself has terminated, and is not able to handle further requests. This usually manifests as a 503 error by an upstream proxy server (nginx/apache/CDN/etc.).

They likely have layer 7 load balancing sending different paths to different servers.

Guess Elon should go and reduce some Tesla services like he did with Twitter. Having different major versions of software running must take up a lot of maintenance...

Maybe he should bring in some Twitter developers to review the code at Tesla.

I usually don't engage in silly comments but this made me belly laugh loud, ta.

I believe this is the whole point of this submission.

Drupalgeddon 7 exploit. Infinitesimal chance it’s a vulnerable version. Unless we live in a sitcom simulation

Reply on news.ycombinator.com