Web Application Cross Site Scripting, Found scanalert help

[tegralens]

What I don't understand is why my other site that does not have chemo seo also has that issue.  When I run Scanalert and change the catalog directory that they have to another directory that I have that does not have any modification aalso has the same issue.

[tegralens]

Cross site scripting exploits insert a client side scripting, code that can be run in a browser. Java script
is a well know client side scripting language. one common method is to include the script is a php


example:
http://www.SOMEDOMAIN.com/index.php?cPath=<script>alert('hello')</script>

problem:
cPath=<script>alert('hello')</script>

on the server side you would usually get the cPath by using a get

$cpath=$_GET['cPath'];

Because we are not filter this it is possible the script <script>alert('hello')</script> will be passed
back to the browser of the person viewing the page and be run. In many cases the is a hostile script
designed to do something bad.

In order to breaks the cross site scripting all variable  should be filtered some how.

This is built int to the code if it is used by the programmer:

There is usually three types of data handle variable, integer and integers with a floating decimal point.
If we know the data will be a whole number we can type class the data,

$product_id= (int)$_GET['product_id'];   
This turns any text like <script>alert('hello')</script> into number that can be translated back and make
any since at all.

For text we can replace certain key symbols so the script won't work in a browser. For  browser to
actually run the client side script there must be script tags. <script> and  </script>

By using tep_db_prepare_input we can filter the string to remove the critical items for the script to run. It
will work with data that is an array to just a string.

$cpath = tep_db_prepare_input($_GET['cPath']);

it becomes: -script-alert('hello')-/script- which will never run in a browser unless there is a bug in the browser code.

it also clean any + signs from the input like this java script code line:

error_message = error_message + "* " + message + "\n";
is changed to:
error_message = error_message  "* "  message  "\n";
Again this will not run in a browser since it has no + to join the string.


By filtering all data fields by type classing, or tep function we are breaking the cross site script so
it won't run. So when you do see those reports the file that they occourded on needs to be check to see
if it has proper filter of variables

Where to I go to make these changes and see if they work?
I know very little of php please be patient with me.

[zip1]

Cross site scripting exploits insert a client side script. Code that can be run in a browser. Java script
is a well know client side scripting language. one common method is to include the script is a PHP.


example:
http://www.SOMEDOMAIN.com/index.php?cPath=<script>alert('hello')</script>

problem:
cPath=<script>alert('hello')</script>

on the server side you would usually get the cPath by using a get

$cpath=$_GET['cPath'];

Because getcre.com does not filter this, it is possible the script <script>alert('hello')</script> will be passed back to the browser of the person viewing the page and be run.

In order to break the cross site scripting, all variables should be filtered input. There is usually three types of data handle variables: integer and integers with a floating decimal point. If we know the data will be a whole number we can type class the data.

Code: [Select]

$product_id= (int)$_GET['product_id'];   
This turns any text like <script>alert('hello')</script> into number that can be translated back and make
any since at all.

For text inupts we can replace certain key symbols so the script won't work in a browser. For browsers to
actually run the client side script there must be script tags. <script> and </script>

By using tep_db_prepare_input we can filter the string to remove the critical items for the script to run. It will work with data that is an array to just a string.

Code: [Select]

$cpath = tep_db_prepare_input($_GET['cPath']);
it becomes: -script-alert('hello')-/script- which will never run in a browser unless there is a bug in the browser code.

it also clean any + signs from the input like this java script code line:

Code: [Select]

error_message = error_message + "* " + message + "\n";is changed to:

Code: [Select]

error_message = error_message  "* "  message  "\n";Again this will not run in a browser since it has no + to join the string.


By filtering all data fields by type classing, or tep function we are breaking the cross site script so
it won't run. So when you do see vulnerability reports from ecommerce security blogs and websites that input validation is need, check to see if it has proper filtering on those variables

[tegralens]

Ok,   its lovely what a few hours sleep and a review of the data can do.

cPath is the category path.  Occurrence of the issue on only those pages actually dealing with categories makes it likely that this is the culprit.

When you hit the url:

