I know there're plenty of topics regarding escaping characters but I just can't find the solution for my problem.
It's very easy. This is string I have:
$path = "C:\Users\Me\Desktop\14409238.jpg";
Howver, no matter how many escaping techniques I use, I can't manage to display the correct path without destroying it. In all cases the \14 will be replaced with
C:\Users\Me\Desktopd09238.jpg
How do I solve this?
Don't use backslashes in PHP for windows paths. It's smart enough to convert for you:
$path = "c:/users/me/desktop/...";
Using backslashes runs into the exact problem you have - backslashing certain characters turns them into metacharacters, not regular characters.
try to change, the Physical path to access the image, stored on Desktop can be written as,
$path = "C:\Users\Me\Desktop\14409238.jpg";
to
$path = "C:\\Users\\Me\\Desktop\\14409238.jpg";
Avoid the situation entirely, PHP under Windows allows you to submit paths with the backslash
c://Users/Me/Desktop/file.jpg
This also avoids interoperability headaches when a script must run within .nix and Windows.
Related
No matter how hard I try, mkvextract doesn't work properly. I'm aware that there is a problem with the file path, but I tried hundreds of times, but I still could not succeed. How can I run this correctly?
shell_exec("mkvextract tracks /home/movies/R-12/X-1 ÇĞŞZ.mkv");
or
$filename = "/home/movies/R-12/X-1 ÇĞŞZ.mkv"
echo shell_exec("mkvextract tracks \"$filename\"");
I am aware that you cannot access the file path due to special characters
There may be several issues:
A file read permision issue: the file exists, but PHP (and the mkvextract it runs) don't have the permission to open it. In the rest of my answer I assume this is not happening, because you haven't added any error message containg the word permission or access to your question.
A shell argument escaping issue: correcly passing a command argument containing whitespace and/or shell metacharacters (e.g. ", \, $). I address this with escapeshellarg below.
A filename encoding issue: correctly specifying non-ASCII characters in filenames. I address this with mb_convert_encoding below.
For testing purposes, make a copy of the input file to /home/movies/t.mkv, and then try echo shell_exec("mkvextract tracks /home/movies/t.mkv").
If that works, then rename the copy to /home/movies/t t.mkv, and then try echo shell_exec("mkvextract tracks " . escapeshellarg("/home/movies/t t.mkv")). Without the escapeshellarg call, it wouldn't work, because the filename contains a space.
If that works, then the problem is with non-ASCII characters in the filename. To investigate it further, examine the output of var_dump(scandir("/home/movies/R-12")), and see how the letters with accents appear there. Pass it the same way to shell_exec. Don't forget about escapeshellarg.
If that works, use encoding conversion (with mb_convert_encoding) for the remaining filenames. You may want to ask a separate question about that, specifying the output of var_dump(scandir("/home/movies/R-12")) and var_dump("X-1 ÇĞŞZ.mkv") in your question.
$filename = "/home/movies/R-12/X-1 ÇĞŞZ.mkv"
echo shell_exec("sudo mkvextract tracks \"$filename\"");
I guess the whole problem was not adding sudo per :)
my code is not working ? and i dont want to use str_replace , for there maybe more slashes than 3 to be replaced. how can i do the job using preg_replace?
my code here like this:
<?php
$str='<li>
<span class=\"highlight\">Color</span>
Can\\\'t find the exact color shown on the model pictures? Just leave a message (eg: color as shown in the first picture...) when you place order.
Please note that colors on your computer monitor may differ slightly from actual product colors depending on your monitor settings.
</li>';
$str=preg_replace("#\\+#","\\",$str);
echo $str;
There is merit in the other answers, but to me it looks like what you're actually trying to accomplish is something very different. In the php code \\\' is not three slashes followed by an apostrophe, it's one escaped slash followed by an escaped apostrophe, and in the rendered output, that's exactly what you see—a slash followed by an apostrophe (with no need to escape them in the rendered html). It's important to realize that the escape character is not actually part of the string; it's merely a way to help you represent a character that normally has very different meaning in within php—in this case, an apostrophe normally terminates a string literal. What looks like 4 characters in php is actually only 2 characters in the string.
If this is the extent of your code, there's no need for string manipulation or regular expressions. What you actually need is just this:
<?php
$str='<li>
<span class="highlight">Color</span>
Can\'t find the exact color shown on the model pictures? Just leave a message (eg: color as shown in the first picture...) when you place order.
Please note that colors on your computer monitor may differ slightly from actual product colors depending on your monitor settings.
</li>';
echo $str;
?>
Only one escape character is needed here for the apostrophe, and in the rendered HTML you will see no slashes at all.
Further Reading:
Escape sequences
The root of this problem is actually in how it was written into your database and likely to be caused by magic_quotes_gpc; this was used in older versions and a really bad idea.
The best fix
This requires a few steps:
Fix the script that puts the HTML inside your database by disabling magic_quotes_gpc.
Write a script that reads all existing database entries, applies stripslashes() and saves the changes.
Fix the presentation part (though, that may need no changes at all.
Alternative patch
Use stripslashes() before you present the HTML.
use this pattern
preg_replace('#\\+#', '\\', $text);
This replaces two or more \ symbols preceding an ' symbol with \'
$theConvertedString = preg_replace("/\\{2,}'/", "\'", $theSourceString);
Ideally, you shouldn't have code causing this issue in the first place so I would have a look at why you have \\' in your code to begin with. If you've manually put it in your variables, take it out. Often, this also happens with multiple calls to addslashes() or mysql_real_escape_string() or a cheap hosting providers' automatic transformation of all POST request variables to escape slashes, combined with your server side PHP code to do the same.
It's a pretty silly question, sorry. There is a big and rather complex system that has a bug and I managed to track it down to this piece
return str_replace('%2F', '/', rawurlencode(str_replace('%20', ' ', $key)));
There is a comment explaining why slashes are replaced - to preserve path structure, e.g. encoded1/encoded2/etc. However there is no explanation whatsoever why %20 is replaced with space and that part is the direct cause of a bug. I am tempted to just remove str_replace() but it looks like it was placed there for some reason and I have a feeling that I'll break something else by doing this. Has anyone encountered anything similar? Perhaps it's a dirty fix for some PHP bug? Any guesses and insights are highly appreciated!
Doing so would prevent %20 (encoded space) from being encoded to %2F20. However, it only serves to prevent double escaped spaces; other special characters would still get double encoded.
This is a sign of bad code; strings that are passed into this function shouldn't be allowed to have encoded characters in the first place.
I would recommend creating unit tests that cover all referencing code and then refactor this function to remove the str_replace() to make sure it doesn't break the tests.
First thing that jumps to mind is as a mitigation technique against double encoding.
Not that I would recommend doing such a thing this way, as it would get real messy real quickly (and one would already wonder why only that entity, perhaps 'they' never experienced issues with any others... yet).
It could be the result of a misunderstanding of rawurlencode() vs urlencode()
urlencode() replaces spaces with + signs
If the original author thought that rawurlencode() did the same thing, they would be attempting to pre-encode the spaces so they don't get turned into +s
This has been driving be crazy, but I can't seem to find an answer. We run a technical knowledge base that will sometimes include Windows samba paths for mapping to network drives.
For example: \\servername\sharename
When we include paths that have two backslashes followed by each other, they are not escaped properly when running 'addslashes'. My expected results would be "\\\\servername\\sharename", however it returns "\\servername\\sharename". Obviously, when running 'stripslashes' later on, the double backslash prefix is only a single slash. I've also tried using a str_replace("\\", "\", $variable); however it returns "\servername\sharename" when I would expect "\\servername\sharename".
So with addslashes, it ignores the first set of double-backslashes and with str_replace it changes the double-backslashes into a single, encoded backslash.
We need to run addslashes and stripslashes for database insertion; using pg_escape_string won't work in our specific case.
This is running on PHP 5.3.1 on Apache.
EDIT: Example Code
$variable = 'In the box labeled Folder type: \\servername\sharename';
echo addslashes($variable);
This returns: In the box labeled Folder type: \\servername\\sharename
EDIT: Example Code #2
$variable = 'In the box labeled Folder type: \\servername\sharename';
echo str_replace('\\', '\', $variable);
This returns: In the box labeled Folder type: \servername\sharename
I'd also like to state that using a single quotes or double-quotes does not give me different results (as you would expect). Using either or both give me the same exact results.
Does anyone have any suggestions on what I can possibly do?
I think I know where is a problem. Just try to run this one:
echo addslashes('\\servername\sharename');
And this one
echo addslashes('\\\\servername\sharename');
PHP escapes double slashes even with single quotes, because it is used to escape single quote.
Ran a test on the problem you described, and the only way I could get the behavior you desired was to couple a conditional with a regex and anticipate the double slashes at the start.
$str = '\\servername\sharename';
if(substr($str,0,1) == '\\'){
//String starts with double backslashes, let's append an escape one.
//Exclaimation used for demonstration purposes.
$str = '\\'.$str;
echo addslashes(preg_replace('#\\\\\\\\#', '!',$str ));
}
This outputs:
!servername\\sharename
While this may not be an outright answer, it does work and illustrates a difference in how the escape character is treated by these two constructs. If used, the ! could easily be replaced with the desired characters using another regex.
This is not a problem with addslashes, it is a problem with the way you are assigning the string to your variable.
$variable = 'In the box labeled Folder type: \\servername\sharename';
echo $variable;
This returns: In the box labeled Folder type: \servername\sharename
This is because the double backslash is interpreted as an escaped backslash. Use this assignment instead.
$variable = 'In the box labeled Folder type: \\\\servername\\sharename';
I've determined, with more testing, that it indeed is with how PHP is handling hard-coded strings. Since hard-coded strings are not what I'm interested in (I was just using them for testing/this example), I created a form with a single text box and a submit button. addslashes would correctly escape the POST'ed data this way.
Doing even more research, I determined that the issue I was experiencing was with how PostgreSQL accepts escaped data. Upon inserting data into a PostgreSQL database, it will remove any escape characters it is given when it actually places the data in the table. Therefore, stripslashes is not required to remove escape characters when pulling the data back out.
This problem stemmed from code migration from PHP 4.1 (with Magic Quotes on) to PHP 5.3 (with Magic Quotes deprecated). In the existing system (PHP4), I don't think we were aware that Magic Quotes were on. Therefore, all POST data was being escaped already and then we were escaping that data again with addslashes before inserting. When it got inserted into PostgreSQL, it would strip one set of slashes and leave the other, therefore requiring us to stripslashes on the way out. Now, with Magic Quotes off, we escape with addslashes but are not required to use stripslashes on the way out.
It was very hard to organize and determine exactly where the problem lay, so I know this answer is a little off to my original question. I do, however, thank everyone who contributed. Having other people sound off on their ideas always helps to make you think on avenues you may not have on your own.
I have a PHP app which takes a user-inputted $imageurl and does the following:
exec('convert "'.$url.'" -thumbnail 80x500 "images/out.jpg"');
Now obviously I have to take some precautions with this to stop users from executing arbitrary code. For example, if the user sets $url to";rm -rf *;" is no good at all.
So for starters I have to filter out " so that no matter what they type in, they can't escape from their input being a parameter to convert. But should I filter out ; as well? I've seen urls with semicolons in them... and while the semicolon is really the danger here, filtering out " would still keep me safe right? But can urls have " in them? And are there any other characters I should watch for?
Maybe instead of filtering characters out I should try to escape them. So should I try to escape every character interpreted specially by the shell? Or just escape " as everything else is sort of "pre-escaped" given that it's inside double-quotes?
Sorry for my rambling confusion, I'm just new at this and want to stay safe!
Thanks,
Mala
Well, if you want to make sure the URL is a URL, use filter_var
filter_var($url, FILTER_VALIDATE_URL);
This will not prevent people from supplying a URL like example.com/foo?;rm -rf though, which is still a valid URL. I'm not sure if this would cause rm to execute, but you could also check the URL with parse_url() and omit the query part.
Generally, it is a good idea to have a look at these as well:
escapeshellarg() — Escape a string to be used as a shell argument
escapeshellcmd() — Escape shell metacharacters
Also see the PHP Manual on securing user input.
You can use the escapeshellarg function.
Use Regular Expressions to ensure that $url only contains valid filename characters, e.g. "(\w\.\-/){1,256}". Plus, I imagine you are renaming the file the user uploads to be a random filename, or at least a whitelisted filename (i.e. using the same regex). sha1.ext or md5.ext are easy formats to use.