[13737] in bugtraq
Re: 'cross site scripting' defenses
daemon@ATHENA.MIT.EDU (flynngn@JMU.EDU)
Mon Feb 7 18:22:23 2000
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <389E047F.AB6F8EF4@jmu.edu>
Date: Sun, 6 Feb 2000 18:32:15 -0500
Reply-To: flynngn@JMU.EDU
From: flynngn@JMU.EDU
X-To: BUGTRAQ@SECURITYFOCUS.COM
To: BUGTRAQ@SECURITYFOCUS.COM
I was thinking of ways that the vulnerabilities could be taken
advantage of to use as examples. It seems that by following a
few minor design rules and one minor usage rule, a lot of the
problem can be contained until the core deficiencies in code
can be fixed. At least in sites which require a login. I base
these rules on the assumption that script can only be injected
into the first page of a web application and that there is only
a single entry point (i.e. web page) into the application. I also
assume that a user isn't tricked into performing an entire web
application transaction on a hostile site. Those rules are:
1) Don't include anything on the login screen except fields
for username and password. Doing this would seem to help
insure that if script is injected, the login will fail.
2) Don't return any user supplied data to the browser on a
failed login. This is so if some script code is injected into
the username and password fields, it won't be returned to
the browser when the corrupted authentication information
causes the login to fail.
3) Encourage users to "logout" of a web application before browsing
elsewhere.
Am I thinking right?
Gary Flynn
Security Engineer
James Madison University
