How can I disable string escape in $db->insert, I need to insert html in my database, so I don't want any string escape.Any solutions?
You don't want to disable that escaping.
Escaping data doesn't prevent you from inserting anything. In fact, quite the opposite: escaping data enables you to properly insert characters like quote marks that could otherwise confuse the database. More importantly, passing unescaped data directly to a database exposes an enormous security hole, making it trivial for a "hacker" (if we use the term liberally) to gain unrestricted access to your site and to your database.
You're probably confusing SQL escaping (which escapes data for use in SQL queries) with htmlspecialchars(), which escapes data for use on webpages. The two are unrelated.
Related
As a part of DB migration, we are moving to PostgreSQL and we observed that extra "" is inserting in bytea column of Quartz table. If we set the parameter "Standard_Conforming_strings" to off, we are able to save the data in proper format. As a part of our scenario, our record uses xml file as a input parameter and we are suspecting that by setting that parameter this setting may omit "" characters which are in xml file.
Can anyone suggest by setting this parameter to "off" is there any impact?
WPF application
PostgreSQL v11
Quartz 1.0.3.3
nHibernate 3.0.4000
dotconnectforPostgreSQL
We tried setting the "Standard_Conforming_strings" to off and its working . But we want to know the impact of this parameter change.
The impact is that sequences such as \n or \t (there are more) start having a special, non standard conforming, meaning in string literals: they are interpreted as special characters (in this case, newline and tabulator).
This is a leftover from the old days, when that was the normal behavior of PostgreSQL. If your client software needs that setting to work properly, that may be because you are using very old drivers to access the database (or the application itself is very old). Upgrading the client libraries and drivers may help.
I have a case where addresses and country names have special characters. For eg:
People's Republic of Korea
De'Paul & Choice Street
etc..
This data get send as JSON payload to backend to be inserted in a JSONB column in postgres.
The insert statement gets messed up because of the "single quote" and ends up erroring out.
The front-end developers are saying that they are using popular libraries to get country names etc and don't want to touch the data. They just want to pass as is.
Any tips on how to process such data with special characters especially something that contradicts with JSON formatted data and safely insert into postgres?
Your developers are using the popular libraries, whatever they may be, in the wrong fashion. The application is obviously vulnerable to SQL injection, the most popular way to attack a database application.
Use prepared statements, then the problem will go away. If you cannot do that, use the popular library's functions to escape the input string for use as an SQL string literal.
Is dollar quoting enough to prevent malicious inputs like SQL injection?
For example:
SELECT * FROM mytable WHERE title = $secret$ hack'-- $secret$
where user input is
hack'--
No, of course not, because the hacker could enter a string containing $secret$.
What you suggest goes by the name “security by obscurity” and enjoys ill respect among security experts. For example, it would not work at all with open source software.
Fortunately PostgreSQL and all relevant APIs have functions that make the safe construction of SQL statements simple.
I have ormlite integrated into an application I'm working on. Right now I'm trying to build in functionality to easily switch from automatically inserting data to the database to outputting the equivalent collection of insert statements to a file for later use. The data isn't user input but still requires proper escaping to handle basic gotchas like apostrophes.
Ideas I've burned through:
Dao.create() writes to the database directly, so that's a no-go.
QueryBuilder can't handle inserts.
JdbcDatabaseConnection.compileStatement() might work but the amount of setup required is inappropriate.
Using a java.sql.PreparedStatement has a reasonable enough interface (if toString() returns the SQL like I would hope) but it's not compatible with ormlite's connection types.
This should be very easy and if it is, I can't find the right combination of method calls to make it happen.
Right now I'm trying to build in functionality to easily switch from automatically inserting data to the database to outputting the equivalent collection of insert statements to a file for later use.
Interesting. So one hack would be to use the MappedCreate class. The MappedCreate.build(...) method takes a DatabaseType and a TableInfo which is available from the dao.getTableInfo().
The mappedCreate.toString() exposed the generated INSERT statement (with a prefix) which might help but you would still need to convert the ? arguments to be the actual values with escaped quotes. That you would have to do in your own code.
Hope this helps somewhat.
I feel like I'm missing a very basic concept. I could use some clarification or reference material.
On my website, I have a user that enters text into an input box and submits that to the database to be stored. I insert that text into the database using a function in the code block below where $conn->exec(query) is from Pg.pm.
$conn->exec("select someFunc($mykey,'text to insert');");
Now, this works, but is vulnerable to a sql injection or even if a user enters a comma, it breaks.
I read about DBD::Pg which has the prepare statement which seems what I want, but I could not find the equivalent of this for Pg.pm. Did I miss it?
If Pg.pm does not support prepare. Should I be using a perl module that supports the prepare statement? Or can I just follow the approach outlined at bobby-tables with quote_ident() and quote_literal in my SQL functions that are inserting/updating user-input fields.
How should I be handling user-input in a safe way?
You can not just use quote_ident and quote_literal, because they're at the SQL level, applying to dynamic SQL invoked with EXECUTE. It won't do you any good when passing arguments into the function because the SQL string parsing (and SQL injection attack risk) occurs before the function is even executed with those arguments.
You really need either prepared statement support or a strong, secure literal escaping function that understands PostgreSQL literal quoting rules. If your database driver provides neither then is is unacceptably insecure and should be discarded in favour of one that does.