http://www.SOMEDOMAIN.com/index.php?cPath=<script>alert('hello')</script>

and check the next page using view source you find:

<input type="hidden" name="cPath" value="<script>alert(\'hello\')</script>">

So, there is a perception of vulnerability, and a potential for one to actually exist.

To avoid the problem being realized, avoid the use of the POST variable cPath by direct means and use the category management code provided by CRE.

Major issue here is that cPath is not a simple variable type, but an array of strings separated by underscores which forms a complete category path - and no validation routine has been written for this osCommerce structure.  If it were, it would walk the array checking that each value consisted of only numbers and underscores.

The same issue probably obtains for link and article categories at least. 

What happens in stock code is that the value is tested, sanitized data is stored in alternate variables and THOSE variables are used to manage the category, BUT the cPath POST variable is not cleared.   So, the content does get passed to the resulting page unchanged, but is never executed.

The issue is a potential vulnerability, but not an actual one unless you install a modification which uses the POST variable without sanitization.

David

I am a little lost.  What did you mean by


To avoid the problem being realized, avoid the use of the POST variable cPath by direct means and use the category management code provided by CRE.

How do I do this?

I did notice it was only on the catagories.

And According to my host mod_security is already enabled.

Thanks for helping me with this issue.

[David M. Graham]

Another possible solution is mod_security.  On our sites, this scan would return an error.  It simply does not let the input reach the code.

David

[David M. Graham]

Ok,   its lovely what a few hours sleep and a review of the data can do.

cPath is the category path.  Occurrence of the issue on only those pages actually dealing with categories makes it likely that this is the culprit.

When you hit the url:

http://www.SOMEDOMAIN.com/index.php?cPath=<script>alert('hello')</script>

and check the next page using view source you find:

<input type="hidden" name="cPath" value="<script>alert(\'hello\')</script>">

So, there is a perception of vulnerability, and a potential for one to actually exist.

To avoid the problem being realized, avoid the use of the POST variable cPath by direct means and use the category management code provided by CRE.

Major issue here is that cPath is not a simple variable type, but an array of strings separated by underscores which forms a complete category path - and no validation routine has been written for this osCommerce structure.  If it were, it would walk the array checking that each value consisted of only numbers and underscores.

The same issue probably obtains for link and article categories at least. 

What happens in stock code is that the value is tested, sanitized data is stored in alternate variables and THOSE variables are used to manage the category, BUT the cPath POST variable is not cleared.   So, the content does get passed to the resulting page unchanged, but is never executed.

The issue is a potential vulnerability, but not an actual one unless you install a modification which uses the POST variable without sanitization.

David

[David M. Graham]

What release and revision is this site??

David

[tegralens]

anything ?

[tegralens]

It may be helpful to have the exact URL, and I get the feeling that at lease some obscurity has been applied to the actual script injection code....

David

I just sent you a PM

[David M. Graham]

It may be helpful to have the exact URL, and I get the feeling that at lease some obscurity has been applied to the actual script injection code....

David

[tegralens]

A bit more time.  I have ran the urls on a dev site with ultimate urls installed and I don't see any sign so far that their attempt is succeeding.

Without a valid example, I don't see that there is an issue so far.  The rewrite either routes them to the right page, or 404s.

I'm seeking consultation..

David

Thank you if you need my url pm me and I will give it to you.

[David M. Graham]

A bit more time.  I have ran the urls on a dev site with ultimate urls installed and I don't see any sign so far that their attempt is succeeding.

Without a valid example, I don't see that there is an issue so far.  The rewrite either routes them to the right page, or 404s.

I'm seeking consultation..

David

[tegralens]

I suspect Denver was looking for a performance hit from the rewrite rule.  There should be more effective ways to disable trace and track access with Apache 2.x and (some) later versions of 1.x.

David

Ok so what do I do now?

[David M. Graham]

I suspect Denver was looking for a performance hit from the rewrite rule.  There should be more effective ways to disable trace and track access with Apache 2.x and (some) later versions of 1.x.

David

[tegralens]

What do you mean by Yslow ?  I don't know what that is.

OK got it now after I run Yslow what do you need.