Checking for user-agent header SQL injection vulns

As I analyze various web applications in the name of fun or fortune, I am sometimes treated to those little reminders that result in a "doh!".
Such was the case when I was assessing the latest release of the Avactis Shopping Cart.
I'd just installed the latest free version (1.9.1). Typically, after finding a flaw in an vendor's offering, I sign up for their new release notices, and had recently received one from Avactis.
When last I'd visited said shopping cart I'd spotted a couple of XSS bugs in the checkout.php script for version 1.8.1 and earlier. I admit that at the time I did not do as robust review of the application as I might now; in all likelihood the following bug was present when the XSS bugs were disclosed in September 2008.

With a fresh version installed thanks to the reminder, I fired up Firefox with Tamper Data, and started poking around. With Tamper Data, as we've discussed before, any web form input parameters/variables are subject to your manipulation.
I habitually work from the right side of the Tamper Data UI wherein POST parameters reveal themselves.
There I sat, happily walking through the app, when the bell went off.
"Hey, Russ, don't forget to fuzz the header values too!"
Cross-site scripting and SQL injection specific to cookie values is certainly not unheard of but you may need to refer to a checklist to always remember to probe them for vulnerabilities.
In my case, this was even more true of the user-agent string value.
Not all apps are written to capture the user-agent data, but you can easily understand why shopping cart providers would make use of such information.
What's the point? Remember to investigate the user-agent header for issues too.
It can be a simple as appending a single tic on the end of the user-agent string and submitting it, as seen in Figure 1.


Figure 1

The results were immediate and revealing. In case you wondered what my typical user-agent entry looks like, Figure 2 will enlighten.



You can see that we've caught the query executed by /var/www/avactis/avactis-system/modules/reports/report-collectors/report_data_visitors_stat_collector.php, specifically SELECT_WEB_ROBOT_ID, and the result.
Which, in turn, clearly justifies the rapid and responsive patch provided by the vendor. I submitted the finding to Secunia on October 10th and the vendor posted the patch on October 12th; Secunia Advisory SA41764 was released as q result on October 14th.
A hearty "Well done!" to the Avactis team for that turnaround.

A quick diff of report_data_visitors_stat_collector.php from version 1.9.1 build 8356 as installed on October 9th and the patched version downloaded today is seen in Figure 3.


Figure 3

The tale is quickly told, and it's a good move by the Avactis dev team.
Begone ye damned addslashes()!
Note that the dev yanked use of the addslashes function on lines 49, 157, 238, and 318; addslashes() is a subject to circumvention, mysql_real_escape_string() is recommended.

See how much we can learn when remembering to be more thorough?

I must say, if I hadn't recently renewed my status as a certified Application Security Specialist, I might have missed this vulnerability altogether.
And I definitely would have missed out on the additional benefits such as photo opportunities with app sec glitterati (taken at the recent BlueHat). ;-)



Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Financials and the need for software regression testing

SearchFinancialSecurity.com just published my article regarding Financials and the need for software regression testing.
This article cites Ameriprise as an example of a financial services provider who would benefit from improved regression testing and version control.

This article was actually written prior to the recent SQL bug I discussed involving Ameriprise, and is made even more interesting by discussion of a possible small, unrelated Ameriprise data breach in New Hampshire.

I truly hope Ameriprise takes a close look at the suggestions offered and moves towards enhancing security practices on behalf of their consumers.

Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Online finance flaw: Ameriprise III - please make it stop

NOTE: This issue was disclosed responsibly and repaired accordingly.

"Now what?", you're probably saying. Ameriprise again? Yep.
I really wasn't trying this time. Really.
There I was, just sitting in the man cave, happily writing an article on version control and regression testing.
As the Ameriprise cross-site scripting (XSS) vulnerabilities from August 2009 and January 2010 were in scope for the article topic, due diligence required me to go back and make sure the issue hadn't re-resurfaced. ;-)
I accidentally submitted the JavaScript test payload to the wrong parameter.
What do you think happened next?
Nothing good.
I reduced the test string down to a single tic to validate the simplicity of the shortcoming; same result.



