| $referrer = $_SERVER['HTTP_REFERER'] echo [message #181951] |
Thu, 27 June 2013 21:23  |
bill
Messages: 310
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
I have what's probably a simple and very basic question.
My goal is to see where a visitor sending a form-email with mail() on
win 7 and XAMPP - PHP 5.3.5, came from. e.g. did he come here from the
right page or just barge into this page as his landing page?
My php.ini seems to be OK and I've not changed any other config
files. All other "If's" work OK and I'm now baffled.
This works fine:
-------------------
$referrer = $_SERVER['HTTP_REFERER'];
echo "<br /><br /> Visitor came here from : ". substr($referrer, -13,
13)."<br />";
------------------
But this will not work:
------------------------------
if(substr($referrer, -13, 13))==="formcheck.php") {echo "Something
showed up";
}
-----------------------------
It results in the following error:
------------
Parse error: syntax error, unexpected T_IS_IDENTICAL in
C:\xampp\htdocs\formcheck2.php on line 36
------------
when when run on my local XAMPP Server.
I have tried everything I can think of to get it to work: Interchaning
the vars on each side of "===", using "==", moved the closing parens
around, with and without curly brackets, etc. etc. etc. I've got myself
so confused now I feel really stuck.
Can anyone straighten me out?
TIA,
Twayne
|
|
|
|
| RESOLVED Re: $referrer = $_SERVER['HTTP_REFERER'] echo [message #181952 is a reply to message #181951] |
Thu, 27 June 2013 21:34  |
bill
Messages: 310
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
<sigh>, never mind. Makes a big difference when a dufus gets his head on
straight. Went back to basics and:
----------------------
if (substr($referrer, -13, 13)=="formcheck.php"){
echo "Came from correct page <br />";
}
else {
echo "came from WRONG PAGE!";
}
---------------------
works fine. Who said I was a dufus, huh? ;)
Twayne`
|
|
|
|
| Re: $referrer = $_SERVER['HTTP_REFERER'] echo [message #181953 is a reply to message #181951] |
Thu, 27 June 2013 21:40 |
Christoph Michael Bec
Messages: 207
Registered: June 2013
Karma: 0
|
Senior Member |
|
|
Twayne wrote:
> I have what's probably a simple and very basic question.
>
> My goal is to see where a visitor sending a form-email with mail() on
> win 7 and XAMPP - PHP 5.3.5, came from. e.g. did he come here from the
> right page or just barge into this page as his landing page?
You should be aware that it is possible that a UA doesn't sent a
referrer header.
> My php.ini seems to be OK and I've not changed any other config files.
> All other "If's" work OK and I'm now baffled.
>
> This works fine:
> -------------------
> $referrer = $_SERVER['HTTP_REFERER'];
> echo "<br /><br /> Visitor came here from : ". substr($referrer, -13,
> 13)."<br />";
> ------------------
>
> But this will not work:
> ------------------------------
> if(substr($referrer, -13, 13))==="formcheck.php") {echo "Something
> showed up";
> }
> -----------------------------
The double )) is wrong; just use a single ). You may consider to use
only simple expressions for an if expression, e.g.:
$cameFromExpectedPage = substr($referrer, -13) === 'formcheck.php';
if ($cameFromExpectedPage) {
echo 'Something showed up';
}
--
Christoph M. Becker
|
|
|
|
| Re: $referrer = $_SERVER['HTTP_REFERER'] echo [message #181954 is a reply to message #181951] |
Thu, 27 June 2013 21:52 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 6/27/2013 5:23 PM, Twayne wrote:
> I have what's probably a simple and very basic question.
>
> My goal is to see where a visitor sending a form-email with mail() on
> win 7 and XAMPP - PHP 5.3.5, came from. e.g. did he come here from the
> right page or just barge into this page as his landing page?
> My php.ini seems to be OK and I've not changed any other config
> files. All other "If's" work OK and I'm now baffled.
>
> This works fine:
> -------------------
> $referrer = $_SERVER['HTTP_REFERER'];
> echo "<br /><br /> Visitor came here from : ". substr($referrer, -13,
> 13)."<br />";
> ------------------
>
> But this will not work:
> ------------------------------
> if(substr($referrer, -13, 13))==="formcheck.php") {echo "Something
> showed up";
> }
> -----------------------------
>
> It results in the following error:
> ------------
> Parse error: syntax error, unexpected T_IS_IDENTICAL in
> C:\xampp\htdocs\formcheck2.php on line 36
> ------------
> when when run on my local XAMPP Server.
>
> I have tried everything I can think of to get it to work: Interchaning
> the vars on each side of "===", using "==", moved the closing parens
> around, with and without curly brackets, etc. etc. etc. I've got myself
> so confused now I feel really stuck.
>
> Can anyone straighten me out?
>
> TIA,
>
> Twayne
>
Like anything else sent by the client, you can't trust
$_SERVER['HTTP_REFERER']. It may or may not exist, and if it does, it
may or may not contain the actual referrer page.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: $referrer = $_SERVER['HTTP_REFERER'] echo [message #181955 is a reply to message #181953] |
Thu, 27 June 2013 22:19 |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
Christoph Michael Becker wrote:
> […] You may consider to use only simple expressions for an if expression,
> e.g.:
>
> $cameFromExpectedPage = substr($referrer, -13) === 'formcheck.php';
> if ($cameFromExpectedPage) {
> echo 'Something showed up';
> }
Good idea, but I would write
$cameFromExpectedPage = (substr($referrer, -13) === 'formcheck.php');
for even greater clarity.
Also, I would let match RFC 3986, Appendix B, against a URI. What if there
is a query part, for example?
But I would never check against the HTTP-Referer [sic!] in the first place.
There are much more reliable solutions, like session variables. See also
<https://owasp.org/>.
PointedEars
--
Sometimes, what you learn is wrong. If those wrong ideas are close to the
root of the knowledge tree you build on a particular subject, pruning the
bad branches can sometimes cause the whole tree to collapse.
-- Mike Duffy in cljs, <news:Xns9FB6521286DB8invalidcom(at)94(dot)75(dot)214(dot)39>
|
|
|
|
| Re: $referrer = $_SERVER['HTTP_REFERER'] echo [message #181956 is a reply to message #181955] |
Fri, 28 June 2013 00:16 |
Christoph Michael Bec
Messages: 207
Registered: June 2013
Karma: 0
|
Senior Member |
|
|
Thomas 'PointedEars' Lahn wrote:
> Christoph Michael Becker wrote:
>
>> […] You may consider to use only simple expressions for an if expression,
>> e.g.:
>>
>> $cameFromExpectedPage = substr($referrer, -13) === 'formcheck.php';
>> if ($cameFromExpectedPage) {
>> echo 'Something showed up';
>> }
>
> Good idea, but I would write
>
> $cameFromExpectedPage = (substr($referrer, -13) === 'formcheck.php');
>
> for even greater clarity.
ACK.
> Also, I would let match RFC 3986, Appendix B, against a URI. What if there
> is a query part, for example?
Good point! However, only recently there was a bug report regarding
PHP's filter_var($var, FILTER_VALIDATE_URL)[1]. This is meant to be
implemented according to RFC 2396; obviously RFC 2396 is obsoleted by
RFC 3986 (I was not aware of that until now--thank you). Anyway, it
seems the regular expression given in Appendix B of RFC 2396 *seems* to
be more permissive than the actual syntax given in Appendix A. I have
not checked RFC 3986 regarding this issue yet.
> But I would never check against the HTTP-Referer [sic!] in the first place.
> There are much more reliable solutions, like session variables. See also
> <https://owasp.org/>.
ACK. OTOH I have some concerns regarding cookies (I do not "like" to
propagate session IDs as a GET parameter) due to the European cookie law(s).
[1] <https://bugs.php.net/bug.php?id=65141>
--
Christoph M. Becker
|
|
|
|
| Re: $referrer = $_SERVER['HTTP_REFERER'] echo [message #181958 is a reply to message #181956] |
Fri, 28 June 2013 08:56 |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
Christoph Michael Becker wrote:
> Thomas 'PointedEars' Lahn wrote:
>> Also, I would let match RFC 3986, Appendix B, against a URI. What if
>> there is a query part, for example?
>
> Good point! However, only recently there was a bug report regarding
> PHP's filter_var($var, FILTER_VALIDATE_URL)[1].
I have not suggested using filter_var().
> This is meant to be implemented according to RFC 2396; obviously RFC 2396
> is obsoleted by RFC 3986
Since 8 years now.
> (I was not aware of that until now--thank you).
You're welcome.
> Anyway, it seems the regular expression given in Appendix B of RFC 2396
> *seems* to be more permissive than the actual syntax given in Appendix A.
Appendixes are not normative. Assuming relevance, in which way does it seem
more permissive?
> I have not checked RFC 3986 regarding this issue yet.
>
>> But I would never check against the HTTP-Referer [sic!] in the first
>> place. There are much more reliable solutions, like session variables.
>> See also <https://owasp.org/>.
>
> ACK. OTOH I have some concerns regarding cookies (I do not "like" to
> propagate session IDs as a GET parameter) due to the European cookie
> law(s).
Directive 95/46/EC does not apply here.
> [1] <https://bugs.php.net/bug.php?id=65141>
PointedEars, IANAL
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300dec7(at)news(dot)demon(dot)co(dot)uk>
|
|
|
|
| Re: $referrer = $_SERVER['HTTP_REFERER'] echo [message #181965 is a reply to message #181953] |
Fri, 28 June 2013 17:33 |
bill
Messages: 310
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
On 2013-06-27 5:40 PM, Christoph Michael Becker wrote:
> Twayne wrote:
>> I have what's probably a simple and very basic question.
>>
>> My goal is to see where a visitor sending a form-email with mail() on
>> win 7 and XAMPP - PHP 5.3.5, came from. e.g. did he come here from the
>> right page or just barge into this page as his landing page?
>
....
> The double )) is wrong; just use a single ). You may consider to use
> only simple expressions for an if expression, e.g.:
>
> $cameFromExpectedPage = substr($referrer, -13) === 'formcheck.php';
> if ($cameFromExpectedPage) {
> echo 'Something showed up';
> }
>
Duh! That helped; thank you!
Twayne`
|
|
|
|
| Re: $referrer = $_SERVER['HTTP_REFERER'] echo [message #181966 is a reply to message #181955] |
Fri, 28 June 2013 17:49 |
bill
Messages: 310
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
On 2013-06-27 6:19 PM, Thomas 'PointedEars' Lahn wrote:
> Christoph Michael Becker wrote:
>
....
> for even greater clarity.
>
> Also, I would let match RFC 3986, Appendix B, against a URI. What if there
> is a query part, for example?
I haven't read the RFC yet, only glanced at it, but it looks like the
kind of thing I can use. Thanks!
Question: by "query", are you referring to using a database?
Otherwise I'm not sure what you meant, now what the problem may be.
>
> But I would never check against the HTTP-Referer [sic!] in the first place.
Why is that? If an attempted entry is made from other than the forms
paths, it'll show up on my own screen quickly. Is it easy to spoof or what?
> There are much more reliable solutions, like session variables. See also
> <https://owasp.org/>.
I am also using Session variables and unsetting them as soon as I'm done
with them and destroying the session at first opportunity after it's no
longer needed. But I'm not sure I see why that's better than checking
the referrer?
owasp.org btw looks like a keeper! I've bookmarked it and intend to
spend some time there. THANKS AGAIN!
Regards,
Twayne`
>
>
> PointedEars
>
|
|
|
|
| Re: $referrer = $_SERVER['HTTP_REFERER'] echo [message #181967 is a reply to message #181958] |
Fri, 28 June 2013 18:03 |
Christoph Michael Bec
Messages: 207
Registered: June 2013
Karma: 0
|
Senior Member |
|
|
Thomas 'PointedEars' Lahn wrote:
> Christoph Michael Becker wrote:
>> Thomas 'PointedEars' Lahn wrote:
>> Anyway, it seems the regular expression given in Appendix B of RFC 2396
>> *seems* to be more permissive than the actual syntax given in Appendix A.
>
> Appendixes are not normative. Assuming relevance, in which way does it seem
> more permissive?
The following example passes the regular expression in Appendix B of RFC
2396, but it is not allowed according to Appendix A (if I'm not mistaken):
http://http://example.com
>> I have not checked RFC 3986 regarding this issue yet.
>>
>>> But I would never check against the HTTP-Referer [sic!] in the first
>>> place. There are much more reliable solutions, like session variables.
>>> See also <https://owasp.org/>.
>>
>> ACK. OTOH I have some concerns regarding cookies (I do not "like" to
>> propagate session IDs as a GET parameter) due to the European cookie
>> law(s).
>
> Directive 95/46/EC does not apply here.
I was referring to directive 2009/136/EC, which *might* apply.
--
Christoph M. Becker
|
|
|
|
| Re: $referrer = $_SERVER['HTTP_REFERER'] echo [message #181968 is a reply to message #181954] |
Fri, 28 June 2013 18:07 |
bill
Messages: 310
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
On 2013-06-27 5:52 PM, Jerry Stuckle wrote:
> On 6/27/2013 5:23 PM, Twayne wrote:
>> I have what's probably a simple and very basic question.
>>
>> My goal is to see where a visitor sending a form-email with mail() on
>> win 7 and XAMPP - PHP 5.3.5, came from. e.g. did he come here from the
>> right page or just barge into this page as his landing page?
>> My php.ini seems to be OK and I've not changed any other config
>> files. All other "If's" work OK and I'm now baffled.
....
>
> Like anything else sent by the client, you can't trust
> $_SERVER['HTTP_REFERER']. It may or may not exist, and if it does, it
> may or may not contain the actual referrer page.
Perhaps you can expand on that? Referrer does exist, and it's sent to me
by my server. If it doesn't indicate MY previous form page, then I know
the visito and it reflects ONLY my own files to be accepted, or hasn't
used the website link to access that particular page, or has tried some
sort of direct access, Back Button, etc.; and I destroy the session and
stop the script.
TIA for enlightening me.
Twayne`
|
|
|
|
| Re: $referrer = $_SERVER['HTTP_REFERER'] echo [message #181969 is a reply to message #181966] |
Fri, 28 June 2013 18:13 |
Christoph Michael Bec
Messages: 207
Registered: June 2013
Karma: 0
|
Senior Member |
|
|
Twayne wrote:
> On 2013-06-27 6:19 PM, Thomas 'PointedEars' Lahn wrote:
>> Christoph Michael Becker wrote:
>>
>> Also, I would let match RFC 3986, Appendix B, against a URI. What if
>> there
>> is a query part, for example?
>
> I haven't read the RFC yet, only glanced at it, but it looks like the
> kind of thing I can use. Thanks!
> Question: by "query", are you referring to using a database?
> Otherwise I'm not sure what you meant, now what the problem may be.
Thomas is referring to a potential query part of the refer(r)er URI
(casually spoken: everything between ? and #). If a query part is
contained in the refer(r)er URI, the last 13 characters won't be the
expected filename.
>> But I would never check against the HTTP-Referer [sic!] in the first
>> place.
>
> Why is that? If an attempted entry is made from other than the forms
> paths, it'll show up on my own screen quickly. Is it easy to spoof or what?
It is very easy to spoof the refer(r)er header[1]--as any other user
supplied input to a website.
[1] <http://en.wikipedia.org/wiki/Referer_spoofing>
--
Christoph M. Becker
|
|
|
|
| Re: $referrer = $_SERVER['HTTP_REFERER'] echo [message #181971 is a reply to message #181968] |
Fri, 28 June 2013 19:26 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 6/28/2013 2:07 PM, Twayne wrote:
> On 2013-06-27 5:52 PM, Jerry Stuckle wrote:
>> On 6/27/2013 5:23 PM, Twayne wrote:
>>> I have what's probably a simple and very basic question.
>>>
>>> My goal is to see where a visitor sending a form-email with mail() on
>>> win 7 and XAMPP - PHP 5.3.5, came from. e.g. did he come here from the
>>> right page or just barge into this page as his landing page?
>>> My php.ini seems to be OK and I've not changed any other config
>>> files. All other "If's" work OK and I'm now baffled.
>
> ...
>
>>
>> Like anything else sent by the client, you can't trust
>> $_SERVER['HTTP_REFERER']. It may or may not exist, and if it does, it
>> may or may not contain the actual referrer page.
>
> Perhaps you can expand on that? Referrer does exist, and it's sent to me
> by my server. If it doesn't indicate MY previous form page, then I know
> the visito and it reflects ONLY my own files to be accepted, or hasn't
> used the website link to access that particular page, or has tried some
> sort of direct access, Back Button, etc.; and I destroy the session and
> stop the script.
>
> TIA for enlightening me.
>
> Twayne`
>
>
>
>
It is supplied by the user, and like anything user-supplied, can easily
be spoofed. And some people don't even send it (I've heard Norton has
an option to strip it, but haven't confirmed that fact).
Just because it exists and is correct on your system does NOT mean it
exists or is correct when coming from other systems!
The bottom line is - it is user-supplied data, and you should NEVER
trust user-supplied data.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: $referrer = $_SERVER['HTTP_REFERER'] echo [message #181973 is a reply to message #181967] |
Fri, 28 June 2013 19:49 |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
Christoph Michael Becker wrote:
> Thomas 'PointedEars' Lahn wrote:
>> Christoph Michael Becker wrote:
>>> Thomas 'PointedEars' Lahn wrote:
>>> Anyway, it seems the regular expression given in Appendix B of RFC 2396
>>> *seems* to be more permissive than the actual syntax given in Appendix
>>> A.
>> Appendixes are not normative. Assuming relevance, in which way does it
>> seem more permissive?
>
> The following example passes the regular expression in Appendix B of RFC
> 2396, but it is not allowed according to Appendix A (if I'm not mistaken):
>
> http://http://example.com
You are mistaken. The relevant productions are:
URI-reference = [ absoluteURI | relativeURI ] [ "#" fragment ]
absoluteURI = scheme ":" ( hier_part | opaque_part )
scheme = alpha *( alpha | digit | "+" | "-" | "." )
hier_part = ( net_path | abs_path ) [ "?" query ]
abs_path = "/" path_segments
path_segments = segment *( "/" segment )
segment = *pchar *( ";" param )
pchar = unreserved | escaped |
":" | "@" | "&" | "=" | "+" | "$" | ","
unreserved = alphanum | mark
mark = "-" | "_" | "." | "!" | "~" | "*" | "'" |
"(" | ")"
alphanum = alpha | digit
alpha = lowalpha | upalpha
lowalpha = "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | "i" |
"j" | "k" | "l" | "m" | "n" | "o" | "p" | "q" | "r" |
"s" | "t" | "u" | "v" | "w" | "x" | "y" | "z"
Applied:
URI-reference
=> [ absoluteURI | relativeURI ] [ "#" fragment ]
=> absoluteURI
=> scheme ":" ( hier_part | opaque_part )
=> scheme ":" hier_part
=> scheme ":" ( net_path | abs_path ) [ "?" query ]
=> scheme ":" abs_path
=> scheme ":" "/" path_segments
=> scheme ":" "/" segment *( "/" segment )
=> scheme ":" "/" segment "/" segment "/" segment "/" segment
=> scheme ":" "/" *pchar *( ";" param ) "/" *pchar *( ";" param ) "/"
*pchar *( ";" param ) "/" *pchar *( ";" param )
=> scheme ":" "/" *pchar "/" *pchar "/" *pchar "/" *pchar
=> scheme ":" "/" "" "/" pchar pchar pchar pchar pchar "/" "" "/" pchar
pchar pchar pchar pchar pchar pchar pchar pchar pchar pchar
=> scheme ":" "/" "" "/" unreserved unreserved unreserved unreserved ":"
"/" "" "/" unreserved unreserved unreserved unreserved unreserved unreserved
unreserved unreserved unreserved unreserved unreserved
=> scheme ":" "/" "" "/" alphanum alphanum alphanum alphanum ":" "/" ""
"/" alphanum alphanum alphanum alphanum alphanum alphanum alphanum mark
alphanum alphanum alphanum
=> scheme ":" "/" "" "/" alpha alpha alpha alpha ":" "/" "" "/" alpha
alpha alpha alpha alpha alpha alpha mark alpha alpha alpha
=> scheme ":" "/" "" "/" lowalpha lowalpha lowalpha lowalpha ":" "/" ""
"/" lowalpha lowalpha lowalpha lowalpha lowalpha lowalpha lowalpha mark
lowalpha lowalpha lowalpha
=> scheme ":" "/" "" "/" "h" "t" "t" "p" ":" "/" "" "/" "e" "x" "a" "m"
"p" "l" "e" "." "c" "o" "m"
=> alpha *( alpha | digit | "+" | "-" | "." ) ":" "/" "" "/" "h" "t" "t"
"p" ":" "/" "" "/" "e" "x" "a" "m" "p" "l" "e" "." "c" "o" "m"
=> alpha alpha alpha alpha ":" "/" "" "/" "h" "t" "t" "p" ":" "/" "" "/"
"e" "x" "a" "m" "p" "l" "e" "." "c" "o" "m"
=> lowalpha lowalpha lowalpha lowalpha ":" "/" "" "/" "h" "t" "t" "p" ":"
"/" "e" "x" "a" "m" "p" "l" "e" "." "c" "o" "m"
=> "h" "t" "t" "p" ":" "/" "" "/" "h" "t" "t" "p" ":" "/" "" "/" "e" "x"
"a" "m" "p" "l" "e" "." "c" "o" "m"
=> "http://http:/example.com"
[Some day I'll write an automatic grammar resolver. And I should let prove
other people their unfounded statements instead of going to lengths
disproving them.]
These productions were probably not intended. But note that the section is
titled “*Parsing* a URI Reference with a Regular Expression”, _not_
“*Validating* a URI Reference”, and that URI References also include things
like “javascript:window.alert("42");”.
>>> I have not checked RFC 3986 regarding this issue yet.
>>>
>>>> But I would never check against the HTTP-Referer [sic!] in the first
>>>> place. There are much more reliable solutions, like session variables.
>>>> See also <https://owasp.org/>.
>>>
>>> ACK. OTOH I have some concerns regarding cookies (I do not "like" to
>>> propagate session IDs as a GET parameter) due to the European cookie
>>> law(s).
>>
>> Directive 95/46/EC does not apply here.
>
> I was referring to directive 2009/136/EC, which *might* apply.
How?
PointedEars
--
Use any version of Microsoft Frontpage to create your site.
(This won't prevent people from viewing your source, but no one
will want to steal it.)
-- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)
|
|
|
|
| Re: $referrer = $_SERVER['HTTP_REFERER'] echo [message #181975 is a reply to message #181971] |
Fri, 28 June 2013 20:03 |
bill
Messages: 310
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
On 2013-06-28 3:26 PM, Jerry Stuckle wrote:
> On 6/28/2013 2:07 PM, Twayne wrote:
>> On 2013-06-27 5:52 PM, Jerry Stuckle wrote:
>>> On 6/27/2013 5:23 PM, Twayne wrote:
>>>> I have what's probably a simple and very basic question.
>>>>
>>>> My goal is to see where a visitor sending a form-email with mail() on
>>>> win 7 and XAMPP - PHP 5.3.5, came from. e.g. did he come here from the
>>>> right page or just barge into this page as his landing page?
>>>> My php.ini seems to be OK and I've not changed any other config
>>>> files. All other "If's" work OK and I'm now baffled.
>>
>> ...
>>
>>>
....
>>
>
> It is supplied by the user, and like anything user-supplied, can easily
> be spoofed. And some people don't even send it (I've heard Norton has
> an option to strip it, but haven't confirmed that fact).
No, it is NOT supplied by the user in this case. It is supplied by the
server of my website, and the only information I'm interested in is
whether the visitor came from the proper page on my website; nothing
else shall pass. You've said nothing to change my mind, but thanks anyway.
>
> Just because it exists and is correct on your system does NOT mean it
> exists or is correct when coming from other systems!
I have zero interest in "other systems", as I described previously.
On my server, not my "system". It's entirely server-side operations.
Others are reporting my scheme as a "good one" when considering
everything the forest contains; possibly even more than really needed.
>
> The bottom line is - it is user-supplied data, and you should NEVER
> trust user-supplied data.
like I said, it's not user-supplied.
The user knows nothing about it without some pretty clever attention to
the problem and hacking the server I use (NOT mine-standard, reputable
servers).
Thanks for the response, even if it was rather lacking in any detail
that I found useful.
Twayne`
>
|
|
|
|
| Re: $referrer = $_SERVER['HTTP_REFERER'] echo [message #181976 is a reply to message #181975] |
Fri, 28 June 2013 20:07 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 6/28/2013 4:03 PM, Twayne wrote:
> On 2013-06-28 3:26 PM, Jerry Stuckle wrote:
>> On 6/28/2013 2:07 PM, Twayne wrote:
>>> On 2013-06-27 5:52 PM, Jerry Stuckle wrote:
>>>> On 6/27/2013 5:23 PM, Twayne wrote:
>>>> > I have what's probably a simple and very basic question.
>>>> >
>>>> > My goal is to see where a visitor sending a form-email with mail() on
>>>> > win 7 and XAMPP - PHP 5.3.5, came from. e.g. did he come here from the
>>>> > right page or just barge into this page as his landing page?
>>>> > My php.ini seems to be OK and I've not changed any other config
>>>> > files. All other "If's" work OK and I'm now baffled.
>>>
>>> ...
>>>
>>>>
>
> ...
>
>>>
>>
>> It is supplied by the user, and like anything user-supplied, can easily
>> be spoofed. And some people don't even send it (I've heard Norton has
>> an option to strip it, but haven't confirmed that fact).
>
> No, it is NOT supplied by the user in this case. It is supplied by the
> server of my website, and the only information I'm interested in is
> whether the visitor came from the proper page on my website; nothing
> else shall pass. You've said nothing to change my mind, but thanks anyway.
Check again. HTTP_REFERER is supplied by the CLIENT. The server has no
idea where the page was called from.
>>
>> Just because it exists and is correct on your system does NOT mean it
>> exists or is correct when coming from other systems!
>
> I have zero interest in "other systems", as I described previously.
>
You should. It's your clients who are using those other systems!
> On my server, not my "system". It's entirely server-side operations.
> Others are reporting my scheme as a "good one" when considering
> everything the forest contains; possibly even more than really needed.
>>
>> The bottom line is - it is user-supplied data, and you should NEVER
>> trust user-supplied data.
>
> like I said, it's not user-supplied.
>
Try again. The server has no idea what page the client was on when he
clicked on a link (or whatever).
> The user knows nothing about it without some pretty clever attention to
> the problem and hacking the server I use (NOT mine-standard, reputable
> servers).
>
The client knows EVERYTHING about it. It supplies the value.
> Thanks for the response, even if it was rather lacking in any detail
> that I found useful.
>
> Twayne`
>
>>
>
Then I would suggest you get some more education. Try running the HTTP
Headers extension under Firefox - you will find the value being sent by
the browser.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: $referrer = $_SERVER['HTTP_REFERER'] echo [message #181977 is a reply to message #181973] |
Fri, 28 June 2013 20:37 |
Christoph Michael Bec
Messages: 207
Registered: June 2013
Karma: 0
|
Senior Member |
|
|
Thomas 'PointedEars' Lahn:
> Christoph Michael Becker wrote:
>
>> Thomas 'PointedEars' Lahn wrote:
>>> Christoph Michael Becker wrote:
>>>> Thomas 'PointedEars' Lahn wrote:
>>>> Anyway, it seems the regular expression given in Appendix B of RFC 2396
>>>> *seems* to be more permissive than the actual syntax given in Appendix
>>>> A.
>>> Appendixes are not normative. Assuming relevance, in which way does it
>>> seem more permissive?
>>
>> The following example passes the regular expression in Appendix B of RFC
>> 2396, but it is not allowed according to Appendix A (if I'm not mistaken):
>>
>> http://http://example.com
>
> You are mistaken.
>
> <snipped proof>
Thank you very much for proofing me wrong. :) (I had not though about
the fact that a segment may be empty.)
> [Some day I'll write an automatic grammar resolver. And I should let prove
> other people their unfounded statements instead of going to lengths
> disproving them.]
My apologies for having bothered you. Actually I had thought about
writing a parser to check it myself, but I have only some experience
with Coco/R[1] which only processes LL(1) grammars. Lex/Yacc would have
been more useful in this case.
> These productions were probably not intended. But note that the section is
> titled “*Parsing* a URI Reference with a Regular Expression”, _not_
> “*Validating* a URI Reference”, and that URI References also include things
> like “javascript:window.alert("42");”.
>
>>>> I have not checked RFC 3986 regarding this issue yet.
>>>>
>>>> > But I would never check against the HTTP-Referer [sic!] in the first
>>>> > place. There are much more reliable solutions, like session variables.
>>>> > See also <https://owasp.org/>.
>>>>
>>>> ACK. OTOH I have some concerns regarding cookies (I do not "like" to
>>>> propagate session IDs as a GET parameter) due to the European cookie
>>>> law(s).
>>>
>>> Directive 95/46/EC does not apply here.
>>
>> I was referring to directive 2009/136/EC, which *might* apply.
>
> How?
Article 2 of the directive[2] §5 states:
| Article 5(3) shall be replaced by the following:
|
| ‘3. Member States shall ensure that the storing of information, or
| the gaining of access to information already stored, in the terminal
| equipment of a subscriber or user is only allowed on condition that
| the subscriber or user concerned has given his or her consent, having
| been provided with clear and comprehensive information, in accordance
| with Directive 95/46/EC, inter alia, about the purposes of the
| processing. This shall not prevent any technical storage or access
| for the sole purpose of carrying out the transmission of a
| communication over an electronic communications net work, or as
| strictly necessary in order for the provider of an information
| society service explicitly requested by the sub scriber or user to
| provide the service.’;
I assume that this concerns all kinds of HTTP cookies. In the given
case the cookie is probably not covered by the second sentence.
However, IANAL.
[1] <http://www.ssw.uni-linz.ac.at/coco/>
[2]
< http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2009:337:0011:00 36:en:PDF>
--
Christoph M. Becker
|
|
|
|
| Re: $referrer = $_SERVER['HTTP_REFERER'] echo [message #181979 is a reply to message #181976] |
Fri, 28 June 2013 20:46 |
Christoph Michael Bec
Messages: 207
Registered: June 2013
Karma: 0
|
Senior Member |
|
|
Jerry Stuckle wrote:
> On 6/28/2013 4:03 PM, Twayne wrote:
>> On 2013-06-28 3:26 PM, Jerry Stuckle wrote:
>>> It is supplied by the user, and like anything user-supplied, can easily
>>> be spoofed. And some people don't even send it (I've heard Norton has
>>> an option to strip it, but haven't confirmed that fact).
>>
>> No, it is NOT supplied by the user in this case. It is supplied by the
>> server of my website, and the only information I'm interested in is
>> whether the visitor came from the proper page on my website; nothing
>> else shall pass. You've said nothing to change my mind, but thanks
>> anyway.
>
> Check again. HTTP_REFERER is supplied by the CLIENT. The server has no
> idea where the page was called from.
ACK. See RFC 2616 section 14.36.[1]
>> Thanks for the response, even if it was rather lacking in any detail
>> that I found useful.
>
> Then I would suggest you get some more education. Try running the HTTP
> Headers extension under Firefox - you will find the value being sent by
> the browser.
If sending the refer(r)er header has not been disabled.[2]
[1] <http://www.ietf.org/rfc/rfc2616.txt>
[2] <http://www.technipages.com/firefox-enable-disable-referrer.html>
--
Christoph M. Becker
|
|
|
|
| Re: $referrer = $_SERVER['HTTP_REFERER'] echo [message #181985 is a reply to message #181977] |
Fri, 28 June 2013 21:55 |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
Christoph Michael Becker wrote:
> Thomas 'PointedEars' Lahn:
>> Christoph Michael Becker wrote:
>>> Thomas 'PointedEars' Lahn wrote:
>>>> Christoph Michael Becker wrote:
>>>> > Thomas 'PointedEars' Lahn wrote:
>>>> > Anyway, it seems the regular expression given in Appendix B of RFC
>>>> > 2396 *seems* to be more permissive than the actual syntax given in
>>>> > Appendix A.
>>>> Appendixes are not normative. Assuming relevance, in which way does it
>>>> seem more permissive?
>>>
>>> The following example passes the regular expression in Appendix B of RFC
>>> 2396, but it is not allowed according to Appendix A (if I'm not
>>> mistaken):
>>>
>>> http://http://example.com
>>
>> You are mistaken.
>>
>> <snipped proof>
>
> Thank you very much for proofing me wrong. :) (I had not though about
> the fact that a segment may be empty.)
The possibility occurred to me only after I went down the “net_path” path as
you probably did, which lead nowhere (in disproving you).
>> [Some day I'll write an automatic grammar resolver. And I should let
>> [prove other people their unfounded statements instead of going to
>> lengths disproving them.]
>
> My apologies for having bothered you.
You have not bothered me. It was an interesting problem to hack, after all.
It was *my* mistake: I should not invite “shifting the burden of proof”
fallacies by doing things like this (but I know you did not intend that).
> Actually I had thought about writing a parser to check it myself, but I
> have only some experience with Coco/R[1] which only processes LL(1)
> grammars. Lex/Yacc would have been more useful in this case.
I have played a bit with JFlex while studying CS. Perhaps this could be an
approach. Thanks.
>>>> > I have not checked RFC 3986 regarding this issue yet.
>>>> >
>>>> >> But I would never check against the HTTP-Referer [sic!] in the first
>>>> >> place. There are much more reliable solutions, like session
>>>> >> variables. See also <https://owasp.org/>.
>>>> > ACK. OTOH I have some concerns regarding cookies (I do not "like" to
>>>> > propagate session IDs as a GET parameter) due to the European cookie
>>>> > law(s).
>>>> Directive 95/46/EC does not apply here.
>>> I was referring to directive 2009/136/EC, which *might* apply.
>>
>> How?
(See? I did it :))
> Article 2 of the directive[2] §5 states:
>
> | Article 5(3) shall be replaced by the following:
> |
> | ‘3. Member States shall ensure that the storing of information, or
> | the gaining of access to information already stored, in the terminal
> | equipment of a subscriber or user is only allowed on condition that
> | the subscriber or user concerned has given his or her consent, having
> | been provided with clear and comprehensive information, in accordance
> | with Directive 95/46/EC, inter alia, about the purposes of the
^^^^^^^^^^^^^^^^^^
> | processing. This shall not prevent any technical storage or access
> | for the sole purpose of carrying out the transmission of a
> | communication over an electronic communications net work, or as
> | strictly necessary in order for the provider of an information
> | society service explicitly requested by the sub scriber or user to
> | provide the service.’;
>
> I assume that this concerns all kinds of HTTP cookies. In the given
> case the cookie is probably not covered by the second sentence.
I think the *session* cookie *is* covered there. It is stored and used only
for making sure that the user is still in the same session. Also, there is
this (unreferenced) statement:
,-<http://en.wikipedia.org/wiki/HTTP_cookie#EU_Cookie_Law>
|
| In June 2012, European data protection authorities adopted an opinion
| which clarifies that some cookie users might be exempt from the
| requirement to gain consent:
|
| - Some cookies can be exempted from informed consent under certain
| conditions if they are not used for additional purposes. These cookies
| include cookies used to keep track of a user’s input when filling online
| forms or as a shopping cart.
Subsequent paragraphs describe and reference the negative reaction to the
“cookie law”. I also remember to have seen at the time, as a negative
reaction, a series of ridiculous popups representing what would need to
happen if that Directive was taken seriously.
> However, IANAL.
>
> [1] <http://www.ssw.uni-linz.ac.at/coco/>
> [2]
> < http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=OJ:L:2009:337:0011:00 36:en:PDF>
IANAL either, and this discussion about layman interpretations of legalese
is probably leading nowhere except perhaps “reasonable doubt”.
However, AIUI Directive 95/46/EC *referred there* explicitly excludes
*session* cookies as it mandates:
< http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:31995L0046:en:H TML>
| Article 2
| Definitions
| For the purposes of this Directive:
| (a) 'personal data' shall mean any information relating to an identified
| or identifiable natural person ('data subject'); an identifiable person is
| one who can be identified, directly or indirectly, in particular by
| reference to an identification number or to one or more factors specific
| to his physical, physiological, mental, economic, cultural or social
| identity;
| […]
|
| Article 3
| Scope
| 1. This Directive shall apply to the processing of personal data wholly or
| partly by automatic means, and to the processing otherwise than by
| automatic means of personal data which form part of a filing system or are
| intended to form part of a filing system.
IMHO it excludes session cookies because they are not “information relating
to an identified or identifiable natural person”. At most you can identify
this way an HTTP client running on a computer that one individual *or more*
(say, a family household or office people) are using.
That said, an EU “directive is a legislative act of the European Union,[1]
which requires member states to achieve a particular result without
dictating the means of achieving that result.” (Wikipedia)
If you think about it: Is is likely that all those companies located in the
EU that use PHP sessions in their Web application are in violation of the
law? Why have they continued doing business and never ever anyone has sued
them?
I think I understand at least a bit of legalese; there is /de jure/ and /de
facto/. While /de jure/ it *might* be necessary to ask the user explicitly
before setting a session cookie, /de facto/ it is the user who defined in
their browser settings to accept session cookies or to be asked about them
and then confirms that they are set in order to use the application. That
also includes the session cookie set for the PHP session ID.
PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee
|
|
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]