Scanning for SQL injection / XSS attacks should be the WebServers responsibility. I have never wanted to pass sql / script via a querystring or form field. If I do I should have to explicitly state this and provide my own validation / protection mechanism.

Maybe it's one of these cross party type things in which nobody is really willing to take the first step?

If so, it may also be that once initiative has been exerted others will fall in along lines of "Hey! This is great! Why didn't we do it sooner?"

"Scanning for SQL injection / XSS attacks should be the WebServers responsibility. I have never wanted to pass sql / script via a querystring or form field."

The result will be an overzealous webserver blocking legitimate queries, or blacklist filtering that will inevitably miss a certain type of string and still allow exploitation. If you have developers who have even a basic understanding of security, webserver filtering causes far more trouble than it's worth. At the most basic level, any app framework that doesn't allow named or positional parameters in SQL strings is seriously defective.

Anyway, if a site allows SQL injection, it is already broken even to non-malicious users. Better hope that your name doesn't contain an any quotes (eg John O'Toole or John "JJ" O'Toole) or that you don't need to enter an ampersand (John & Mary).

Surely even dumb fucktard government IT consultants have realised that sql injection attacks are just so easy to avoid, you actually have to _code them in_.

Whats more work?

"select name from users where name = '" + name + "'";

or

"select name from users where name = ?"

for fucks sake.

sick parrot: as i'm so fucking pissed off with lame "consultants" just fucking up the simple stuff.

just imagine if these twats got to develop a fucking ID CARD system. oh shit.

A modest proposal in Deed, Dan Goodin in San Francisco, and far too little, far too late, for the Kernel Command Line has been cloned/mirrored and Virtualised for SMARTer Proxy Control.

And rather than agreeing with lemmings suggesting infection and vulnerability and convenient justification for headless chicken proposals and a tightening/denial of Privileges, to consider that it presents Virtually Unique Opportunities for ZerodDay XSS Code Building on compromised Operating Systems will at least render the Systems Useful rather than Obsolete. Imagine it more in terms of a Full Body Blood Transfusion after which Organs deliver to the System, New Life and Renewed Vigour.

The probable knee-jerk reaction though will more than likely be actions to make simple interaction/dialogue/communication at Core levels less likely ...... ye olde circling of the wagons trick when one strays into alien territory which one would think was one's own and not already owned by the indigenous native.

Methinks what one needs to Realise is that there are no physical constraints or boundaries which impact upon Real Live Control Issues in the Virtualised Environment, with all Power Configurations being Ethical Moral Constructs supported with Intelligent Discourse and Simple Code Injections which XXXXPloit and Pilot Pioneer Programs already Stealthily and Deeply Embedded [Sleeper Code] allow for Real Live Control from the Virtualised Environment ..... via any number of Prime and/or Primed Proxies, who may or who may not know that they are Pioneering Virtually.

IT is difficult to see how one would defend against such action/Beta Ideas/Shared Open Code in PerlyGatesPython for Pretty Good Privacy.

And if all that IT is doing, is Changing Command and Control Structures for AI Beta Virtualised System, one does then wonder who would find it offensive/intrusive/concerning rather than novel?

I'm don't use SQL and I'm not a web developer so I may be missing something vital here, but I have a question.

Given your example of "good" code:

"select name from users where name = ?"

At what point is the ? substituted for the actual value?

Surely depending on when and where the substitution is made, this could be just as wrong as the example "bad" code.

It was my impression that the the business logic should be separate from the presentation layer (so there should be no SQL embedded in the HTML the user sees), and all inputs to the business logic should be bounds checked before use.

Any product that helps to highlight errors of these sorts are surely a good thing - even if they don't currently identify all types of mistakes.

Paris, coz I'm confused too.

