Japanese Keyword Hack

@maparfitt If the result points directly to your site, and one of your pages (which is in japanese) then it sounds like a hack. If it points to their site which redirects to yours, it does not sound like a hack

@Sinnbeck Yep, it points directly to my site. Any suggestions about what to do now -- given that I'm not seeing any obvious problems on the site?

@maparfitt I would start by downloading the files. I assume that it is a dynamic url that is somehow pointing to something strange? Be aware that the more info you give us the better we can help :)

And you can then start by using git to compare your local files with the files you downloaded. They should be identical, but I assume they are not :)

@Sinnbeck The site is https://bostonrhetoricwriting.org and the organization is the Boston Rhetoric and Writing Network. When I go to Google Search Console and do a URL inspection test for the page http://bostonrhetoricwritingnetwork (not https), the code is totally corrupted Japanese content. But in practice, the link redirects to https://... and seems to be fine -- source code looks exactly as it should. So is it possible that the http version of the site got hacked but not the https version?

@maparfitt it is related to the user agent. The moment you visit your website with the following user agent you see the japanese signs: Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html). So something on your server / your code makes this happen.

@click Thanks. Yes, you're right.

Luckily (I think), it doesn't seem to happen with any other user agents. But what could cause this? The Japanee code that gets rendered with the GoogleBot user agent isn't anywhere in my repository. For what it's worth (and I'm not sure it's relevant), "robots.txt" and htaccess both seem fine.

Thanks for the link to the web.dev article. I'm following the procedure -- but it takes a while.

@maparfitt I don't know exactly how but it could be done in your nginx, apache settings or anywhere in the PHP code? Maybe some funky composer package that is compromised? Try replacing the entire PHP codebase with the code you have locally and see if it still happens.

If you can also reproduce the japanese texts on your local webserver you know it is probably in some composer package.

Are the urls you see in google like 01787overpleased1803463 URL's your website created or are these URLs that this japanese spam created? If so, try searching in your server for 01787overpleased1803463, I would start with the nginx directory and the forge home directory (where your actual website is stored)

sudo grep -irhnwl "01787overpleased1803463" "/etc/nginx"
sudo grep -irhnwl "01787overpleased1803463" "/home/forge"

or if you have apache something like
sudo grep -irhnwl "01787overpleased1803463" "/etc/apache2" (not sure what the path is for apache) 

PS. You can easily change your user agent in google chrome by switching to mobile view and add a new device with user agent: Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html) see https://developer.chrome.com/docs/devtools/device-mode/

@click I'm trying to replace the codebase. After I pushed new code, the deployment failed because of a difference between my local public/index.php and the one on the server. I see that the index.php on the server has one line of code that's different from what's in index.php on the main branch of my github repository:

$response = tap($kernel->handle(
    $request = Request::capture()
))->send();

I don't understand the tap helper too well, but could this be the root of the problem?

@maparfitt This is the latest index.php from Laravel 8 https://github.com/laravel/laravel/blob/8.x/public/index.php but they had a tap() at some point see: https://github.com/laravel/laravel/commit/ca8e5d65da361d070e637d0d82a8eb49b6a41afb so that does not have to be the issue.

How do you deploy your code? As normally it should not fail because of a difference between two files.

@click I'm using Forge, so it automatically deploys when I push new code to my github repo. I have a staging site, so I normally push code there first, check that everything's okay, and then merge staging into main. So I don't usually run into this kind of problem. The staging site deployed fine, but the production site failed to deploy. Weird. Forge does have a "reset git state" option that I could try.

(By the way, I haven't been able to find those strange URLs you mentioned. I'm using nginx.)

Thanks again for all your help.