The Daily WTF: Curious Perversions in Information Technology

2010-03-01 Reply Admin

Probeily Some Guy:
Rob:
Am I the only one who noticed the name of the function is "FQ"?
Nope, you aren't. My theory is that it had a different name before they were asked to prevent SQL injections... they renamed it "FQ" as a passive-aggressive way of stickin' it to the man for thinking that the code wasn't already perfect the first time.

Probably "Fix Query" or something like that.

2010-03-01 Reply Admin

"...told the vendor to fix the ‘blatant SQL-injection vulnerabilities’ that we discovered."

This just HAS to be an offshore vendor. Customer said to fix the blatant SQL-injection vulnerabilities, vendor fixed the blatant SQL-injection vulnerabilities.

If the customer wanted ALL the SQL-injection vulnerabilities fixed, he should have said so.

-Harrow.

2010-03-01 Reply Admin

RBoy:
Tim:
Paul:
Won't the first bit protect against SQL injections? So, it is actually safe now?
OK, the second bit (all the replaces) is dumb, but converting ' to '' is all that is required isn't it (even though it is being done in a lame way in this case)?

Or am I missing something?

You're missing something:

''; DROP TABLE users; --

Source: http://unixwiz.net/techtips/sql-injection.html

Also, captcha quoters: You're not funny. You're tedious. Tedious and boring.

Sorry, didn't mean to quis you off.

You rang?

frits · 2010-03-01 Reply Admin

Herohtar:
Probeily Some Guy:
Rob:
Am I the only one who noticed the name of the function is "FQ"?
Nope, you aren't. My theory is that it had a different name before they were asked to prevent SQL injections... they renamed it "FQ" as a passive-aggressive way of stickin' it to the man for thinking that the code wasn't already perfect the first time.

Probably "Fix Query" or something like that.

It would have been cooler if they named it FuhQ().

2010-03-01 Reply Admin

OK, I can accept that there are some fine people out there who just don't know about SQL injection, even though it should be their job to get themselves educated before creating their crud.

What I find absolutely unconscionable is when someone is warned "you have an SQL injection security vulnerability in your code" and they don't bother to do a single google to find out what that means and how to correctly fix it. Typically, the vendor who dares to charge good money for their crud has been given valuable information, by their customer, for free, on how to dramatically improve their crud. Why we should give them this knowledge for free, I'm not sure, but instead of being grateful for this gift they expend all efforts to return to their state of ignorant bliss as quickly as possible.

Now it isn't a mistake any more. You've been warned, and you chose to ignore it. Now it is deliberate, premeditated, inexcusable stupidity.

I want to gather up all of those knuckleheads and ship them off to another planet. Or I'll go and they can stay here. I'm just sick and tired of sharing oxygen with them.

somedude · 2010-03-01 Reply Admin

I actually did something like that. Was assigned to take a look at some 'minor security issues brought up by a pesky auditor'. Set up a 5 minute appointment with the big cheese (which too like... days to get). Asked him to pull up one of the offending web pages, then asked to use his keyboard for a second. "So, I type in ;select * from events where 1=1 -- and check it out" His eyes grew larger as the page that was supposed to display a single event scrolled off in to oblivion as it laboriously spit out every single event in the database.

I paused for a dramatic effect, allowing him to soak in the possibilities of what he had just seen.

"Now, watch what happens when I type in ; delete from customers where 1" "WHOA!! STOP RIGHT THERE!"

It was truly amazing to a dev order fly so quickly through the massive red tape at this place.

ContraCorners · 2010-03-01 Reply Admin

DOA:
Only a matter of time now before someone posts a link a certain webcomic, which will no doubt be followed by a thousand people groaning...

Yes, only a matter of time. 24 minutes.

2010-03-01 Reply Admin

Tim:
Paul:
Won't the first bit protect against SQL injections? So, it is actually safe now?
OK, the second bit (all the replaces) is dumb, but converting ' to '' is all that is required isn't it (even though it is being done in a lame way in this case)?

Or am I missing something?

You're missing something:

''; DROP TABLE users; --

