Penetration Testing mailing list archives
RE: Cross Site Scripting Vulnerabilities - XSS
From: "Matt Andreko" <mandreko () ori net>
Date: Fri, 9 Aug 2002 16:10:43 -0500
I'm sorry I didn't explain my point as well as I'd hoped. If the site doesn't have a storage, or doesn't need to worry about cookies (no store), what is the point in being able to inject things? Sure, if you send an email with a link in it, they'll get taken to another site, but my understanding was it was as if information was stored in a database so that an unknowing user could fall into it. Do I have the wrong idea of XSS in my head, or does it cover both situations? -----Original Message----- From: Kevin Spett [mailto:kspett () spidynamics com] Sent: Wednesday, August 07, 2002 2:38 PM To: Matt Andreko; pen-test () securityfocus com Subject: Re: Cross Site Scripting Vulnerabilities - XSS If you were really trying to exploit a XSS issue, you wouldn't make a pop-up box... people just use that to test for it. You would do something like silently sent an HTTP request containing the cookie value to another site, so that the person (or program) at the other end would be able to hijack the session. Kevin Spett SPI Dynamics, Inc. http://www.spidynamics.com/ ----- Original Message ----- From: "Matt Andreko" <mandreko () ori net> To: "'Bill Pennington'" <billp () boarder org>; <pen-test () securityfocus com> Sent: Tuesday, August 06, 2002 5:56 PM Subject: RE: Cross Site Scripting Vulnerabilities - XSS
I am kinda new to XSS, but am intrigued by how it works. I have found sometimes you can get javascript messages to pop up and such, but if it's not being stored in a database, what good is it? Take for example Iwillusa.com (a motherboard maker's website). They have a product page that I saw had some html in the URL:
http://www.iwillusa.com/products/spec.asp?ModelName=DVD266<i>u</i>-RN&Su
pportID= I edited it and it became:
http://www.iwillusa.com/products/spec.asp?ModelName=DVD266u-RN<script%20
language=javascript>alert(document.cookie);</script>&SupportID= I'm fully able to get a javascript error. However, what good does
this
do, if it's not stored anywhere? -----Original Message----- From: Bill Pennington [mailto:billp () boarder org] Sent: Tuesday, August 06, 2002 10:29 AM To: Jason binger; pen-test; webappsec Subject: Re: Cross Site Scripting Vulnerabilities - XSS Cross posting to webappsec because I know other people will have comments and suggestions. I have done more XSS testing that I care to remember. There are no tool that I am aware of that can accurately test for XSS issues in a web application. Some scanners have pretty good test for web
server
and application server XSS issues (like request <SCRIPT>alert("foo")</SCRIPT>.jsp and exploit the 404 handler), Nessus and nikto come to mind. For XSS testing I use a browser and a cheat sheet, a list of XSS
strings
to inject. My testing goes something like this: Assuming I am looking at a URL based variable, VAR= 1. Determine if the variable is displayed on the screen. Change VAR=realcontent to VAR=foo. This should generate an error message but
it
might not. On the resulting page, view source and search for foo.
Note,
you might want to pick a less common string to make searching easier. If foo is not on the resulting page you can not perform a URL based
XSS
attack. The data might be stored and displayed latter though. Keep an eye out for it :-) 2. See how the application handles "<" and ">". Now change the
variable
to VAR=<foo>. Again view source on the returned page and look for <foo>.
If
<foo> is present you most likely have an XSS issue. If you see
something
like %ltfoo> then the variable is not vulnerable. 3, Now you just need to build an actual bit of client code and see if
it
gets gets executed. Change VAR= to VAR=<SCRIPT>alert("XSS");</SCRIPT> When you submit the page you should get a pop-up box that says XSS on your screen. If you do not get the pop-up, view source and find your string and make sure the proper syntax is in place. Some variables to put in strange places and you may need to format your injection string differently.
If
you are getting the full string returned to the browser without
modification
it is vulnerable, you just need to figure out the proper format. Most likely you need to close out another tag or a set of quotes before you XSS
code
is inserted. The above steps are a bit redundant but they are part of testing the application for all known issues, not just XSS. You could just do step
3
but you might miss a bit of important info along the way. Most automated tools will only catch the simple XSS attacks, the more difficult ones are passed over. Hope that helps! On 8/3/02 10:52 PM, "Jason binger" <cisspstudy () yahoo com> wrote:Has anyone on the list done much with testing for XSS vulnerabilities? Has anyone written a simple work program to test for these vulnerabilities that they are happy to distribute so others can do basic testing for these vulnerabilities? There a few papers out on this topic, but none that I hve seen that really focus on the testing side of things. Thanks __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com
------------------------------------------------------------------------
----This list is provided by the SecurityFocus Security Intelligence
Alert
(SIA)Service. For more information on SecurityFocus' SIA service which automatically alerts you to the latest security vulnerabilities
please
see:https://alerts.securityfocus.com/
------------------------------------------------------------------------
---- This list is provided by the SecurityFocus Security Intelligence Alert (SIA) Service. For more information on SecurityFocus' SIA service which automatically alerts you to the latest security vulnerabilities please see: https://alerts.securityfocus.com/
------------------------------------------------------------------------ -- --
This list is provided by the SecurityFocus Security Intelligence Alert
(SIA)
Service. For more information on SecurityFocus' SIA service which automatically alerts you to the latest security vulnerabilities please
see:
https://alerts.securityfocus.com/
------------------------------------------------------------------------ ---- This list is provided by the SecurityFocus Security Intelligence Alert (SIA) Service. For more information on SecurityFocus' SIA service which automatically alerts you to the latest security vulnerabilities please see: https://alerts.securityfocus.com/ ---------------------------------------------------------------------------- This list is provided by the SecurityFocus Security Intelligence Alert (SIA) Service. For more information on SecurityFocus' SIA service which automatically alerts you to the latest security vulnerabilities please see: https://alerts.securityfocus.com/
Current thread:
- Cross Site Scripting Vulnerabilities - XSS Jason binger (Aug 06)
- Re: Cross Site Scripting Vulnerabilities - XSS Chad Loder (Aug 06)
- Re: Cross Site Scripting Vulnerabilities - XSS Bill Pennington (Aug 06)
- Message not available
- Re: Cross Site Scripting Vulnerabilities - XSS Jeremiah Grossman (Aug 07)
- Message not available
- RE: Cross Site Scripting Vulnerabilities - XSS Matt Andreko (Aug 07)
- Re: Cross Site Scripting Vulnerabilities - XSS Bill Pennington (Aug 07)
- Re: Cross Site Scripting Vulnerabilities - XSS Kevin Spett (Aug 09)
- RE: Cross Site Scripting Vulnerabilities - XSS Matt Andreko (Aug 12)
- Re: Cross Site Scripting Vulnerabilities - XSS Kevin Spett (Aug 12)
- <Possible follow-ups>
- RE: Cross Site Scripting Vulnerabilities - XSS Jeremy Junginger (Aug 12)