At the least, this is ridiculous information disclosure, if not leaning heavily towards a SQL injection vulnerability.
As we learned the last two times we discussed Ameriprise, the only way to report security vulnerabilities is via their PR department, specifically to Benjamin Pratt, VP of Public Communications.
Alrighty then, issue reported and quickly fixed this time (same day)...until some developer rolls back to an old code branch or turns on debugging again.

We all know the ColdFusion is insanely verbose, particularly when in left in debugging mode, but come now...really?
I really didn't want to know the exact SQL query and trigonometry required to locate an Ameriprise advisor.
Although, after all this, I can comfortably say I won't be seeking an Ameriprise advisor anyway.

Please Mr. Pratt, tell your web application developers to make it stop.

Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

toolsmith: Firefox Addons for the Security-minded

Few websites are safe from a hearty probe when I come by for a visit, and I'd be remiss if I didn't share some of my favorite Firefox add-ons utilized as part of said probing.
I opted to do just this as the topic for February's toolsmith, and focused on the expected standards (NoScript, FoxyProxy Standard, BetterPrivacy, and Torbutton) as well as some of my less known favorites.

PassiveRecon
Justin Morehouse’s PassiveRecon will let you dig up everything you ever wanted to know about a given site you may be browsing or analyzing.

WorldIP
WorldIP from WIPmania.com is very cool and very useful.
It provides everything you could every need to know or trace with regard to IP addresses and geolocation.

Groundspeed
I saved the best for last; a new powerhouse in my web app sec arsenal.
Felipe Moreno-Strauch’s Groundspeed, a newer add-on “that allows security testers to manipulate the application user interface to eliminate annoying limitations and client-side controls that interfere with the web application penetration tests.”
And this it does well. ;-)

The article is live for your reading pleasure here.

Cheers and enjoy.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Fun with fake Flash: an Abode update you don't want

Jericho of Attrition.org (support the Open Security Foundation!) recently asked the VIM mailing list a question: Adobe Flash - vuln or just "design"?
The question, inspired by Mike Bailey's work for Foreground Security, leads to healthy debate, including press and vendor response. But, ironically the same day I received the VIM mail, I was led to explore a slightly different perspective on Adobe Flash issues. Thus, your author doesn't intend to get in the middle of above proposed curmudgeonly discussion.

I am however inspired to be curmudgeonly; grumpy even.

The crux of this conversation is the fact that the oft updated Adobe Flash Player continuously proves to be social engineering attack vector fodder. This is by no means news, or likely a surprise to the 19 of you who read this blog, but I recently stumbled on a real gem in the wild and I thought I'd share.
Whilst defending the Intarwebs from evildoers, I spotted
hxxp://www.abodeplugin.com/flashpayer/thankyou/flashplayer.htm
Explore this site at your peril, the binary sure isn't Adobe's; nor is it any update you want to install.

First, the use of letter juxtaposition (Adobe to Abode) is a pretty smooth endeavor likely to be missed by happily unaware clickers.

Second, the faux page layout is built largely right from the source Abod...er, Adobe site.



This irony is not lost on me: this "update" page is so pure it includes JSON formatted addon offers from Adobe, including a free McAfee Security Scan. Woot! You're going to likely need one if you install plugin.exe.

Speaking of, plugin.exe is a Trojan-Downloader.Win32.Genome sample that would normally go grab additional ill-intended binaries. Runtime analysis showed some common behaviors, though this sample seemed rather neutered.
1) Spawned a process and created C:\WINDOWS\system32\services.exe
2) Made a call to 212.180.97.163 (hxxp://www.sofec.21s.fr/k70.htm), now resulting in a 404.
3) Strings output was amusing (highlights parsed):
Buffer overrun detected!
unable to initialize heap
unexpected heap error
HeapDestroy
HeapCreate
HeapReAlloc
HeapSize
show me the money!
Nice. Really?

Who knows what additional evilware once lurked at 212.180.97.163, but it wasn't likely removed by anyone thinking clearly. The site hosted there is in miserable shape, suffering from numerous issues including SQL injection, horribly managed Frontpage extensions, cross-site scripting, and more. Which is to say, "give any one species too much rope and they'll f**k it up" (Roger Waters from Amused to Death).





So what's the lesson?
Negligence begets opportunity.
Opportunity begets maliciousness.
Maliciousness begets victimization.
Simple, yet entirely preventable.