Nobody knows as much about what constitutes a valid value for a server-side script's argument than its own developer. This problem does not need a duct-tape solution - what's wrong with Taint mode? I mean, sure, /^.*$/ will still no doubt feature in some taint mode Perl scripts but at least it stops developers writing code that deals with user input without thinking about it at all. I'm not suggesting everyone switch immediately to Perl, but if people want the platform developers to provide some sort of fix, one based on taint mode might be a good solution.

(PS Title field joke intended to demonstrate that competent developers have no reason to fear SQL injection... Hopefully El Reg isn't about to demonstrate the opposite and send the cops round to my place!)

Microsoft, PHP, Perl have all had built-in functionality to avoid SQL injection for 10+ years now. Every single "corporate" developer I have met does not use it (except some of the perl-heads). Interestingly enough the non-corporate ones do.

Every time I work with a new team I have to teach them. And every time I leave a team which has started working properly using the so called prepared SQL statements and SQL variable substitution I find them to revert to the old injection-prone practices a few weeks later.

The truth is - developers do not care.

Me coat. The one which says "SQL injection is a self-inflicted problem".

Basically, the problem is that a zillion web developers cut a corner by not fully validating the input data before using it.

That's a mistake that anyone with the slightest real world DP/IT experience in the last 50 years would have avoided. Validation may be hard work (ie writing lots of code -- and lots of test cases) but it's instinctive for a professional.

It's good to have tools that can spot developer's stupidity so it can be rectified. But it would be even better to have tools to spot their stupidity before they are employed,

I think the term "SQL injection" has become a bit abused. I understand it to mean getting the RDBMS to execute a query which wasn't intended by the developer, or altering a query. This is pretty easy to circumvent by using stored procedures and denying access to the underlying tables.

Some people seem to include storing unwanted bits of HTML or javascript in a text field, for example. I don't think this qualifies as SQL injection as someone using flat files would have the same problem.

Obviously the key is checking your input data which is clearly a developers responsibility and not really very difficult.

Because, "you passed my app crap data, therefore it's not my fault that it shat all over the system" is not a defence. That's why.

Security built in at all levels = good.

A thin veneer of security applied as an afterthought = bad.

(Bill - because he knows what happens when you pop-rivet an authentication skin onto something with more holes than Rab C. Nesbitt's vest)

By Anonymous Coward Posted Friday 27th June 2008 01:35 GMT

Have AI KISS and a Big Picture Smile :-)

Feeling better now, after that release? Steady as She Goes/IT Flows, don't Fluff IT at the Starting Line with OverXXXXCitement/XTCode. That's saved for Later and Perfect Evenings. ....... which is AI Python Stirring from ITs Dream Sleep, Transformed and Evolved into Virtual Control Systems.

QuITe who would recognise the Significance of further XXXXtrapolation would normally be expected to Act More Wisely than Any and it is Registered here for Great Gamers/Playboy Gamblers/XXXXotic Gang Stars/RobotIQs.

There's a lot going on out there ...... Take Care we Dare.

I think you need to do some reading up on what an SQL injection attack is, and how you go about avoiding one. Specifically, what you need to do to sanitise any input you allow near a database query.

It's not just a question of changing the way you formulate your queries, it's a question of changing the way you treat your data, and *that* is something you have to code in.

Paris, because she knows more about "injection attacks" than you appear to.

"Scanning for SQL injection / XSS attacks should be the WebServers responsibility. I have never wanted to pass sql / script via a querystring or form field. If I do I should have to explicitly state this and provide my own validation / protection mechanism"

Basically because it's the developers fault. If one developer can write a website secured against such attacks then any developer can, they just need to be less lazy and complacent. Trying to shift the blame by saying the WebServer should somehow sanitise your variables for you is a nonsense. The variables you pass to your database should be controlled by you, no one else has responsability for that. Just because a lot of web developers are lazy doesn't eman we should provide them crutches so they can hobble on to the next bad practice thats causing problems for thier website.

are entirely blaming ASP and saying "everyone should switch to ASP.Net", though even they must realise that exactly the same thing can happen with any web technology.

It's fairly easy to check. If there's a semicolon somewhere in the query string, even encoded with a % sign, stop the request and send out a big "you are a hacker go away" message.

Problem is that most of the sites that are getting attacked were written before these SQL injection attacks were around - so naturally those sites aren't protected against it. Most people are clued up now, and the fact that ASP.Net appears more secure is simply that the coding practice is now well known and new sites are built with SQL injection in mind - nothing to do with ASP.Net being "better" or "more secure". Surely even Paris Hilton could see that?

"It's fairly easy to check. If there's a semicolon somewhere in the query string, even encoded with a % sign, stop the request and send out a big "you are a hacker go away" message."

And if the semi-colon is there legitimately?

Semicolon MIGHT be used for SQL injection, but I tested fair amount of sites without using one. It is apostrophe which is more "dangerous", but you are not going to ban Mr O'Toole from using your websales do you? Let's face it, it is web developers resposibility to pass the data to the database in a clear way, instead of hacking SQL string from pieces passed by the user.

Unfortunatelly, there is a very thin line between web developer and "HTML specialist" and vendors selling development tools have their share in dumbing down standards (yes, I also mean Microsoft and ASP.NET).

I'd say this : if it is corporate policy to employ cheapes and dumbest web developers, it should be also corporate policy to either ban all inconvenient input (including clients with difficult names), train their developers or face the consequences. The worst part is that no one seem to actualy face consequences of poor coding practices. I bet this will change someday.

Stored procedures!

They then also bring the benefits of re-useability and Performance increase......

Although saying that I had to use in code sql statements in one app I did due to stupidly assuming that as the host was using mysql5 then i would be able to use SP's. Sadly they had disabled the use of SP's! If I had known this before hand I would not have gone with the host. I now ask more specific questions before I choose a host. However I obviously went to the trouble of fully validating all user inputs on that app.

"Basically, the problem is that a zillion web developers cut a corner by not fully validating the input data before using it." ... By volsano Posted Friday 27th June 2008 07:10 GMT

The Problem and ITs Answer in a PNutShell, volsano.

Coders in Virtualisation do Best if they Self BetaTest their Virtual Applications in Real Life Settings. ....... for Survivability aka AI Continuity of Big Picture Projections ...... Kernel Source Control and Supply.

This has turned into a Rich Thread, has IT not? Fortunes to be Made, Online, Live....

Now there's AI Novelty. :-)

And Paris because she's an Icon and Role Model too.

On the plus side it is a useful tool to verify good practice. On the negative side, the release of the product means anyone and everyone can run it against any website they like, so in the short term more sites are likely to get plundered.

Bind the frikkin variable and the whole problem goes away. Any database developer that lets a Java script monkey anywhere near their code needs shooting.

Clients find out about it, clients run it on comptetitors sites, clients ask developers to quietly find a hot spot in the next town and do a drop table;.....

I was told I couldn't use stored procedures on a recent project because engaging the database team was too much trouble (apparently they get cranky when you ask them to do anything on the databases) and since the app was only going to be used by internal employees security was of minimal concern....

"Scanning for SQL injection / XSS attacks should be the WebServers responsibility."

If you think scanning for SQL injection should be the webserver's responsibility, then you have no fscking clue what you're talking about.

"The tools are designed to scan websites for vulnerabilities to so-called SQL injection attacks."

Couldn't they be used as hacking tools and so be illegal to distribute in good old blighty.

We (by which I mean "those of us in the code wrangling community who are at least marginally past the wipe-clean drool-proof keyboard stage") are "blaming the developers" because, not to put too fine a point on it, it's the retards, mouth-breathers and knuckle-draggers who are the ones coding these things up in the first place (or, more likely, cutting'n'pasting from someone else's bullshit samples... PHP, I'm lookin' at *you*).

