274 replies to this topic

[eww]

if the @ symbol is harmless, i don't see the point in adding additional code to sanitizing it.

the problem with this is that oscommerce stores the emails with the @ in tact. so eventually it's going to need to be in there anyway if you're searching to remove a specific address.. i haven't tried to see if the ascii bits of @ would work the same way.. but if you can't get hacked by somebody passing @ in a querystring i fail to see the point in sanitizing it, especially if security pro already only allows a-z, 09 and dots and dashes.. so before and after @ are already cleansed (and are cleansed inside the unsubscribe.php codes, as well)

str_replace('-emailand-', '@', $HTTP_GET_VARS['querystring']);

when this is parsed, isn't this essentially the same thing as using the @ from the get go? it would still end up as:
myemail@example.com

Edited by eww, 07 March 2008, 23:34.

[FWR Media]

eww, on Mar 7 2008, 11:33 PM, said:

if the @ symbol is harmless, i don't see the point in adding additional code to sanitizing it.

the problem with this is that oscommerce stores the emails with the @ in tact. so eventually it's going to need to be in there anyway if you're searching to remove a specific address.. i haven't tried to see if the ascii bits of @ would work the same way.. but if you can't get hacked by somebody passing @ in a querystring i fail to see the point in sanitizing it, especially if security pro already only allows a-z, 09 and dots and dashes.. so before and after @ are already cleansed (and are cleansed inside the unsubscribe.php codes, as well)

str_replace('-emailand-', '@', $HTTP_GET_VARS['querystring']);

when this is parsed, isn't this essentially the same thing as using the @ from the get go? it would still end up as:
myemail@example.com

The concept of Security Pro is ALLOWING characters not STRIPPING characters.

There is no reason for @ to be in a querystring imo.

[code]str_replace('-emailand-', '@', $HTTP_GET_VARS['querystring']);

when this is parsed, isn't this essentially the same thing as using the @ from the get go? it would still end up as:
myemail@example.com[/code]

The end result is the same yes but it removes the need for passing unwanted characters via the querystring.

[jay2xra]

Hello,

I have FEC and Customer Testimonial 3.2 installed. After installing Security Pro, i can no longer receive email notifications on each order..
Any idea where to look into?

Thanks.

[jay2xra]

jay2xra, on Jun 9 2008, 06:59 AM, said:

Hello,

I have FEC and Customer Testimonial 3.2 installed. After installing Security Pro, i can no longer receive email notifications on each order..
Any idea where to look into?

Thanks.

sorry, my fault.. my sendmail died... :-)

By the way thanks for this contrib.. I hope it will solve this claim saying if you are using FEC, your site can be hacked in less than 2 minutes
http://forums.oscommerce.com/index.php?sho...t=#entry1234914

[Debs]

For some time I have blocked exploits by using this in my htaccess.
This may be a silly question... but why is the contribution better then a simple htaccess like mine below?

Options +FollowSymLinks
RewriteEngine On
RewriteBase /


########## Begin - Rewrite rules to block out some common exploits
#
# Block out any script trying to set a mosConfig value through the URL
RewriteCond %{QUERY_STRING} mosConfig_[a-zA-Z_]{1,21}(=|\%3D) [OR]
# Block out any script trying to base64_encode crap to send via URL
RewriteCond %{QUERY_STRING} base64_encode.*\(.*\) [OR]
# Block out any script that includes a <script> tag in URL
RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR]
# Block out any script trying to set a PHP GLOBALS variable via URL
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
# Block out any script trying to modify a _REQUEST variable via URL
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})
# Send all blocked request to homepage with 403 Forbidden error!
RewriteRule ^(.*)$ index.html [F,L]

[failsafe]

Hi,

Great contribution. Many thanks.

I do have one question... in includes/functions/security.php there's the following function...

function fwr_clean_global($get_var) {
  foreach ($get_var as $key => $value)
  ( isset($GLOBALS[$key]) ? $GLOBALS[$key] = $get_var[$key] : NULL );
}

The isset line looks a rather strange version of a ternary construct and is relatively tricky to understand (esp. for newbies). Is there any reason it couldn't be written as:

