tag:blogger.com,1999:blog-20011960.post3589166600193886907..comments2024-01-15T00:25:02.006-08:00Comments on HolisticInfoSec™: XSS and PCI: Not compliant, or Hacker SafeRuss McReehttp://www.blogger.com/profile/05647342839278416757noreply@blogger.comBlogger4125tag:blogger.com,1999:blog-20011960.post-51430279370358240202021-02-03T06:32:51.202-08:002021-02-03T06:32:51.202-08:00This comment has been removed by a blog administrator.swamyhttps://www.blogger.com/profile/11612897528414815558noreply@blogger.comtag:blogger.com,1999:blog-20011960.post-46458366510943956962008-10-08T05:37:00.000-07:002008-10-08T05:37:00.000-07:00Now... Russ... let's be fair. [sarcasm]osCommerce...Now... Russ... let's be fair. <BR/><BR/>[sarcasm]<BR/>osCommerce has only had 6 *disclosed* vulnerabilities this year, which means it's doing much better<BR/>[/sarcasm]<BR/><BR/> I think that once I read this person's reply a fourth or fifth time something struck me. I thought - maybe this isn't their fault... then I read it again and I felt a touch better. Work with me here... This person is [hopefully] acknowledging that there are ridiculous amounts of XSS througout osCommerce [as evidenced by your link to the vuln. database]. Given that, I agree it would be semi-silly to try and fix osCommerce flaws when you're simply a customer of theirs. Now, this is where reality takes a bite. Given that this person's administrator (I'm assuming that this means this person is just the developer, or 3rd party developer?) has absolutely *no interest* in making their site more secure [which is honestly what really bugs me here] they're just going to go for HackerSafe approval and get on with life. Not really more secure, just "HackerSafe".<BR/><BR/>Here's my analysis...<BR/><BR/>- First off... Shame on osCommerce!<BR/>- This scenario, although terrible, is likely the way things go in lots of places out here in the "Wild West" of the Interweb<BR/>- This person apparently found the 'signature' that McAfee's HackerSafe program used to scan for XSS and will be filtering that pattern out (blacklisting) - this will fail<BR/>- This site's administrator is either a moron, or lazy; neither of which should allow him/her to keep their job<BR/>- "HackerSafe"? Maybe. Secure? Unlikely. Better off?... sadly, probably.<BR/><BR/> And now I'm even more convinced we're [you, me, and others in security] are talking to ourselves most of the time.Rafal Loshttps://www.blogger.com/profile/18106347834259269413noreply@blogger.comtag:blogger.com,1999:blog-20011960.post-67958780961346253452008-10-07T22:58:00.000-07:002008-10-07T22:58:00.000-07:00Wow...I'm just not sure where to begin with that c...Wow...I'm just not sure where to begin with that comment. Assuming even the slightest legitimacy, I'll say thanks for proving my point: the vast majority of McAfee Secure / Hacker Safe subscribers don't give a damn about security, just conversions. Ever think of global code remediation as opposed to single parameter quick fixes? Oh wait, you're using osCommerce. How's that working for you? Here's a <A HREF="http://search.securityfocus.com/cgi-bin/swsearch/swish.cgi?query=oscommerce&metaname=alldoc&sbm=%2F&start=0" REL="nofollow">link</A> to the FIFTY (50) vulnerabilities posted for osCommerce in BugTraq. I repeat...wow.Russ McReehttps://www.blogger.com/profile/05647342839278416757noreply@blogger.comtag:blogger.com,1999:blog-20011960.post-54771480539702023552008-10-06T14:15:00.000-07:002008-10-06T14:15:00.000-07:00Upon receiving ScanAlert’s report, I immediately s...Upon receiving ScanAlert’s report, I immediately saw that almost all of vulnerabilities reported by ScanAlert were cross site scripting (XSS) vulnerabilities. Now, I’m not particularly knowledgeable about XSS attacks, but I really didn’t need to be to see what ScanAlert was doing and figure out how to strategize around it(!). Basically, ScanAlert was sending various GET and POST requests to the system remotely and scanning the response to see if they had successfully injected what could be malicious code in the response.<BR/><BR/>The administrator who contacted me assumed I would sift through the code and fix each error individually on a per case basis, which given the large number of vulnerabilities as well as the size and complexity of the osCommerce code base, would probably not get done in the 72 hour window. Even if I focused on updating just the core functions and classes in osCommerce, I am not sure I could have plugged every hole in time. Furthermore, such changes would introduce a tremendous maintenance burden whenever the site was upgraded to a new version of osCommerce, especially as the administrator had no real knowledge of PHP. And, given various constraints, that included the administrator’s reluctance to contribute any code he has paid for to open source projects, it didn’t appear practical to try to update the core osCommerce code and submit changes back to the project.<BR/><BR/>So, just to be clear, my goal really wasn’t to “fix” this aspect of osCommerce or even to make the site more secure necessarily, it was to achieve “Hacker Safe” approval in a given amount of time and do so in a way that could be maintained by the system administrator.<BR/><BR/>Fortunately, this fork of osCommerce had theme/templating capabilities, and the site was already using a customized template , which meant that I could inject the code into the main template script, and it would execute before any output was sent to the browser and “sanitize” any user input at that point. Because I would be injecting the code into a customized template that was already being maintained and accounted for in upgrades, I could add this code without adding to the administrator’s responsibilities.Anonymousnoreply@blogger.com