I have an update query that updates a column that holds another application SQL query.
Putting SQL inside has been problematic I wanted to resolve it with escape characters.
update
my_table
set
sql_column = 'UPDATE inner_table SET user_name=\'user_name\' text=\'this this free text with things like \" inside it and drives me made\''
where
condition_col = 123456
The above is correct in any SQL syntax checker; however, Sybase throws an error simply Incorrect syntax new 'username.'
I am new to Sybase; please help.
I was expecting that Sybase would behave like MySQL, which is different.
Sybase (and ansi-standard SQL*) escapes the single quote with itself. You don't need to do anything special with a double quote inside a string literal (since in ansi-standard SQL double quotes do not create literals).
sql_column = 'UPDATE inner_table SET user_name=''user_name'' text=''this this free text with things like \\" inside it ...'
But Sybase will NOT behave like MySQL (it's far more standards compliant).
Lacking some context here, but this kind of code is also likely to end up leaving you dangerously susceptible to SQL injection issues, and that's a really big deal.
* The link is for Informix, but it does a good job explaining the standard
Related
The MySQL documentation says that it should be \'. However, both scite and mysql shows that '' works. I saw that and it works. What should I do?
The MySQL documentation you cite actually says a little bit more than you mention. It also says,
A “'” inside a string quoted with “'” may be written as “''”.
(Also, you linked to the MySQL 5.0 version of Table 8.1. Special Character Escape Sequences, and the current version is 5.6 — but the current Table 8.1. Special Character Escape Sequences looks pretty similar.)
I think the Postgres note on the backslash_quote (string) parameter is informative:
This controls whether a quote mark can be represented by \' in a string literal. The preferred, SQL-standard way to represent a quote mark is by doubling it ('') but PostgreSQL has historically also accepted \'. However, use of \' creates security risks...
That says to me that using a doubled single-quote character is a better overall and long-term choice than using a backslash to escape the single-quote.
Now if you also want to add choice of language, choice of SQL database and its non-standard quirks, and choice of query framework to the equation, then you might end up with a different choice. You don't give much information about your constraints.
Standard SQL uses doubled-up quotes; MySQL has to accept that to be reasonably compliant.
'He said, "Don''t!"'
What I believe user2087510 meant was:
name = 'something'
name = name.replace("'", "\\'")
I have also used this with success.
There are three ways I am aware of. The first not being the prettiest and the second being the common way in most programming languages:
Use another single quote: 'I mustn''t sin!'
Use the escape character \ before the single quote': 'I mustn\'t sin!'
Use double quotes to enclose string instead of single quotes: "I mustn't sin!"
just write '' in place of ' i mean two times '
Here's an example:
SELECT * FROM pubs WHERE name LIKE "%John's%"
Just use double quotes to enclose the single quote.
If you insist in using single quotes (and the need to escape the character):
SELECT * FROM pubs WHERE name LIKE '%John\'s%'
Possibly off-topic, but maybe you came here looking for a way to sanitise text input from an HTML form, so that when a user inputs the apostrophe character, it doesn't throw an error when you try to write the text to an SQL-based table in a DB. There are a couple of ways to do this, and you might want to read about SQL injection too.
Here's an example of using prepared statements and bound parameters in PHP:
$input_str = "Here's a string with some apostrophes (')";
// sanitise it before writing to the DB (assumes PDO)
$sql = "INSERT INTO `table` (`note`) VALUES (:note)";
try {
$stmt = $dbh->prepare($sql);
$stmt->bindParam(':note', $input_str, PDO::PARAM_STR);
$stmt->execute();
} catch (PDOException $e) {
return $dbh->errorInfo();
}
return "success";
In the special case where you may want to store your apostrophes using their HTML entity references, PHP has the htmlspecialchars() function which will convert them to '. As the comments indicate, this should not be used as a substitute for proper sanitisation, as per the example given.
Replace the string
value = value.replace(/'/g, "\\'");
where value is your string which is going to store in your Database.
Further,
NPM package for this, you can have look into it
https://www.npmjs.com/package/mysql-apostrophe
I think if you have any data point with apostrophe you can add one apostrophe before the apostrophe
eg. 'This is John's place'
Here MYSQL assumes two sentence 'This is John' 's place'
You can put 'This is John''s place'. I think it should work that way.
In PHP I like using mysqli_real_escape_string() which escapes special characters in a string for use in an SQL statement.
see https://www.php.net/manual/en/mysqli.real-escape-string.php
Following on from this question MySQL database contains quotes encoded and unencoded and it's breaking javascript
I am executing this MySQL query:
DELETE FROM `example` WHERE `name` = ''12345''
However it fails because the value in the database is '12345'. It seems that old data in the database has a mixture of encoded and unencoded quotes. Is it safe to to update all ' to ' in the database?
In most cases (yours included), store text without any "encoding". That is, do not store htmlentities, store the actual characters, do not store unicode 'codes', store the actual characters, etc.
Do likewise for anything you need to compare to what is in the database.
You will, however, have to escape strings when building SQL statements. Otherwise, you can't get quotes (in text) inside quotes (that are part of the SQL syntax.
That is, you will end up with this SQL when searching for that Irishman:
... WHERE `name` = 'O\'Brian'
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 was building a portal for my college with posting messages option. Hence I used LONGTEXT to store the message in mysql. But somehow the LONGTEXT doesn't accept the apostrophe mark.
It gives following error whenever I post some sentence with apostrophe mark:
"Error: You have an error in your SQL syntax; check the manual that corresponds
to your MySQL server version for the right syntax to use near 's open singles
tournament, will Electrical be able to maintain their dominance o' at line 1"
PS: not in the escape string, but in <textarea>, if I input the apostrophe mark it gives the error!
Escape it with a backslash like
SELECT 'This is a escape \' quote test';
EDIT
If you are taking information directly from a web form and inserting it into a data base - this is a massive security risk. This is how SQL injection is done.
You have two problems.
You copied the value of the long text into your 'query' (presumably an INSERT or UPDATE statement, though it could simply be the value to compare with in a SELECT).
You did not notice that the first unescaped single quote after the opening quote terminates the string.
Given that you are using MySQL, I believe you have two options on escaping:
Standard SQL (applies to most, if not all, SQL DBMS): use two consecutive single quotes to insert one:
'''' -- Insert a string consisting of one single quote
'He said, "Don''t do that!"' -- A string containing a single quote
MySQL (may also be an option elsewhere, but not every SQL DBMS will recognize it): use a backslash to escape the single quote:
'\'' -- As above
'He said, "Don\'t do that!"' -- Also as above
There may also be functions you can use to do the escaping for you - depending on the host language you are using. However, the preferred way to get values into an SQL statement, especially ones that might contain random characters, is to use placeholders. The mechanics depend on the host language in which you are embedding the SQL, but the general idea is:
The raw SQL string looks like: INSERT INTO SomeTable VALUES(?, ?, ?);
You PREPARE the statement, more or less explicitly.
When you execute it, you provide the data as parameters to the EXECUTE.
Or, if it is a SELECT statement, you PREPARE it, you DECLARE a cursor for it, then you OPEN the cursor and provide the parameter values at that time.
In one SQL-based language (IBM Informix 4GL):
DEFINE a INTEGER, b DECIMAL(10,2), c VARCHAR(250)
LET a = 1
LET b = 99999999.99
LET c = 'He said, "Don''t do that!"'
PREPARE p1 FROM "INSERT INTO SomeTable(a,b,c) VALUES(?, ?, ?)"
EXECUTE p1 USING a, b, c
PREPARE p2 FROM "SELECT * FROM SomeTable WHERE c = ?"
DECLARE c2 CURSOR FOR p2
OPEN c2 USING c
Note that if you do not use placeholders, you have to be extremely careful not to fall into the SQL Injection trap.
use the backslash character to escape the string:
"Carlito\'s Ways"
You may need to unescape later, but PHP has a built-in function for that.
insert into customers(firstname, lastname)
values ('Bill', 'O\'Connor');
I'm assuming you need to escape your apostrophes with a backslash character (\), but it would also be intuitive to provide the SQL query that you attempted to execute in order for people to help you further.
In postgresql, it's possible to use "Dollar-Quoted String Constants" to avoid escaping single quotes in constant strings:
Without Dollar-Quoted String Constants:
'Jeff''s table'
With Dollar-Quoted String Constants:
$$Jeff's table$$
Is there a MySQL equivalent?
On edit: I'm not looking for a way to sanitize inputs, I'm looking for a way to make queries that generate sql easier to read.
No, because it doesn't really work. An attacker just addes a pair of dollar signs to their injection attempt instead.
The correct way to handle this is a system that uses real query parameters, such that the parameter values are never substituted directly into a query string. This is also generally better for performance because the db can do a better job caching the execution plan you don't end up building string dynamically, which tends to be slow in modern languages.
Not having excess concatenation statements greatly improves the readability of the code, as well. Instead of this:
sql = "SELECT * FROM MyTable WHERE Column1=$$" + somevarialbe + "$$ AND Column2=$$" + OtherVariable";
it's just this:
sql = "SELECT * FROM MyTable wHERE Column1=#Value1 AND Column2=#Value2";
Hmm... Okay, I can see some limited utility for this feature now.
Imagine a ticket tracking system with a stored procedure to get open tickets. You might actually hard-code the literal 'open' into the where clause of the query. Not that this would be a good design — ticket status should be in a table with it's own key, so that you'd hardcode the key rather than the text. But it plants the seed for something valid and more-complicated.
You can enclose your string in double quotes instead, e.g.
"Jeff's table"
Note: If this doesn't work, it means that you've got ANSI_QUOTES SQL mode turned on. The MySQL docs say:
If the ANSI_QUOTES SQL mode is enabled, string literals can be quoted only within single quotation marks because a string quoted within double quotation marks is interpreted as an identifier.