shell_exec problem in PHP

Hello
This command couldn't work, can anyone help me:

<?php
shell_exec("php ..\..\wu\index.php");
?>

PHP:

 

Well... on my server I have shell_exec amongst the many functions I block from being allowed to run since it's a security hole... maybe your host did the same?

Of course, with those up-tree links are you sure you even have access to that directory from the currently executing script?!?

Though if all you want to do is run some PHP file, why are you trying to shell_exec it instead of a simple include?

 

now i have found that unfortunately shell_exec command blocked on many servers
i decided to find a way to hide redirect html codes from google crowlers.
i tested include... redirect meta tags and ....
but finally i found this answer it seems google crowler can't trace our redirect codes with this code:

PHP:

header("HTTP/1.1 301 Moved Permanently");
header("Location: http://www.site.com/test.htm");
exit();

Code (markup):

ASP:

<%@ Language=VBScript %>
<%
Response.Status="301 Moved Permanently"
Response.AddHeader "Location", "http://www.site.com/test.asp"
response.end
%>

Code (markup):

 

Still wondering why in your example you weren't just running it as an include.

 

yes include_once should have worked fine

 

part of website designers use this way to locate files (../../test/test.css) and part of them use this way to locate files (test.com/test/test.css)
include is unable to (change default path of our php file) to the destination path (the place that included php is in it)! for example: if i run this php file test.com/test1/test2/test3/test.php and use include in it, to get php data of this file: test.com/test.php the include can only return its php codes. and can't change the path to root of test.com

 

Uhm... that's gibberish... or dangerous -- one of the two...

Since if you ran your code in test.com/test.php that ../../ would literally resolve ABOVE the http root -- someplace you shouldn't be trying to access in the first place.

I mean, assuming that the http root of test.com/ resolves to /var/www/test.com/web as the local directory (or c:\xampp\htdocs\test.com in local testing or /users/test.com/www or whatever) it's a really bad idea to write code that points that far up-tree.

That's why if your directory and/or include structure needs to point up-tree with ../, it is likely there is something horrifically and terrifyingly wrong with your directory structure; remember the rule of good structure, all links should point down-tree. Probably a hefty part of why I favor 'one index.php to rule them all' construction, since you ALWAYS start in root regardless of what page is being called... or even if I don't do that, I put all my user callable files in root with all the sub-files in directories.

/ -- index.php, all user callable php files
/downloads -- user downloads
/images -- content images
/libraries -- library files (includes)
/static -- static includes (like pages that aren't db stored)
/templates/templateName -- template includes and CSS
/templates/templateName/images -- presentational images unique to the template

...and so forth. That way you NEVER have to do a ../ since they're a security risk on includes, generally make portability or running in a subdirectory harder, etc, etc... Quite literally if you're using ../ on a website, there's something REALLY wrong with the planning! (hell, my 'one index' uses the presence of ../ as one of it's triggers to detect hacking attempts!)

... and whiskey tango foxtrot are 'designers' doing setting up directory structures? PSD jockeys have no business telling the back-end folks how to handle that! Tell them to stick to pushing pixels around with their ignorant back-assward bull of putting the cart before the horse. Since generally speaking what most people who call themselves "designers" do has no business in the process until AFTER there's semantic markup and working responsive layoutS -- YES, PLURAL!

 

I'm just curious as to what the security risk is with using ../? Generally I / up from the index or declare the mail folder first but there's no particular reason why I do this...

 

Windows install of Apache you could accidentally access directories above the root location since PHP runs with the same permissions as the active user Apache was started from (big problem during XAMPP/WAMP testing), some PHP installs execute with elevated privileges, again pointing at directories above the current location -- and even if you can up-tree to the root, you could end up with access to some user specific values thanks to idiocy like suphp, end up being able to access things like users mail directories. SMF had a vulnerability in the theme system that exploited this back on 1.0.7 (so a while ago) that let a user upload be loaded as if it was the template file. (doh)

Generally that's why you should filter any user input that you use to make directories so it can't contain ".." at all... I extend that to just say it's sloppy/bad practice since if you have a directory structure that's worth a damn, you never have to use "../" in the first place.

 

Well you learn something new every day! Cheers.