lynx-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: LYNX-DEV WebStar Server with DynaMorph problems


From: Julie Rutherford
Subject: Re: LYNX-DEV WebStar Server with DynaMorph problems
Date: Mon, 3 Nov 97 09:35:08 -0500

Klaus--

thanks for investigating this issue. I'm passing this along to my 
programmer and will get back to you with any results.

Best Regards,

Julie Rutherford
BloodLine Editor


>On Sat, 1 Nov 1997, Doug Kaufman wrote:
>
>> I have found a site that I would like to access with lynx, but can't get a
>> display of the pages.  I was hoping that someone was familiar with this
>> problem and can give me a hint on how to do it.  The site uses a WebSTAR
>> server with DynaMorph enabled.  On Netscape the display looks like a frame
>> display, but with no line between the frames.  Using a DOS version of lynx
>> (ac-0.87, compiled with PDCurses 2.3) or a Unix version (SUNOS 4.1.3_U1,
>> compiled with SLANG, Fotemods from September 5, 1997), I only get a blank
>> screen when going to the pages indicated by any of the links in the
>> style "query.morph?nameofpage".  Following is a "Print" of the side
>> frame having the links to the pages that I was trying to reach, followed
>> by a trace from the DOS version.  (If anyone wants to try this site, you
>> will have to register.  They don't seem to send out UCE, however.) I
>> sent this with the long lines unmodified; I hope they get through any
>> intermediate sites in readable condition.
>> 
>> The "TrackID" changes with each visit to the site.
>> 
>> 
>>                                   SIDE_NAVmap
>>                                        
>> MAP: 
>http://www.cjp.com/blood/html/sidemenu.morph?ForceTrackID=tid10286#SIDE_NA
>> Vmap
>> 
>>      * [1]http://www.cjp.com/blood/logout.morph?TrackID=tid10286
>>      * [2]http://www.cjp.com/blood/query.morph?nameofpage=watch1.morph&Fo
>>        rceTrackID=tid10286
>>      * [3]http://www.cjp.com/blood/query.morph?nameofpage=journal1.morph&;
>>        ForceTrackID=tid10286
>>      * [4]http://www.cjp.com/blood/query.morph?nameofpage=reviews1.morph&;
>>        ForceTrackID=tid10286
>[ etc. ]
>
>Those links, which Lynx creates from a MAP element's content, are
>supposed to return a 302 redirection to the "real" location when
>activated.  Experimentation shows that they don't do that, but just
>return an empty 200 response, if the request does not include a
>Referer header filed with (at least) the string
>morph?ForceTrackID=tid<NNNNN>.
>
>Previous versions of Lynx would send
>
>Referer: 
>LYNXIMGMAP:http://www.cjp.com/blood/html/sidemenu.morph?ForceTrackID=tid10
>286#SIDE_NAVmap
>
>in this situation.  That isn't really an official and valid URL, but
>what Lynx uses internally to identify the resource it generates
>internally for the HREFs from a MAP.  It happens that it contains the
>string the server is looking for, so the server would send the 302
>redirection and things would work.
>
>This is why later versions of the Lynx development code (and 2.7.1f)
>act differently now:
>
>1997-07-02
>  ...
>* Mods in LYGetFile.c to include URLs with content from a form submission
>  with method GET in the group for which Referer headers are never sent,
>  because the content might include private (e.g., password or credit
>  card) information which should not be visible in Referer logs. - FM
>
>So it appears we have a conflict of interest here, since I FM's concern
>is a valid one.
>
>Anyway, the code doing this additional check is
>
>                    if ((LYNoRefererHeader == FALSE &&
>                         LYNoRefererForThis == FALSE) &&
>                        (url_type == HTTP_URL_TYPE ||
>                         url_type == HTTPS_URL_TYPE) &&
>                        (cp = strchr(HTLoadedDocumentURL(), '?')) != NULL &&
>                        strchr(cp, '=') != NULL) {
>                        /*
>                         *  Don't send a Referer header if the URL is
>                         *  the reply from a form with method GET, in
>                         *  case the content has personal data (e.g.,
>                         *  a password or credit card number) which
>                         *  would become visible in logs. - FM
>                         */
>                        LYNoRefererForThis = TRUE;
>                    }
>
>You may want to disable this and see whether this really solves the
>immediate problem.
>
>I question whether the server's behavior is a good idea, since the
>content of the Referer header line is something that can be faked
>easily (as I did for testing), so this doesn't afford any protection.
>In fact the tracking system can be easily fooled; the tracking IDs are
>assigned sequentially, so it is simple to guess a valid one that has
>been assigned to someone else and then use that for requests that
>would be tracked as being part of the other user's session.  Some of
>the pages also use HTTP cookies, my remark may not apply to those.
>But, if the service has to be session-based, then why not used HTTP
>cookies exclusively, which exist explicitly for this purpose.
>
>
>
>    Klaus
>
;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;

reply via email to

[Prev in Thread] Current Thread [Next in Thread]