I am using MySQL connection string to connect to a MySQL database in my current project.
Server=127.0.0.1;Uid=root;Pwd=12345;Database=test;
But the connection throws ecxeption when one of the paremeters contain ; symbol. For example:
Pwd=12;345
Exception:
Keyword not supported.
Parameter name: 345;Database
How to solve this problem?
Check your connection string at here
And your pasword looks like contain illegal value for MySQL..
Just look at your code.
e.g Server=127.0.0.1;Uid=root;Pwd=12345;Database=test;
before Pwd, it have already has ; then after your password, it still have ;
so, it means that password start from ";" and end at ";" again.
So, the best suggestions is change your password.
Hope will be help
Enclose your password in double quotes.
See http://msdn.microsoft.com/en-us/library/system.data.sqlclient.sqlconnection.connectionstring%28VS.71%29.aspx under the Remarks section about a third of the way down.
The basic format of a connection string consists of a series of keyword/value pairs separated by semicolons. The equal sign (=) connects each keyword and its value. To include values that contain a semicolon, single-quote character, or double-quote character, the value must be enclosed in double quotes. If the value contains both a semicolon and a double-quote character, the value can be enclosed in single quotes. The single quote is also useful if the value begins with a double-quote character. Conversely, the double quote can be used if the value begins with a single quote. If the value contains both single-quote and double-quote characters, the quote character used to enclose the value must be doubled each time it occurs within the value.
Related
please look here:
UPDATE cars_tbl
SET description = '{\rtf1'
WHERE (ID=1)
Description field is "blob", where my RTF document is to be stored.
When I check updated data I always find
{
tf1
\r simply disapears. I tried to find solution on the web, but no success. My rtf files are corrupted on many places, because the escape characters used in the string are substituted. How to suppress this substitution and update field with string as is?
Thanx for advice
Lyborko
Backslash is an escape character, so to keep it you need a double backslash:
UPDATE cars_tbl
SET description = '{\\rtf1'
WHERE (ID=1)
As an aside \r is a carriage return.. and it hasn't disappeared in your data; it is responsible for tf1 appearing on the line below the {.
You can achieve this with a more generic approach
use of QUOTE() in mysql
MySQL QUOTE() produces a string which is a properly escaped data value in an SQL statement, out of an user supplied string as argument.
The function achieve this by enclosing the string with single quotes, and by preceding each single quote, backslash, ASCII NUL and control-Z with a backslash.
example
UPDATE cars_tbl
SET description = QUOTE('{\rtf1')
WHERE (ID=1)
UPDATE
to escape your RTF you can also just use REPLACE this way all your \ will become \\
Example
UPDATE cars_tbl
SET description = REPLACE('{\rtf1', '\', '\\')
WHERE (ID=1)
Is there any way to perform a SQL injection when single quotes are escaped by two single quotes? I know the MySQL server is using this specific technique to prevent against an attack. I'm trying to log in as a specific user but all of the common injections I've tried for the password have not worked successfully (i.e. ' or '1'='1, ' or ' 1=1, etc.).
No, and yes.
There's no way to have an unsafe values "breakout" of literal values that are enclosed in single quotes, if the value being supplied is "escaped" by preceding single quotes by with an additional single quote.
That is, assuming that your statement is guaranteeing that string literals are enclosed in quotes, as part of the "static" SQL text.
example perl-ish/php-ish
$sql = "... WHERE t.foo = '" . $safe_value . "' ... ";
^ ^
I've underscored here that the single quotes enclosing the literal are part of the SQL text. If $safe_value has been "escaped" by preceding each single quote in the "unsafe" value with another single value to make it "safe"...
$unsafe_value $safe_value
------------- ------------
I'm going I''m going
'she''s' ''she''''s''
1'='1 -- 1''=''1 --
As long as the escaping is handled properly, that we guarantee that potentially unsafe values are are run through the escaping, then including single quotes in data values is not a viable way to "breakout" of a literal with the SQL text.
That's the "no" part of the answer.
The "yes" part of the answer.
One of the biggest problems is making sure this is done EVERYWHERE, and that a mistake has not been made somewhere, assuming that a potentially unsafe string is "safe", and is not escaped. (For example, assuming that values pulled from a database table are "safe", and not escaping them before including them in SQL text.)
Also, the single quote trick is not the only avenue for SQL injection. The code could still be vulnerable.
Firstly, if we're not careful about other parts of the statement, like the single quotes enclosing string literals. Or, if for example, the code were to run the $sql through some other function, before it gets submitted to the database:
$sql = some_other_function($sql);
The return from some_other_function could potentially return SQL text that was in fact vulnerable. (As a ridiculous example, some_other_function might replace all occurrences of two consecutive single quotes with a single single quote. DOH!)
Also, with the vast number of possible unicode characters, if we're ever running through a characterset translation, there's also a possibility that some unicode character could get mapped to a single quote character. I don't have any specific example of that, but dollars to donuts that somewhere, in that plethora of multibyte encodings, there's some unicode character somewhere that will get translated to a single quote in some target.
There's a default character in the target for unmapped characters in the source, and that's usually a question mark (or a white question mark in a black diamond.) It would be a huge problem if the default character in the target (for unmapped characters in the source) was a single quote.
Bottom line: escaping unsafe strings by replacing single quotes with two single quotes goes a long ways towards mediating (mitigating?) SQL injection vulnerabilities. But in and of itself, it doesn't guarantee that code is not vulnerable in some other way.
if the input accepts unicode and is implicitly converted to ascii in the database (not as uncommon as it sounds) then an attacker can simply substitute ʻ or ʼ (0x02BB or 0x02BC) in place of single tick to get around the escaping mechanism and the implicit conversion will map those characters to single ticks (at least that's the case in SQL Server)
Does MYSQL has a bult-in escaping mechanism?
I'm running some scripts and inserting values to a MYSQL Database. When monitoring the script everything seems ok, printing outputs shows everything is in order, but when checking the database, some values get inserted in a weird fashion, with some letters replaced with control characters or breakspaces (I´m doing set basename=!var:~7! to get the values to insert that present problems).
Specifically, the lowercase b is replaced with a BS char and lowercase r with a break.
Since the script is a Windows Batch File, I was wondering if I can force to escape those characters via query (like mysql_real_escape_string in PHP but directly in MYSQL) or set some option server side so the database take care of those cases.
Any ideas?
What you describe is the result we would expect, given a backslash character in the input stream.
Where '\b' occurs in a string literal, that will be interpreted as a backspace character.
Where '\r' occurs in a string literal, that will be interpreted as a carriage return character.
To avoid the interpretation of these (and other similar) special "escape sequence" characters, the normative pattern is to precede the backslash character with another backslash.
Where '\\' occurs in a string literal, that will be interpreted as a single backslash character.
So, to answer your questions... yes, MySQL has a builtin "escape sequence" for special characters; that sounds like the problem you are encountering; some of your backslash characters are being interpreted as "escape sequences".
And, no, there's no option in the mysql command line client to perform mysql_real_escape_string type functionality. The command line client passes the strings to the server as it receives them.
But it is possible to set sql_mode of the session to include the NO_BACKSLASH_ESCAPES option. That disables the interpretation of the backslash character as the start of special escape sequence, and a backslash character will interpreted as a literal backslash character.
To query the current sql_mode of the session:
SELECT ##SESSION.sql_mode ;
To set the current sql_mode, e.g.
SET SESSION sql_mode = 'NO_BACKSLASH_ESCAPES'
NOTE: the SET statement will overwrite the current sql_mode, not just change the one setting. So you may just want to add to the existing sql_mode, if it's already set to something other than blank, e.g.
If current sql_mode is set to 'ALLOW_INVALID_DATES,ANSI_QUOTES', you'd want to just add the option to the current setting, e.g.
SET SESSION sql_mode = 'ALLOW_INVALID_DATES,ANSI_QUOTES,NO_BACKSLASH_ESCAPES'
I Have selected these lines from Mysql official site dev.mysql.com.
I am unable to understand what these lines means.
There are several ways to include quote characters within a string:
A “'” inside a string quoted with “'” may be written as “''”.
A “"” inside a string quoted with “"” may be written as “""”.
I did not understand how this sql.
mysql> SELECT 'hel''lo';
Outout: hel'lo
Please Help
You have a string inside single quotes, then it finds another quote, escaped by yet another code. So, it will translate into
'(start of string)hel'(escaping the next quote)'(the escaped quote)lo'(ending the string)
And thus outputting:
hel'lo
It's simple. If you need to put a quote within a string literal delimited by those quotes, you can't use just a standalone quote character (like 'O'Brien') since there's no easy way to tell which of the second or third quote is the closing quote.
So they introduce a rule. If the SQL interpreter is within a quoted string and it finds another quote, it uses these rules:
if the quote is immediately followed by another quote, assume the user wants one quote within the literal.
otherwise it's the closing quote for the literal.
So, for example, consider:
select * from people where surname = 'O'Brien' order by id
Now you and I can tell which of those quotes actually terminates the string literal because we understand how names work. The computer does not take that for granted, instead requiring:
select * from people where surname = 'O''Brien' order by id
and turning the '' inside the literal into a single '.
I have a query in the following way.....i have a column named location_ns and it contains
'Marriott\256 Hotel & Convention Centre' as it's value. But query is not resulting any id.
when i remove \ in both value and query it is working.
SELECT id
FROM notice
WHERE
lon = 78.48693966865540000000
AND lat = 17.42434596639255000000
AND location_ns = 'Marriott\256 Hotel & Convention Centre'
AND notice_type="text"
Please let me know if any one has a solution for it
As documented under String Literals:
Within a string, certain sequences have special meaning unless the NO_BACKSLASH_ESCAPES SQL mode is enabled. Each of these sequences begins with a backslash (“\”), known as the escape character. MySQL recognizes the escape sequences shown in Table 9.1, “Special Character Escape Sequences”. For all other escape sequences, backslash is ignored. That is, the escaped character is interpreted as if it was not escaped. For example, “\x” is just “x”.
Therefore, you must escape your backslash:
AND location_ns = 'Marriott\\256 Hotel & Convention Centre'
However, you would do well to pass your literals to MySQL as parameters to a prepared statement.
\ is an escape sequence in MySQL. If you had a record with value:
Marriott\256 Hotel & Convention Centre
You would need to query for it like
AND location_ns = 'Marriott\\256 Hotel & Convention Centre'
This let's MySQL know you are looking for a literal \.