There are a growing number of spammers exploiting PHP scripts to send spam.
Such scripts are often simple "Contact Us" forms which use PHP's mail()
function. When using the mail() function, it is important to validate any
input coming from the user before passing it to the mail() function.
For example, consider the following simple script.
<?php
$to = 'info@example.com';
$subject = 'Contact Us Submission';
$sender = $_POST['sender'];
$message = $_POST['message'];
$mailMessage = "The following message was received from $sender.\n\n$message";
mail($to, $subject, $mailMessage, "From: $sender");
?>
Such a script looks fairly innocuous. The problem is that sender variable sent
from the client is not sanitized. By manipulating the value sent in the sender
variable, a malicous spammer could cause this script to send messages to
anyone.
Here's an example of how such an attack might be carried out.
curl -d sender="spammer@example.com%0D%0ABcc: victim@example.com" \
-d message="Get a mortgage!" http://www.example.com/contact.php
Now, in addition to being sent to info@example.com, the message will also be
sent to victim@example.com.
The solution to this problem is to either not set extra headers when using
mail(), or to sanitize all data being sent in these headers. A simple example
would be to strip out all whitespace from the sender's address.
Salesforce applications can sometimes be difficult to debug. The debug
log often has the information you need, but finding it isn't always easy.
For example, in a recent project, I needed to figure out why performing an
action from a Visualforce page was causing more SOQL queries than expected,
generating warning emails as we neared the governor limit. This was a large
application that had been under development for about eight years; many different
developers had been involved in various phases of its development.
As with many Salesforce applications that have been through many phases of
development, it wasn't obvious how multiple triggers, workflow rules, and
Process Builder flows were interrelated.
It was easy enough to figure out which SOQL queries were running multiple times
by grepping the debug log, but it wasn't obvious why the method containing the
query was being called repeatedly.
In researching ways to analyze call paths, I found Brendan Gregg's work on flame graphs, which
visualizes call stacks with stacked bar charts. (You might also be familiar
with Chrome's flame
charts.)
Visualizing the call path through stacked bar charts turned out to be a good
way to make sense of the Salesforce debug log.
So I created Apex Flame
to visualize Salesforce debug logs using flame charts or flame graphs.
You can drill in by clicking on a statement, or click on Search to highlight
statements that match a string.
I'd love to get some feedback from other Salesforce developers. Try out Apex Flame, and
let me know what you think.
As for the debugging issue that initially inspired the creation of Apex Flame, it
turned out to be the combination of a trigger that wasn't checking whether the
old and new values of a field were different, causing it to run code
unnecessarily, combined with a workflow rule that was causing the trigger to be
called multiple times.
Another recent case in which it turned out to be helpful was in troubleshooting
a process builder flow that was failing to update child records as expected.
The flow assumed that if the parent record is new (ISNEW()) that
it didn't have child records. It turns out this isn't necessarily true because
a trigger on the parent object can create child records, and the flow runs
after the after insert trigger. The order
of execution is documented, but visualizing the execution order made it
clear what was causing the unexpected behavior.
