Jump to content

Recommended Posts

I think PHP tags technically wouldn't matter, as long as the input is always treated as a string and never written to a file to be parsed by PHP again. Even if you had:

 

$content = "<?php /*some evil stuff*/ ?>";
echo $content;

 

it would NOT be parsed by PHP as valid PHP code. However, you would still want to properly escape those while printing the output, e.g. by using htmlentities. If you really do have reason for stripping those PHP tags, you will probably need to use preg_replace.

 

EDIT: well, since you need to allow HTML tags too, htmlentities might not work (which would also escape the html tags). However, any PHP code should still not be parsed by PHP, and will just be sent to the browser and interpreted as invalid HTML markup. The next step you could take would be to validate the input to see if it has a valid HTML syntax.

Edited by seanlim

you could just do str_replace();?

 

eg:

 

$string = $_POST["somethingRandom"];

$string = str_replace("<?php", "", $string);
$string = str_replace("<?", "", $string);
$string = str_replace("?>", "", $string);

echo $string;

Edited by White_Lily

Much better to replace the tags with an escaped version, so that the text still shows. After all, we wouldn't be happy if the forum decided to silently remove the PHP tags from our posts here, would we? ;)

 

$string = preg_replace ('/<\\?(php)?/i', '<?$1', $string);
$string = str_replace ('?>', '?>', $string);

 

First line will replace all opening tags, and preserve case. White_Lily's solution would still allow any opening tag that's not purely lower-case through.

Edited by Christian F.

There is no "obvious reason" to disallow PHP tags. If you're using eval() or any other method of dynamically evaluating user-input as though it were PHP code, stop what you're doing now and change it.

 

Allowing PHP in your inputs should not be a security concern at all, since there should be no way for user input to ever be executed by the PHP interpreter.

Allowing PHP in your inputs should not be a security concern at all, since there should be no way for user input to ever be executed by the PHP interpreter.

 

Unless they are writing the input to a .php file and then including it.

im using ckeditor, and when i input php it shows up in the page source as a html comment so that isn't a problem but i would still need to use mysql_real_escape_string(); to prevent sql injection wouldn't i?

 

while im on the subject does real escape protect against all sql injection? ik there is different types but im not too sure

All SQL injection relies on abusing special characters, like quotes. mysql_real_escape_string() escapes those special characters, so SQL injection is not possible.

 

It may still be possible to manipulate the database with user input though, without SQL injection taking place. For example, let's say you have a Users table with a column called "status". Let's say there are three possible values for the "status" column: "enabled", "disabled", and "banned". Let's say you only want normal members to view users by "enabled" or "disabled", and administrators can also view "banned". For argument's sake, let's say the input is in the form of a dropdown box. If you don't validate the input, any user can just change "enabled" or "disabled" to "banned", and view all the banned users.

 

With that said, <?php ?> isn't going to harm your database in the slightest way.

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.