In standard SQL, '' is not a metacharacter. So if they are building a SQL statement with something like:

sql="select customer_id from customer where lastname='"+lastname+"';"

Then doubling any quotes means that the input string you give will result in the final SQL being

select customer_id from customer where lastname='''''; DROP TABLE users; --'

That is, it will look for customers named "''; DROP TABLE users; --". A strange last name, but no SQL injection.

Yes, some dialects of SQL treat a backslash as a meta character. For those, you should also double any backslashes or whatever you need to escape the escape.

If you want your code to work on multiple dialects of SQL, you should either have multiple escape functions, use prepared statements, or maybe just write a single escape function that works for all of them and too bad if someone wants to put back slashes in his text.

i.e. Paul is correct: Simply doubling quotes -- and handling other magic characters if your SQL dialect supports them -- is not only easier than searching for every possible dangerous SQL, but far more reliable.

I've never understood why people try to search for every possible dangerous SQL one could write, rather than just ensuring that everything entered is treated as text and not executable code so that you don't care what they enter.

Really now, surely even the most innocuous SQL could subvert an application. I don't need to drop a table to screw up an app. ANY query that is not the intended query would be dangerous. How about "update customer set credit_limit=1000000.00 where customer_id=..." or even "select name, address, city, state, zip from customer" might be interesting to a competitor.

This would be like having a security system where instead of only admitting employees and registered vistors to your top secret facility, you admitted anyone EXCEPT those found on the FBI's 10 Most Wanted List. Sure, that would keep out a few of the most obviously dangerous people, but is hardly adequate security.

2010-03-01 Reply Admin

Oho! Yet another example of SQL sanitization being woefully inefficient for anyone with a SQL grammar. Truly worth attention on the front page.

Seriously, when do you retire a class of WTFs and let a new class of failures take its place?

2010-03-01 Reply Admin

aristos_achaion:
Or they could sidestep the whole issue by using a real fix, like parametrized queries.

Amen! This is exactly what I was thinking!

On the original posting, maintaining this "Whack-a-Mole" code will be quite an ongioing cash cow for the vendor - especially as it screws up legitemate databeing entered by the users.

"I submitted a bug about the 'gumdrop columns' into the help system, and all it stored was 'gums?!'"

2010-03-01 Reply Admin

Jeff K.:
On the original posting, maintaining this "Whack-a-Mole" code will be quite an ongioing cash cow for the vendor - especially as it screws up legitemate databeing entered by the users.

I believe you meant databeeing.

2010-03-01 Reply Admin

Why can I see this as the next support wtf showing up here?

Plaga: I got-a the plag-a!

sprained · 2010-03-01 Reply Admin

DeepThought:
It would be far better to ... HTML encode the incoming data before persisting it in the DB thus making it safe to display in a browser.

Please don't do that. Then when you have to send a plain-text email or export a CSV or let the user-re-edit the content or any of a number of other things you' end up with, for instance, """ peppered all over your text.

Much better to escape the HTML after you retrieve it from the DB and before you output it to the page (although, granted, that means you have to trust your developers to do so.)

2010-03-01 Reply Admin

Bill P. Godfrey:
They should have used an embedded system, because without a file system, there's nowhere to store a database.

Can't we stop repeating these memes ad nauseum? It's getting so that... er... uh.... Oh what the heck!

I want to be embedded with the Irish Girl!

2010-03-01 Reply Admin

Jeff K.:
aristos_achaion:
Or they could sidestep the whole issue by using a real fix, like parametrized queries.

Amen! This is exactly what I was thinking!

On the original posting, maintaining this "Whack-a-Mole" code will be quite an ongioing cash cow for the vendor - especially as it screws up legitemate databeing entered by the users.

"I submitted a bug about the 'gumdrop columns' into the help system, and all it stored was 'gums?!'"

Or if you can't be bothered with parameterised queries, a triple-replace will do: query = query .Replace("\\","\\\\") .Replace("\"","\\\"") .Replace("'","\\'"); also known as $query = addslashes($query); in PHP.

2010-03-01 Reply Admin

To everyone saying "MySQL!", this is from the postgresql manual:

"If the configuration parameter standard_conforming_strings is off, then PostgreSQL recognizes backslash escapes in both regular and escape string constants. This is for backward compatibility with the historical behavior, in which backslash escapes were always recognized. Although standard_conforming_strings currently defaults to off, the default will change to on in a future release for improved standards compliance."

You should always either use parameterised queries, or use the god damn escape function provided by the library!

2010-03-01 Reply Admin

DeepThought:
It would be far better to use parametrized SQL statements, stored procedures, and/or to HTML encode the incoming data before persisting it in the DB thus making it safe to display in a browser.

Yes to parameterized statements.

Stored procedures without parameterized statements are still prone to SQL injection.

OMG, please don't store html in my db. Html is for the presentation layer. Nobody's last name is actually "Smith".

2010-03-01 Reply Admin

Paul:
Won't the first bit protect against SQL injections? So, it is actually safe now?
OK, the second bit (all the replaces) is dumb, but converting ' to '' is all that is required isn't it (even though it is being done in a lame way in this case)?

Or am I missing something?

What if there is a table that uses an Integer for an id? In this case there would be no string that you must close. Kind of like the other poster demoed with their events table.

SqlStr = "select * from customer_order where order_id = " + inputFromAnEmbeddedLink

In this case a simple input of

OR 2>1

does not even need to break out of the quoted string. Parameterized queries are the only way to go...

Good error handling also helps... If you know you should receive exactly one row for a particular query, then RollBack if you don't get it.

In addition to having the customer sign an acknowledgement of the problem prior to installing the program, include language to hold vendors' feet to the fire in the contract.

2010-03-01 Reply Admin

DeepThought:
Of course, it's almost impossible to catch all known and future attack vectors using a technique such as the one demonstrated in the code as the variations could be endless (example: "language = javascript" would not be caught).

Yes it is possible. Just use white listing to define the value domain of each parameter your application should accept.

DeepThought:
It would be far better to use parametrized SQL statements, stored procedures,

Yes.

DeepThought:
and/or to HTML encode the incoming data before persisting it in the DB thus making it safe to display in a browser.

No! Please! No! I've seen this done in many places and its just another case of security through obscurity. Encoding to something else before stuffing data into the database will just end up tying you to the format, you expect to display the data in. In many scenarios, this is a serious design error. For instance, a user enters "<html>" in a field. Thats exactly what the field should contain, when we update the database. Why? Who said we were ever going to use the data in HTML? What about printing it in a report? I'd hate to see "<html>" turning up in an invoice, let alone having to write the darn conversion function that takes escaped html and makes it printable again, whereas converting the field "<html>" to "<html>" before displaying it on a web page is something most web developers know how to do.

The solution is to analyze what acceptable values you want to stuff into the database.

Jaime · 2010-03-01 Reply Admin

Griphon:
Why doesn't anyone address the security side of it. Minimum permissions, grant the select, insert, delete, update ONLY as needed, but don't grant DBO permissions to any user accounts. This way the outside vendor can deliver the crappy code, and you can install it anyway, but you're less concerned about damage. Still, using views, stored procedures and other good practices should be the norm, but the reality is that you can't control everything, so control what you can.

Those techniques only limit the scope of SQL Injection vulnerabilities. A SQL Injection vulnerability will usually allow anyone (possibly even anonymous users) to perform any task that the highest privileged user needs to perform. Good database design and security practices do not let you off the hook for writing apps that protect against SQL injection. There are way too many people in the world that already think you can solve this problem in the data layer, please don't encourage them.

2010-03-01 Reply Admin

mike:
DeepThought:
It would be far better to use ..., stored procedures, ...
Stored procedures without parameterized statements are still prone to SQL injection.

Agreed.

My current client where I work onsite is notorious for a) writing a stored procedure for every interraction with the database (supposedly for performance and security reasons), and b) doing nearly 100% SQL string concatenation in those stored procedures (almost completely negating the possibility of any performance or security improvements). They have to jump though all the same hoops as if the SQL were being built outside the database to prevent SQL injection attacks.

2010-03-01 Reply Admin

Why don't you all just use mysql_REAL_escape_string()? I mean... it is REALLY escaping the string for mysql, not just merely adding some slashes...

2010-03-01 Reply Admin

jchannell:
Also notice the script tag/javascript filtering at the end - stopping SQLi and XSS at the same time!

Well it would NOT have helped the political party in germany whose chatsite became a porn/SM-page: http://asset.soup.io/asset/0707/3492_3515_800.jpeg

2010-03-01 Reply Admin

mike:
OMG, please don't store html in my db. Html is for the presentation layer. Nobody's last name is actually "Smith".

Speak for yourself, mike

2010-03-01 Reply Admin

mike:
OMG, please don't store html in my db. Html is for the presentation layer. Nobody's last name is actually "Smith".

I have bold ancestors, you insensitive clod!

2010-03-01 Reply Admin

Tim:
Also, captcha quoters: You're not funny. You're tedious. Tedious and boring.

What's your excuse?

2010-03-01 Reply Admin

bd:
(http://xkcd.com/327/ for the uninitiated)

Seriously?

2010-03-01 Reply Admin

EngleBart:
What if there is a table that uses an Integer for an id? In this case there would be no string that you must close. Kind of like the other poster demoed with their events table.
SqlStr = "select * from customer_order where order_id = " + inputFromAnEmbeddedLink
In this case a simple input of
OR 2>1
does not even need to break out of the quoted string. Parameterized queries are the only way to go...

In that case, you don't blindly quote the string and append it. It needs to be sanitised differently; parsing it as an integer then appending the result, converted back to string, to the query would work.

asprintf (&SqlStr, "select * from customer_order where order_id = %u",
         atoi (inputFromAnEmbeddedLink));

frits · 2010-03-01 Reply Admin

Quirkafleeg:
EngleBart:
What if there is a table that uses an Integer for an id? In this case there would be no string that you must close. Kind of like the other poster demoed with their events table.
SqlStr = "select * from customer_order where order_id = " + inputFromAnEmbeddedLink
In this case a simple input of
OR 2>1
does not even need to break out of the quoted string. Parameterized queries are the only way to go...
In that case, you don't blindly quote the string and append it. It needs to be sanitised differently; parsing it as an integer then appending the result, converted back to string, to the query would work.
asprintf (&SqlStr, "select * from customer_order where order_id = %u",
         atoi (inputFromAnEmbeddedLink));

Just make sure order #0 doesn't exist.

2010-03-01 Reply Admin

Yetihehe said: Why don't you all just use mysql_REAL_escape_string()? I mean... it is REALLY escaping the string for mysql, not just merely adding some slashes...

Because we're not using PHP or MySQL, and the real solution is paramaterization.

If you think the real solution is anything else, you're wrong.

See how simple that is?

2010-03-01 Reply Admin

DeepThought:
<snip> Of course, it's almost impossible to catch all known and future attack vectors using a technique such as the one demonstrated in the code as the variations could be endless (example: "language = javascript" would not be caught). It would be far better to use parametrized SQL statements, stored procedures, and/or to HTML encode the incoming data before persisting it in the DB thus making it safe to display in a browser.

Thankfully, not altogether impossible. Simply post any code that you propose to use in the 'real world' on this site and the resident experts will gladly explain all the vulnerabilities.

As an added bonus, they will also collaborate together to ensure that you have adhered to the most stringent programming principles and assess your value as a developer (if not human being)....

frits · 2010-03-01 Reply Admin

Homerclese:
DeepThought:
<snip> Of course, it's almost impossible to catch all known and future attack vectors using a technique such as the one demonstrated in the code as the variations could be endless (example: "language = javascript" would not be caught). It would be far better to use parametrized SQL statements, stored procedures, and/or to HTML encode the incoming data before persisting it in the DB thus making it safe to display in a browser.

Thankfully, not altogether impossible. Simply post any code that you propose to use in the 'real world' on this site and the resident experts will gladly explain all the vulnerabilities.

As an added bonus, they will also collaborate together to ensure that you have adhered to the most stringent programming principles and assess your value as a developer (if not human being)....

There are far more sarcastic, trolliscious, and flat-out wrong answers here than any real solutions. But feel free to post any code at all--you will be mocked for your crappy code and/or your inability to see that is/is not bad.

2010-03-01 Reply Admin

sane person:
Tim:
Paul:
Won't the first bit protect against SQL injections? So, it is actually safe now?
OK, the second bit (all the replaces) is dumb, but converting ' to '' is all that is required isn't it (even though it is being done in a lame way in this case)?

Or am I missing something?

You're missing something:

''; DROP TABLE users; --

In standard SQL, '' is not a metacharacter. So if they are building a SQL statement with something like:

sql="select customer_id from customer where lastname='"+lastname+"';"

Then doubling any quotes means that the input string you give will result in the final SQL being

select customer_id from customer where lastname='''''; DROP TABLE users; --'

