Thread

Moderator’s note: Moved to General.

I’m just about to take my site live, but have one important security base to cover.  I’ve got a form which sends a variable to an independent PHP page, and I want to make sure that I am protected from attacks or other weirdness.  I really don’t know very much about PHP at all, so I’d appreciate any support someone knowledgeable of the language can offer.

Here’s an example of the code:

My HTML:

<form action="{site_url}otherpage.php" method="post" target="_blank">
<input name="variable" type="text">
<input type="submit" value="">
</form>

otherpage.php:

<?php $variable = $_POST['variable'];?>

<frameset rows="125, *">

  <frame src="http://www.mr-frame.com">
  <frame src="http://www.some-site.com/search<?php echo "?p=", $variable; ?>">

</frameset>

Is this vulnerable to attack?  And if so, what can I do to secure the vulnerability?

While I am no PHP Guru, I do know that the code in otherpage.php won’t be viewable through a normal HTTP request. As PHP is a server side language it’s interpreted before it gets sent to the client. If anyone navigates to otherpage.php all they’ll probably see is a blank page, and if they view source all they’ll get is an empty page.

I hope this helps, although you should probably wait for a PHP head to confirm this. Depending on your server setup it might be possible for someone to use a PHP function such as f_open to get into the guts of otherpage.php - I know you can turn f_open off, but sometimes it is needed for the app your running.

The PHP page actually loads fine and works as I anticipated, so I guess I’ve done something right on that end 😊

I’ll do some research on f_open and see if I can find any info on it and whether I need to safeguard against an attack using it.  Thanks for your response!

You are only passing a URL variable…no problems what so ever. The only person even in any ‘danger’ would be the site executing the search. They also might ‘bust out of frames’ so make sure they are in on it.
All the best!

Thank you very much!  That’s what I suspected as I tried to run a bunch of different php scripts to break my own page but they just kept getting passed to the other site.

Believe me, I’m praying the other site doesn’t go the frame buster route.  My site will actually improve their bottom line quite a bit, so it’s to their benefit to keep frames alive.

Um, if you are dumping a POST variable anywhere to your browser without sanitizing it, yes, absolutely, you have a security problem.  Anyone can visit that page and set their own POST values, or craft a link on an external site that when clicked on by another user visits that page with whatever POST data they like.  You basically have a cross-site scripting vector on your site with the above code. Consider:

<frame src="http://www.some-site.com/search<?php echo "?p=", $variable; ?>">

And someone submits _POST[‘variable’] as:

><script>alert('yoohoo!');</script>

If you are running this through ExpressionEngine, you can use $REGX->xss_clean() on it, but what would be even better would be a whitelist approach, where only text that meets whatever the particulars of formatting you are expecting are allowed, and anything else is ignored.

This is why you Derek get paid the big $ 😊.
Technically…isn’t this really ‘their’ problem vs. his EE site…right? Granted, he would get blamed but it is not EE security issue he just provides the means/form….just curious what if the form processing site is EE?Would these types of attacks against CP or pages with SAEF be prevented and/or logged?
Thanks the info!

What do you mean “their” problem?  It sounds like this PHP page is still hosted on the same site, or at least under lobstersan’s control.

Oops, I left this topic for dead a while back and didn’t get any e-mail notifications that it had be responded to.  The “www.some-site.com” PHP page is not hosted on my site.  The “otherpage.php” page is hosted on my site.  The “www.some-site.com” is a major enterprise that I’m certain has safeguards to easy attacks.

Thanks for the extra look though!  One of these days I need to get myself trained in PHP properly.

lobstersan, the security vulnerability is in otherpage.php; the external site is irrelevant.  Please reread this carefully.

Hmm, ok, I guess I’ll have to take a look at how to put a whitelist in place.  One sticky tidbit here is that allowable form characters is going to have to include Japanese characters.  Might that get a little tricky?  Would it be so horrible to use a blacklist instead?

Your first concern is preventing any cross-site scripting attacks on your site, which you can accomplish by instead of echoing $variable unfiltered, using $REGX->xss_clean().

<frame src="http://www.some-site.com/search<?php global $REGX; echo "?p=", $REGX->xss_clean($variable); ?>">

Validation would be recommended of course, but your main concern is plugging that hole.

OK, thank you very much.  I will do that right away and research white lists with Japanese encoding.  Many thanks, Derek!  You may have saved me from a monumental collapse sometime down the road.