SitePoint Sponsor

User Tag List

Results 1 to 8 of 8
  1. #1
    SitePoint Wizard gold trophysilver trophybronze trophy dc dalton's Avatar
    Join Date
    Nov 2004
    Location
    Right behind you, watching, always watching.
    Posts
    5,431
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    making sure mailer script can't be exploited

    As you all know I've been hacking my way through PHP the past few months and have done a few sites that have simple contact form mailer scripts. I've seen a few posts around here and the web about php mailers being hacked and used to send spam by an outside party.

    Anyone have information on how to set up a mailer script to be "non hackable". I'd hate to leave a script open by mistake just because I'm new to this and have a client (or hosting company) come back later with a problem!

  2. #2
    Keep it simple, stupid! bokehman's Avatar
    Join Date
    Jul 2005
    Posts
    1,935
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Validate all your inputs to make sure they contain what they are supposed to. Don't check them for what they shouldn't contain (blacklisting), check them for what they should contain (whitelisting).

  3. #3
    SitePoint Addict SRTech's Avatar
    Join Date
    Mar 2005
    Posts
    224
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I would try and hardcode the To: email address in to the script. Don't let it be passed to the script in a post request.

    If you need to have more than one email option, (like using a dropdown list to select, Support, Sales, etc), use a code in the HTML and have PHP select the correct address. i.e. Sales - 1, Support - 2, then in the php code, if the $_POST['to']==1, then send to sales@example.com

    Make sense?

  4. #4
    SitePoint Wizard gold trophysilver trophybronze trophy dc dalton's Avatar
    Join Date
    Nov 2004
    Location
    Right behind you, watching, always watching.
    Posts
    5,431
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by SRTech
    I would try and hardcode the To: email address in to the script. Don't let it be passed to the script in a post request.

    If you need to have more than one email option, (like using a dropdown list to select, Support, Sales, etc), use a code in the HTML and have PHP select the correct address. i.e. Sales - 1, Support - 2, then in the php code, if the $_POST['to']==1, then send to sales@example.com

    Make sense?
    I never allow a to email addy to be passed in to a script, it's always hardcoded into the script or in the case of allowing the client to choose I will have an array of the proper email addys in the script and grab the right one based on the incoming variable.... is this good enough?

    Is there any other way this type script can be exploited? I'm used to Java where we lock everything down so only another class (which is 100% protected) call the mailer class.

  5. #5
    SitePoint Guru
    Join Date
    Sep 2004
    Location
    NY, USA
    Posts
    712
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    All great advice

    Here's a quick punch list off the top of my head. (some of it repetitive to the above)

    • NEVER send the recipients address(es) through incoming data, they should always be hard coded on the back end.
    • When the data comes in, check the count() of the $_POST array, if it's larger or smaller than expected (or not within a set range), exit.
    • If possible, compare the $_POST keys to a hard-coded array of allowable keys... if a strange key appears - one you weren't expecting, then exit.
    • Once that's done, examine each $_POST value, for type and length --- type could just be a legitimate user error, but if the length largely exceeds what is allowable for that item (especially if you had the client-side maxwidth attribute set), then EXIT
    • I also check for suspicious patterns, like if all the text fields contain the @ symbol, exit. This is not normal and I've had some bots that stick an e-mail address in every field.
    • As mentioned above, when it comes re-using form processing scripts... have a special key-value that determines which course of action to take [subject, recipients etc. after validation is passed]. If that key is not existant - exit. If that key does not contain a legitimate pre-determined value - exit.
    • Set a session variable on the form, then check for the existence of the session variable on the processing script so you know the request came from the page you intended. Immediately unset that session and continue. If it's not there, exit.
    • On any premature exit... log it or email yourself ALL $_POST data and remote user info so you can track patterns. Then you can add more checks to your validation arsenal to compensate for these suspicious patterns.


    These are a just bunch of things you can do. I don't profess to be an expert at all, but all these things (like any security measures) add up to the point evil-doers pass you by and look elsewhere for easier targets. There's prbobably a few others I can't think of at the moment. But I hope this helps you out.


  6. #6
    SitePoint Wizard gold trophysilver trophybronze trophy dc dalton's Avatar
    Join Date
    Nov 2004
    Location
    Right behind you, watching, always watching.
    Posts
    5,431
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thanks, I will keep that list handy and once I know what half it means I'll impliment them.... I may be great a Java but PHP just frustrates the hell out of me!

  7. #7
    SitePoint Guru LinhGB's Avatar
    Join Date
    Apr 2004
    Location
    Melbourne, Australia
    Posts
    902
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Add a security image on the mail form (CAPTCHA). It can be cracked but it requires more processing power and brain than 99.9999999999999% of spambots out there have, or can be bothered to have.

  8. #8
    SitePoint Addict
    Join Date
    Oct 2004
    Location
    Brooklyn, NY
    Posts
    359
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I think the most overlooked input to the mail() function is the fourth argument that allows you to specify headers. Even if the first argument is hard coded, your use of the function can be vulnerable to these attacks, because attackers can add arbitrary BCCs and such.

    Your approach to filtering the first argument sounds good. Just extend that to everything you use in a critical function such as mail(), and you'll be doing better than most. :-)

    Hope that helps.
    Chris Shiflett
    http://shiflett.org/


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •