| 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:
|
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.)
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]