That is, it will look for customers named "''; DROP TABLE users; --". A strange last name, but no SQL injection.

Yes, some dialects of SQL treat a backslash as a meta character. For those, you should also double any backslashes or whatever you need to escape the escape.

If you want your code to work on multiple dialects of SQL, you should either have multiple escape functions, use prepared statements, or maybe just write a single escape function that works for all of them and too bad if someone wants to put back slashes in his text.

i.e. Paul is correct: Simply doubling quotes -- and handling other magic characters if your SQL dialect supports them -- is not only easier than searching for every possible dangerous SQL, but far more reliable.

I've never understood why people try to search for every possible dangerous SQL one could write, rather than just ensuring that everything entered is treated as text and not executable code so that you don't care what they enter.

Really now, surely even the most innocuous SQL could subvert an application. I don't need to drop a table to screw up an app. ANY query that is not the intended query would be dangerous. How about "update customer set credit_limit=1000000.00 where customer_id=..." or even "select name, address, city, state, zip from customer" might be interesting to a competitor.

This would be like having a security system where instead of only admitting employees and registered vistors to your top secret facility, you admitted anyone EXCEPT those found on the FBI's 10 Most Wanted List. Sure, that would keep out a few of the most obviously dangerous people, but is hardly adequate security.

Hows about making sure that certain punctuation characters aren't allowed in a name field. An Apostrophe or a hyphen are probably the only non-alphabetic characters required to display a name (and maybe numbers for King Henry 4 {although I suspect he would use IV}). For addresses things may be a little more complex, but we should still be able to limit the number of non-alphanumeric characters allowed. Getting rid of any entered semi-colon goes a long way (although doesn't stop the problem entirely, I don't think)...and reducing other punctuation {such as brackets} can help a lot too.

