Massive SQL injection attack making the rounds—694K URLs so far
arstechnica.com
arstechnica.com
Firstly, you should periodically scan your app. Both Burp Suite[1] and Netsparker[2] have free versions of their excellent tools. Burp Suite Pro comes with a very capable scanner and is about $250 (£175). Netsparker Community Edition is a fairly good automated scanner, but it doesn't cover all forms of SQL injection and the full version is quite expensive.
Running Wordpress? Head to Sucuri[3] and get your wordpress scanned. If you haven't upgraded already, now's the time.
Once you've done that, things vary according to your language and platform. Generally OWASP[4] is the font of (almost) all knowledge. You can test the app but if you wrote it you're probably more familiar with the code, so looking at how you handle user-supplied input and applying consistent changes where needed is probably your best bet. If you get really stuck, there are plenty of security geeks on HN, or alternatively you can drop me an email (address in my profile) and I'll see if I can answer your question. Alternatively if you're in London, come to DC4420[5] next month, there's going to be about 200-300 security geeks there, many of whom would be happy to help with specific questions in exchange for a beer. I'll be one of them.
[1] - http://www.portswigger.net/
[2] - http://www.mavitunasecurity.com/
[3] - http://www.sucuri.net/
[4] - http://www.owasp.org/index.php/SQL_Injection_Prevention_Chea...
[5] - http://www.dc4420.org/
The attack appears to be indiscriminate in its targets, with compromised machines running ASP, ASP.NET, ColdFusion, JSP, and PHP, and no doubt others.
RTFA.
And linking to random n00bs chatting in the asp.net forums is not evidence. Obviously they're only going to be talking about MS.
SQL injections following this pattern appear to have been happening off and on for six or more months now. The domain name hosting the JavaScript changes each time, but the file name—ur.php—and the style of injection remain consistent. The actions of the scripts have been similar too; pop-up windows and malware downloads. Previous efforts were on a much smaller scale, however: hundreds of compromised URLs instead of hundreds of thousands. In these earlier cases, the attacks originated from IP addresses in eastern Europe and Russia.vs
http://www.google.com/#q=%22%3Cscript+src%3Dhttp://lizamoon.... Page 41 of 403 results
"The “number of results” count that Google gives when you search is clearly fabricated." http://blog.xkcd.com/2011/02/04/trochee-chart/
If you click to include omitted results, the number of results stays at 631k when you get to the last page they will show you.. (1000 results max) Though I don't think it would be hard to imagine that the actual number is far fewer.
Edited several times.. I don't post often...
Seems they were going after low hanging fruit based on my logs and the syntax they were using.
2. Use parameterized queries rather than pasting strings together.
3. There is no step 3. Seriously, it's not hard.
If this attack works by storing the data in the original (intended) field and just happens to bypass the JavaScript filters then it's XSS and not injection.
It is almost impossible to fuck up prepared statements, so although they take longer to write it is a good way to secure a website.