The above mentioned combination of bad web application security and common malware practices likely means that someone may not have a nice Thanksgiving and that makes me sad. I don't like to be sad.
So beware fake Flash updates and button up your crappy websites so jerkwater ne'er-do-well's have less opportunity, damn it!

I am thankful for my dear family and all 19 of you readers.
Pass the Tofurkey!

Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Pending book review: ModSecurity 2.5

Packt Publishing, a UK based publishing firm specializing in focused IT books, has asked me to review Magnus Mischel's ModSecurity 2.5.


Having recently discussed monitoring ModSecurity with OSSEC, I'm looking forward to reading this book.
I've been a ModSecurity fan since incorporating it in a secure server implementation, back when it was version 1.9.4 in 2006, as part of a paper written for OWASP.

Expected highlights include:
* Securing your system by knowing exactly how a hacker would break into it
* Writing rules in-depth and ModSecurity rule language elements such as variables, actions, and request phases
* Covers the common attacks in use on the Web; find the geographical location of an attacker and send alert emails when attacks are discovered
* Many real-life examples for better understanding

I'll give you a detailed, honest assessment of ModSecurity 2.5 in a few weeks.

Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

ColdFusion, SaaS, and negligence

Recent headlines have described news pertinent to ColdFusion-related vulnerabilities and hacks specifically targeting the FCKEditor text editing tool, and the CKFinder file management tool. There have been further indications of attackers uploading a ColdFusion web shell as often seen on vulnerable PHP platforms.

These discussions reminded me of two significant pet peeves.
1) ColdFusion error verbosity and how useful it is to attackers.
2) Negligent vendors who do absolutely nothing about security vulnerabilities they've been advised of; worse still, when the vendor is a SaaS provider.

Case in point: WebPublish CMS

I communicated with these folks at multiple intervals via email and telephone from February 20, 2009 until April 23, 2009. It took multiple efforts just to get through as my messages were manually interpreted as "potential SPAM". Trust me, my security advisory language does not trip SPAM filters and is most often easily and well received. Yet, after finally making a connection, I received the classic "we don't have the time and resources to address this issue any time soon." To which I replied with useful resources for mitigation and remediation. My last received communication stated "I will have a look and see if I can incorporate as much as I can." That was two and half months ago.
I think we can agree the tenets of responsible disclosure were followed, yes?
Thus, a seemingly capable, growing SaaS provider quite simply blew me off.

So be it. Here's my favorite example of something they should immediately fix: A cross-site scripting (XSS) vulnerability exhibited in the ColdFusion error page leading to significant information disclosure (ID) while indicating possible SQL injection (SQLi) vulnerabilities. Wow, really?

A screen shot complete with a wee bit 'o appsec humor courtesy of an IFRAME insertion:


Now take this absurdity to the next level.
As many a vendor is prone to doing, WebPublish CMS sites clearly state that "This site is powered by WebPublish".
How helpful.
Try intext:"powered by WebPublish" via Google.
Just a few results, yes?
We'll use a few for further analysis. What do they all have in common?
kellyprecision.ie
multiples.ie
netcommunications.ie
snapprinting.ie
webpublishcms.com
Yep, all the same IP, as in all on the same server.

Core application vulnerabilities in a primary service offering (SaaS) from one vendor, on one server, affecting hundreds if not thousands of clients.
See the problem?
Negligence, plain and simple.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Online finance flaw: U.S. Bank & National City Bank XSS and more

Updated 12/24/08 (see end of post)

