Note that git remembers things forever. So it's not just a question of whether or not there is a credential stored in your latest code base, but whether there was ever a secret stored in your code base which is still valid. There are even lots of fun tools out there that wills can the entire git history for secrets! Fun times

Yes! Not only the current code, but all commits since the beginning of the repository. Someone commited a password and deleted later? No problem, the password is there.

Furthermore, don't ever deploy by doing a git pull. Instead, have a dedicated update process which checks out the latest release branch and then actually deploys the sever standalone. There is no reason to ever have a .git folder in your web root.

This. Repeat after me: GIT IS NOT A DEPLOYMENT TOOL.

@MechMK1 What about git clone --depth 1?

Thank you very much to all for your valuable suggestions. @ThoriumBR, In git there never ever had any type of credentials in the git repo. Also, I found from the log the attackers not able to index in git/objects. They bruce force the file names, so they don't have all of the files from there, but some of there. I already change the server key pairs, DB passwords, DB names, tables names. Can you please suggest what is the most secure way to a deploy PHP applications?

Use an automated pipeline to deploy only whitelist of files from your repository. Namely, your pipeline will checkout the correct branch and publish a zip artifact not including hidden files, which .git is a great representative. The zip is collected by the deploy pipeline and deployed to the server. I assume you have a build pipeline that at bare minimum runs a bit of unit testing/linting on the code

@nalzok There are other (non-security related) issues with using git for deployment beyond accidentally leaking your entire revision history. Using a shallow clone avoids (most) of the risk of disclosing revision history, but does not do anything about those other issues.

You can use git as a deployment tool if you properly configure and isolate the webserver. But it's not worth it, it's better to never have useless sensitive information on the server in the first place. It's worth noting that with some language (like PHP), the sources are always at risk of leaking (with or without git).

@MargaretBloom I would say that any deployed code is "at risk of leaking" in that sense. JVM bytecodes and .Net CLI can be trivially "de-compiled"; fully compiled languages like Rust and Go may be trickier to fully reverse engineer, but that's not going to be any protection at all against hunting for hard-coded credentials. If someone can get hold of your deployed application, you are going to have a headache.

@IMSoP Well, I said sources :)

@MargaretBloom Sure, but the idea that this has anything to do with the programming language is still worth challenging. If I run a PHP application under php-fpm, fetched by an nginx proxy with a completely different folder as its document root, it is no easier to get at that PHP source than it should be no easier to get at a JAR file or compiled .net assembly running on Tomcat or IIS. The only difference is that if you do get it, it's fractionally easier to read. There's also the possibility of using a code execution exploit + Reflection in any of those languages to get the running code.

This sounds very much like a "security through obscurity is great!" answer. If having access to the source code of an application is really a security nightmare, just imagine how awful it would be if someone could get access to the whole git repository of your operating system! The horror! Oh wait, no that's how open source works and there's no proof that I'm aware of that open source software is somehow more likely to be exploited than closed source.

So basically if having access to your source code is a security risk, you're doing things horribly wrong. Don't treat the symptoms, treat the cause. Because people can "look for remote code execution, file inclusion, and SQL Injection right now" even without the source code. That's actually how the majority of exploits happen.

I'm downvoting this answer because I think it's overboard, and presumes horrible code. Not all code is horrible. Some code is actually publicly available. All the code on the computer I'm writing this on is open. Some of it clearly has exploits, and isn't bulletproof. I'm not terrified. I also have a general disagreement about the tone of this that you should have a purely emotional response. That rarely, if ever helps people, and mostly hurts.

@Kevin And if the focus was on those particular things (also "perhaps"? No that's definitely not a good idea!) I'd agree. But most of the things mentioned here, can be exploited without having access to the source code.. you shouldn't be worried about sql injection attacks because your source code leaked, you should always be worried about sql injections.

The attackers also know the names and emails of the developers, they can use those to make convincing phishing attacks