Security Risk or Other Threat?

[jscheuer1]

If I have a PHP page on my server:


<?php
$field1value = isset($_POST['field1value'])? $_POST['field1value'] : '';
echo $field1value;
?>

Does it pose any sort of security or other threat?

Obviously anyone could post any string to it. But, by doing so could they get it to reveal sensitive information about the system or cause the server to do something bad like create or delete files or execute any commands?

[fastsol1]

Well you wouldn't be able to do anything to the files directly on the server as far as I know but you could certainly do just about anything with javascript with the example you showed. All you really need to do is use htmlentities() on the variable and that will convert any characters into their html equivalent and not actual < or " type symbols, therefore not parsed as code.

[djr33]

Definitely not. There's never a danger in having values sent to the server or referring to those variables, such as checking if they are set.
If you then use those variables for something (such as inserting them into a database) that could be a security problem. But just looking at the variables (your first line) isn't a threat of any kind.

Your second line sends the value of the variable to the user. So indirectly that could be a security concern in an absolutely theoretical sense, because it could contain XSS or something. But of course that's from the user him/herself, so it's not a real threat. (I suppose that if you submitted a form on another site that directed you to this site and posted that data to the server, you could theoretically have an XSS attack occur...)


The only possible threat to your server is if you have register_globals turned on (if so, turn it off!) because that would automatically set 'fieldvalue' to $fieldvalue. In fact, you're already doing that, so register_globals is irrelevant.
So, now that $fieldvalue contains some potentially "dangerous" code, the only problem is if you use it later expecting another value.

The simple example is the following:

<?php
$admin = $_POST['admin'];
if ($admin==1) { delete_stuff(); }
?>

It realistically would be more complicated than that-- you'd have something else going on between those lines. When you're using $admin as a "secure" variable and accidentally let the POST values get into it, that's a problem.

So if what you've posted is the end of your script, there's nothing to worry about. If there's more after that, the only potential risk is if you have $fieldvalue later and use it for something else...

[jscheuer1]

OK thanks, and yes that's it. That's all that's on the page. The sole purpose is to return the string that was sent via an AJAX post request.

About javascript. Sure, I've experimented with it and most if not all javascript could be run. But is this any different than say a user with developer tools running javascript on the page?

If another site posted javascript &/or HTML to this page, they could get it to do lots of things. I don't think there's any real threat there though, just potential confusion/embarrassment because neither this page, nor the page it's intended to work with connects to a database or does anything sensitive. The page it connects to in fact is an HTML page.

It's an experimental editor I'm helping another forum member with.

I'm thinking of taking it a step further:


<?php
$field1value = isset($_POST['field1value'])? $_POST['field1value'] : '';
echo html_entity_decode(strip_tags($field1value));
?>

Now do we have problems?

Here's a demo of what I have so far:

http://jscheuer1.comli.com/postedit/postit_2_h.htm

What you do is click in the edit window, add your text and/or tags, then click the Update button. The WYSIWYG version should appear in the other window. Tab characters currently cause a problem, so don't use those.

[djr33]

Seems fine. And, no, that won't be a problem.

I'm not sure why tabs would be a problem. But if you want to know how to remove them, let me know. It's a simple str_replace() operation.


And by the way, the only serious problem you could get would be if the value sent to the server isn't a string and can't be converted to a string. Technically arrays in forms are possible, so that would be one example. It's rare. And it won't actually hurt anything, but what it can do is generate an error. So in theory you could be checking the type of that variable if you want a perfect script. But only someone messing with it (not using your form for example) would have any problems, and it will at worst just display an error and potentially mess up the HTML encoding of that page (if you're even using it as HTML-- looks like you're not).
Anyway, the error would come from the 'echo' statement, which can only take strings and string-like things.

[jscheuer1]

I was just playing with it on my live server and apparently it has some form or addslashes on as a default in situations like this in that I can run javascript when using my wamp localhost server, but my live server is escaping " and ' so scripts aren't working.

[traq]

on your live server, you need to change your php.ini file to include the following lines:
; this should fix your immediate problem
; and is VERY GOOD PRACTICE in all cases anyway
magic_quotes_gpc = Off
; this one will have no affect on your current code
; and is usually not enabled anyway but it's good to make sure
magic_quotes_runtime = OffCreate the php.ini file if it doesn't exist in your site root.

----------------------
In your example above,

<?php
$field1value = isset($_POST['field1value'])? $_POST['field1value'] : '';
echo html_entity_decode(strip_tags($field1value));
?>are you trying to view HTML code "as code" (preventing it from being parsed by the browser)?
or the opposite?

what you're doing seems a little contradictory - you're removing all html tags, then decoding any htmlentities into their actual characters. so, if I input
<button>Button #1</button>
&lt;Button #2&gt;I'd get "Button #1" as plain text, and "Button #2" as an actual <button>.

