Question about php include() security

[TheServant]

Usually when I write a form in html, I put the action as :
[PHP]action="<?php echo $_SERVER['REQUEST_URI']; ?>"[/PHP]

Now in my page I obviously include() the thing I want my form to do. So how it works is it checks the variables that have been sent, and if they are what is expected then it does the rest of my code. Now why I do that is so that if you go view page source, your will only see the current pages URL in the action part.

Obviously the alternative is to have action to point straight to the file so that it actually posts the data to another file rather than itself. So I wanted to know your thoughts on if I am being over protective, or if this is standard practice, or if this is a waste of time and you have no idea why I do this?

Without hacking in the server, is there a way to view the php of a php file if you know the file location?

Cheers,
TS

[Markus]

Usually when I write a form in html, I put the action as :
[PHP]action="<?php echo $_SERVER['REQUEST_URI']; ?>"[/PHP]

Now in my page I obviously include() the thing I want my form to do. So how it works is it checks the variables that have been sent, and if they are what is expected then it does the rest of my code. Now why I do that is so that if you go view page source, your will only see the current pages URL in the action part.

Obviously the alternative is to have action to point straight to the file so that it actually posts the data to another file rather than itself. So I wanted to know your thoughts on if I am being over protective, or if this is standard practice, or if this is a waste of time and you have no idea why I do this?

Without hacking in the server, is there a way to view the php of a php file if you know the file location?

Cheers,
TS

To your last question, which should really sum everything up: there is now way for a user to view your unprocessed php pages - the php is processed on the server and before it gets to the browser. Therefore, it is impossible to read.

Imagine if people could actually intercept your php *cringe*

Regards!

[TheServant]

To your last question, which should really sum everything up: there is now way for a user to view your unprocessed php pages - the php is processed on the server and before it gets to the browser. Therefore, it is impossible to read.

Imagine if people could actually intercept your php *cringe*

Regards!

Great! So, is it better to send the form to a script, or include() it as I described? I am presuming it makes no difference but I would just like to make sure.

[Markus]

Great! So, is it better to send the form to a script, or include() it as I described? I am presuming it makes no difference but I would just like to make sure.

Makes no difference my friend!

[TheServant]

Makes no difference my friend!

Cheers, but I just thought of a potential problem. If someone knew the path to your php file, could they send a form to it? I don't think it can, because it is server side, so can only be accessed from the same server (requesting page), but I better check.

So for example, I have a update_player_money.php which accepts some form inputs and applies them appropriately to the db. If someone made their own form, to simulate mine and send it to MY php file, would it work? Or because it wouldn't be from my server it would fail?

[Markus]

Cheers, but I just thought of a potential problem. If someone knew the path to your php file, could they send a form to it? I don't think it can, because it is server side, so can only be accessed from the same server (requesting page), but I better check.

So for example, I have a update_player_money.php which accepts some form inputs and applies them appropriately to the db. If someone made their own form, to simulate mine and send it to MY php file, would it work? Or because it wouldn't be from my server it would fail?

No, it would work. But why is that a problem aslong as you are sanitising ALL the input before it's put into the database?

[TheServant]

No, it would work. But why is that a problem aslong as you are sanitising ALL the input before it's put into the database?

Well, my script gets the session username, and then finds the data in the table according to that username. You use the forms to do things like train/untrain troops (online game). Now if someone worked all this out, they could send all the data I usually send (fake a form submission) including a fake session username. Why is this a problem? If they use another players username, they could do things to their account.

I have only just thought about this and I need to go through my code to see if I am in fact protected, but from memory, I think you could do this. The only way of solving it would be to have the users encrypted password stored as a session variable and check that on every load.

[TheServant]

Well, my script gets the session username, and then finds the data in the table according to that username. You use the forms to do things like train/untrain troops (online game). Now if someone worked all this out, they could send all the data I usually send (fake a form submission) including a fake session username. Why is this a problem? If they use another players username, they could do things to their account.

I have only just thought about this and I need to go through my code to see if I am in fact protected, but from memory, I think you could do this. The only way of solving it would be to have the users encrypted password stored as a session variable and check that on every load.

OK, so after some testing, it doesn't matter it I have include() or just post the form. If someone wanted to use my php function they just send it to my form page and the include() function will run it for them anyway.

Now the major problem is, securing my session variables. If someone knew what my session variable for username was (which is my table index), they could set it to another username and then run a script to send that as well as anything they want to my php file which will do what it is supposed to?

Potentially they could tell the server to untrain, or even delete another user. Any ideas how I could stop this?