Botnet sics zombie soldiers on gimpy websites The miscreants who have poisoned more than half a million web pages aren't the only attackers thinking big. People behind a botnet known as Asprox have recently rejiggered their army to infect websites in a similar fashion. Asprox zombies have recently been blessed with a tool that sniffs out potentially vulnerable sites …
If they are not coding to code they shouldn't be available to ISPs, it is as simple as that. Why have ISPs been so lax so long?
If they sorted out all the spam and all the botnets we could clear the decks for unrestricted file transfers from You Tube. Think of all the cats we could be watching.
I said it here already, and was called stupid for giving my opinion, but it is weird that most databases engine do not already include an option making this impossible.
Apparently, H2 has an option for this, called "disabling literals". If you are a professional making an important web site, you check the option, and yes, your code is slightly harder to read. That's it.
The question is, why is there only ONE database engine with this option? I've seen an Oracle database auto-replicating on five different servers. Is this option harder to implement? Or maybe they did not have the resources to do it, because, y'know, Oracle is such a small start-up and everything?
I guess the web developers, the coders, and the database programmers have been passing each other the buck for years now...
Paris, because she knows something about getting passed from one person to the other...
If I recall correctly, the mysqli functions for PHP 5 only allow one query to be run per call to query(), so even if the developer was stupid and didn't cleanse his inputs (and there are many ways to do so) then there's not a guarantee of the site being taken over. (Still doesn't stop malicious OR queries in logins for example, but nevertheless it seems a step in the right direction.) Another thing that bugs me is cPanel's MySQL database setup automatically checks All Privs for when you add a new user to a database. If you're only going to be selecting records, only allow the database user to select records.
Perhaps all books and classes for web design, especially scripting, need to be required to give a large nod to security before being eligible for publication. There's not really a way to regulate internet tutorials, save perhaps something like a "W3C compliant tutorial" label that is given out to those who can prove they demonstrate proper practices. Add a back-link to it to W3C for verification.
And I don't usually like to bash languages (all right, I have fun poking fun at Java every now and again), but it seems to me that the fact that this is happening a lot with ASP and MS servers suggests either a large pool of dummies using those technologies, or the technologies themselves being horribly inferior to the open alternatives.
PHP and most other frameworks have various ways oif diosabling SQl injection attacks.
In PHP you can set an SQL escape global setting and if that doesnt work there are numerous functions to clean up entered strings.
Failing that ORACLE and most other databases supply an SQL escape function/option.
Failing that how hard is s/;/\\;/g s/'/''/g ?
I am afraid this one is totaly down to developers not understanding the consequences of thier lazy coding styles.
Personaly I always "prepare" and "bind" which are bulletproof and perform better anyway.
I'm curious about how you plan to prevent the server executing valid sql that is passed into it. You could do it by seperating raw sql from stored procs (at least that is one common way) - the only thing then to make sure is that the user that the application connects as only has the rights to exec the procs, not rights on any other objects.
Most rdms have this, but the chances are that if sql injection is going to get anywhere the lazy devs have the app user running with massively escalated rights in the database - more often than you might believe they are running as sysadmin level.
The point is that there are best practices to minimise the risks, and they are not being followed. Any more clever tricks you add to the best practice list will almost certainly also be ignored.
From the article, the code "does not spread on its own, it relies on the Asprox botnet in order to propagate to new hosts."
There are many biological infections that require several hosts, at different stages of their life cycle. Liver flukes, for example, have two distinct phases of their life cycle, one in water snails, and one in mammals (including humans).
As more technologies open up, and traditional peer-to-peer transmission vectors become less effective, I predict that we will see this kind of thing more and more. Here, we see a two-phase life cycle, with the client PCs infecting the servers, and vice-versa.
"The point is that there are best practices to minimise the risks, and they are not being followed. Any more clever tricks you add to the best practice list will almost certainly also be ignored."
yes I agree with this. I think that much more responsibility must go to the developers of the databasetools. The reason is that those tools are marketed to relative IT novices with "anyone can now make a online database using our "easy to use tools". This means that the type of development that 20 years ago required competence in networked database systems and associated security issues is now done by people who have very limited competences in this area. Is this a problem? Well it should not be. When it comes to areas of technological development it is common that as technology is developed the demand on the users of this technology in understanding the technical aspects of it goes down. This is not a problem as long as it is remembered that while the user of a car has to know how to drive the car she does not have to be an engineer to secure the car. When it comes to design of databases - the responsibility for what the database does should be the web designers - the responsibility for much of the underlying security issues must be put on the designers of the database tool itself. Ofcourse this will not solve many common security issues - but it should solve many important security flaws that today are seen more often than not.
Its easy enough to simply use stored procedures and never have to worry about SQL Injection attacks again.
That said there are ALLOT of developers out there who don't even know what an SQL Injection attack is. One of my friends, I self taught php / flash freelancer, was in shock after I showed him how vulnerable his sites where to this kind of attack.
>Apparently, H2 has an option for this, called "disabling literals".
Well, it's something I suppose.
The problem is developers generally building up entire queries with bits of strings rather than using the prepare/bind/dbquote type mechanisms that always exist.
It's probably down to many sites being built by poorly trained junior developers rather than having an experienced lead, the total absence of code reviews, and tight deadlines.
I dont think its a problem inherent with using ASP, as the article makes no mention of .net its likely that ASP "classic" is the main target, and i would hazard a guess that one of the main searched for pages to inject SQL into is from the OS Snitz Forum project, which has numerous published vulerabilites with no update since 2006.
The main problem here is with lazy developers, a language (and that is pushing the deffinition tbh in ASP's case) that hasnt been updated in 7 years (all ASP dev at MS stopped with the release of ASP.net) coupled with improper practice being followed.
Although this is most deffintatly not a ASP exclusive problem. any web facing system with inadequet input filtration and screening is vulnerable. ASP's weakeness here is that virtually all encryption and input filtration is left to the developer to impliment. At least PHP has magic quotes and built in md5 but then php5 is 2 versions ahead of the last release of ASP (3.0) but significantly behind ASP.net 2.0 and 3.5 imho. However it is possible to construct parameter based sql queries in ASP which can go a long way to stopping this sort of thing, and is a lot better than php's 'sprintf' function, as you can kind of impose data typing onto the input using ADO and db column types.
Finally several security features are often disabled or unaccessable to a developer when using a shared hosting environment, stuff like custom error pages, so that db struture cannot be gleened from an ADO error or having the ms access db being accessible from the web, in my experiance often with directory browsing enabled as well :(, that really is the responsibility of the ISP in those cases.
I"m not sure, I don"t think that will work. What if I"d entered text with apostrophes in?
Or if I put in \; it"d be escaped to "\\;" which will give me my semicolon back again.
Just use the escape function, the db api always provides one.
It's language independent, I can attempt to build up a query string from user supplied text in assembly if I were mad enough.
There is nothing wrong with IIS, any specific breed of SQL or language used to script the website.
All (and I mean *all*) SQL injection errors originate in application passing not satinized user input to SQL, and *all* platforms with database backends *do* provide functionality to do both : pass not satinized input to SQL or satinize it beforehand.
It is "web developer" choice not to satinize user input, and it does not surprise me, as many of them are as ignorant as it goes. The question whether "web developer" knowing only PHP, HTML and basics of SQL is real programmer had not been answered yet.
I've seen some horrible programming mistakes made by people who have just come off Java training classes then being given the job of writing J2EE applications to the best of their ability.
Surely, it's down the the employers to ensure that their coders have adequate training and adhere to programming standards that they publish. (And possibly enforce by sensible use of tools like JUnit and Cactus)
As usual, if you think training/education is expensive, try ignorance.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
