- Feature Articles
- CodeSOD
- Error'd
- Forums
-
Other Articles
- Random Article
- Other Series
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Msg 208, Level 16, State 1, Line 1 Invalid object name 'financialrecords'.
Admin
I always get annoyed when I have to figure out how to write something just so whatever form requires it, accepts it.
Even things that first ask you what country you live in, and then go on asking you what state, even if you don't happen to be living in a federal state, and the only ones they allow you to pick are the USA states, and sometimes the Canadian ones.
I find the safest way to handle things, is to store it as unicode. Even telephone numbers, if if those are relatively tame in my experience.
It's not funny if you can't enter your own name properly, and you have to mangle it.
Admin
Other than the fact that you are clearly right.... Other than maybe my first line about I have never met anyone who has an issue dealing with systems that don't cater for accents, umlauts and similar punctuation, there is little in my post that has anything to do with internationalisation (and so I've taken it to heart that you accuse me of being inexperienced in such things).
To have an allowable set of characters is (IMHO) reasonable, especially if it can be extended as required. You don't (unless you are incredibly stupid) have to sit there trying to work out how to do it (as you suggest). This isn't about selecting multiple options, it's about entering data via the keyboard.
Further, it's a 'horses for courses' thing...Why would you allow '$' in a Name field? (In a currency field, it's another matter, perhaps).
I don't suggest anywhere that international characters be avoided - if anything, I endorse the idea (or that was my intent).
Anywho, it's late and I'm grumpy, so MAH!!
Admin
No.
Admin
Yes, proper parameterization; No, home-grown solutions.
The first bit of the code escapes characters without checking if they're already escaped. Doh!
Admin
well, you can still html decode the data, if you need to get them to "editable" form... i would even think of it as a logical step, doing it automatically after retrieving the data from DB (exept cases when you don't need it, offcouse)
Admin
I would kill if i saw this in our codebase
Admin
I doubt the uppercase version of é is &EACUTE
Admin
I've hardly ever come across anything which will run on ANY DB..
ODBC stuff maybe (but not guaranteed, unless it only does trivial things), but otherwise most times people require a specific database, or a specific set of databases. If you want to use stored procedures/triggers/custom functions/custom data types, then most DBs use non-standard stuff, so anything you write will only work on one DB.
Even preparing statements works differently on different DBs. Some DBs don't support them at all (eg SQLite). The API might, but what do you think that is doing, other than converting ' to '' in parameters... The ones that do, handle them differently, eg some use '?' for parameters (which can't be reordered or reused), others use $1, $2 etc for parameters (which can be reordered and reused within the query) and so on.
So, once you know the DB you are using, it's easy to quote parameters. If you have an abstraction layer in your code to handle multiple database engines, then it's trivial to add a suitable quoting function to that. It can be considerably harder to add prepared statement capabilities to a database abstraction layer.
For instance, in our abstraction layer, we have a function which we pass a 'pseudo prepared statement' containing parameter types (similar to a printf string; similar to many database's built in 'prepare' statements) and parameters, which are all then converted and quoted accordingly. We don't use DB based prepared statements because, with all the semantic differences between the different databases we support, it is over complicated, when our system works just as well, and is safe from injection attacks, because the abstraction layer can do type checking and knows how to quote for our supported databases.
Admin
Stop being picky.
CAPTCHA: odio. Do I really have such a bad breath?
Admin
ooooh get her!
Admin
Admin
Admin
In HTML It's É
Admin
Anyone suggesting anything other than a prepared statement should be asking people if they want fries with that
Admin
I never ceased to be amazed by people who understood what an SQL injection was and that now think they know it all about security when they can spot a SQL-injection vulnerable piece of code.
Admin
Please don't do that. HTML Encoding is formatting for a particular use. Please store the real data and format it when needed.
Admin
I know all about security, me.
Admin
I sometimes hit the same problem with email addresses and idiotic form validation allowing only ASCII alphanumerics and a few symbols.
(Hmm. The next time that I encounter this, I'm going to determine whether the validation is Javascript-only and, if it is, use a convenient browser extension to rip out that validation…)
Admin
Would not replacing any "--" with "- -" do it? If a nefarious statement is inserted, and the sql following it is the remnants from what should have been the statement is not commented out, won't the compiler cause the entire statement to fail?
I know that an app that wants the "--" as, say, part of a text field entry will never get that, but for typical "enter your name" etc. sites this would work, no? --Jim
Admin
Admin
What a great idea! This will prevent SQL-injections attacks, as last I checked SQL does not recognize the "ropday abletay" command. And it also encrypts the data, thus protecting it from any hackers who do not know Pig Latin.
Seriously now, why is it that every time someone points out the flaws to a bad idea, there's always someone else to point out how, if you just stand on your head and learn to whistle under water, you could make it work?
Admin
Umm, and in Java, or C++, just what is the name of that function in the library? I've always wondered why the Java JDBC package does not include such an escape function -- like maybe call the same function that they surely use for prepared queries -- but they don't expose it, so you have to write your own.
Not that writing your own is hard.
Admin
Umm, yes, but what if you have something more like this:
Please tell me how you would do that with a prepared statement.
Sure, in principle, you could construct a separate prepared query for every possible combination of conditions, and then plug the values in to the right place in each of these. But I've had plenty of cases in real life where I constructed queries on the fly like that where there were easily hundreds of possible combinations. Not only would this be very tedious to code, but it would be a nightmare to maintain, as every change would have to be made dozens of times. And imagine testing such a monstrosity!
I have nothing against prepared statements, but in all but the most simple applications, I routinely have to build queries on the fly out of pieces like this.
Admin
Of course they do something you idiot! Quote from one webpage: "stored procedures can help to provide protection against SQL Injection attacks, but ultimately developers must understand the underlying causes of these vulnerabilities and build applications with the appropriate threats in mind.".
In the case of the article it's great to see that if we use two spaces between 'drop' and 'table' that we're still going to be able to do the damage.
Admin
While I'm all for validating inputs, this could never be a general strategy against SQL injection. Yes, you can limit telephone numbers to hyphens and digits, etc., but sooner or later your database will surely have some field where almost any character is valid. How about a field to hold the text of a math problem? Are you going to bar "<" and ">"? That would be a little impractical. Or how about a field for text of posts on a SQL programmers forum? Hard to see how you could exclude anything that might look like SQL commands from that. For that matter, SQL injection doesn't require bizarre, far-out characters that people wouldn't use in many text fields: Just single quotes, semi-colons, and alphabetics, really. Are you going to forbid the use of contractions in all text fields?
A solution that "usually works" just isn't really practical. Especially when we're talking about security, when you know that the hackers will be looking for the one place where there's a hole.
Admin
Panzi said You always have to assume that your SQL code will be run on some crap DB so you should use prepared statements
Well, I dunno about you, but I sure as hell don't.
My SQL code will be run on MS SQL Server (normally Express edition), and nothing else, period, end of statement.
Of course, that's because I'm not a web developer...
Or in whatever other really weird niche it is that means you have to write ODBC code against arbitrary backing stores...?
Admin
So are Massachusetts and Pennsylvania. If you're going to be pedantic, at least be correctly pedantic.
Admin
Please submit this for CodeSOD.
Admin
Ummm, only if that developer was entering SQL via the Name field of a webform, or some related idiocy. It's not like this code gets run when they type SQL into the database admin application.
Admin
Jesus, haven't these people ever heard of SQL parameterization?a
Admin
Use an array. Trying some PHP off the top of my head:
if ( condition1 ) { ....sql .= "where thing = ?" ....array_push( params, value1 ) } if ( condition2 ) { ....sql .= "and thing = ?" ....array_push( params, value2 ) }
foreach( params as value ) { ....i++; ....statement->bindParam( i, value ) }
Handling of "AND" vs "WHERE" left as an exercise for the reader.
Admin
The other day we got the inevitable spat of comments where 20 PHP developers pointed to the other 19 and said, "I'm not like those guys."
Today's group must be a different 20, because they're all proposing SQL injection "solutions" that involve building queries directly from user input.
Admin
Alternatively, you could go completely bonkers and use a stored procedure. That way the DB itself would be invulnerable to sql injection attacks in any and all forms, for the simple reason that there would be no SQL to inject.
Anything else is posturing (and drivel).
Admin
Oh,
and by the way, I was so busy going OTT about SQL injection that I forgot to mention the lunacy of allowing the application to do DDL on the fly. How exactly can a DBA (such as myself) manage a system where the db is altered by the application unannounced and uncontrolled? If anyone could oblige me with an informed answer to that I'd be ever so grateful.
As to the PHP idiots out there, I call bullshit on you. You post a clear cut statement of requirement, and I'll post the Oracle stored procedure that does it, complete with unit tests and outcomes.
Conduct yourselves on the basis of demonstrable proven code, not assertions and assumptions.
Put up or shut up.
Admin
Dude, is this your first time on the internet? No one's going to shut up.
Admin
Admin
Yes.
No.
(Puerto Rico and the Northern Mariana Islands are also named "Commonwealth", but are not states.)
Admin
Lots of high level intellectual wanking going on here, but no-one with their feet on the ground. In the real world, how does anyone know if SQL injection works? They might go around randomly testing simple SQL injections, but if 1=1 and 2=2 don't work, they probably stop there.
Simple solution for minimal security: pass all your text input strings to the database in reverse order (i.e. right to left text order)...
Admin
I concede. I have been out-pedanted. I was going from memory -- I forgot about MA and PA.
If this had been a real act of pedantry and I was actually trying to ridicule someone, I would have looked it up.
Admin
Okay, I'll buy that, that will work. Seems to me like it's a lot harder to read than just writing an escape function and using it where you need it, though. 'Might create performance issues with creating prepared statements that are only used once each, but I guess I'd worry about that if it happened.
Admin
Okay. Suppose you had this problem, i.e. need to search for customers where the set of search criteria can include one or more of city, account type, and balance; and where the output may be sorted by name or city plus address. How would you write it more cleanly? Is the above example easy-to-follow code? I concede, no. Is there a better alternative that would be more readable and more maintainable? I can't think of one. If you have a better solution, I'd like to use it in some of my programs.
Admin
What do you think this is, rentacoder.com?
Admin
The submitter probably would have had better luck providing a link to his customer. "It will break if they do '1 = 1'" looks picky to a non-tech savvy user. "It still isn't secure. CLICK HERE TO BREAK IT" looks scary to a non-tech savvy person. Especially if they actually click the link.
Of course, all that would accomplish is getting the one particular case fixed, not "1 = 1"
Admin
Admin
If you squint the right way, you cab see Freddy.
Admin
Admin
Duh, that's why it's called PL/SQL (presentation layer SQL). I thought you guys knew that…
Admin
Guys,
tee hee, nice response. I guess it does come across an naieve, but as I have noted with protagonists far and wide, a call to prove the BS they're peddling usually results in a plethora of zero responses - just like here.
I have to sigh and say Q.E.D. and then get on with life. Anyhow, someone talked to me just last year, don't you know?
I'm just off to find my sandals, shorts, beard trimmer, and circular gold-rimmed glasses. I reckon they're somewhere in the dungeon where I work....
Admin
Just inject "SELECT * FROM sys.objects" first, then inject a procedure call to do anything you want to do. Since every is done in a procedure, it is gauranteed that there will be a procedure to do anything that you want to do.