It may mean that people can only enter their names in English, but provided it's an English system that shouldn't be too much a problem

2010-03-01 Reply Admin

frits:
Homerclese:
DeepThought:
<snip> Of course, it's almost impossible to catch all known and future attack vectors using a technique such as the one demonstrated in the code as the variations could be endless (example: "language = javascript" would not be caught). It would be far better to use parametrized SQL statements, stored procedures, and/or to HTML encode the incoming data before persisting it in the DB thus making it safe to display in a browser.

Thankfully, not altogether impossible. Simply post any code that you propose to use in the 'real world' on this site and the resident experts will gladly explain all the vulnerabilities.

As an added bonus, they will also collaborate together to ensure that you have adhered to the most stringent programming principles and assess your value as a developer (if not human being)....

There are far more sarcastic, trolliscious, and flat-out wrong answers here than any real solutions. But feel free to post any code at all--you will be mocked for your crappy code and/or your inability to see that is/is not bad.

Indeed!!

I think perhaps you missed the point....

2010-03-01 Reply Admin

EngleBart:
Paul:
Won't the first bit protect against SQL injections? So, it is actually safe now?
OK, the second bit (all the replaces) is dumb, but converting ' to '' is all that is required isn't it (even though it is being done in a lame way in this case)?

Or am I missing something?

