This is an attempt to exploit the nearly-two-year-old "Log4Shell" vulnerability, which existed in the popular Log4j server-side logging utility. It's been long patched and only ever affected Java (unrelated to Javascript); if you're using pure PHP, or even if you have some Java but it either doesn't use Log4j or is using a patched version, you're fine.
The malicious pattern is essentially attempting to tell Log4j to fill in a string template with the result of evaluating a Java Naming and Directory Interface URI. The JNDI URI is itself specifying an LDAP (Lightweight Directory Access Protocol) URI, which indicates what is presumably an LDAP server operated by the attacker and exposed to the Internet. The LDAP URI would be fetched and then, critically, treated as a Java object that the server attempts to extract a string from. In this way, it's a form of server-side code injection, allowing a remote attacker to gain code execution on the victim server just by presenting a string somewhere that the attacker will hopefully log it.
This being one of the easiest and most widespread code execution vulnerabilities out there, lots of would-be attackers have tried spamming arbitrary websites with the pattern to see if they can take over the server. What you're seeing is almost certainly just automated traffic, possibly just from a single IP, with no intelligence behind it; it's nothing personal about your site, you're just a reachable webapp on the public Internet, and they have a crawler that can identify fillable fields and is trying to find webapps that use Java and haven't installed patches for a couple years.
As mentioned above, you personally are almost certainly immune to this specific attack. To avoid similar exploits in the future, though, you should do the following:
- Minimize attack surface. Disable features that you don't need (even if those features are enabled by default in your libraries or frameworks), especially anything that even vaguely smells of "make your server send unexpected requests" or "make your server load executable code". The string replacement, JNDI, and code execution features in Log4j were all part of the problem here, and most devs don't need them or at least don't need the latter two.
- Install security updates promptly. This applies to both your application (including its dependencies) and the infrastructure on which it runs (operating system and server components and their dependencies). You don't always need to be running the latest version of everything, but you should definitely install a security update any time it patches a vulnerability that could be present in your server.
- Vet your dependencies carefully. That might not have saved you here - Log4j is part of the generally-respected Apache Software Foundation - but at least that means they pushed out a patch very quickly. Definitely don't use dependencies which are poorly maintained or abandoned, have a history of leaving vulnerabilities unpatched for extended periods, have loose control over their code or releases (such that an attacker could pull off a supply chain attack by publishing a release with malicious code built into it), or otherwise seem untrustworthy. Be warned: low quality dependencies are a common problem in both the JS and PHP ecosystems.
- If possible, sandbox your servers. Don't allow them to make outbound requests unless they need to, in which case restrict those requests as much as possible. If possible, isolate the server from long-term secrets, such as TLS private keys and other sensitive data; it's generally impractical to avoid the server having some such access, but you can limit the blast radius. Functionality that can be encapsulated outside of the main server process - such as logging - would ideally be run in its own sandbox with extremely limited access (adhering to the principle of least privilege) such that even if there's a vulnerability in some component, it can't damage or expose anything out of its direct area of responsibility.
- Perform a security review of your application, or hire somebody to do so. Such reviews can take many forms, such as code reviews, penetration tests, threat modeling and mitigation analysis, automated static and dynamic analysis security scanners, and so on. Depending on your budget and the sensitivity of your application, some options will be more cost-effective than others; for example, automated dependency scanners are cheap or free and worth using continually in basically any system, whereas a manual pentest by a skilled security consultant can run tens of thousands of dollars and is probably only worth it for high-value targets. One middle-ground option is to create a bug bounty program, usually through one of a few commercial platforms for such programs, which encourages people to find vulnerabilities in your application in non-destructive ways and then report them to you for compensation.
- Consider obtaining a web application firewall (WAF) or similar system. This recommendation starts with "consider" because WAFs are, frankly, categorically not very good products. They tend to both have considerable false positives (including both things like "catching Log4Shell attempts even though they're made against PHP where it wouldn't matter" and "blocking perfectly reasonable web traffic that happens to look a little too much like SQL"), and be remarkably easy to bypass. However, they are good at blocking well-known automated attacks, and provide a useful single point of control for things like "block this IP, which appears to be malicious".
