Hello im really curius about this, i want to know is it possible to intercept the code of execution in PHP but not on the server side. So if i have a script like this for example uploaded to mine server

    while($i<100) {
       mail("xxxxxx@gmail.com", "SPAM", "It´s ME");
    echo "DONE!";

How can i intercept and stop it from its execution and also if possible change the code. But lets suppose i do not have access to the server. It is possilbe to do this ?

Oh and yea Happy New Year and wish you all the best in the new one DANIWEB

Member Avatar

Not sure if this specific example could cause issues if you do not have access to the server. Messing with the fourth param (from) could conceivably cause issues if not sanitized.

IMO - it all depends on the security of the site itself and whether a hacker could gain access to any page therein. There have been a number of instances recently where site owners have used eval() and left their site wide open.

mail() is a real bare bones function. If you are intending on sending 100+ emails on a regular basis, perhaps you'd want to use a library or a even a service.

I'm sure others here will have more info.

While im in these "hacker" days i have made my website vulnerable to sql injection and Cross Site Scripting, i want to know how a hacker can use theese vulnerables and hack my website, also how the hacker will know about these holes. BTW this question poped in my head while i was reading the PHPMailer hack

Given the terms you are using ("no access to the server", "man in the middle", "stop it from execution", "intercept/change the code"), the short answer is no. PHP is a server side language. The php code will be interpreted and executed on the server and the process to send the emails will be started, all on the server side, BEFORE anything gets to the "middle". Now if you are the "man in the middle", you can potentially block, add, or alter any packets between the server and the e-mail recipient, which means you may be able to prevent the spam emails from getting to their destination. Similarly if this php script is executed by some mechanism external to the server telling it to run (i.e. that php code is part of a public web page that gets executed), if you can intercept/block/re-route/change/etc the packets that cause that code to execute, you have stopped the emails from being sent by preventing the php code from being interpreted/executed in the first place. On the other hand, if the php script is executed via a cron job or something else internal to the server, as mentioned, it will execute and you'll have to do some "man in the middle" stuff to prevent the emails from getting to the right place, but that's AFTER the php code has already done its job.

Regarding "no access to the server", if it's a public webpage available to anyone, you might want to redefine the term "access to the server". If I can run a script at will, and particularly if I can pass the script parameters (no parameters in your code apparently?), then if there's a weakness to exploit in the core php C code or the php script or wherever, well... lots of systems have been compromised by SQL injection as you mentioned, and buffer overflows, etc. by folks who had no "access to the server" other than public web access.

Regarding spam, I know that is just an example and not the actual code, but 100 emails sent with no delay, all to the same person's gmail account, and all with "SPAM" in there, plus the fact that, as Diafol mentioned, you're using PHP's mail function, my guess is you don't have to do anything as the "man in the middle" to block this. Gmail is going to figure out this is spam and your own server/host might figure it out too and block it.

mail() is a real bare bones function. If you are intending on sending 100+ emails on a regular basis, perhaps you'd want to use a library or a >even a service.

I'm sure others here will have more info.

I already weighed in on this, but to add, I'm not much of a PHP guy, so I used the mail function as above to send out NON-spam emails to a mailing list of several hundred people in the manner of the initial post (loop, no delay, no extra headers, no monkeying around with ini files or the other settings, etc.), and they almost all got false-flagged as spam. So I kept doing little tweaks and re-sending and re-failing as opposed to taking the time to get it right before sending. End result was when I DID get it right, I was already flagged as a spammer, so even the right configuration no longer worked. I got a nastygram from the hosting service. I eventually proved that I wasn't a spammer and it was a coding mistake, but the damage was done. Ended up switching IPs, hosting services, etc, just because of the hassle. Once you're on the spammer list, you're on the spammer list, which is like the No-Fly-List. You ain't getting off. Luckily I personally wasn't on the spammer list, just my email address, so it wasn't fatal.

Moral of the story is that spam filters are cynical #######s and err toward false positives, so get it right first with a few small tests with throwaway email addresses, THEN send out the mass emails when those all get through.

the PHPMailer hack would probably fail if submitting filtered data to the library, i.e.:

  • sanitizing through filter_input()
  • and by using SMTP, because it will not use sendmail, nor mail()

Note, a filter_* function is also used in the PHPMailer library, but as default option of their validateAddress() switch and does not run, if other extensions are loaded.

In reference to your first request search for SSLsplit and mitmproxy, in practice the attacker takes the role of the gateway and intercepts & modifies the requests, but it requires to be in the same network.



just to add something: the first step to avoid spam filters is to setup SPF and DKIM in the TXT records of the domain. That way Google, Hotmail & co. can verify if the sender address is allowed and if the origin is correct. For example, take Daniweb setup:

# query Google DNS
> dig daniwebmail.com ANY @

daniwebmail.com.    299 IN  MX  5 daniwebmail-com.mail.protection.outlook.com.
daniwebmail.com.    299 IN  A
daniwebmail.com.    299 IN  TXT "MS=ms74324738"
daniwebmail.com.    299 IN  TXT "v=spf1  include:spf.protection.outlook.com ip4: ip4: ip4: a mx include:_spf.google.com ~all"

The TXT record is saying from which IP addresses the emails should be considered valid, this includes a range of IPs, the mail server defined in the MX record and the IP from the A record.

For example last newsletter came from community@daniwebmail.com and from IP With spfquery you can test the validity of the origin:

spfquery -guess "v=spf1 mx a -all" -ip -sender community@daniwebmail.com

The response looks like this:


spfquery: domain of daniwebmail.com designates as permitted sender
Received-SPF: pass (spfquery: domain of daniwebmail.com designates as permitted sender) client-ip=; envelope-from=community@daniwebmail.com;

Which is basically what are doing mail services when receiving an email message. If the SPF is genuine then there are good chances to avoid the SPAM folder. But at that point it's necessary to act like you wrote, by rate limiting messages and by choosing correct phrasing.

More info:


commented: Good info +7