McAfee Secure Vulnerabilities found

[Mike718NY]

McAfee Secure is giving this vulnerability report.
Does anyone know anything about this? Is McAfee wrong?


Cross Site Scripting (XSS)

The remote web application appears to be vulnerable to cross-site scripting (XSS).
The cross-site scripting attack is one of the most common, yet overlooked, security problems facing web developers today. A web site is vulnerable if it displays user-submitted content without sanitizing user input.

General Solution
When accepting user input ensure that you are HTML encoding potentially malicious characters if you ever display the data back to the client.
Ensure that parameters and user input are sanitized by doing the following:
Remove < input and replace with <
Remove > input and replace with >
Remove ' input and replace with &apos;
Remove " input and replace with "
Remove ) input and replace with &#x29;
Remove ( input and replace with &#x28

[sohaib]

McAfee Secure must have said more about which page(s) it found XSS vulnerabilities on.
Is it an Ablecommerce page to begin with?

[Mike718NY]

If this helps . ., but I can't make heads or tails out of this McAfee nonsense:

Path /Default.aspx

Headers Referer=http%3A%2F%2Fwww.super-vits.com%3A80%2F%3FM%3DA
Content-Type=application%2Fx-www-form-urlencoded


Path /Search.aspx

Headers Referer=http%3A%2F%2Fwww.super-vits.com%3A80%2FSearch.aspx%3Fm%3Dhttp%253A%252F%252Fwww.scanalert.com%252Fhelp%252Fscanner%252F5%252Frfi%253F
Content-Type=application%2Fx-www-form-urlencoded


Path /Search.aspx

Headers Referer=http%3A%2F%2Fwww.super-vits.com%3A80%2FSearch.aspx%3Fk%3D..%252F..%252F..%252F..%252F..%252F..%252Fetc%252Fpasswd
Content-Type=application%2Fx-www-form-urlencoded


Path /Basket.aspx

Headers Referer=http%3A%2F%2Fwww.super-vits.com%3A80%2FBasket.aspx
Content-Type=application%2Fx-www-form-urlencoded


Path /ContactUs.aspx
Headers Referer=http%3A%2F%2Fwww.super-vits.com%3A80%2FContactUs.aspx
Content-Type=application%2Fx-www-form-urlencoded


Path /Help.aspx
Headers Referer=http%3A%2F%2Fwww.super-vits.com%3A80%2FHelp.aspx
Content-Type=application%2Fx-www-form-urlencoded


Path /NewProducts.aspx
Headers Referer=http%3A%2F%2Fwww.super-vits.com%3A80%2FNewProducts.aspx
Content-Type=application%2Fx-www-form-urlencoded

[jmestep]

In Able 5, the shotgun fix for this was:
<pages validateRequest="true"> in the <system.web> section of the web.config file.

It looks like you can change it to true in Able 7 here:
<pages theme="AbleCommerce" enableEventValidation="false" validateRequest="true">

I'm not sure if it would mess up the WYSIWYG editor used from the store, not the admin interface.
And it might mess something else up-- can Logan chime in here?

[Shopping Cart Admin]

Hello,

After looking over the site, it's most likely the super search form or a false positive which is known to happen. To be sure you could try removing the search form from on of the affected pages and the newsletter sign up form from one of the other pages.

We have lot's of folks using McAfee Secure with 7.0 without throwing these errors and our PABP certification process also showed no issues with cross site scripting. So it's likely 1. server setup. 2. False flag. 3. Custom coding of the search.aspx page or 4. something I'm not thinking of.

Did these same errors show up in todays scans as well and/or on prior days?

[Shopping Cart Admin]

Hello,

Did these same errors show up in todays scans as well and/or on prior days?

I don't like to have unresolved security issues, please answer my questions or is this issue no longer of concern?

Also based on another post where you indicated you have a customized search.aspx page, I'd be double checking the customizations to confirm they are stripping out the offending characters.

[Mike718NY]

>> you indicated you have a customized search.aspx page . .

I just changed the layout and design of the page. I didn't change anything
that had to do with data input or validation:

<asp:Panel ID="SearchPanel" runat="server" DefaultButton="SearchButton">
<asp:TextBox ID="SearchPhrase" runat="server" Columns="36"></asp:TextBox> <asp:LinkButton ID="SearchButton" runat="server" Text="&nbsp;GO!&nbsp;&nbsp;&nbsp;" OnClick="SearchButton_Click" CssClass="searchButton2" SkinID="ignore" CausesValidation="false"></asp:LinkButton>
</asp:Panel>

I think McAfee is wrong here. I'm going to ask them if the Seal can be displayed anyway.
If it can, I'll just ignore it.

[meer2005]

I've got the same thing on my McAfee scan:

Description
The remote web application appears to be vulnerable to cross-site scripting (XSS).

The cross-site scripting attack is one of the most common, yet overlooked, security problems facing web developers today. A web site is vulnerable if it displays user-submitted content without sanitizing user input.

The target of cross-site scripting attacks is not the server itself, but the users of the server. By finding a page that does not properly sanitize user input the attacker submits client-side code to the server that will then be rendered by the client. It is important to note that websites that use SSL are just as vulnerable as websites that do not encrypt browser sessions.

The damage caused by such an attack can range from stealing session and cookie data from your customers to loading a virus payload onto their computer via browser.

The pages listed in the vulnerability output will display embedded javascript with no filtering back to the user.

When accepting user input ensure that you are HTML encoding potentially malicious characters if you ever display the data back to the client.

Ensure that parameters and user input are sanitized by doing the following:

Remove < input and replace with <

Remove > input and replace with >

Remove ' input and replace with &apos;

Remove " input and replace with "

Remove ) input and replace with &#x29;