What if there is a table that uses an Integer for an id? In this case there would be no string that you must close. Kind of like the other poster demoed with their events table.
SqlStr = "select * from customer_order where order_id = " + inputFromAnEmbeddedLink

In this case a simple input of

OR 2>1

does not even need to break out of the quoted string. Parameterized queries are the only way to go...

Good error handling also helps... If you know you should receive exactly one row for a particular query, then RollBack if you don't get it.

In addition to having the customer sign an acknowledgement of the problem prior to installing the program, include language to hold vendors' feet to the fire in the contract.

Okay, don't want to look the idiot, but why would we rollback on a select? Are we afraid (because we got an unexpected result) that they may also have sneaked a few other niceties in there?

2010-03-01 Reply Admin

Sigivald:
Because we're not using PHP or MySQL, and the real solution is paramaterization.
If you think the real solution is anything else, you're wrong.

See how simple that is?

You are obviously working with simplistic requirements. There are cases where parameterised queries/procedures work, and there are cases where they can't work. If that is the only tool in your box, then you will be stuck if you come across a scenario where they won't work.

At the moment I am working on something which requires an arbitrary query to be submitted in one form, and converted to another (in my case, an LDAP query converted to an SQL query). There is no way to do this using parameterisation AND take advantage of the DB's query optimiser. I could use parameterisation and do lots of queries and then do procedural unions/intersects, but that is really slow and complicated (I may as well use a flat file for data storage instead of a relational DB). Or, I can create an SQL query based on the LDAP query, and pass that to the DB to let it do its query optimisation magic, which ends up with the query being really quick.

