setting variables and white list and security?

[phatsion2]

Hi all. 

i am trying to use php to include a javascript onto different pages, and then "sort of " pass it a var.

The bulk of the code will be in an included footer php file.

The var will be set in the main page.

 

i have it working as follows: by just using echo 3 times.. the 1st with the first part of the script, the 2nd is the variable, and the 3rd is the rest of the script.

The same endcode.php file needs to also be used for pages that wont have a var set, and wont be using the script - hense the isset.

<!-- mainPage.php -->
<?php $sion_gallery_id = '450'; ?> 
<?php include(endcode.php); ?> 

<!-- endcode.php -->
<?php if (isset($sion_gallery_id)) 
 {echo "start of javascript.......album/"; echo $sion_gallery_id; echo"/end of script"; }   
  else { echo "var not on set";} ?> 

 

This works great, and i can set $sion_gallery_id do different numbers, and it pulls different albums through for diff pages.

 Is this secure enough as it is?

 

I have read about whitelists, and tried the following:

<!-- Headcode.php -->
<?php $whitelist = array('465','6', '7','745','450'); ?>



<!-- mainPage.php -->
<?php include(Headcode.php);?>

<?php $sion_gallery_id = '450'; ?> 

<?phpinclude(endCode.php); ?>




<!-- endCode.php -->
 <?php 
if (isset($sion_gallery_id)) {if (in_array($sion_gallery_id, $whitelist))
  {echo "java script content goes here.......album/"; echo $sion_gallery_id; echo"/end of script"; }   
   else { echo "var not on white list";}} 
   else { echo "No var set"; }; ?> 

This works when i try it at a basic level.

However,

when i set it up properly  with the headcode and endcode pages being included, and also with all the actual javascript being echoed in endcode.php  -- it worked perfectly for the first page. But when i changed the var to a different number, remembering  to add this to the whitelist, it wont load - and echoes "var not on white list". ..... but it is?

 

So, do i need to use a white list for this, or have i got the wrong end of the stick anyway.

And if i do, can anyone see what may be happening?

Is the first var getting cashed somewhere?

 

Any help is much appreciated.

 

Thanks,

Sion.

 

 

 

 

 

 

[requinix]

You don't need to whitelist your own code so that it can work with itself.

 

A whitelist is about permitting unknown input. Something coming from a user. Or really something that you aren't coming up with by yourself. That's the whole point: you don't know what input you may get so you need to be restrictive about what you allow.

But your own code? You wrote it. You don't need to validate the variable that you yourself literally just set.

[phatsion2]

Thanks for this. that makes life much easier.

 

If i was to set the variable in the url , www.mysite.com/page.php?sion_gallery_id=465

 

if(isset($_GET['sion_gallery_id'])){

$sion_gallery_id = $_GET['sion_gallery_id'];}

 

Should i use a white list then?

 

Thanks,

Sion.

[Jacques1]

You always have to make sure that the input is safe, even if you think it comes from you. The general approach is also rather poor, but more on that later.

 

Contrary to requinix' assumption, hard-coded variables are not inherently safe. For example, PHP developers love to inject user-defined variables through mechanisms like Register Globals or extract(), and this can enable the user to overwrite your variable with a new value. That's obviously a problem. It's also common that hard-coded variables sooner or later turn into dynamic variables, because that's easier to manage. Are you sure that you or your successor will remember that there's now a security vulnerability they have to fix? I wouldn't bet on that.

 

So don't do this. As I already said, the approach itself is bad: Your included script pulls some global variable from “nowhere” (hopefully the main script), and then you dump that variable straight into a JavaScript context. C'mon, this has nothing to do with proper programming.

 

There's already a well-defined interface for safely passing values from a server-side script to JavaScript: Ajax. Use it, and the problem will go away.

[requinix]

You always have to make sure that the input is safe, even if you think it comes from you. The general approach is also rather poor, but more on that later.

Thinking it came from you and knowing it came from you are two different things. In the first case OP knows it came from him. In this new case it does not. That's all I said.

 

 

Contrary to requinix' assumption, hard-coded variables are not inherently safe.

