Im limiting my clients from entering certain characters.
Right now I allow:
All the numbers
All the english letters
-
_
I do not allow:
'
"
;
What other safe characters and/or unsafe characters exist when doing a query via programming using a textbox or such?
The safest way to work with any SQL (MySQL included) is to use parameterized queries. This will allow your clients to enter any characters they want and prevent any SQL injections.
You didn't mention what language you are working with so here's a .NET example for working with MySQL: http://dev.mysql.com/doc/connector-net/en/connector-net-tutorials-parameters.html
Related
These is one keyword confliction issue in the query module of my application,please see if you can tell me a smart solution.
First,In query module,each query condition contains three parts in UI:
1.field name,its value is fixed,e.g origin,finalDest...
2.operator,it is a select list which includes "like","not like","in","not in","=","!="
3.value,this part is input by user.then in back-end,it will assemble the SQL statement according to UI's query criteria,e.g if user type/select following stuff in UI
Field Name Operator Value
origin like CHI
finalDest in SEL
In back-end,it will generate following SQL:
select * from Booking where origin like '%CHI%' and finalDest in ('SEL').
But there is a bug,e.g if user type some of special symbol in "value",e.g "'","_" etc,it will lead to the generated SQL also contain ' or _ ,e.g:
select * from Booking where origin like '%C_HI%' and finalDest in ('S'EL').
you could see as there is special symbol in "where" block,the SQL can't be executed
For this problem,my solution is add escape character "/" in front of the special symbol before executing it,but what i know is just ' or _ that would conflict with the SQL keywords,do you know if there is any others similar symbol that i need to handle or do you guys have any better idea that can avoid the injection
Sorry,forgot told you what language i am using,i am using java,the DB is mysql,i also use hibernate,there are a lot of people said why i didn't use PreparedStatement,this is a little complex,simply speaking,in my company,we had a FW called dynamic query,we pre-defined the SQL fragment in a XML file,then we will assemble the SQL according to the UI pass in criteria with the jxel expression,as the SQL is kinda of pre-defined stuff,i afraid if change to use PreparedStatement,it will involve a lot of change for our FW,so what we care is just on how to fix the SQL injection issue with a simple way.
The code should begin attempting to stop SQL injection on the server side prior to sending any information to the database. I'm not sure what language you are using, but this is normally accomplished by creating a statement that contains bind variables of some sort. In Java, this is a PreparedStatement, other languages contains similar features.
Using bind variables or parameters in a statement will leverage built in protection against SQL injection, which honestly is going to be better than anything you or I write on the database. If your doing any String concatenation on the server side to form a complete SQL statement, this is an indicator of a SQL injection risk.
0 An ASCII NUL (0x00) character.
' A single quote (“'”) character.
" A double quote (“"”) character.
b A backspace character.
n A newline (linefeed) character.
r A carriage return character.
t A tab character.
Z ASCII 26 (Control+Z). See note following the table.
\ A backslash (“\”) character.
% A “%” character. See note following the table.
_ A “_” character. See note following the table
Reference
Stack Similar Question
You should use bind variables in your SQL statement. As already mentioned this is done with PreparedStatements in Java.
To make sure, only valid column names are used, you can validate the input against the database. MySQL provides schema information like columns of each table as part of the INFORMATION_SCHEMA. For further information, check the MySQL documentation:
"The INFORMATION_SCHEMA COLUMNS Table"
I am concerned about inserting text in a MySQl table w.
I have to insert/update text that contains characters such as / " and '
The escape character / could be inserted only if the NO_BACKSLASH_ESCAPES SQL mode is enabled. wich interfere with the characters " and ' see this link http://dev.mysql.com/doc/refman/5.1/en/string-literals.html#character-escape-sequences
If anyone can explain to is in earth the mysql_real_escape_string() I don't came to understated
I would like to find a pure mysql solution
I am not using php. What I am trying to do here is to "simulate " Content Management System: I am about to write a C# coded solution that manage the content in its different forms(article, category ,tag, etc..) and generate .html files, the MySQl database is local in my computer next i will upload the .html files to the server.
I did this to ensure that all my html pages are html valid and because I don't trust any existent solutions (not only when it concerns coding but in life in general)
Please help
each php db connection extension (mysql, mysqli, pdo) has a special way to safe query against sql injections, when you are using mysql extension, it's strongly recommended to use mysql_real_escape_string() function to make safe all variables used in query, it's most widely used function. i think there isn't any pure solution (when you are using mysql extension in php).
from php.net:
mysql_real_escape_string()-Escapes special characters in the
unescaped_string, taking into account the current character set of the
connection so that it is safe to place it in a mysql_query().
Whatever string data can be inserted into SQL query, if formatted according to 2 rules
it is enclosed in quotes (preferably single ones)
it is passed through mysql_real_escape_string()
if both rules followed, there would be not a single problem with whatever characters, either slashes, quotes or anything.
According to your question, / has no special meaning in MySQL. It's \ that is escape character. It can be escaped by another backslash as well.
$str = 'slashes \ quotes \' or whatever " else symbols';
var_dump($str);
$str = mysql_real_escape_string($str);
$sql = "INSERT INTO table SET str='$str'";
I'm working on a Spanish language website where some text is stored in a MS SQL 2008 database table.
The text is stored in the db table with characters such as á, í and ñ.
When I retrieve the data, the characters don't display on the page.
This is probably a very simple fix but please educate me.
You must use Unicode instead of ANSI strings and functions, and must choose a web page encoding that has the required character set. Some searches on those terms will yield all you need. Look up content type 1252 and 8859 as well in case you get stuck (examples, not answers).
I want to Remove Invalid unicode Characters from a field in sql server.
How to achieve that?
What exactly do you count as "invalid" characters?
What is the data-type of the field (char/varchar) or (nchar/nvarchar)
What you may find is that this is an instance where a SQLCLR function to take a SqlString as an input and return a SqlString.
You can then use the more powerful .NET String-manipulation, Encoding, and Globalization features.
Does MySql 5.1 and SQL Server 2008 (Web edition, Standard) have any functional password limitations other than length limits? Are metacharacters in any form a bad idea to use, like bang, pipe, hash, any slash, carrot, and so on?
I know that MySql 5.1 has a password length limitation of 16 characters that is hardcoded, but I was wondering, are any metacharacters (i.e. non alphanumerics) a bad idea to use? And is this true in SQL Server 2008 Web edition, Standard?
So specifically: can symbols like:
/`~>:}{[]^ be used successfully?
I would hope it doesn't matter to the database, but I don't understand enough about password storage in enterprise database systems yet to know for sure, and I was looking for confirmation or an explanation.
All these characters are good in SQL Server passwords, but the docs to back it up are sketchy.
The MSDN documentation on SQL Server password strength implies that any symbol including whitespace characters is allowed in SQL Server passwords, but if it contains white space it must be delimited in T-SQL statements.
Microsoft SQL Server passwords can contain up to 128 characters, including letters, symbols, and digits. Because logins, user names, roles, and passwords are frequently used in Transact-SQL statements, certain symbols must be enclosed by double quotation marks (") or square brackets ([ ]). Use these delimiters in Transact-SQL statements when the SQL Server login, user, role, or password has the following characteristics:
Contains or starts with a space character.
Starts with the $ or # character.
The MSDN documentation on password policy explicitly confirms the following characters are allowed: ! $ # %
And, as you'd already know, the same documentation strongly encourages that you use passwords which are "as long and complex as possible."
mysql> create user test identified by '/`~>:}{[]^';
Query OK, 0 rows affected (0.13 sec)
yes - you can actually login now with this command line:
C:\Documents and Settings\rbouman2>mysql -utest -h127.0.0.1 -P3351 -p
Enter password: **********
I tried entering the password directly after -p, but that didn't work for windows - it thinks i want to invoke more if I do that. but I am 100% sure that's on the windows shell. MySQL itself feels this is a valid password.
In my experience, it's the backslash \ and the single quote ' that you'll want to avoid in a MySQL password. From my tests, the following special characters appear to be fine to use:
!##$%^&*:./?=+-_[]{}()<>
Also, 32-character passwords seem to be okay to use, too.
Watch out, even though MYSQL may work, your php/http daemon/.htaccess may do some wierdness to the req's before passing them along, I had a password with ( $ and ! in it, and it did NOT work from php-mysql based web page, but DID work from the console... 8 character password. $db_pass = "($JlKl1!";
And what do you know, it fails.
change the password to "test" . and bam, it works.
Change the password to something ridiculously long, (and entirely devoid of "$" or "!" or "(" ) and it also worked.