In this, our second entry in the series Online Finance Flaws, I call to your attention a report from Javelin Strategy & Research, the Banking Identity Safety Scorecard.
According to the MarketWatch writeup on the report, it "measures 25 leading U.S. financial institutions' customer-facing identity fraud capabilities. The Javelin model measures Prevention, Detection and Resolution(TM) features to track performance throughout the fraud cycle."
While I don't have the $1500 handy to purchase rights to read the complete report, it appears to be a comprehensive, well intended, ongoing effort.
Key questions asked by Javelin include:
1) Which financial institutions rank highest against Javelin’s customer-facing Prevention, Detection and Resolution™ criteria?
2) What type of account protection capabilities should banks and credit unions implement now to increase customer safety through Prevention, Detection and Resolution™?
3) Which customer safety features will most differentiate financial institutions in the future?
In answer to #1, the report lists its Top 5 indicating that Bank of America once again earned top overall honors, demonstrating excellence in its efforts to partner with customers against a crime that uniquely targets both the financial institution and the consumer. National City Bank (acquired by PNC) and Wells Fargo shared second position with equivalent scores followed closely by US Bank and Wachovia.
I'll answer #2 & #3 below.
I'll ask some further questions first, however.
Do we agree that web application security should and does play a critical role in what Javelin refers to as Prevention, Detection and Resolution™?
Do we agree that cross-site scripting (XSS), cross-site request forgery (CSRF), information disclosure, and SQL injection (SQLi) are all flaws that should not exist in a bank site on Javelin's Top 5?
Do we agree that XSS issues make for golden phishing opportunities for the inherently malicious, and again, should not exist in bank sites on Javelin's Top 5 with regard to a Banking Identity Safety Scorecard?
Before I discuss the flaws, be aware that I followed my terms of engagement with both of the following banks, and was largely ignored with either no reply or very vague, inconclusive brush-offs.
It is my hope that you, dear reader, will contact the following institutions, as I have, on behalf of the consumers they are obligated to protect, in the hope that they will make timely repairs.
And here, as I am prone to saying, is where the trouble begins.

U.S. Bank is vulnerable to XSS at their logon page.

National City Bank is vulnerable to XSS and information disclosure, as well as potential CSRF and potential SQLi, in a Cold Fusion (gasp!) app that runs a subdomain; specifically insights.nationalcity.com.

While the potential National City Bank vulns don't necessarily give a malicious attacker a ton to work with, given that it's an isolated app running a subdomain, the XSS issue is still useful in obvious ways.
I am particularly saddened by the XSS issue on the U.S. Bank site given the history of exploitation of just opportunities. See what I call the Italian Bank Job, and the article I wrote, Anatomy of an XSS Attack, inspired by the Italian caper.



Note that, as indicated in the Netcraft article on the Italian bank issue, SSL "security" is a moot point. Any script execution in the context of the U.S. Bank site occurs "protected" by SSL. As Netcraft says, "any SSL certificate associated with the site - included Extended Validation certificates - would display a padlock icon and apparently assure the user that the injected login form is genuine."

The National City Bank issues appear as follows.

XSS:


Information disclosure and potential SQLi both appear in the grossly verbose, overly helpful Cold Fusion error:


As a technical evangelist for online consumer well-being, and an information security practitioner, I'm here to tell you: these vulnerablities are indicative of behavior unbecoming of secure online banking; particularly as applied to two of the five "top-ranked banks who partner with customers to protect against identity fraud."

To answer #2 and #3 from above: build secure web applications.

U.S. Bank and National City Bank, I ask you to resolve these issues soon, on behalf of customers in your care.

Update 12/24/08:
U.S. Bank has notified me that they've repaired the vulnerable login code. Additionally, they've asked that I remove the video PoC, a request I choose to honor in deference to their open communication during the remediation period.

I've heard nothing from National City Bank. That said, while the initially reported issues appear to have been resolved, the resulting error message is still sloppy and overly informative (typical of Cold Fusion left unchecked).

del.icio.us | digg | Submit to Slashdot

Online Finance Flaws: An Awareness Campaign

Here begins a series regarding web application security inadequacies in online financial service offerings. The services to be discussed will include banks, credit unions, credit card companies, and others. As the economy struggles profoundly, and much of the blame points at the financial sector, I believe it important to point out the false sense of security so many brand-name financial services wrongly instill in their customers.
Often this sense of security is coupled with a typical "security badge" provider, helping drive conversions rather than security, as we will also legitimize how often the badge providers miss the mark on their promises.
Accountability in loan making decisions and practices might have prevented the sub-prime market collapse and the subsequent credit crunch that has hogtied our economy.
Accountability with regard to web application security while providing online financial services is now all the more important as cybercrime will continue to increase at a pace proportionate to economic woes.
Each post relevant to this campaign will include Online Finance Flaw in its title for tracking purposes.
Look forward to surprising flaws in financial services brands you'll recognize.
Perhaps, the more attention we draw to services that should place security above all else, the more likely it is they'll commit to improving their security posture.
Feel free to comment or contribute; we'll begin in a day or two.

