On Sat, Aug 31, 2002 at 02:47:45PM -0400, Gianni Johansson wrote: > On Saturday 31 August 2002 12:46, Matthew wrote: > > > > On Sat, Aug 31, 2002 at 12:33:58AM -0400, Gianni Johansson wrote: > > > On Friday 30 August 2002 08:57, Matthew wrote: > > > > > On Thu, Aug 29, 2002 at 01:57:03PM +0100, Matthew Toseland wrote: > > > > > Hi. Newly implemented fproxy functionality allows you to fetch an old > > > > > edition of a DBR site, like this: > > > > > http://127.0.0.1:8888/SSK at > > > > > rBjVda8pC-Kq04jUurIAb8IzAGcPAgM/TFE//?date= > > > > >2002 0817 > > > > > > You don't need to change the anonymity filter. Just add support for a > > > date specifier in fproxy that doesn't use any illegal characters, similar > > > to to the external checked jump stuff. > > > > > > e.g. > > > http://127.0.0.1:8888/__USE_DATE_20020817__SSK at > > > rBjVda8pC-Kq04jUurIAb8IzAG > > >cPAgM/TFE// > > > > Ugh. The anonymity filter blocks all links, both outlinks and links > > within freenet, which have ? in them... > > > this is a problem for several sites > Why? Are there cases besides the one I outlined below? If we allowed escaped > ?, : and & in checked jumps would that make content authors happy or are > there other issues? Yes, there are a number of sites which have tried to link to external links with ?'s in them (eg news stories). > > As far as internal content goes, I don't think that allowing content authors > to pass arbitrary arguments to fproxy is a good idea, at least not without > warning first. Hmmm. Perhaps. We have ?htl (hmmm) ?force (useless, as mallory doesn't know the random number) ?date (useless to mallory) ?mime (useless, as fproxy will reconfirm or filter if the mime type is risky) ?key (useless to mallory)
As far as I can see, the ONLY thing we need to block is ?htl=<anything>. And that's unclear. However, we do need to block this on any server, as well as on relative links, because we do not know where the node is being run. But current behaviour is to block ? everywhere. Unless by using ? (and not colon, and not any forbidden tags), you can induce javascript? > > For example, I don't think that content authors should be able to override > the htl I set without fproxy asking me. > > Another issue would be preventing the case of a freesite making a link that > causes local files to be inserted into freenet without warning you... This can happen through a get request? Really? How? > > > Can it indicate javascript, or is this just to stop links within > > freenet from messing with the fproxy parameters? Can we safely allow ?'s > > in external links then? > > I think there was some issue with escape sequences that would allow you to > generate dangerous html but I can't remember. The debate on the filter went > on for months and months. I would be really careful about changing it unless > you are sure you know what you are doing. > > [ > Aside: Could someone (Ian? agl?) get the old mailing list archives back on > line so newer developpers have access to ancient freenet dev chronicles. > ] > > The only place I have seen ? (and also ":" ) cause problems is in legal > checked jumps. > > e.g. /__CHECKED_HTTP__hawk.freenetproject.org:8890/ > > Trips the anonyimity filter even though it's safe. Yes, and similar problems with ?'s. javascript: can cause evil code... but probably not when prefaced with http://... > > The easy conservative thing to do is to create legal escapes. > > So the above example would become: > > /__CHECKED_HTTP__hawk.freenetproject.org__COLON__8890/ > > the filter wouldn't trip when the page was loaded. > > When the user clicks on the link, they would get the usual warning message, > with the escapes still in the url (that way fproxy is *never* rendering html > that might have dangerous characters). > > If they clicked through then fproxy would generate a redirect to the external > page with the escapes unescaped. So an extra level of indirection? Hmmm. > > -- gj > So an alternate date format may make sense... how about /DATE at YYYYMMDD/SSK at ...? SSK at blah/blah at YYYYMMDD ? @ is reserved in keys, isn't it? I want old-edition links to work without invoking click-through security, because they represent no conceivable security risk above regular links. The other possibility is to special case ?date=YYYYMMDD<end of URL> in the parser. Any suggestions? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20020831/4e887a97/attachment.pgp>