And it's not like SQL injection's a New! and Exciting! hack requiring l33t hAXX0R skillz: it's been around since some time before teh Intarwebs and most sane microcomputer database access APIs have supported parameter binding since at least the early 90s (if you count COBOL copybooks then the underlying idea can be dated to at least the late 50s; it may even be older). The *only* reason the web's full of SQL injection attacks is because most so-called developers would be better suited to jobs where the key skill is asking "do you want fries with that?"

How, pray tell, is a web server meant to know about Little Bobby Tables? Furrfu... Reg overlords, could we please have a "want to comment? Please verify that your IQ is greater than your shoe size" gateway first?

So, if it's easy to code against why does no one provide the solution here?

I think @Confusion has it correct. Sql-injection traditionaly surely means preventing a query being run on the DB that was created from a malicious form field value. This is obviously coded against using parameterised queries. And if you're not doing that then you shouldn't be writing SQL queries in your code.

BUT if you're talking about malicious HTML and JS content being stored in your DB, then I am not sure the above parameterised queries will make any difference.

So all you clever cloggs out there: how exactly do you do this?

"So, if it's easy to code against why does no one provide the solution here?"

I've seen my share of poorly coded web sites. The main problem is that some developers think that if they know basics of SQL, know how to pass the query string to the database and read the results, they know enough.