For this, you HAVE to build a query on the fly, and you HAVE to quote the parameters. Quoting the parameters is not hard, as long as you know the DB's metacharacters. Once you do that, it is no less secure than using parameterised queries/procedures.

2010-03-01 Reply Admin

Harrow:
"...told the vendor to fix the ‘blatant SQL-injection vulnerabilities’ that we discovered."
This just HAS to be an offshore vendor. Customer said to fix the blatant SQL-injection vulnerabilities, vendor fixed the blatant SQL-injection vulnerabilities.

If the customer wanted ALL the SQL-injection vulnerabilities fixed, he should have said so.

-Harrow.

Best comment on this story

2010-03-01 Reply Admin

Paul:

Source: http://unixwiz.net/techtips/sql-injection.html
Ah, that only works with MySQL. SQL compliant databases won't suffer from that weakness.

Is there a standard conform SQL database? You always have to assume that your SQL code will be run on some crap DB so you should use prepared statements.

2010-03-01 Reply Admin

Better yet, don't allow manky data that it's difficult to handle into your database in the first place. Telephone field? Why not only accept numeric characters and dashes? Address field? Why do you need CRs, LFs, null bytes, and diamond brackets?

If you whitelist characters for given form fields, and encode whenever you handle data from untrusted source (this means user-supplied data, or any data which might be user-supplied, derived, or influenced, from external SOAP calls to database rows), chances are you'll make XSS very difficult.

And if you do encode, please, please take care of all the special-use characters in javascript and HTML. <>"' isn't good enough. See OWASP for more details.

Now, onto XSRF...

2010-03-01 Reply Admin

Unless you are sure it will always need to be html, or unhtml is a good enough solution. I agree with your point in general, but the right answer is always dependant on the situation.

2010-03-01 Reply Admin

Practising the Principle of Least Priviledge is always a good idea, but it doesn't prevent SQL Injection.

Secure information can be leaked in a read-only environment as well. Consider the addition of "union select user,password from users". Or "select employee,salary from bonuses".

LoztInSpace · 2010-03-01 Reply Admin

Wiggly Woo:
Sigivald:
Because we're not using PHP or MySQL, and the real solution is paramaterization.
If you think the real solution is anything else, you're wrong.

See how simple that is?

You are obviously working with simplistic requirements. There are cases where parameterised queries/procedures work, and there are cases where they can't work. If that is the only tool in your box, then you will be stuck if you come across a scenario where they won't work.

