Hi, sorry it took a couple days to respond here with the holiday and
all. What I mean by not exploitable is that since a user never sees
another user's messages, a malicious user cannot post a script to steal
other users' cookies. Since the application is vulnerable to SQL
injection, a malicious user can use that to post a script that another
user will see, it is just a little more complicated. Thanks for the
response, have a good weekend, and I am looking forward to Hacme Suite 2005.
Chuck
Michael Silk wrote:
Chuck,
No it doesn't seem it is 'exploitable' in that you could use it
to take over the system, however it does allow you to observe the
attempts of XSS and how you could use that against someone viewing the
code (in this case: yourself). I'd suggest that the point of HacMe bank
is not to take down the system (after all, it's installed on your server
...) but to learn about what to do - this lets you do that.
-- Michael
-----Original Message-----
From: CFW [mailto:cfw_security@comcast.net]
Sent: Tuesday, 9 November 2004 5:56 AM
To: Mark Curphey
Cc: webappsec@securityfocus.com
Subject: Re: Looking for a Web Application Vulnerable to XSS Cookie Grab
Mark,
Thanks for the response and thanks for writing a great learning
tool.
Maybe I am just not doing something right, but it looks to me like
the Stored XSS is not really exploitable because a given user will never
see another user's posts to the message board. Am I missing something?
Chuck
Mark Curphey wrote:
Hacme Bank has both reflective and stored XSS already so what you are
asking for is already there.
We will have a new version due out around Jan 2005. I am taking feature
requests ;-)
-----Original Message-----
From: CFW [mailto:cfw_security@comcast.net]
Sent: Friday, November 05, 2004 4:33 PM
To: webappsec@securityfocus.com
Subject: Looking for a Web Application Vulnerable to XSS Cookie Grab
Hi all,
I am setting up a lab to learn about web application security and I
have been messing with WebGoat and Foundstone's HacmeBank and found
them to be very useful learning tools. One thing lacking in them (from
what I can
tell) is a multiuser, XSS Cookie Grabbing example.
Basically, I would like to have a little application (or part of
one of these applications) that one (malicious) user can log in to and
post a XSS cookie grabber to a forum or guestbook or something. Then,
the attacker fires up a listener until another user logs in and hits
the script, sending the cookies to the listener. Then, the first user
can change his cookies, and see clearly that the web application thinks
it is the second user. Does anyone know of such an application?
The Foundstone Hacme Bank is almost there in that it has a "Post
Message" section that is vulnerable to XSS, but it is set up so that
each user sees only their own messages, so it is not possible to post a
malicious script to someone else. If the Foundstone people are reading
this, have you considered changing this behavior?
While I am asking, are there any other web applications like these
that I should set up? I looked at WebMaven, but it looks like that has
been overtaken by Hacme and Webgoat (correct me if I am wrong).
Someone mentioned a while back on pen-test that you could use an old
version of PHP-Nuke as a vulnerable site since it has a lot of known
issues. Has anyone done this and have any hints on what version is the
most useful in this respect (most vulnerable I guess)?
Thanks a bunch and have a good weekend.
Chuck
**********************************************************************
This email message and accompanying data may contain information that is
confidential and/or subject to legal privilege. If you are not the intended
recipient, you are notified that any use, dissemination, distribution or
copying of this message or data is prohibited. If you have received this email
message in error, please notify us immediately and erase all copies of this
message and attachments.
This email is for your convenience only, you should not rely on any information
contained herein for contractual or legal purposes. You should only rely on
information and/or instructions in writing and on company letterhead signed by
authorised persons.
**********************************************************************
