Same problem on windows XP PHP version 5.2.5 on cells that contain a \ followed by double quotes (")

This bug is the same as bug #38918 and bug #38929.

* fputcsv() does escape values (replacing " with "", for example)
* It seems that fgetcsv() accepts two incompatible unescaping methods

Reproduced:
php > $fp = fopen('php://temp', 'r');
php > fputcsv($fp, array('foo', 'bar\\', 'baz'));
php > rewind($fp);
php > echo fgets($fp);
foo,"bar\",baz
php > rewind($fp);
php > var_dump(fgetcsv($fp));
array(2) {
  [0]=>
  string(3) "foo"
  [1]=>
  string(10) "bar\",baz
"
}
php > echo PHP_VERSION;
5.2.6-pl7-gentoo
php > 

I believe this problem is due to the fact fgetcsv() accept two escaping methods. An extra argument to fgetcsv() could (maybe?) fix this (and the extra argument could be added to fputcsv too)

magicaltux@php.net is wrong.  This bug is not about fgetcsv but about fputcsv.  fputcsv should always escape a double quote to two double quotes. But it doesn't do so if the field contains \"  This will mess up the CSV output such that it will not be importable in Excel or other such programs.

I've found the cause of this while writing tests for PR 197.

php_fputcsv(), while iterating over the fields to be output, has this fairly odd "escaped" concept — once escape_char (which is hardcoded \ at present) is seen, escaping stops until the next enclosure (" by default) is seen. It doesn't matter whether it's the following character or not.

After that, escape_char is then ignored anyway, and the enclosure is used as the "escape" character.

This came in via https://github.com/php/php-src/commit/af0adbed3963cdee1bfaf5e3a74b029d2b92c8b7 seven years ago to make the use of enclosures optional — the feature in general is good, but this is definitely an issue in the implementation.

Fixed in 5.3.22 and 5.4.12: https://github.com/php/php-src/commit/9b5cb0e8059b1e8bec096067491ed8d75f878938

Sadly, that was a classic case of fixing one thing and breaking another. Reopening, and unassigning myself.

Just not to confuse people, aharvey@php.net said it's fixed in "5.3.22 and 5.4.12", but in fact I tested in 5.4.31 and it's not fixed.

Looking at the patch commit it seems it's tagged with php-5.6.0beta4, so I guess will only be available in 5.6.

To summarize the related bugs: fputcsv() seems to be using inconsistent and broken escaping of the enclosing char (`"`) :

 - `"` followed by `\` are not escaped

 - `"` not followed by `\` are escaped by doubling them (e.g. `"` becomes `""`); leading to inconsistent escaping method

 - `\` themselves are not escaped, leading to generation of invalid CSV if a field is terminated by `\`: `"foo bar\",baz`

 - With the input `\\"`, the `"` is still considered to be escaped

Due to this combinaison of bugs, it is impossible to parse the CSV generated by the following call:

    fputcsv(STDOUT, ['foo\"bar', 'foo""bar', 'foo bar\\']);

Output is:

    "foo\"bar","foo""""bar","foo bar\"

Trying to parse this with a parser using the doubled-char escaping method will break on the first field.

Trying to parse this with a parser using the backslash escaping method will break on the 2nd and 3rd fields.

Trying to parse this with a parser allowing both methods will break on the 3rd field. Without the 3rd field, parsing this CSV document would result in loss of information (some `\` or `"` from the original input would be lost).

The issues with PHP’s CSV functions also seem to be exploitable.

<?php

$handle = fopen('php://memory', 'w+b');

fputcsv($handle, [
    'foo bar\\',    # 1
    'baz quz',      # 2
    'x',            # 3
    'y',            # 4
    'z',            # 5
    'foo\\\\",bar'  # 6
]);

rewind($handle);

var_dump(fgetcsv($handle));

// array(6) {
//   [0]=>  string(18) "foo bar\",baz quz""    # 1
//   [1]=>  string(1)  "x"                     # 2  (was # 3)
//   [2]=>  string(1)  "y"                     # 3  (was # 4)
//   [3]=>  string(1)  "z"                     # 4  (was # 5)
//   [4]=>  string(5)  "foo\\"                 # 5
//   [5]=>  string(4)  "bar""                  # 6
// }

3v4l.org: http://3v4l.org/LTnC1

One thinking to `disable` escape method: fputcsv($handle, $array, ',', '"', "\0")

Still not fixed after almost 10 years? The thing is this can result in formula injection.

http://blog.securelayer7.net/how-to-perform-csv-excel-macro-injection/

For example I have this string (it should go into one cell):

=,test'\","",=cmd|' /C calc'!A0"

According to the article I sanitize it by escaping the = at the beginning with an apostrphe.

'=,test'\","",=cmd|' /C calc'!A0"

Because of this bug however this string can still cause an injection because this bug causes the string to split into multiple cells and the second = is not escped.

> Still not fixed after almost 10 years?

It is not as simple. We first have to understand why fputcsv() and
friends support an escape character, which is an unrecognized
concept for RFC 4180; however, this RFC is informal and never made
it to a standard, so an escape character may make perfect sense.
But how exactly is it supposed to work?

Anyhow, "disabling" the escape character as plentysu already said,
is suffienct to get the desired result, see
<https://3v4l.org/eW2Mt>. This should be possible in a more
intuitive way, though, see request #51496.

Well, this behavior is there for so many years, that we can't
change it easily for BC reasons (and frankly, the sense of *this*
escaping escapes me).  Therefore I'm closing this ticket as
duplicate of request #38301 and request #51496, respectively.