Hey,
while reading the session documentation today
(en/reference/session/reference.xml) I noticed the following:
To continue, <A HREF="nextpage.php?<?php echo strip_tags (SID)?>">click
here</A>
The `strip_tags()` is used when printing the SID in order to prevent XSS
related attacks.
What's the point of having the SID support < and > anyway and can't we
just do the 'strip_tags' internally. The usage of strip_tags() in the
example is now needed, but it looks, well, kinda strange that it is
needed.
regards,
Derick
Perhaps the real answer here is to turn on input filtering by default so
we defeat XSS once and for all across the board.
Hey,
while reading the session documentation today
(en/reference/session/reference.xml) I noticed the following:To continue, <A HREF="nextpage.php?<?php echo strip_tags (SID)?>">click
here</A>The
strip_tags()is used when printing the SID in order to prevent XSS
related attacks.What's the point of having the SID support < and > anyway and can't we
just do the 'strip_tags' internally. The usage ofstrip_tags()in the
example is now needed, but it looks, well, kinda strange that it is
needed.regards,
Derick
Excuse my ignorance Rasmus but how do we turn on input filtering now? (I
will pretend I know what "input filtering" is)
El dom, 08-02-2004 a las 20:26, Rasmus Lerdorf escribió:
Perhaps the real answer here is to turn on input filtering by default so
we defeat XSS once and for all across the board.Hey,
while reading the session documentation today
(en/reference/session/reference.xml) I noticed the following:To continue, <A HREF="nextpage.php?<?php echo strip_tags (SID)?>">click here</A> The `strip_tags()` is used when printing the SID in order to prevent XSS related attacks.What's the point of having the SID support < and > anyway and can't we
just do the 'strip_tags' internally. The usage ofstrip_tags()in the
example is now needed, but it looks, well, kinda strange that it is
needed.regards,
Derick--
--
This message represents the official view of the voices in my head
Hi,
Perhaps the real answer here is to turn on input filtering by default
so
we defeat XSS once and for all across the board.
seems like nobody is interested. I'd like to see some sort
of discussion on this. How would an actual implementation
would or should look like in PHP 5? What are the benefits
(obvious, but still), what are the drawbacks (partly obvious,
but still)? Is it PHP's role to provide this kind of
XSS prevention built-in or is it sufficient to give the
possibility to add it by hand (like now)? What is
internals' opinion on this?
Best regards,
Jan
Perhaps the real answer here is to turn on input filtering by default
so
we defeat XSS once and for all across the board.seems like nobody is interested. I'd like to see some sort
of discussion on this. How would an actual implementation
would or should look like in PHP 5? What are the benefits
(obvious, but still), what are the drawbacks (partly obvious,
but still)? Is it PHP's role to provide this kind of
XSS prevention built-in or is it sufficient to give the
possibility to add it by hand (like now)? What is
internals' opinion on this?
I don't think there is any question that PHP should play a role in helping
people solve XSS which is why I added it to PHP5. However, as it is, the
average person is not going to use it since it requires implementing the
security policy in C.
Implementation-wise we could go all out and break everything. Add a
striptags-like filter to be applied to all remote input data and have an
access function that lets you get the raw data. So something like:
input data POST data foo : Hi <b>jan@php.net</b>
what you see in $_POST['foo'] : Hi jan@php.net
get_raw_data(POST, 'foo') : Hi <b>jan@php.net</b>
get_raw_data(POST, 'foo', MAIL_FILTER): jan@php.net
with various other filters possible along with user-supplied ones.
-Rasmus