You heard it here first, folks:

$value = "123";
echo $value;

is unsafe.

 

For example, PHP developers love to inject user-defined variables through mechanisms like Register Globals or extract(), and this can enable the user to overwrite your variable with a new value.

Then that's not a hard-coded value and, thankfully, doesn't apply to what I said.

 

It's also common that hard-coded variables sooner or later turn into dynamic variables, because that's easier to manage. Are you sure that you or your successor will remember that there's now a security vulnerability they have to fix? I wouldn't bet on that.

There wasn't a vulnerability before. They introduced it by using user input without validating it, which is where it needs to happen anyways because in "my" code it's too late to react properly to the bad value - all I can do is fail.

If I can't trust the developer then all hope is lost. Or my life would be a nightmare because I'd have to second-guess everything. Could they hardcode a malicious value? Yes. Could I take precautions? Sure. Could they simply circumvent those precautions instead? You bet.

 

So don't do this. As I already said, the approach itself is bad: Your included script pulls some global variable from “nowhere” (hopefully the main script), and then you dump that variable straight into a JavaScript context. C'mon, this has nothing to do with proper programming.

Forcing to int or JSON-encoding doing something else explicitly would be a good idea.

 

There's already a well-defined interface for safely passing values from a server-side script to JavaScript:

Exactly: JSON.

Ajax.

Oh. Right. That debate...

[Philip]

There's already a well-defined interface for safely passing values from a server-side script to JavaScript: Ajax. Use it, and the problem will go away.

 

Extra pointless server calls ftw!

[Jacques1]

Have you guys ever wondered why the rest of the world makes fun of PHP and thinks of it as a toy language for kiddies and clueless amateurs?

 

This isn't even about “security”. It's programming 101: How to think ahead and avoid bugs. It's OK for a newbie to not understand those concepts, but you've been doing this long enough. requinix, you've actually seen those vulnerabilities right here at phpfreaks. You've personally observed them. But for some reason you just keep making the same mistakes.

 

It's not enough to write code which works under lab conditions. It needs to work in real life, and real life includes bugs, misunderstandings, unexpected situations, carelessness and sometimes plain incompetence. If your application cannot handle this, then it's garbage. You may try to blame the mistake on somebody else, but it's actually you who hasn't thought ahead.

 

Why is this so hard to understand? Applications need to be robust. It doesn't matter if a variable is currently “trusted” or “kinda-sorta trusted” or “untrusted”. You simply make sure that it cannot cause any damage. You choose an approach which works at all times, even if things go wrong. That's why we use prepared statements instead of relying on our good eye. That's why we use bcrypt instead of relying on the user to provide a strong password.

 

The variable in the original code is not hard-coded. It's set somewhere in various parent scripts, and now you're hoping that it's indeed hard-coded and doesn't contain any unexpected value (Hi, Steam) and hasn't been overwritten and will be safe now and forever. You cannot be serious. If you consider this good programming, then you have a problem.

 

 

 

Extra pointless server calls ftw!

 

Oh noez, an HTTP request! Yes, that's the biggest problem of a guy writing his first PHP script. Thank you for you smart comment.

 

And it's also fine to waste dozens of requests for stupid ads, tracking garbage and GUI gimmicks. But you can't have an Ajax request to improve security. That's evil.

 

Anyway, there's hope for you: You can also JSON-encode the value, HTML-escape it, store it in a hidden element and parse it with JavaScript (see the OWASP).

Edited January 21, 2015 by Jacques1

[NotionCommotion]

You don't need to whitelist your own code so that it can work with itself.

 

A whitelist is about permitting unknown input. Something coming from a user. Or really something that you aren't coming up with by yourself. That's the whole point: you don't know what input you may get so you need to be restrictive about what you allow.

But your own code? You wrote it. You don't need to validate the variable that you yourself literally just set.

 

Don't know why, but this just struck me as humorous.  Well, I'm a user.  Some times, I just need to protect me from myself!

[phatsion2]

Hi Guys.

Thanks for all the Advise.

Will look into doing with with JSON.