Remove ( input and replace with &#x28;

/Default.aspx
Headers Referer=http%3A%2F%2Fwww.site.com%3A80%2F
Content-Type=application%2Fx-www-form-urlencoded

Body __WPPS=s
__EVENTTARGET=0
__EVENTARGUMENT=0
__VIEWSTATE=e8bmHwl0nz9Kn6E+68gtq9Gd7HKxLkHPRSvxDjXomAY5FDdPVxmxfraHVL5dyUK22zpCTJgPK8XhH47di8/1AvVcZ0pkhzySIUgWI4Cm/1aKktSvYZxcQFyKm3ecXtylpC3Df3UBBg20iSPpvOH2saC0JHRWbk92i8RniyqSVz5Rumqq7ZBzTBKpEpabo7iPiLiAOgzAUbc4qWlrWx5vSvLMZ6oMy0xr9QAvooNNC/fabVVv7OszX0k4lHnzQCK+ph0HRFh7Q4SQFb1iVsEGqEBr/qaH0X5EnF7z7n4mzheHT0Vxy98ltVxEaNTZeAMYiKAtR3RO09QfsSJMrwvHtc1tFsKQN1ryXoACnn8/zKgCEBanLQdnU1Nj/nZArdWRb1E4RqOeR9K1YoGwqIucOtKVGG6muzoQZVzO7kwrKJAmVTYSgewGFfjH8wjD+xua+8sUtc1EohE2KgyCpQ/rXYRZAkjqAyMxvJeFmPpjSbknqWT4fXSvUqzqAOErQwb81lZkXNGAldZovb30SrB2oJeKLgHH4U2ngmXNZZAx8qoYj54wVcIUyYiqfN9EbWQMZnAFnmT/0zPKCbDScg2SJK+E8nzG3TbzN1qCIJu7IzsPKrKcLwMMJFwKAwFqbBUR/eRZ0WUmvulkf53ZMFG57NW5ejd4ylxrDMkklODUi/ru7dNlXic9QzgdxcbDv7jBA+5d4Hytw28LEAdK+b0Gop8L+ETFx1gFWQOKYce5tKBDSHq1FCA2jlXrCA/UOsfzRLD6IS0NN9P/ahW+0DT1rOKdZWPZE4wfHMS+iFdJ+/r1/880sMJvrTZjJnw9bRfFGpcvGNB9xp/ldcG5gZVjvg==
__VIEWSTATEENCRYPTED=0
ctl00$wpm$HomePage$ctl01$SearchPhrase=0
ctl00$wpm$HomePage$ctl01$SearchButton=Search
ctl00$wpm$HomePage$ctl04$UserEmail=>"></title></iframe></script></form></td></tr><br><iFraMe src=http://www.HackerSafe.com width=900 height=1100></IfRamE>
ctl00$wpm$HomePage$ctl04$SubscribeButton=Subscribe Now
ctl00$wpm$HomePage$ctl05$ProductList$ctl00$Price$VS=qgaA+YcdneaYDytm3P5i+/b92NKmolbSVeXic2CnHAE++GuQiM8UOAAh00X6gxXD
ctl00$wpm$HomePage$ctl06$ProductList$ctl00$Price$VS=3SrD1PyGlMVQR33olaGY37maZeiUjne4FRrEIZ8AKgzXroo2ltNWynv9+xC2z/Fw
ctl00$wpm$HomePage$ctl02$ProductList$ctl00$ProductPrice$VS=rMIll0jHSZ9kg320gt3r5CTiYvvVm25gPn6qRY/5qZex7yU96k6xauV+DnE7xyJ7
ctl00$wpm$HomePage$ctl02$ProductList$ctl02$ProductPrice$VS=doPdK8LQuC9cllOyrFHUISVOSeCR/YGoecD7mM9FjfgAc2rDEleGI8xTseMOG26+
ctl00$wpm$HomePage$ctl02$ProductList$ctl00$AddToCartLink1$VS=ONNmD0Wrddtju7hCf3j1JQFlvXh0ezKlmdb6vZ1Mm8Q/oBUwdWD5TAN84NEpU/e6
ctl00$wpm$HomePage$ctl02$ProductList$ctl02$AddToCartLink1$VS=KZxSpuP0PZAVW+duLzwFQJ0JEWfe6RDrkAVKJ7kiWQpc9JTmG7paaYmxD7XQVIcy

[jmestep]

Try this solution from above. It will stop the attack, but I don't know what it will do to the admin.
It looks like you can change it to true in Able 7 here:
<pages theme="AbleCommerce" enableEventValidation="false" validateRequest="true">
you might have to put
validateRequest="false" in web.config files under the admin
[Edit]
I just tried this in our site and it stopped the vulnerability-- if you enter any html code into a form in the site, it throws an error, which it is supposed to do.
I put validateRequest="false" in the web.config in the admin and you can still enter html there.
When that vulnerability came up in Able 5, I remember someone at Able being surprised that the web.config files weren't set that way-- that is what the "true" setting is for.

[Brewhaus]

Because we are wanting to get this error off of our McAfee list, I want to confirm the resolution. We change:

Code: Select all

  <system.web>
    <customErrors mode="On"/>
    <pages theme="AbleCommerce" enableEventValidation="false" validateRequest="false">

to

Code: Select all

  <system.web>
    <customErrors mode="On"/>
    <pages theme="AbleCommerce" enableEventValidation="false" validateRequest="true">

Has this been found to affect any function of the site in any way?