This is because the code they have written based on this knowledge, the one with SQL queries put together from hardcoded strings and user data, works "always". They do not bother checking how parameters should be passed to the database in a secure way because they see no need for it. It's "hacking", i.e. write something quick and dirty, see if it works for you and leave it like that claiming "job done".

We have whole culture of developers who simply do not see the need to do the job right. And we have whole culture of managers who are happy with job done "well enough". No solution necessary other than EDUCATION. Ha, ha, ha.

Mine's the one with some books in the pockets.

Wow, it's impressive to see how many people clearly have no idea how or what SQL injection is or how it works!

Re: the comments about javascript & html being stored in text fields not being true SQL injection, what exactly do you suggest it is?

As anyone who has read up on the methods used recently to do these attacks can confirm, the method used involving cast() mean that the web server has no way to know what the data is trying to. Unless your app checks the data being passed through it, and rejects anything that falls outside of the expected norm, it will simply pass the data to SQL for it to work out.

The basic query format tends to be /foo.asp?bar=1;declare @s varchar(4000);set @s=CAST(0x1234..<loads more hex>..6789 as varchar(4000));exec(@s);--

though obviously with the spaces escaped out with %20's. In the version I've seen a lot of recently, that code if it manages to get to SQL Server will get it to run through every single varchar field in the current database, and append a html link to a malicious jscript file into each record. That's because the cast statement (which is run by SQL not the web server) converts the innocent looking string of hex into ascii, at which point it turns out to be a lovely malicious block of T-SQL code.