...unless that's what you intended to do :)

[jscheuer1]

Can I turn off magic quotes just for a single page? I'd imagine so, and I'd think it preferable. If I can, how? And do I have to turn them back on?



Yes it does seem contradictory to strip tags and then decode entities. However, if you view the source of the HTML page, you will see that the Edit Window is not a textarea, rather a contenteditable div. As such it has HTML tags in it, but when you type - say:


<div>Hello World!</div>

into it, these are represented as:


&lt;div&gt;Hello World!&lt;/div&gt;

That gets posted to:


<?php
$field1value = isset($_POST['field1value'])? $_POST['field1value'] : '';
echo html_entity_decode(strip_tags($field1value));
?>

which is then returned back to the Viewing Window as:


<div>Hello World!</div>

and so what is seen in the Viewing Window is:


Hello World!

The reason tags are stripped first is to prevent actual HTML tags in the Edit Window from being preserved. In a contenteditable div, if you hit the enter key, it inserts a p (or perhaps a <br> - varies by browser). We don't want that p or br in the Viewing Window, only ones the user types in as <p> or <br>.

[traq]

you could put
php_flag magic_quotes_gpc Offin an .htaccess file for a specific directory (though I've found this to be less reliable).

To turn them back on, you'd simply need to remove those line(s) in your php.ini and/or .htaccess files.

Really, though, it's not a good idea to keep magic quotes turned on (php.net/manual/en/security.magicquotes.whynot.php).
Warning
This feature has been DEPRECATED as of PHP 5.3.0. Relying on this feature is highly discouraged.

If you want to "leave it alone" for now, you could just remove the slashes manually on that page:
<?php
if(get_magic_quotes_gpc()){
function stripslashes_recursive( $v ){
return is_array( $v )?
array_map( 'stripslashes_recursive',$v ):
stripslashes( $v );
}
$_GET = stripslashes_recursive( $_GET );
$_POST = stripslashes_recursive( $_POST );
$_COOKIE = stripslashes_recursive( $_COOKIE );
}I use this anyway, on almost everything, as a fallback measure (makes things portable).



--------------------
I see what you're doing now :)

--------------------
regarding cross-browser stuff, yeah - in fact, I've found webkit to be one of the worst at adding extra inline style junk - <span class="Apple-style-span"> (which has no observable effect on the actual style of anything), and so forth, everywhere.

[djr33]

Intuitively, disabling something for one page makes more sense. But magic_quotes is a mistake that has now been corrected in newer versions of PHP and should be removed from all systems-- it makes things easier, not harder.

The only case where you want magic_quotes is if you need it for a certain script that you find that was written to rely on magic_quotes. It's rare (and that script is coded badly, at least in that way), but as a workaround you can enable it for that page only. It's much better to do that.

[jscheuer1]

Hmm, OK well my host doesn't explicitly say I can have a php.ini - they don't explicitly say I can't either, but .htaccess in the folder works, and they do explicitly allow full use of .htaccess files.

I can experiment with php.ini - as I imagine there would be lots of uses for that. When you say the root of the site, do you mean the public or private root?

I'm not so sure I want magic quotes gpc off for this though, it does allow for cross site scripting. I don't think anything directly bad could happen, but a clever person could make a page of any kind look like it's on my domain. That might get me into trouble with my host. So I deleted the .htaccess file. That worked too, the quotes are back on. It's good to know about all that for future reference.

I checked the phpinfo() page, magic quotes runtime is already off and so is the one you didn't mention, the sybase one.

It wouldn't even have gpc on except that it's 5.2.17 and I guess that's the default or for backward compatibility reasons.

[djr33]

It's your choice, but there's really no debate about this: magic quotes is bad, so it should be disabled. It's true that it might cause some backward compatibility issues, but it's better to fix the bad code (or in those cases enable it).

Regarding anyone adding content to your site, that's a separate issue entirely.

Note that you can (and in some cases should) mimic the behavior of magic quotes-- in some cases, you want to escape quotes, and that's perfectly fine. But what you don't want is to have it done automatically on everything because it will be confusing, and you'll have lots of forward compatibility issues (which are harder to fix, not to mention more important, than backward compatibility, I think). So disabling magic quotes doesn't prevent anything-- it just turns off escaping as an arbitrary default for everything.


Regarding php.ini, it can be in different places. But it's almost certainly going to be in a private location (somewhere under the HTML directory). You'd have to check with your host.

You can use .htaccess effectively here. There's no real need for php.ini if you can't use it. php.ini is just lower level, so it means a little less processing I think. But it's not a problem realistically.
And if you put it in the .htaccess file for the root of your site (HTML root, in this case) you won't have to worry about it again.

[traq]

Right - the public_HTML/ or whatever its called on your host. If it 'works,' it's safe to assume that you're 'allowed' to use it.