reference/pcre/pattern.modifiers.xml
37e10ee15067a55ff20be4641c5b3935ec3aa170
37e10ee15067a55ff20be4641c5b3935ec3aa170
...
...
@@ -75,91 +75,6 @@
75
75
</simpara>
76
76
</listitem>
77
77
</varlistentry>
78
-
<varlistentry xml:id="reference.pcre.pattern.modifiers.eval">
79
-
<term><emphasis>e</emphasis> (<literal>PREG_REPLACE_EVAL</literal>)</term>
80
-
<listitem>
81
-
&warn.deprecated.feature-5-5-0.removed-7-0-0;
82
-
<simpara>
83
-
If this deprecated modifier is set, <function>preg_replace</function>
84
-
does normal substitution of backreferences in the
85
-
replacement string, evaluates it as PHP code, and uses the
86
-
result for replacing the search string.
87
-
Single quotes, double quotes, backslashes (<literal>\</literal>) and NULL chars will
88
-
be escaped by backslashes in substituted backreferences.
89
-
</simpara>
90
-
<caution>
91
-
<para>
92
-
The <function>addslashes</function> function is run on each matched backreference before
93
-
the substitution takes place. As such, when the backreference
94
-
is used as a quoted string, escaped characters will be converted
95
-
to literals. However, characters which are escaped, which would
96
-
normally not be converted, will retain their slashes. This makes
97
-
use of this modifier very complicated.
98
-
</para>
99
-
</caution>
100
-
<caution>
101
-
<para>
102
-
Make sure that <parameter>replacement</parameter> constitutes a valid PHP code string,
103
-
otherwise PHP will complain about a parse error at the line containing
104
-
<function>preg_replace</function>.
105
-
</para>
106
-
</caution>
107
-
<caution>
108
-
<para>
109
-
Use of this modifier is <emphasis>discouraged</emphasis>, as it can easily introduce
110
-
security vulnerabilites:
111
-
</para>
112
-
<informalexample>
113
-
<programlisting role="php">
114
-
<![CDATA[
115
-
<?php
116
-
$html = $_POST['html'];
117
-
118
-
// uppercase headings
119
-
$html = preg_replace(
120
-
'(<h([1-6])>(.*?)</h\1>)e',
121
-
'"<h$1>" . strtoupper("$2") . "</h$1>"',
122
-
$html
123
-
);
124
-
]]>
125
-
</programlisting>
126
-
</informalexample>
127
-
<para>
128
-
The above example code can be easily exploited by passing in a string such as
129
-
<literal><h1>{${eval($_GET[php_code])}}</h1></literal>. This gives
130
-
the attacker the ability to execute arbitrary PHP code and as such gives him
131
-
nearly complete access to your server.
132
-
</para>
133
-
<para>
134
-
To prevent this kind of remote code execution vulnerability the
135
-
<function>preg_replace_callback</function> function should be used instead:
136
-
</para>
137
-
<informalexample>
138
-
<programlisting role="php">
139
-
<![CDATA[
140
-
<?php
141
-
$html = $_POST['html'];
142
-
143
-
// uppercase headings
144
-
$html = preg_replace_callback(
145
-
'(<h([1-6])>(.*?)</h\1>)',
146
-
function ($m) {
147
-
return "<h$m[1]>" . strtoupper($m[2]) . "</h$m[1]>";
148
-
},
149
-
$html
150
-
);
151
-
]]>
152
-
</programlisting>
153
-
</informalexample>
154
-
</caution>
155
-
<note>
156
-
<para>
157
-
Only <function>preg_replace</function> uses this modifier;
158
-
it is ignored by other PCRE functions.
159
-
</para>
160
-
</note>
161
-
</listitem>
162
-
</varlistentry>
163
78
<varlistentry>
164
79
<term><emphasis>A</emphasis> (<literal>PCRE_ANCHORED</literal>)</term>
165
80
<listitem>
...
...
@@ -207,7 +122,7 @@ $html = preg_replace_callback(
207
122
This modifier inverts the "greediness" of the quantifiers so
208
123
that they are not greedy by default, but become greedy if
209
124
followed by <literal>?</literal>. It is not compatible with Perl. It can also
210
-
be set by a (<literal>?U</literal>)
125
+
be set by a <literal>(?U)</literal>
211
126
<link linkend="regexp.reference.internal-options">modifier setting within
212
127
the pattern</link> or by a question mark behind a quantifier (e.g.
213
128
<literal>.*?</literal>).
...
...
@@ -242,6 +157,7 @@ $html = preg_replace_callback(
242
157
<simpara>
243
158
The (?J) internal option setting changes the local <literal>PCRE_DUPNAMES</literal>
244
159
option. Allow duplicate names for subpatterns.
160
+
As of PHP 7.2.0 <literal>J</literal> is supported as modifier as well.
245
161
</simpara>
246
162
</listitem>
247
163
</varlistentry>
...
...
@@ -251,15 +167,22 @@ $html = preg_replace_callback(
251
167
<simpara>
252
168
This modifier turns on additional functionality of PCRE that
253
169
is incompatible with Perl. Pattern and subject strings are
254
-
treated as UTF-8. This modifier is available from PHP 4.1.0
255
-
or greater on Unix and from PHP 4.2.3 on win32. UTF-8
256
-
validity of the pattern and the subject is checked since PHP
257
-
4.3.5. An invalid subject will cause the preg_* function to
170
+
treated as UTF-8. An invalid subject will cause the preg_* function to
258
171
match nothing; an invalid pattern will trigger an error of
259
172
level E_WARNING. Five and six octet UTF-8 sequences are
260
-
regarded as invalid since PHP 5.3.4 (resp. PCRE 7.3
261
-
2007-08-28); formerly those have been regarded as valid
262
-
UTF-8.
173
+
regarded as invalid.
174
+
</simpara>
175
+
</listitem>
176
+
</varlistentry>
177
+
<varlistentry>
178
+
<term><emphasis>n</emphasis> (<literal>PCRE_NO_AUTO_CAPTURE</literal>)</term>
179
+
<listitem>
180
+
<simpara>
181
+
This modifier makes simple <code>(xyz)</code> groups non-capturing.
182
+
Only named groups like <code>(?<name>xyz)</code> are capturing.
183
+
This only affects which groups are capturing, it is still possible to
184
+
use numbered subpattern references, and the matches array will still
185
+
contain numbered results.
263
186
</simpara>
264
187
</listitem>
265
188
</varlistentry>
266
189