Vulnerabilities quickly mitigated by security-conscious vendors

As you are likely aware, I spend a fair bit of time heckling those I believe deserving due to their shortcomings with regard to protecting online consumers.
I do, however, continue to seek opportunities to shed positive light as well, and recent responses from a number of vendor/developers warrant an opportunity to do just that.
In the last 30 days, I've discovered vulnerabilities in products from four different vendors, and advised them all immediately upon discovery. Usually, that's where the story ends, as sadly, my repeated requests for action are often ignored. The last 30 days have proven to be entirely different, with swift responses and action from ALL vendors to whom I reported vulnerabilities. In all cases I received replies within 24 hours or less, and patches/fixes/updates were typically released within 24-72 additional hours. These are exemplary responses, and reflect why I choose to conduct vulnerability research. I believe we, as web application professionals (both developers and security practitioners), are beholden to the greater public and must endeavor to protect the online safety of the Internet consumer.
To each of these vendors/developers I'd like to issue a hearty "well done" and issue public kudos for their diligence and security consciousness, on behalf of consumers and website operators.
To Lukas of PlanetLuc, Jasper and Eric of Infrae/Silva, Alexander of CompactCMS, and Peter from ActiveCampaign may I say that your efforts are greatly appreciated. Where too few choose to do the right thing, your responses leave us with the perception of caring and integrity.
Thank you.

del.icio.us | digg | Submit to Slashdot

ColdFusion: Hack Me or Help Me

For your consideration, the endless battle between security and convenience.
Front and center: ColdFusion.
I've been picking on ColdFusion-built apps again a bit lately, and one of my observations has been that consistently, if mismanaged, the verbose error reporting features in ColdFusion can be really problematic.

HIO-2008-0713 JOBBEX JobSite SQLi & XSS
HIO-2008-0729 BookMine SQLi & XSS

Recently, I stumbled on an example of way too much information disclosure in a few sites running a ColdFusion-built CMS. The error reporting was so verbose it included the base path, data source name, database username, and yes, the database password.
I've cleaned it up for the protection of all involved, but here's a screen shot of only 1/4 of the details this site coughed up when I tweaked the input to a calendar date variable.



When I reached out to the developers of this app (always and immediately responsive), they assured me that this was not due to a flaw in the app, but that the "information should be protected, and is by default for our installations" and that the client disabled the security check and turned debugging on. I accept this explanation entirely, but it leads to the classic debate around the dangers of mismanaged debugging features, be they developer added or ColdFusion feature driven. Stupid user tricks are always an issue, but how much rope should they be given to hang themselves? Does error reporting really need to include the database username and password?

Allow me to present a few different perspectives.
First, rvdh's take on Attacking ColdFusion. Developers can learn a lot from this post, if only in that it precisely points out attack vectors. Ronald sums up my concerns aptly:
"As we know, error messages are important. Especially error messages generated by database software we want to inject. This, is useful for obtaining information about table structures that can be a real time-saver for attackers. If the right information is available, attackers do not have to guess database tables and fields anymore, nor having to brute force them. I have never seen so much information regarding the site's structure, used database, table names, drivers, server setup and other information useful for attackers that those of ColdFusion. It almost says: Please Hack Me!"
As I can't presume to improve on this stance, I won't. Well said.

Next, a developer's take on the issue from Joshua Cyr, who has declared it Check Your Error Output Day. Joshua highlights two key points:
1) Do NOT enable the robust errors setting in CF Administrator.
2) Don't forget to remove debugging dump code.
Heed this advice, ColdFusion fans!

One destination that all "secure" ColdFusion paths should lead to is the use of cfqueryparam. Ronald spells it out well mid way through his discussion, and so do the following resources:
coldfusionjedi
Coldfusion Muse

Further excellent resources for ColdFusion security issues:
SQL Injection Part II (Make Sure You Are Sitting Down)
12Robots.com

In closing, security and convenience needn't always be at odds, but often allowing for both requires a higher state of awareness for developers and end-users. Let common sense prevail; perhaps it'll give me less to do in the way of research. ;-)

del.icio.us | digg

Blue River's stance on Sava security stands out

