If it didn't work, they wouldn't be doing it. Companies, you know, they do research on this sort of thing. They know what moves handsets. Whatever can be done that increases sales, they do that.
My first programming class was PILOT. it was a community education evening-classes type thing at a local public school, and it would have been, maybe, 20-25 years ago.
The only chunk of a "postback" (ASP.NET terminology, has nothing to do with AJAX) that is "encrypted" is the "viewstate" hidden field. This field generally contains information on what was in the rest of the form fields at the moment the page was rendered, and is generally used to tell what changed once the form is posted back to the server (the "postback"), as well as store information that for some reason the developer chose not to store in the server-side session state.
This field could theoretically be posted along with the rest of a form through an AJAX operation, but is not always (never in any AJAX I've done with ASP.NET), and even if it was somehow altered on the client-side, the values contained within would not (in the normal case) be used to construct database queries. Queries would generally be constructed from the CURRENT values that would come from the normal, everyday, unencrypted form fields.
Microsoft does not propose AJAX as a solution to SQL injection. In fact, they would only propose the solution that most everyone else in the entire world would propose, which is parameterized queries (or "bind variables" as they've been referred to). They wouldn't propose AJAX, because AJAX, as I've stated several times already, has nothing to do with databases and how database queries might be constructed.
How about not shooting him in the head? That might be something he wants...
I'm all for the great "we'll all be free to pursue our passions instead of being a slave to wages" dreams, but the fact is that most of the degenerate scum on the earth here have no higher passions to pursue, and would simply resort to violence for fun.
Why not? Just disallow inline literals. If we're going to require major backwards-incompatible changes to database engines, let's fix the REAL problem, not just part of it.
So poorly programmed ordinary statements are immune. What about poorly programmed block statements?
Seriously, I get your point here. It's great, but it's not a cure-all. The cure-all is to disallow queries that use literals. If that's even possible. The practical answer, is "don't program stupid". Unfortunately, that's unrealistic, so rest assured we'll get to have this discussion over and over for the foreseeable future:)
My point was, this hypothetical person only NEEDS a car because of the choices they consciously made. It's not his employer's problem if he chooses to live somewhere that would require him to use a vehicle to commute.
That said, I commute in a car, and I'm grateful my current employer provides free parking. If they didn't, I'd likely do something else. When I worked in New York, I lived only a couple blocks from where I worked, and that was a big reason.
What are you talking about? You don't have the slightest clue what AJAX is, do you?
AJAX has nothing to do with checksums, encryption, or "models". It's a technique for moving data (any data, in spite of the acronym) to and from the server without requiring a reload of the page. Nothing more, nothing less.
Requiring block syntax protects against the worst injection attacks, yes. Requiring parameterized queries protects against ALL of them.
Besides, Oracle is in the minority, here (from my experience). Right or wrong (I've got no dog in that particular fight), most database engines don't require special block syntax.
PHP has historically encouraged the ad-hoc generate-your-queries-on-the-fly-and-embed-your-parameters-as-literals behavior. Java and.NET have never prevented or punished this behavior, but from my own experience it has definitely been less pronounced.
This is a simple problem to fix. All the databases that support this by default should make it an option, and disable the option by default in the next major version of the database. It is not rocket science, and would add a valuable layer of defense to any number of database applications.
You're right, this is a simple problem to fix. It doesn't even require changes to any of the database servers that are commonly used. Parameterize your queries. Bang, problem solved.
This is a bog-standard SQL injection attack, that basically every single database engine ever created is vulnerable to, when paired with a sufficiently brain-dead programmer.
Wait, what? It's squarely the fault of the programmer who created the script, not the scripting language. He didn't imply anything else. What is it you're looking to fight over? If you'd clearly state what you have a beef with, we can formulate intelligent arguments for you to counter. Otherwise, it's just shooting in the dark...
How is MS SQL "particularly susceptible"? It uses the same query language that all the other database engines use. As you say, it's the fault of the application programmers, not the database engine programmers. If anything, I'd point to PHP as the hotbed of SQL injection. Constructing queries at runtime by concatenating input values with sql statements is going to lead to pain, EVERY TIME.
Runtime-constructed queries and using literal values instead of parameters are not mutually exclusive.
Slashdot Mirror
If it didn't work, they wouldn't be doing it. Companies, you know, they do research on this sort of thing. They know what moves handsets. Whatever can be done that increases sales, they do that.
locate the APs (which is outrageous by itself, who gave 'em permission?)
They don't NEED permission. You broadcast a signal, you're gonna be locatable. Don't like that? Turn your house into a faraday cage.
My first programming class was PILOT. it was a community education evening-classes type thing at a local public school, and it would have been, maybe, 20-25 years ago.
The only chunk of a "postback" (ASP.NET terminology, has nothing to do with AJAX) that is "encrypted" is the "viewstate" hidden field. This field generally contains information on what was in the rest of the form fields at the moment the page was rendered, and is generally used to tell what changed once the form is posted back to the server (the "postback"), as well as store information that for some reason the developer chose not to store in the server-side session state.
This field could theoretically be posted along with the rest of a form through an AJAX operation, but is not always (never in any AJAX I've done with ASP.NET), and even if it was somehow altered on the client-side, the values contained within would not (in the normal case) be used to construct database queries. Queries would generally be constructed from the CURRENT values that would come from the normal, everyday, unencrypted form fields.
Microsoft does not propose AJAX as a solution to SQL injection. In fact, they would only propose the solution that most everyone else in the entire world would propose, which is parameterized queries (or "bind variables" as they've been referred to). They wouldn't propose AJAX, because AJAX, as I've stated several times already, has nothing to do with databases and how database queries might be constructed.
Or maybe they'd listen to Reason?
Wesley Mouch? Is that you?
How about not shooting him in the head? That might be something he wants...
I'm all for the great "we'll all be free to pursue our passions instead of being a slave to wages" dreams, but the fact is that most of the degenerate scum on the earth here have no higher passions to pursue, and would simply resort to violence for fun.
Wait, wait, let me try to follow your logic here:
MS "encrypts" a hidden field and uses AJAX to post it to the server ... somehow leads to ...
AJAX prevents SQL injection attacks ... somehow leads to ...
AJAX is the same technology as "bind variables" in database engines ... riiiiiight.
Why not? Just disallow inline literals. If we're going to require major backwards-incompatible changes to database engines, let's fix the REAL problem, not just part of it.
So poorly programmed ordinary statements are immune. What about poorly programmed block statements?
Seriously, I get your point here. It's great, but it's not a cure-all. The cure-all is to disallow queries that use literals. If that's even possible. The practical answer, is "don't program stupid". Unfortunately, that's unrealistic, so rest assured we'll get to have this discussion over and over for the foreseeable future :)
Because noone ever uses block statements in Oracle, amirite?
My point was, this hypothetical person only NEEDS a car because of the choices they consciously made. It's not his employer's problem if he chooses to live somewhere that would require him to use a vehicle to commute.
That said, I commute in a car, and I'm grateful my current employer provides free parking. If they didn't, I'd likely do something else. When I worked in New York, I lived only a couple blocks from where I worked, and that was a big reason.
What are you talking about? You don't have the slightest clue what AJAX is, do you?
AJAX has nothing to do with checksums, encryption, or "models". It's a technique for moving data (any data, in spite of the acronym) to and from the server without requiring a reload of the page. Nothing more, nothing less.
Requiring block syntax protects against the worst injection attacks, yes. Requiring parameterized queries protects against ALL of them.
Besides, Oracle is in the minority, here (from my experience). Right or wrong (I've got no dog in that particular fight), most database engines don't require special block syntax.
I agree, we must maintain backwards compatibility with the SQL injection vulnerabilities.
Yeah, 'cause that's worked so far, amirite?
PHP has historically encouraged the ad-hoc generate-your-queries-on-the-fly-and-embed-your-parameters-as-literals behavior. Java and .NET have never prevented or punished this behavior, but from my own experience it has definitely been less pronounced.
The array of tokens to substitute should be an optional argument to mysql_query()....
I think what you actually meant was that PHP needs to eliminate mysql_query() NOW. Or, better, 5 years ago.
Yeah. Seriously, people. When will you all learn?
I mean, noone ever got fired for buying IBM, and noone ever wrote insecure software on open source platforms. Like PHP.
This is a simple problem to fix. All the databases that support this by default should make it an option, and disable the option by default in the next major version of the database. It is not rocket science, and would add a valuable layer of defense to any number of database applications.
You're right, this is a simple problem to fix. It doesn't even require changes to any of the database servers that are commonly used. Parameterize your queries. Bang, problem solved.
This is a bog-standard SQL injection attack, that basically every single database engine ever created is vulnerable to, when paired with a sufficiently brain-dead programmer.
MSSQL, Sybase, MySQL, PostgreSQL, SQLite.
In fact, I've never used a database engine that DIDN'T allow multiple statements. Do you have one in mind that doesn't?
Wait, what? It's squarely the fault of the programmer who created the script, not the scripting language. He didn't imply anything else. What is it you're looking to fight over? If you'd clearly state what you have a beef with, we can formulate intelligent arguments for you to counter. Otherwise, it's just shooting in the dark...
How is MS SQL "particularly susceptible"? It uses the same query language that all the other database engines use. As you say, it's the fault of the application programmers, not the database engine programmers. If anything, I'd point to PHP as the hotbed of SQL injection. Constructing queries at runtime by concatenating input values with sql statements is going to lead to pain, EVERY TIME.
Runtime-constructed queries and using literal values instead of parameters are not mutually exclusive.
Yeah, you are. "Ajax" has nothing to do with SQL or databases whatsoever.