function fwr_clean_global($get_var) {
  foreach ($get_var as $key => $value) {
	if (isset($GLOBALS[$key])) { $GLOBALS[$key] = $get_var[$key]; }
  }
}

or is there a special reason to write it the way it is currently? Perhaps I'm even misunderstanding what those lines actually do?

Ta.

Edited by failsafe, 30 September 2008, 16:57.

[FWR Media]

failsafe, on Sep 30 2008, 04:56 PM, said:

Hi,

Great contribution. Many thanks.

I do have one question... in includes/functions/security.php there's the following function...

function fwr_clean_global($get_var) {
  foreach ($get_var as $key => $value)
  ( isset($GLOBALS[$key]) ? $GLOBALS[$key] = $get_var[$key] : NULL );
}

The isset line looks a rather strange version of a ternary construct and is relatively tricky to understand (esp. for newbies). Is there any reason it couldn't be written as:

function fwr_clean_global($get_var) {
  foreach ($get_var as $key => $value) {
	if (isset($GLOBALS[$key])) { $GLOBALS[$key] = $get_var[$key]; }
  }
}

or is there a special reason to write it the way it is currently? Perhaps I'm even misunderstanding what those lines actually do?

Ta.

Oooh never saw this.

Yes it's written like that because it's the way I wrote it .. AND .. curly brackets on the same line .. YUCK!

[Flinspach]

Thank you, works fine.

Martin

[FWR Media]

Flinspach, on Nov 26 2008, 09:51 AM, said:

Thank you, works fine.

Martin

My pleasure, hope it helps keep you safe.

[Black Jack 21]

Hi Robert,

one question. It's necessary to pass through special characters like äüöÄÜÖß posted from the search box. What's the way to do it? I've found it works if i modify the function like this:

function tep_clean_get__recursive($get_var)
  {
  if (!is_array($get_var))
  return preg_replace("/[^ {}a-zA-Z0-9ßäüöÄÜÖ_.-]/i", "", urldecode($get_var));

  // Add the preg_replace to every element.
  return array_map('tep_clean_get__recursive', $get_var);
  }

What do you think, do you see any problems? Please comment and point me in the right direction!

Thank you in advance
BJ

[FWR Media]

Black Jack 21, on Nov 27 2008, 06:32 AM, said:

Hi Robert,

one question. It's necessary to pass through special characters like äüöÄÜÖß posted from the search box. What's the way to do it? I've found it works if i modify the function like this:

function tep_clean_get__recursive($get_var)
  {
  if (!is_array($get_var))
  return preg_replace("/[^ {}a-zA-Z0-9ßäüöÄÜÖ_.-]/i", "", urldecode($get_var));

  // Add the preg_replace to every element.
  return array_map('tep_clean_get__recursive', $get_var);
  }

What do you think, do you see any problems? Please comment and point me in the right direction!

Thank you in advance
BJ

Yes adding limited but valid language characters is not an issue as long as you are careful not to allow in bad characters.

A shortened version that should work is ..

$get_var = preg_replace("/[^\s{}a-z0-9ßäüö_.-]/i", "", urldecode($get_var));

[Black Jack 21]

FWR Media, on Nov 27 2008, 09:12 AM, said:

Yes adding limited but valid language characters is not an issue as long as you are careful not to allow in bad characters.

A shortened version that should work is ..

$get_var = preg_replace("/[^\s{}a-z0-9ßäüö_.-]/i", "", urldecode($get_var));

Thank you very much!

[vicster]

Great contribution! Thank you!

I have one problem, however, and I'm pretty sure it's SecurityPro causing it.

My Categories infobox has disappeared from my index page (and only from my index page). I use the ' &raquo; ' character in my categories infobox. I have tried excluding it in admin by typing in the following in the 'excude from cleansing' area:
includes/boxes/categories.php

but it still does not show.

I did not want to type in 'categories.php' because there is also a file called categories.php in admin and I only wanted to exclude the file that is in catalog/includes/boxes/.

How should I handle this? (And I'm really hoping that it is SecurityPro causing the prob - I installed a few security contrib's before I noticed it was missing dummy me!)

Thanks!

[FWR Media]

