Jaqui Greenlees

This exploit is caused by one thing and one thing only: script author’s screwup.
Any website script that does not, by default, treat all site visitor input as dangerous is vulnerable to such an attack.

The only thing that can be done is to use scripts that do not pass SQL from within a users post to the database engine, it should instead mark such as code or a quote and put it into the database as text in the “comment” section of the table when the page displays, the user attempt to exploit the database engine by injection SQL is shown in the post, rather than actually being processed by the database engine. This, along with server logs, can be used as evidence in a court of law for the user’s attempted criminal activity. It also will very quickly stop others from attempting the same thing, as they can see that the attempt with fail and be publicly displayed as such.

Browser development teams, both open source and proprietary, need to give their heads a shake when it comes to the CA list.

They seem to have forgotten that all Certificate Authorities are businesses first. For a website to get a certificate they only have to pay a fee to any C.A. To phrase it in plain English: Pay me n dollars and I’ll tell everyone that you are a good site to do business with. This is absolute stupidity to say that any Certificate Authority is, or can be, TRUSTED.

There is no oversight on the activities of the CAs, without a body able to REVOKE a CA’s operations there is nothing to make them do anything to validate the information, business reputation specially, for those who want a certificate from them. As long as the situation remains the same, any web broswer development team that includes a list of “Trusted” Certificate Authorities should be held legally liable for any damages that end users suffer from shady website operators. Make the end user have to accept the certificate for the website, then it was by their choice that they trusted the site owner. Currently, because the CA list exists, end users are NOT being reminded that they are risking confidential data that can cost them thousands to a website and company they would most likely never be able to get recompense from. They may not be in the same part of the world as the end user, making the end user unable to even try to get their money back through legal process. [ After all, who can afford to fly to China* to try to sue a company for the money they stole. ]

So, a list of trusted Certificate Authorities is actually an extreme dis-service to the end user, and is not a nice thing for any software to have. With no oversight and enforcement body, there is not one single CA that can honestly be called “trusted”

* China only used as an example of a difficult journey and drastically different legal system, I am not saying that all companies, or even if there are any companies, in China that would or do engage in such illegal activities.

It seems that a lot of website are suffering from this particular problem, which leads me to wonder why this is so.

When I look into the records for exploits from Secunia and Sans I see that web exploits are increasing in number, with cross site scripting being the most common exploit. If we look at the site scripts named in the exploits we begin to see some commonalities. Most happen to be written in PHP, and most happen to use MySQL as the backend.

Can we honestly claim that PHP or MySQL is the reason for the exploit? I don’t think so. When the scripts themselves are examined the cause becomes much more apparent. It is a flaw in the Author(s) of the scripts work rather than in the technologies used. Most of the scripts are popular, open source, scripts readily available for download by anyone. They are written to make it easy for them to be installed and used on their website. The problems are two.
1) They tend to use relative urls within the scripts for includes and functions. If the scripts used Absolute urls instead of relative they would be less vulnerable to this type of exploit.
2) The end user input sanitization is weak to non-existent. This is the one that leave them open to the most damage. The authors of these scripts do not exclude user supplied data from parsing, allowing both cross site scripting and SQL Injection exploits.

The only real solution to this would be for people to submit bug reports to the script authors saying the dismal lack of sanitization on user supplied input is a critical security flaw in the script.

PHP and MySQL are not the only technologies that leave sites exposed to this exploit, they just happen to be the most commonly used technologies in scripts that have suffered from it.

With the rise of WEB 2.0 technologies, where websites consume services from other websites, I do fully expect that AJAX will become the “Poster Child” for cross site scripting exploits if “Web Designers” don’t smarten up and start including security in the core of their designs.

A “Web Designer” isn’t really known for doing anything but worrying about how a site looks. They are known for using code generation tools that write bad, bloated code with no attention to security issues. [ Dreamweaver being a number one culprit ]

A company wanting their corporate website revamped should immediately discard any “Web Designers” that submit quotes and only review quotes from those who identify as Website Developers and Designers. Those who use the developer term are more likely to worry about solid code that is secure first, then work on making the site look good with that code. This is the ideal solution for any website that has Client data that must be kept confidential.
[ ecommerce sites specifically, they have credit card and mailing address data being submitted to them. ]