Showing posts with label XSSed. Show all posts
Showing posts with label XSSed. Show all posts

Friday, January 25, 2008

An Open Letter to Ken Leonard, CEO, ScanAlert

Dear Mr. Leonard,

As well you are aware; the Hacker Safe brand has long been viewed by those in the information security field with varying levels of skepticism, if not vehement disdain. As there are a plethora of blogs, articles, and exposed vulnerabilities available for you to review, I will not waste your time with excerpts validating our position. Suffice it say, the community at large shares certain doubt about the service offering ScanAlert arrogantly calls Hacker Safe.
It is our view that this is a marketing position only. Nothing, I repeat, nothing, is truly "hacker safe". You claim that websites are free of vulnerabilities when they are clearly not. This is disingenuous and is at the root of what angers information security professionals. If a site is vulnerable while under the auspicious care of ScanAlert's Hacker Safe program should it not lose its Hacker Safe credential until such a time as the vulnerability is remediated? If I take this down to a fundamentally simple premise, saying a site is Hacker Safe while vulnerable to SQL injection, XSS, CSRF, etc. is, in essence, a misrepresentation. If a consumer commits a transaction on a site that is vulnerable, are they not at risk due to vulnerabilities your service claims to scan for? While we understand that you are in the business of growing revenue by indicating websites as “hacker safe”, we believe you are also beholden to the consumers using those sites.
We ask of you this: if a site is found to be vulnerable during your scans, or as reported by third parties, then enforce the findings and suspend their certification. Strive to improve your scan engine where possible. It is your responsibility to NOT label a site “Hacker Safe” when it is not. Then, at least, you are telling the truth, and a consumer can make an informed choice as to how confident they feel about the site's security practices.
There are, at the time of this writing, sites still vulnerable to XSS, yet branded Hacker Safe, that were identified as vulnerable MORE THAN A YEAR AGO. These sites should not be reported as Hacker Safe, period.
Please don't insult us with more of Joseph Pierini’s pearls of wisdom like “XSS vulnerabilities aren't material to a site's certification”. Adopting a view like this is ridiculous and blatantly ignorant given the risks to consumers. You scan for XSS and clearly denote it in your How We Scan section. Therefore, if a site is vulnerable to XSS it is not “Hacker Safe”.
This is far from the first round, credit sla.ckers.org with driving this point home in 2006, only to be shrugged off by Pierini then too. I think there may be a job opening for him over at Zango. Perhaps he could change his mantra from “XSS is not our problem” to “We don’t make spyware.”
What about the PCI argument? If a site is vulnerable to XSS, it’s simply not compliant. See this post for details. It all adds up to consumers at risk. ScanAlert should remember, above all, that safety for the consumer is paramount. Why not live up to your marketing hype and offer a service that truly, honestly, and with integrity, lives up to even a fraction of its namesake.
"What gets us into trouble is not what we don't know. It's what we know for sure that just ain't so. - Mark Twain"

Sincerely,

Russ McRee

Those information security professionals wishing to lend your name to this plea, please add your name as a comment.

del.icio.us | digg

Friday, January 18, 2008

XSS and PCI: Not compliant, or Hacker Safe

As a follow up to the last post on sites vulnerable to XSS that are certified McAfee Hacker Safe, there is more to this story.
Of the additional sites listed in Thomas Claburn's recent Information Week article, many take credit cards online and are thus required to comply with PCI DSS 1.1.
If a website is vulnerable to XSS, THE COMPANY IS NOT PCI COMPLIANT.
Supporting language from the Payment Card Industry Data Security Standard:
6.5 Develop all web applications based on secure coding guidelines such as the Open Web Application Security Project guidelines. Review custom application code to identify coding vulnerabilities. Cover prevention of common coding vulnerabilities in software development processes, to include the following:
6.5.1 Unvalidated input
6.5.2 Broken access control (for example, malicious use of user IDs)
6.5.3 Broken authentication and session management (use of account credentials and session
cookies)
6.5.4 Cross-site scripting (XSS) attacks

So not only can we call into question the validity of the Hacker Safe label, we can question how these businesses can be considered PCI compliant. Again, see the Information Week article for the list of sites.
For further consideration, what if these businesses, as McAfee Hacker Safe customers, are signed up for their Scan Alert PCI service?
"To validate compliance with the PCI DSS, a merchant, service provider, and/or financial institution may be required to undergo a PCI Security Scan conducted by an Approved Scanning Vendor (ASV)."
Are there potential gaps here as well?

del.icio.us | digg

Tuesday, January 15, 2008

Hacker Safe? Not so much.

Likely you've all read about Hacker Safe certified Geeks.com being hacked. ScanAlert, recently bought by McAfee, says that "research indicates sites remotely scanned for known vulnerabilities on a daily basis, such as those earning 'Hacker Safe' certification, can prevent over 99% of hacker crime."
I agree...but here comes strike two.
I was happily bouncing about the internet looking for things that should be fixed, when what did I see at Toastmasters International but a McAfee Hacker Safe certificate. Ever the skeptic, I said to myself "Prove it." But, of course, because my white hat and professional values require it, I remembered that first, do no harm are words to live by. But a wee script test in a form field can't hurt, right?
There's video of this here if you prefer.
Let's begin.
Here's the Advanced Search page, note the McAfee Hacker Safe tag in the lower right:


Then, said little test script about to be submitted to the Advanced Search page:



Ruh roh, Rastro. Can you say XSS?



Man, that's not good, so let's try a bit more trickery.



XSSed indeed.



Something tells me the McAfee Hacker Safe service offering would do well to dig a little deeper before certifying a site.
Meanwhile, sanitizing input might not be a bad idea for our Toastmasters friends.
Play nice until Toastmasters gets a chance to fix it, please. I've already let them know.
Cheers.
del.icio.us | digg

Moving blog to HolisticInfoSec.io

toolsmith and HolisticInfoSec have moved. I've decided to consolidate all content on one platform, namely an R markdown blogdown sit...