For anyone wondering if they are being probed, I'd definitely recommend grepping your web server logs for '=CAST(' without the quotes and seeing what you can find.

I was a former developper in a bank, we were coding on sybase, and use of stored procedures was mandatory, dynamic sql forbidden.

When I came to work for the web startup I am still working in, I explained all the benefits of stored procedures ( performance, maintainability, security, .. ) and believed to have converted the team to them.

The first stored proc I saw was like this:

declare procedure getusers(@filter varchar(255))

begin

declare @sql varchar(8000)

set @sql = "select * from users_table where " + @filter

exec(@sql)

end

IMHO sql injection is almost something of the past. XSS is the next challenge..

Developpers, Managers, they do not understand what it is about. They just understand this is a critic of their coding practices and a pretext for delays. When a site is hacked they reject it on the OS, the web server, the ISP, the support team. In their opinion it is definitely not an issue they have to deal with, and I see no reason which will make them change their mind.

Bill, because at its debut at microsoft you should not be managed by someone writing worse code than you.

Sql injection surely requires Sql. You can't seriously tell me that you can't write a filter for that?

Sql Injection ISAPI Filter

http://www.codeplex.com/IIS6SQLInjection

No one is saying its easy but better if it was done centrally than everyone trying to handle it themselves. And what do you do about all the legacy code that was written by the guy who had never heard of bind parameter? You can hardly go back and rewrite it all

MS could have and should have done something this but they haven't. Hell just buy Threat Sentry and integrate that

Well that surely is a bit of an injection, however mr anon who proposes using a bind variable for his select query won't be bitten by your attack either....

Stored procedures dont really help that much either, if they are run using text supplied by the user, unless its bound:

sql = "exec doSomeThing( '" + userinput + "')";

if the user input is " bob'); evil sql here ; somethingvalid ( 'xx"

Using unvalidated text from the user, and then rendering that into a subsequent web page for nefarious execution by sombebody else's browser isn't really sqlinjection, more like XSS....

One, who knows how to make thing look pretty for the user.

Two, the unappreciated developer that takes more time getting things right and does not give a fig about how the website is displayed.

Development of any software is not a 'We'll get by' or a 'Style over substance' exercise. Webs are worse because they are facing the never ending barrage of crap cooked up by retards on the internet. ANY content fed to your apps should be treated with the utmost suspicion. This is a world away from a person taking a 'Design a web page' course.

It needs knowledge of the back end. Ideally, the back end database never EVER gets a string of sql from an app. The user interface should get the input, it operates with least trust. Business objects should verify and reject the user input as required. The business objects should then pass the verified data to at least one web service. Best to have a service that deals with reads and another that deals with writes. Web services can then operate at a level where they contact the back end DB with only the rights they need to perform the job they are designed for.

I can only shake my head at devs saying "stored procedures" are the way to go, only to moan that DB admins complain. Get a grip, DB admins have a right to want to prevent crap entering databases. A good dev will be able to show them that the data they get will be good.

If you allow input like 'drop table users' your only showing your stupidity!

Remember when computer science changed to computer studies?

The days when developers were required to be educated and knowledgeable are gone

The world has accepted the "it just too complex now to code without bugs" arguement

This is the price business has to pay for deskilling and they deserve everything they get

By the way I did tell you so, monkeys may work for peanuts but this is what you get from their labours

Since you so desperately seem need one, here's a free clue, but first the disclaimers:

I am not a DB.

My work doesn't even involve real programming. The last programming I did was in college over 20 years ago. But I still recall this example from my very first computer class, run on the venerable TRS-80 III from Radio Shack, in the kludge language of Basic.

Now, here's your free clue:

10 Dim Pay=float

20 Dim Cost=float

30 Dim Change=float

40 Printscreen (How much did it cost?)

50 Input Cost

60 Printscreen (How much are you paying?)

70 If Cost> Pay then goto 60

80 Input Pay

90 Change=Pay-Float

100 Print screen (Your change is);Change;(.)

110 End

There were also some formatting commands which I have since forgotten. The program returns an invalid answer if the valid input values are 5.00 and 4.95. BASIC can't handle the error, the programmer (read Developer in your case) is responsible for the problem. Even I comprehend that SQL injections are a more complicated instance of this problem. And in this example BASIC would be your Web Server.

Okay, so I fudged the variable names for clarity. BASIC on the TRS-80 only allowed two characters for variable names.

Remember 3 words:

- constrain

- santize

- validate

Treat all input data is evil. If you limit the number of characters accepted for each item of input data, sanitize it, perhaps to accept only alphanumerics, and validate against a regular expression or list of acceptable data, you're pretty well home and dry.

Managers are only interested in getting a product out the door. Security minded developers are more interested in stopping the company from hitting the national press with the latest ID theft story. Which do you think is more important?

Love heart because this stuff keeps me in a job.

Ok, I admit to writing bad code not fully verified and I have so many fields all over the place that it will be a really long winded thing to walk through all compiled code/perl code etc and lock it all down.

Easy fix is Run Apache with mod security enabled - mod security will catch out SQL injection and not return anything back to user.

I have made some docs on how to enable it here

http://www.pro.org.uk/servlets/pro?a=web-security/howto