vicster, on Dec 21 2008, 03:54 PM, said:

Great contribution! Thank you!

I have one problem, however, and I'm pretty sure it's SecurityPro causing it.

My Categories infobox has disappeared from my index page (and only from my index page). I use the ' &raquo; ' character in my categories infobox. I have tried excluding it in admin by typing in the following in the 'excude from cleansing' area:
includes/boxes/categories.php

but it still does not show.

I did not want to type in 'categories.php' because there is also a file called categories.php in admin and I only wanted to exclude the file that is in catalog/includes/boxes/.

How should I handle this? (And I'm really hoping that it is SecurityPro causing the prob - I installed a few security contrib's before I noticed it was missing dummy me!)

Thanks!

Turn it off see what happens.

I'd also add that allowing a file to bypass like a plain old categories file is not in keeping with the contributions intentions.

You should sort out the offending file not lower your security.

[vicster]

I forgot I could turn it off! LOL! I've been too busy pulling my hair...and comparing files again.

Anyway, I turned it off and it's still not showing, so it must be another contrib causing the problem.

Thank you for your quick response! It's much appreciated!

[bobsi18]

Thanks for what looks like a great contrib... Just one question, how do I test it? I tried following the instructions on the first page (added the section to application top, excluded product_info etc), but as I use a contribution that re-writes the url to a .html url, I don't think I'm getting the results I should be. Any suggestions on what I can do to check it's working?

I'll continued to test, to see if any of my other files aren't working...

Thanks

[vicster]

I have a question. I have installed SecurityPro and I have installed the Anti Cross Site Scripting (originally by pixclinic and then updated by someone else) as per a Tips and Tricks thread regarding securing our sites. SecurityPro seems to be working just fine. However, the anti-xss contrib is causing my 'advanced search' to stop working (taking you to a HTTP 403 page) when the 'include description' option is checked.

My question is does the anti-xss contribution do the same as the SecurityPro contribution? So that I can remove the .htaccess file (or at least the part that's breaking my advanced search)? I have deducted that it is pixclinic's part of the htaccess file that is breaking my advanced search.

For more info, here is a thread I had started about this before I had figured out exactly what was causing the problem:

http://forums.oscommerce.com/index.php?showtopic=324462

I know absolutely nothing about htaccess files and so don't know what to change or add to fix the problem. And if this contrib's purpose is being served with SecurityPro anyway, I'd like to remove it.

Thanks!

[FWR Media]

vicster, on Dec 29 2008, 10:32 PM, said:

I have a question. I have installed SecurityPro and I have installed the Anti Cross Site Scripting (originally by pixclinic and then updated by someone else) as per a Tips and Tricks thread regarding securing our sites. SecurityPro seems to be working just fine. However, the anti-xss contrib is causing my 'advanced search' to stop working (taking you to a HTTP 403 page) when the 'include description' option is checked.

My question is does the anti-xss contribution do the same as the SecurityPro contribution? So that I can remove the .htaccess file (or at least the part that's breaking my advanced search)? I have deducted that it is pixclinic's part of the htaccess file that is breaking my advanced search.

For more info, here is a thread I had started about this before I had figured out exactly what was causing the problem:

http://forums.oscommerce.com/index.php?showtopic=324462

I know absolutely nothing about htaccess files and so don't know what to change or add to fix the problem. And if this contrib's purpose is being served with SecurityPro anyway, I'd like to remove it.

Thanks!

It is really up to you which contributions you add, and any questions related to the individual contributions should be directed at the relevant support thread.

I am happy to support security pro but other contributions are outside of the scope of support here.

[vicster]

Hi! I completely understand where you are coming from ...I was just wondering if SecurityPro already performs the task that the Anti-XSS (htaccess file) is performing.

[FWR Media]

vicster, on Dec 29 2008, 10:47 PM, said:

Hi! I completely understand where you are coming from ...I was just wondering if SecurityPro already performs the task that the Anti-XSS (htaccess file) is performing.

fair enough

All I will say is that security pro (used correctly) secures your querystring. There is no need to my mind (other than standard vigilence to user input) to use more (related ONLY to querystring)

Edited by FWR Media, 29 December 2008, 22:54.