It's been awhile since I've had something nice to say, and the golden opportunity to rectify that issue has presented itself in the discovery of some vulnerabilities in Sava CMS from the Blue River Interactive Group.
At 9:29pm May 19th, I sent a note to Blue River pointing out an XSS vulnerability. I received a reply from Malcolm at 9:46pm (yes, 17 minutes later), stating that the issue would be addressed immediately and asking if I had questions or suggestions.
Wow! Really?
The lonely life of security dork/vuln researcher sometimes has its rewards. I offered to take a deeper look at Sava, with their permission, which Malcolm immediately granted. After further inspection, I noted a SQLi issue as well, but the update they'd already released had fixed the issue on other sites where the update had been applied. So, in what really amounts to 48 hours, the Blue River team went after the issues with a vengeance, and addressed them appropriately (and obviously quickly).
It's no secret that I am giant open source proponent, and Sava fits that definition in every way, not just their application but their open communication, pride in their product, and concern for their users.
This is what we in the security community hope for...those rare occasions to feel good about well intended efforts being met by further well intended efforts, all to the benefit of the user and the consumer.
Well done, Blue River...go Sava!

Any Sava users who may be reading this, ensure that you are running Sava CMS 5.0.122 or later.
Advisory here: HIO-2008-0523 Sava CMS SQLi & XSS

del.icio.us | digg

Redmondmag...I told you so!

There is no more egregious an act of negligence committed by online vendors and businesses than ignoring notifications of vulnerabilities found in their applications.
So when Dancho Danchev pointed out that Redmond Magazine had been SQL injected by Chinese Hacktivists, I was both appalled, yet not surprised.
On January 29th, 2008 I informed 1105 Media, the parent company of the Redmond Media Group, of multiple XSS vulnerabilities in various properties they maintain, including EntMag.com and AdtMag.com, as well as Redmondmag.com.

From my email:
"I’d like to advise you of XSS vulnerabilities in the search code used by all Redmond Media Group websites.
This is most easily validated by pasting a simple script alert generator in the search form.
These vulnerabilities were disclosed by XSSed.com in February and July of 2007.
http://www.xssed.com/mirror/20073/
http://www.xssed.com/mirror/13305/
These vulnerabilities could be exploited by malicious people to conduct XSS attacks and it could further lead to reputation and PR issues for the Redmond Media Group."

Not only did they flatly ignore me, and they guys from XSSed.com who'd notified then in FEBRUARY and JULY 2007!, but all these vulnerabilities still exist, including Redmondmag.com. You could definitely say that these issues have led to "reputation and PR issues for the Redmond Media Group."
Doh! I told you so!
It goes without saying that if you are vulnerable to XSS, you have a significantly higher likelihood of being vulnerable to SQLi.
Redmondmag.com was also victimized by the 2nd wave of mass SQL injection attacks that dropped in nihaorr1.com/1.js.

Regarding current vulnerabilities, observe the following:
http://www.whiteacid.org/misc/xss_post_forwarder.php?xss_target=http://search.redmondmag.com/search.asp&cmd=search&SearchForm=%%SearchForm%%&index=C:\dtSearch\rmg\red_all&sort=Date&srcrequest=%22%3E%3CSCRIPT%3Ealert('XSS_Alert')%3C/SCRIPT%3E&submit1=Search">http://www.whiteacid.org/misc/xss_post_forwarder.php?xss_target=
http://search.redmondmag.com/search.asp&cmd=search&SearchForm=%%SearchForm%%&
index=C:\dtSearch\rmg\red_all&sort=Date&
srcrequest=(Insert JavaScript here)&submit1=Search

Props, as always, to Whiteacid's XSS Assistant and POST forwarder.
But behold, what do we see, but index=C:\dtSearch\rmg\red_all.
Well, now we know you use dtSearch on the C: of your Windows server (no surprise there ;-)).

Come on people, fix your sites!
You have been found guilty of the following charges:
1) Vulnerable to SQLi
2) Vulnerable to XSS
3) Internal file disclosure
4) Flagrant negligence with regard to secure coding best practices
50 Flagrant disregard fo information submitted to you by the information security community.
1105 Media and the Redmond Media Group, you have failed your readers, your visitors, your customers, and yourselves, and you should be ashamed.

del.icio.us | digg