At the moment I am working on something which requires an arbitrary query to be submitted in one form, and converted to another (in my case, an LDAP query converted to an SQL query). There is no way to do this using parameterisation AND take advantage of the DB's query optimiser. I could use parameterisation and do lots of queries and then do procedural unions/intersects, but that is really slow and complicated (I may as well use a flat file for data storage instead of a relational DB). Or, I can create an SQL query based on the LDAP query, and pass that to the DB to let it do its query optimisation magic, which ends up with the query being really quick.

For this, you HAVE to build a query on the fly, and you HAVE to quote the parameters. Quoting the parameters is not hard, as long as you know the DB's metacharacters. Once you do that, it is no less secure than using parameterised queries/procedures.

You can and should still use parameters. With a bit of thought there is nothing to stop you dynamically building a query that is like

SELECT x, y, z from a, b, c where p=? and q=? and r=? then go through & add all the parameters.

rather than

SELECT x, y, z from a, b, c where p='bob' and q='arthur' and r=27

You quite obviously have all the information you need so why not just do the right thing?

2010-03-01 Reply Admin

There are 2 grammatical errors at the end of your article "they told us were beeing too picky, and had us install the application anyway." First, you an extra 'e' in 'being'. Second, it should be 'we're' not 'were'

2010-03-01 Reply Admin

If you don't limit DB access via Stored Procedures and Prepared Statements then you deserve all the pain you will get (and it's just a matter of when).

Still, if you're a dumbass and persist in building your own queries, at least do something like this with your inputs...

internal static string FQ(string WhichField) { if (WhichField != null) { WhichField = Regex.Replace(WhichField, @"[^\sa-z0-9]", "", RegexOptions.IgnoreCase | RegexOptions.SingleLine); } return WhichField; }

2010-03-01 Reply Admin

update financialrecords set amountinallbankaccounts = 1000000000000000;

Callin · 2010-03-01 Reply Admin

return Strings.Trim(Strings.Replace(Strings.Replace(Strings.Replace(Strings.Replace(expression, "1=1", "", 1, -1, CompareMethod.Text), "1 =1", "", 1, -1, CompareMethod.Text), "1= 1", "", 1, -1, CompareMethod.Text), "1 = 1", "", 1, -1, CompareMethod.Text));

2010-03-01 Reply Admin

bobdobbs:
There are 2 grammatical errors at the end of your article "they told us were beeing too picky, and had us install the application anyway." First, you an extra 'e' in 'being'. Second, it should be 'we're' not 'were'

I reckon it should be "we were" not "we're" (ie "we were" rather than "we are" ("we were" might be shortened to "we're" somewhere in the world, but I've never seen it))

anywho, I think your beeing two picky

2010-03-01 Reply Admin

Johnno:
Hows about making sure that certain punctuation characters aren't allowed in a name field. An Apostrophe or a hyphen are probably the only non-alphabetic characters required to display a name

Spaces, accented letters, and some language-specific letters are required even if you're sticking with Latin alphabets, although I suspect that some Germans are well used to using ‘ss’ or ‘sz’ instead of ‘ß’…

2010-03-01 Reply Admin

Quirkafleeg:
Johnno:
Hows about making sure that certain punctuation characters aren't allowed in a name field. An Apostrophe or a hyphen are probably the only non-alphabetic characters required to display a name
Spaces, accented letters, and some language-specific letters are required even if you're sticking with Latin alphabets, although I suspect that some Germans are well used to using ‘ss’ or ‘sz’ instead of ‘ß’…

Might be nice to have but are certainly not required....(I know many people who have names with umlauts or other marks, who simply leave them off when creating forms). If required, you can always create an 'allowable character set' (which you can later extend if you need to because vast hordes of people want a certain character).

Either way, my reading is that the OP was saying you can filter punctuation and non-alphabetic letters. Language specific letters and accented letters would still be letters, I would think, so I'm not quite sure the point you're making?

2010-03-01 Reply Admin

An unhappy pentester:
Better yet, don't allow manky data that it's difficult to handle into your database in the first place. Telephone field? Why not only accept numeric characters and dashes?

You'd want to allow a leading ‘+’ for reporting fax errors to somewhere in India.

Injection Proof'd

Leave a comment on “Injection Proof'd”