Post a Comment
Three words: No dynamic SQL
Actually the solution is simple: Always use parameterized queries. Never ever ever use string concatenation. Not everyone is a fan of sprocs, and they've actually fallen out of favor more lately now that ORM's are more mainstream and easier to use.
The first comment posted on the article already explains the whole issue at hand:
By default this tool searches for Microsoft ASP pages (an IIS specific web development technology) and injects a Microsoft SQL Server specific payload: these defaults, maybe, have generated the false perception that an IIS vulnerability is involved, while the infection is just leveraging trivial coding errors made by the web developers.
So, perhaps some poor default values combined with not-so-good programming caused this. It's not specifically IIS bug or anything like that at all. Switching to Linux and using Apache won't help either if you can't make your code secure. So, remember all web devs out there: ALWAYS check any variables you pass to SQL server that they are fully valid and will not contain any intended characters there.
Imagine how many will sue Microsoft over data and hardware loss!
It would be awesome!
Microsoft has clauses in their EULA's that explicitly prohibit anyone suing them for data loss. Actually, almost ALL software/hardware vendors have these clauses, so don't go thinking they are unique to MS. And don't think you're protected if you live in Europe or whatnot. Imagine all the bogus claims that would be made if those clauses didn't exist.
And this is what I have a real problem with - why should they be protected? If they have produced a flawed product, that results in a loss to me, or my business, they *should* be responsible. Period. Imagine if you bought a new Ford, and due to manufacturing issues the steering wheel collapsed and crashed as a result - you *can* sue Ford for damages etc.
Why should software companies not have the same laws applied to them that every other consumer manufacturer has to agree to?
Dave
And why do you think they don't? If software causes you tangible harm or loss, you have the same legal recourse as for any other product. EULAs are not a shield against that, in fact, they're not a shield against much, really.
The same rules apply, you simply need to show a direct cause-effect relationship between the product and your damage, and quantify that damage. The problem is that when it comes to software, that is easier said than done, but it's doable. Software manufacturers operate under the same laws as every other manufacturer, an EULA doesn't absolve them of responsibility.
Not from what I see. See Thom's article on Dutch laws and how EULAs are considered contracts under Dutch law. If you sign that contract saying you won't sue, then you're screwed. I suspect a great deal many countries will be the same as the Netherlands, caring more for the big corporations and rich, and bugger all for the average person.
Dave
Why would you assume the people behind these attacks are actually Chinese? Just because the websites that host the vulnerabilities are in China doesn't mean the people who put those there are as well.
We're talking about crackers here - they're not likely to just throw up their malicious code on any old domain they happen to own.
If the issue is that someone attacked the server an injected code into the MS-SQL server, then how are the client systems being infected?
The best I can see is that they injected code to turn on a back door so they could modify the web-server.
Thus the security issue is also on the client pc's. They are allowing a web site to install anything the server wants on their pc. SQL Injection shouldn't work on the client since the DB is located on the server.
What types of clients are being infected? And since MS verified that it was a server issue, what is MS's advice on how to protect the client from the servers?
The client injection is caused by javascript code that's injected into the database. In other words...
1. SQL injection puts Javascript into he database
2. Injected database content is shown on the page
3. Javascript opens windows with malware
So, the client injection part of this could have been stopped if the web sites used proper HTML encoding of the database output.
The issue is with a server-side "exploit", it has nothing to do with the client browser. You could hack together a script to do the same thing, without even using a browser. The issue is lazy coding on the part of the web developers, it's not a browser issue.





