That is all.
More than 100,000 webpages, some belonging to newspapers, police departments, and other large organizations, have been hit by an attack over the past few days that redirected visitors to a website that attempted to install malware on their machines. The mass compromise appears to have affected sites running a banner-ads module …
This post has been deleted by its author
Banner ads have been one of the worst malware vectors for the last few years, at this end, so I always encourage people to use it.
It reduces the amount of crapware- also, vastly speeds up browsing, as the ad servers are often the slowest element on a page.
I'm not against sites using advertising as a way of funding development, but if they insist on a format that's easily abused and can be used to compromise my machine, I will use an adblocker.
Some of the sites I frequently browse seem to frequently get bad ads. Grr.
to the developers of these sites. A day doesn't go by without hearing about more sql injection exploits. Just take at look at xssed.com as an example. And it'll be high up on the list of programming errors on sans.org and owasp.org's top 10 security vulnerabilities, I'm sure.
"Shouldn't this sort of thing (injection and execution of an abitrary set of commands) be filtered out before any further processing of the text string involved?"
It should. But data validation is one of those ares to squabble over. Is the web designer or the data base people responsible? Web designers tend not to know much about validation and assume the DB is bulletproof. Besides it might slow down response and we wouldn't want to damage the "user experience" would we? If it's not clear who *is* responsible unless someone actually *manages* the project the odds are excellent that *no* one is responsible.
Repeat with as many websites as necessary.
"But I don't understand why an SQL command passed in a SQL command fools the database's engine"
It doesn't fool the engine at all. A SQL injection attack fools the web server process into passing two (or more) commands to the database engine. The database engine simply executes the commands it's given.
I have a full proof of this, but this comments thread has not enough room for it. Besides, there are more that enough resources on the web to find the answer you seek.
The first time I saw a string resource with printf() flags inside it I was scared. That would be back in the late 80s. Admittedly I was concerned with program stability rather than security but even my young teenage brain could see the danger. Sadly even that kind of idiocy still goes on. At least with C# the risks are mitigated but I still don't like to see it being done.
As for web stuff - meh. They aren't proper programmers anyway.
How many times do these things need to happen before developers and admins wise up and dump Microsoft products. If this was a programmer's error, why would 100,000 sites have the same mistake. It is inherently poor product design that continues to plague users of Microsoft products.
Nothing is 100% secure but open source seems to have more people examining the code to make sure these problems aren't pushed out to unsuspecting users. Microsoft and other commercial products are too focused on protecting their intellectual property.
it shows up O'level IT skills ( that's MS Revered Partner or something or other).
Never allow a web site (or app come to that) to call a piece of SQL - always run a stored procedure or a function - that way not only can you implement some decent security* and still get some development done but if you should actually happen to write something useful you can change it behind the scenes without having to re-write everything else.
* not sure about MSSQLServer but most mickey mouse db's can do this.
It's been a couple of years since I did any web programming. But if you bind the parameter to a placeholder, then it doesn't need to be quoted, e.g.
my $stmt = $dbh->prepare( 'SELECT name FROM users 'WHERE email = ?' );
$stmt->execute( $param );
You can do that in PHP, can't you?
Biting the hand that feeds IT © 1998–2021