Received: with ECARTIS (v1.0.0; list gopher);
 Mon, 22 Jul 2002 09:31:34 -0500 (EST)
Return-Path: <spectre@stockholm.ptloma.edu>
Delivered-To: gopher@complete.org
Received: from stockholm.ptloma.edu (stockholm.ptloma.edu [199.106.86.50])
	by pi.glockenspiel.complete.org (Postfix) with ESMTP id C4A363B850
	for <gopher@complete.org>; Mon, 22 Jul 2002 09:31:33 -0500 (EST)
Received: (from spectre@localhost)
	by stockholm.ptloma.edu (8.9.1/8.9.1) id HAA10026
	for gopher@complete.org; Mon, 22 Jul 2002 07:39:35 -0700
From: Cameron Kaiser <spectre@stockholm.ptloma.edu>
Message-Id: <200207221439.HAA10026@stockholm.ptloma.edu>
Subject: [gopher] Re: Gopher+ Suggestion
In-Reply-To: 
 <Pine.LNX.4.21.0207221513350.23953-100000@pinkstuff.transformers.org.uk> from
 Thomas Thurman at "Jul 22, 2 03:23:54 pm"
To: gopher@complete.org
Date: Mon, 22 Jul 2002 07:39:35 -0700 (PDT)
X-Mailer: ELM [version 2.4ME+ PL39 (25)]
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 8bit
X-archive-position: 658
X-ecartis-version: Ecartis v1.0.0
Sender: gopher-bounce@complete.org
Errors-to: gopher-bounce@complete.org
X-original-sender: spectre@stockholm.ptloma.edu
Precedence: bulk
Reply-to: gopher@complete.org
List-help: <mailto:ecartis@complete.org?Subject=help>
List-unsubscribe: <mailto:gopher-request@complete.org?Subject=unsubscribe>
List-software: Ecartis version 1.0.0
List-ID: Gopher <gopher.complete.org>
X-List-ID: Gopher <gopher.complete.org>
List-subscribe: <mailto:gopher-request@complete.org?Subject=subscribe>
List-owner: <mailto:jgoerzen@complete.org>
List-post: <mailto:gopher@complete.org>
List-archive: <http://www.complete.org/mailinglists/archives/>
X-list: gopher


> > While true, this should hardly be the responsibility of the client to
> > enforce -- this only masks badly written server software and makes it
> > less likely to find exploits.
> 
> Difficult to prevent attempts to send people to arbitrary gopher URLs,
> though. (Consider an HTML document containing
> 
>  <img src="gopher://vunerable.host:25/0HELO+evil-overflow-attempt-XXXX-etc"
>    width="1" height="1" alt="">
> 
> If such a page is read in a graphical browser, and that browser doesn't do
> anything to stop such URLs, it will send arbitrary text (up to a few
> kilobytes) to an arbitrary port on an arbitrary host without the user's
> knowledge.

What I'm saying, though, is the server should still be ultimately responsible
for security. By hiding the ability to send an exploit from a client doesn't
solve the server's inherent flaw, and in fact makes finding the flaw more
difficult in that it will require a more involved or technical approach that
is less likely to be discovered early and countered. It's sort of a "security
through obscurity" approach.

> It's difficult to see how to stop such attacks on the server side.

Sure. But I think this masks security flaws rather than improving security.
IMHO, of course. ;-)

-- 
----------------------------- personal page: http://www.armory.com/~spectre/ --
 Cameron Kaiser, Point Loma Nazarene University * ckaiser@stockholm.ptloma.edu
-- For every credibility gap, there is a gullibility fill. -- R. Clopton ------