Slashdot Mirror
New SQL Injection Attack Fuses Malware, Phishing
PainMeds tips a recent post in Secure Computing's research blog describing a new SQL injection attack that had infected thousands of MSSQL-based web servers by last weekend, turning them into malware delivery systems. The attack apparently rewrites the server's Web pages to include JavaScript which pushes malware to the visitor as if it were from the genuine site. Sites using Sybase might possibly be vulnerable, as it uses the same exploited syntax that MSSQL does. The post includes an example of the attack. Unlike most malware attacks, this one appears to originate from the site the user is actually visiting. From the blog: "'Similar to phishing, this attack takes advantage of the website visitor's trust in the site they are visiting. Instead of phishing for information, however, malware is sent to the client, which the client has a higher likelihood of accepting being from a trusted site... These web pages are associated with Web sites from around the world and supplying various content — including government sites, sales sites, real estate sites, and financial information sites among others."
echo 'show tables'|mysql slashdot|awk '{print "delete from " $1}'|mysql slashdot
Comment removed based on user account deletion
malware + phishing = phalware?
No wonder my dogs are always barking at the Squirrels.
If you can read this, I forgot to post anonymously.
Anyone know of a good way to scan through all databases and tables on a server to search for any code? Currently I know 'we' have around 200 databases with over 10,000 tables total. It would be bad to see any of these DBs compromised.
No I didn't see this coming you insensitive clod.. I'm blind.
I saw attacks that were the same as this 1 month ago in our webserver logs
Our web apps got hammered with this over the weekend... our simple but effective SQL injection block kept them out, but it is also comforting to know that even if it had not, it would not have worked on good ol' MySQL 4.1
Also, for what its worth, all of the IPs (100s of them used in the course of 3 days) trace back to ISPs based in Beijing. Hmmm...
Although this isn't really new why do SQL injection attacks still occur. There are countless articles on how to protect yourself. Or do the webmaster simply not care?
UPDATE management SET perf_review='Epic Fail' WHERE jobtitle='MSSQL Engineer';
Tubal-Cain smokes the white owl.
Why is using stored procedures so taboo. It is a very easy way to protect against most SQL Injections. It also allows you to share the database logic to different apps as well, allowing more integration across your other apps. update x set x.y=@varname where x.j=@find is so much more secure then sql_exec("update x set x.y='"+varname+"' where x.j='"+find)
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
Yes, nothing new at all...
People used to do this by compromising the site in other ways, and inserting their malware rather than defacing the site... Some subtle malware tagged to a site is a lot less obvious than a blatant defacement so it lasts a lot longer and gets more hits.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
This attack has been going on for months... http://hackademix.net/2008/04/26/mass-attack-faq/
You don't need a weatherman to know which way the wind blows.
We were added to the attack list a few weeks back, and one of our largest, most popular websites was hit. Apparently, the developers had never thought to sanitize their data, and we had multiple vulnerabilities throughout the site.
I implemented a transparent reverse proxy server running Apache with mod_security that helped prevent further attacks from getting through, but the developers finally saw the error of their ways and converted hundreds of inline SQL calls into stored procedures.
Since we were added to "the list", I've been seeing the same attack happen across multiple pages every 20 seconds, so they are definitely not letting up anytime soon.
Why do you assume all code is new. Many SQL Calls are decades old and were copied and pasted assumed what isn't broke don't fix. Not really taking into account that the interface is not controlled by the server anymore. But can be easily altered by the client. being that the bug is threw Microsoft SQL there is a higher chance that it is threw Mr. Certified .NET Developer who knows .NET but has now clue on how the web works so he assumes that if he puts a size limit on that textbox or make important fields hidden he is safe. As well a bunch of people have a poor understanding on how to use SQL, they just think it is bit more optimized version of a flat file. Where the hard stuff are using joins. So they figure well this data isn't that important.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
You may want to rethink what you know about modern-day Javascript after reading this article.
Excerpt:
addendum: constraints often occur too they work to get a proof of concept and run out of money to harden their code. In theory they should have harden it before hand however, sometimes those methods get in the way of proof of concept testing, and their not paid for that. Also there is a huge number of developers who have no idea about SQL injection errors they just never thought about it before. Not all developers are on top of their game. They go to work and leave, and don't bother to learn anything new.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
This trojan, called Asprox or Danmec, has been around for a few years. It was originally intended as a Spam distribution system but I believe that sometime in 2007 an SQL Injection tool was installed via its botnet. It has been doing the rounds every so often on the Internet since at least January.
http://blogs.zdnet.com/security/?p=1122
http://www.secureworks.com/research/threats/danmecasprox/?threat=danmecasprox
-dZ.
Carol vs. Ghost
I just looked and see this in my logs too; looks like they started on August 6 over here.
What's funny is that it looks like they're trying the attack in pairs: once in the "classical" quotation mark form (GET /index.php';SQLCOMMANDSHERE) and then again without the quotation mark (GET /index.php;SQLCOMMANDSHERE). How is that second form supposed to get executed? They've gotta be trying it for a reason.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
Die mund halten!!
I saw a post in the "best of" section of craigslist from early July that described the same attack from the article. The victim included some great documentation of the attack: http://www.craigslist.org/about/best/bos/742662737.html
Comment removed based on user account deletion
Users of Microsoft operating system who use Microsoft's browser may be at risk from malware served by infected Microsoft servers.
Comment removed based on user account deletion
There is also deliberate gross misconduct. A lot of the code is written by outsourced divisions, I-9 lackeys, or contractors who will be long gone by the time someone discovers the SQL injection bug. Most companies don't pay for audits of their Web code, nor do they care to.
Sad thing is that MS is doing their best to prevent this, but they still get blamed for what their customers do (or fail to do.)
Sure, blame the coders... we're partly at fault here, but a bigger piece of the problem is that such arbitrary code is allowed to be executed at all, with no way to disable it.
You can restrict queries, but there's no option to disable EXEC. That, to me, is a grave oversight. What's worse is the SQL folks sternly refuse to implement such a feature.
-Billco, Fnarg.com
It seems with each passing year that the web is becoming more "broken".
Perhaps the problem is too many groups are attempting to use it as if it is a fail-safe system - banks, corporations, financial institutions, governments. It was never designed to be fail-safe. Frankly if they had treated it more like a the "wild west web" and less like a "cheaper and easier platform for advertising/cost-cutting" then we wouldn't be in this mess.
Answers on a postcard as to how to fix it.
They're just inserting the javascript directly into the websites's content, instead of putting an iframe to a hacked server to then run the javascript...
No, they're still using a central location. It's only a script tag instead of an iframe. Same idea though.
You'll have that sometimes...
I can't wait to see how many posts will bash Microsoft for the 'obvious' vulnerabilities they left in their SQL Server product..
I went to eat some animal crackers and the box said, "Do not eat if seal is broken." I opened the box and sure enough..
I've seen it done before to generate backlinks for spam websites. They'd hack several websites via sql injection and insert "hidden" links to the sites to gain search engine ranking.
"Ubuntu" -- an African word, meaning "Slackware is too hard for me". - stolen from Dan C alt.os.linux.slackware
Don't blame the contractors, If they mess up it is usually do to bad management on the company. Having worked as a contractor/consultant I can tell you when there is good management at the company I produce really good work. When there is bad management my work isn't that great. The case of leaving a bug and being long gone has a flaw. Because people want return business and a good name. Doing a Hit and run of coding doesn't allow for a good professional credentials. But with contractors they are often under the gun far more then W2 employees to be cost efficient, any work they do needs to be approved as the company doesn't want to pay for extra non-speced work, and if that spec doesn't cover SQL injections or security and they do the right thing and bring it up, bad management will say it isn't an issue and just do what is speced, thus causing the problem. If they did go and take an extra 4 hours to make it secure they will not get paid for it. If the manager was smart and listed to the advice then good quality code can be released.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
http://www.bloombit.com/Articles/2008/05/ASCII-Encoded-Binary-String-Automated-SQL-Injection.aspx
I'm afraid to say any more but I may have invented this hack, but it was for a marketing company in 1998 so its okay. :)
Agreed.
http://www.rtraction.com/blog/devit/sql-injection-hack-using-cast.html?f_src=darkreading_section_318_320
http://www.oreillynet.com/sysadmin/blog/2008/07/protect_your_database_from_you.html
No. You're right. This isn't "new(s)" at all. I was blocking against this at least 4 months ago, if not longer. Anyone silly enough to not parse their Querystring data before allowing it to be executed against the database *will* be impacted by this.
On the upside, the SQL used in the injection (convered to Hex) was pretty impressive. These micreants ought to get a day job...
TD Canada Trust (one of the largest Canadian banks) had one of their servers infected by this virus for at least 48 hours before taking the server down. I tried through a few different channels to get them to notice they are infected, but it took a day of effort until they reacted. And they decided to not alert their visitors that there had been a problem. In my world, a financial regulator would be all over their ass about something like this. You can see gory details at http://blog.cognistudio.com/
I can't wait to see how many posts will bash Microsoft for the 'obvious' vulnerabilities they left in their SQL Server product..
Man, that is sooo late 90s and early 00s.
/. is becoming a platform independent idiot basher. Whcih is good; in a way. Unfortunately, they don't take into account that folks are human; many times they're hired for one thing and then have go and develop or port an app to the web; are trying to learn new skills and screw up a web app because they've been developing corp intranets for the last decade and that's all they've been doing; /. posters are geniuses and they would have NEVEER made such a stupid error regardless of platform; all proprietary platforms are evil and therefore promote such stupidity; some of us are great at the "big picture" and horrible with the details; some of are great with details but miss the "big picture"; did I mention that we're all human and fuck up now and again; and I ran out of things to say.
It doesn't even look like this is being passed in as a parameter. How come so many sites send the string onto the database? I think I'm missing something. Wouldn't the system just ignore it since it isn't an application parameter?
Are you serious? EXEC is a basic privilege in SQL. EXEC, Select, Alter, Create, drop, update, and delete are all basic privileges and can be enabled per user. Beyond that, individual stored procs can be disabled per user so this isn't really a concern for most of us who already secure their databases. I do the same thing on Oracle which also allows local commands to be executed through SQL statements if you allow the user to do it that is. As a dba for the box I have lots of reasons to do this but my application server users obviously don't.
WELCOME TO LAST YEAR. This sort of SQL injection - DECLARE/CAST/EXEC has been going on since last November.
-AutoNiN
Aw man, you're making me want to play Diablo II again. I remember it clearly, as Deckard Cain Said:
"According to HORADRIC lore the HORADRIC key can be made with HORADRIC alchemy by inserting HORADRIC staff and HORADRIC amulet into the HORADRIC cube. HORADRIC."
Ran into this recently on an old website on one of our servers, and there's an easy fix if your site doesn't have code requiring the use of system tables itself.
Simply deny access to syscolumns & sysobjects for whatever SQL account the website is using, as the attack uses those to do the table updates. This script can do it quickly:
declare @name varchar(200), @sql varchar(500), @type char(2), @tablelist varchar(800)
DECLARE sSysFiles CURSOR FOR
SELECT name, xtype FROM sysobjects where xtype IN ('s') FOR READ ONLY
OPEN sSysFiles
FETCH NEXT FROM sSysFiles INTO @name, @type
WHILE @@FETCH_STATUS = 0
BEGIN
IF @type = 'S'
BEGIN
select @sql = 'DENY SELECT, INSERT, UPDATE, DELETE ON [' + @name + '] TO [DatabaseUserName]'
EXEC (@sql)
END
FETCH NEXT FROM sSysFiles INTO @name, @type
END
CLOSE sSysFiles
DEALLOCATE sSysFiles
You should still of course do a code review for possible future modified attacks, but it's a quick & dirty to buy time.
Also, here's a script that's reversed from the attack code which basically reverses the attack - either shows all infections, or deletes their code back out (depending on what you un-comment). Warning: it does trim TEXT fields down to 8000 characters (although if you were infected, their code already trimmed them down to 4000), so use with caution.
USE [MyDatabaseName]
GO
DECLARE @CodeToReplace varchar(500)
SELECT @CodeToReplace = '' --If fixing code, put the offending script here
DECLARE @T VARCHAR(255),@C VARCHAR(255)
DECLARE Table_Cursor CURSOR FOR
SELECT a.name,b.name
FROM sysobjects a,syscolumns b
WHERE a.id=b.id AND a.xtype='u' AND (b.xtype=99 OR b.xtype=35 OR b.xtype=231 OR b.xtype=167)
OPEN Table_Cursor
FETCH NEXT FROM Table_Cursor INTO @T,@C WHILE(@@FETCH_STATUS=0)
BEGIN
--Uncomment next line to just show possible infections:
--EXEC('IF EXISTS (SELECT TOP 1 * FROM ['+@T+'] (NOLOCK) WHERE ['+@C+'] LIKE ''%.js>'') SELECT '''+@T+''' [Table Name],'''+@C+''' [Column Name],['+@C+'] FROM ['+@T+'] (NOLOCK) WHERE ['+@C+'] LIKE ''%script %''')
--Uncomment next line to fix them:
--EXEC('IF EXISTS (SELECT TOP 1 * FROM ['+@T+'] WHERE ['+@C+'] LIKE ''%script src%'') UPDATE ['+@T+'] SET ['+@C+']=REPLACE(RTRIM(CONVERT(VARCHAR(8000),['+@C+'])),''' + @CodeToReplace + ''','''') WHERE ['+@C+'] LIKE ''%script src%'' AND LEN(CONVERT(VARCHAR(8000),['+@C+'])) 8000')
FETCH NEXT FROM Table_Cursor INTO @T,@C
END
CLOSE Table_Cursor
DEALLOCATE Table_Cursor
Many SQL Calls are decades old and were copied and pasted assumed what isn't broke don't fix.
All too true. My company maintains some sites that were originally written during the 90s by a different web consulting company. The sites were happily chugging along and serving up pages for upwards of 10 years, until last weekend when they were hit with the exact attack described in this article. Fortunately, the attack was noticed early and we were able to fix the problem quickly, resulting in a minimal impact on our client's users.
I wasn't involved much with the emergency fixes, but our team ended up installing a product called dotDefender that seems to have done a fantastic job of filtering out malicious requests. It inspects GET and POST data _before_ it's passed on to the vulnerable application and stops the request if it detects things like SQL injection, cross-site scripting, directory traversal, or other attacks. If you use IIS6 and have a lot of vulnerable code; or, like us, some of the bad code is contained within compiled libraries for which you don't possess the original source, I'd definitely recommend checking it out.
Alternatively, there's a free ISAPI filter that will perform similar pre-application-level checking of GET and POST data, though I believe it only checks for SQL injection, and I can't vouch for it since I've never seen it in action.
Unfortunately, I don't believe either of these solutions work with IIS7, so if your sites run on IIS7, I wish you luck!
@ASP.NET's parent-teacher meeting: "Little Johnny.NET is very bright, but he doesn't play well with others."
From TFA:
If this means that the browser allows malware to actually be installed without user intervention (which is implied by 'the client trusts the site') that implies that this is taking advantage of Microsoft's "Security Zones" trust model. Which should mean that this exploit is only applicable to Internet Explorer.
I think we just passed the 11th anniversary of Microsoft creating this flawed security model. Would it be too much to ask that Microsoft finally backed down and gave up on the idea that it's possible to build this kind of exception into a sandbox without unconditionally and irreparably compromising basic security?
deny select on sysobjects to WebUserName
Don't blame management. If you were asked to make a kid's toy, would you ask 'do you want it the safe way, which will cost an extra $5 per unit, or do you want the cheap way?'.
You are a professional, it is your job to produce software that meets professional standards. If others screw up, fine, but don't deliver an unsafe product just because nobody told you to make it safe.
You've never actually held a real job, it would seem.
You can restrict queries, but there's no option to disable EXEC
If more database-accessing code used stored procedures (and hence EXEC) instead of arbitrary queries, the database parts would work faster and there would be less likelihood of this type of attack working.
It's *possible* to write a stored procedure that's vulnerable to SQL injection, but it's a lot harder than writing a plain query that is.
"...always new atoms but always doing the same dance, remembering what the dance was yesterday." -Richard Feynman
i dont know what mssql is all about nor do i have javascript turned on usually (im using w3m anyway most of the time), but it seems im getting my revenge now for all the wasted hours of my life ive been spending with the windows2000 installer. there must be gods...postgresql anybody?
I just wish these bots would attempt to identify their targets first. I hate having microsoft specific attacks in my access_logs!
And its usually developed by a bunch of noobs that decide they fall in the "enterprise application" category.
So the inbuilt data-binding crap will not be good enough for them! Also the cost of a $500 ORM product will be "too expensive" and... um "wont scale" or "we can do better in house" (shitty code generator ahoy).
End result is a bunch of code-generated epic fail, completely vulnerable to all sorts of code-injection, inflexible, and runs like crap.
All this because they couldnt suck in their pride and use the VS integrated crap for noobs, or drop the $500 on something like Diamond Binding.
(Course, neither of those prevent XSS style attacks, but ASP.Net has a nice annoying setting that by default bitches about HTML tags in postback data.)
Its just noobs doing what they do, running around with big egos, inventing the hell out of the wheell
3laws: No freebies, no backsies, GTFO.
Bingo. If it takes this hypothetical 4 extra hours to make you application secure, you should have quoted 4 extra hours, and if you didn't it's your fault, not your client's.
Under MSSQL its a myth that stored procs are faster for basic CRUD tasks (they may even be slightly slower). In summary
* Any 'arbitary' queries should be parameterized anyway: "set foo = @foo" style, rather than "set foo = 'foo'". That gives the same level of protection as stored procs from injection.
* Arbitary queries go through the execution plan cache since v7, so they are just as fast.
* Security has to be done per-table c/r/u/d, rather than per sproc. (No real difference here IMO, but sprocs do give you finer grained control).
I tend to access data using a tool called Diamond Binding anyway, which is based on NHibernate - and the performance benefit of the flexible queries it can do far outweighs the more traditional CRUD sproc layer. (Pulling back say a customer and all addresses in one go, for example).
Don't knock the flexibility of the ad-hoc query ;)
3laws: No freebies, no backsies, GTFO.
I can see those in my webserver's logs dating back to 23rd of July:
Oh, and the hexes decode to:
(phew, I'm lucky to get that through Slashdot's filter!)
You can easily decode that from your webserver logs even on MySQL, just take into account the different CAST syntax:
This assumes you're not billing by the hour, which I ALWAYS do, for this exact reason.
I give estimates, but they're estimates. In the end, a job takes as long as it happens to take. Others do things differently but to make the assumption you made in your comment seems to show a lack of understanding of the market.
I'm going to say you're likely in the same category as the parent and haven't actually done much serious consulting work, although I'm wiling to be wrong.
www.clarke.ca
Amen. I'm not going to name names here, but I've fixed two sites so far for clients who got hit with this worm. In the one case, soon after I got there, before the worm came out, I did an informal and mostly unasked-for security audit and found the site was open to SQL Injection attacks. I dutifully notified management and proposed some solutions, and nothing came of it. I brought it up once or twice more and made sure there was a written record of my suggestion, but still nothing came of it.
:-/
Once the site got hacked, I fixed it, and I closed the entry vectors. It should be obvious that this isn't how I PREFER to work, but I'm not going to stick my neck out and do work that wasn't approved and risk not getting paid for it either. It does make them more likely to listen to me next time I notify them of a security problem
In the other instance someone saw one of my ads and phoned me up that their client's site wasn't working. I was able to deduce the problem within a couple minutes and fix the issue quite quickly which made everyone very happy.
I should add that in neither of these cases was the original compromised code mine!
www.clarke.ca
Mr. Certified .NET Developer who knows .NET but has now clue on how the web works so he assumes that if he puts a size limit on that textbox or make important fields hidden he is safe.
That reminds me of a time when I was asked to help someone add a new feature to a set of reports generated on an internal web app. I take a look, and discover that this system works by generating SQL statements based on the form fields in client-side JavaScript before loading them in a new window via window.open. So you had ?sql=SELECT+*+FROM+TABLE sitting there for all to see.
Checking the JSP (it's not just .NET devs) confirmed that it was just blindly passing whatever it got to the database and essentially dumping the resulting data as an HTML table.
I tried to explain why this is a bad thing, that anyone can run any SQL statement the want through the address bar. And he agrees, that's a bad thing. Fortunately, he immediately saw the solution:
Pass the SQL statements with a POST.
Eventually I was able to convince him that, no, POST requests aren't magic and yes, people can, in fact, create arbitrary POST requests.
You are in a maze of twisty little relative jumps, all alike.
Like I said, the 4 hours was hypothetical. It was the amount of time the grandparent had mentioned in his post. If I were doing consulting work (I've been on salary for the last couple of years), I couldn't imagine a circumstance where I wouldn't bill 4 hours over my estimate. If your estimates are so far off that your clients won't pay actuals or you're uncomfortable even billing them then you're obviously inexperienced, and that's part of gaining experience. Sorry if I threw you off there.
My point was that you should be planning to build your application right from the beginning, and saying a client or management didn't ask for it to be right is just making excuses for your own incompetence.
You sound like a very competent developer. Too bad you will never contract at the company I work for (and many others I know of) because the management can't be convinced that using fixed bid doesn't limit liability. They continue to bid out work - fixed bid only - pay for that project, get a pile of garbage delivered, then pay more to get it fixed. I've given up that fight a while ago.
878659 - yep its prime.
Another one about the old bugs floating out of the void... Please vote :)
http://slashdot.org/firehose.pl?op=view&id=803927
As a contractor myself, here's how that scenario sometimes goes:
* Client requests bid for web project
* I produce bid for web project, allowing for secure practices
* Client thinks bid is "high", requests task itemization
* Upon further review, some involved employee of client asks "What would this part cost without all that secure coding stuff?"
* Regardless of my answer, the client responds "We don't need that, redo the bid without it"
* Attempting to "hide" the extra work in the itemization is dishonest, and the likely result is that someone else will get the work, or the client will decide not to do the work
* I can turn down an otherwise good contract, or I can produce insecure web pages; nice choice, that
Sometimes the best you can do is document the client's intent to cut corners.
- T
And that's why all the toys these days are coming from China... where there's allmost no quality control etc... because they want these toys the cheap way...
The "feature" of MSSQL that allows compound statements separated by semicolons, without any sort of begin / end block, makes it particularly vulnerable to this type of SQL injection attack.
This type of attack requires more than just modifying a where clause or changing a value - it requires injecting one or more complete statements. MSSQL allows you to begin a new statement in the middle of any unchecked parameter. Most databases don't. That is why MSSQL is unusually vulnerable to this sort of attack.
Oracle applications with unchecked parameters (for example) are difficult to exploit this way because compound statements must occur in a PL/SQL begin end block and it is usually impossible to inject text at both the beginning and end of a statement.
See this post as to why I don't do fixed bid work.
Also, I'm regularly turning away work as it is, so why should I spend hours and hours of extra time bidding out jobs that I don't have time to take anyway? I just tell clients that I work hourly, and if they're OK with that then we move on.
Granted, I'm never going to make huge extra profits this way, but overall I think it's fairest to everyone. If the client wants, I give a range of what a project will cost with a low and high cost, and if my costs start to get up to the high number I let my client know.
www.clarke.ca
Now we know whose dream it is.
The Future of Human Evolution: Autonomy
Comment removed based on user account deletion
Hi,
Try this www.radio3net.ro/1001 . it's a romanian site where u'll find the best 1001 albums to listen before you die. Most of the albums have videoclip, pictures and lyrics.
Even when you bill hourly there is always the risk they will not pay for work. ...cough...G..E..cough... if you are working hourly and they see you doing anything not in the spec they wont pay for it but gladly use it. What company's want is hourly up to a point then it stays at fixed price. They are fine hourly until you exceed the quote by 25% then they will try to get into fix price. You could refuse it but you will not work with them again or try to make a deal take a beating but still leave with something and the next round make a better quote, which is easer as you are a proven contractor.
Consultanting reminds me when I was in high school when I worked in a Hardware (Hammers,Nails etc...) store in one of their trade rags. There was an add They Lie, They Steal, They Pay their bills late... but they are your best customer.
These jobs is not all about making clean code. You can be the best programmer in the world but if the client doesn't like, trust, or can work with you. They will not come back to you. And will be happier with someone who is less skilled but works better with the customer. And you have to take not doing your best work vs. loosing the job. I usually on record mention that X and Y should be done however it is up to management to say do it or not.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
It's always the contractors fault...
The attack is ancient.
The method of delivery is a bit newer - a few months ago it all got a lot more efficiently delivered - it's pretty mainstream knowledge, even this article from the paper edition of SC Magazine talks about it - and their copy deadlines will be from weeks ago.
I had to clean up my one site that was sql injected with that js file. I hear its a b**** to clean up that trojan it downloads too, people are reformatting for the most part.
seems as if sql injections are becoming more and more popular these days. I heard some pages on Yahoo were affected with this as well. Crazy
for a few reasons, the biggest of which is that no one in their right mind would use ASE on Windows to begin with (thus probably wouldn't be running IIS)...
But seriously, ASE doesn't use xtype in such a way, nor do (most) of the (x)type ID's match up to meaningful ASE datatypes (the TEXT type IDs do match).
Anyway, ASE admins need not fear any more than Oracle or MySQL or DB2 or PostgreSQL or $DB admins; this script would have to be modified to run successfully on ASE.
Thanks,
--
Matt
I'm a contractor and I've worked on many programming jobs: from adding e-commerce to a website, to building scripts that handle password expiration and user deletion. As of recently, the company I contract through has updated the wording of their contracts to explicitly include extra time for bug-checking and security related testing (it's an abstract timeframe, I think they say about 20% over the time it takes to build the system, plus possibly more if issues are found).
Given that information, I think the problem is sort of with management though not where most of the above posts are pointing. I would say the management that isn't giving proper consideration to bugs and security is the company (or individual) setting up the contractual work. It should be implicit in the contract that extra time will be taken to guard against future problems. I would very much doubt that very many prospective companies would not give a contract based on that condition; doing so would be like saying, "we want it done fast and cheap, we don't want to worry about security." Of course, that may be the exception and not the rule... *cry*
Sanity is like a condom: rather have it and not need it, than need it and not have it.
This has been going on since last year. There have been numerous mainstream media and blog posts about it. Also calling this phishing is misnomer, the bad guys are injecting malicious content onto legitimate websites, not setting up a fake version of a legitimate website.
TFA doesn't mention nearly enough details.
This comment is my opinion and does not represent an official position of Donald Trump or others I do not work for
Sometimes the best you can do is document the client's intent to cut corners.
True dat. But that street goes both ways. The assumption that a contractor needs client X and thus should do second rate work to keep their business is a fallacy. A common one, but a fallacy none the less.
Lets look at the big picture: You build site Y for client X. Client X wants to save a few bucks and opts to have you remove those useless "security" features. Site Y gets hacked. Client X is unhappy. Do they blame themselves? Ha! Contractor may be called in to fix he problem, but there's a good chance contractor has lost future business with client X. Client X may have friends and acquaintances in contractor's business area. Contractor loses good reputation with those people (who might themselves be good clients, but you won't know, you don't get the chance to work with them).
There are bigger issues at stake than a quick buck.
If that works for you, great. Power to you.
I'm not sure what we're debating anymore. I'm talking about taking pride in your work and basic professionalism and you're talking about billing models. Are you trying to use your billing model as a proxy to defend your right to deliver a sub-standard product? Or are you suggesting that binding estimates and quality work are antithetical to each other?
The syntax shown would not run correctly on Sybase Adaptive Server Enterprise (ASE), as opposed to MS-SQL. The difference lies in the way the statments are grouped into a batch: in this form, it's invalid syntax in ASE (though it would be correct syntax in a stored procedure in ASE, but that's just a few bridges too far here)