SQL Injection attacks about squel HOT 12 CLOSED

We can use this function :

function mysql_real_escape_string (str) {
    return str.replace(/[\0\x08\x09\x1a\n\r"'\\\%]/g, function (char) {
        switch (char) {
            case "\0":
                return "\\0";
            case "\x08":
                return "\\b";
            case "\x09":
                return "\\t";
            case "\x1a":
                return "\\z";
            case "\n":
                return "\\n";
            case "\r":
                return "\\r";
            case "\"":
            case "'":
            case "\\":
            case "%":
                return "\\"+char; // prepends a backslash to backslash, percent,
                                  // and double/single quotes
        }
    });
}

from squel.

I originally didn't include such a function because I was aware that most db engines provide their own escape()-ing methods. However, perhaps we can include something generic and then make it overridable by client code...?

from squel.

Well, even if the function name means that is for MySQL, I think it's generic to all SQL databases.

from squel.

Well, the MySQL function for escaping strings shouldn't be used when modifying a db with, say, PostgreSQL. Nevertheless it might still be worth including something generic. If there's enough demand for this I'll code it in.

from squel.

Alternatively I'll be happy to accept a pull request for the same with test and doc updates.

from squel.

Why are the .where() conditions not escaped? This renders the function wide open to SQL injection. The typical approach is to use ?'s (e.g.,.where('foo = ?', 2)). This allows users to specify whatever comparison operators they need (e.g., .where('x >= ?', 10), etc.).

from squel.

@mikejholly This technique is actually now available as of #16. I just need to update the docs and re-publish.

from squel.

Nice. Thanks for the update!

On Tue, May 28, 2013 at 9:50 PM, Ramesh Nair [email protected]:

@mikejholly https://github.com/mikejholly This technique is actually
now available as of #16 #16. I
just need to update the docs and re-publish.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/8#issuecomment-18596022
.

from squel.

Docs updated about where parameter substitution.

from squel.

Hi,

Rather than opening a new issue I'm just using this one (you might want to close it after, because #16 should have closed it).

I wanted to know if your library is as bullet proof against SQL injection that sequelize is.
Here is some code that you might want to borrow: https://github.com/sequelize/sequelize/blob/641624eb7d620d6bd7ceca6eb43473f9fc2f3e12/lib/sql-string.js

Thanks,
Antoine

from squel.

@amarcadet That's nice.

So far opted for the route of letting the db engine methods do the escaping (since they'll be better at it). Just now I've pushed out v2.0.0 with much better parameterized querying support to help with that.

Also, for non-scalar value types (e.g. Objects instantiated from classes) Squel allows you to register a custom value type handler, thus allowing you to escape and format the value to your heart's content. This also means Squel doesn't need to have built-in support for every value type out there across every db engine dialect.

Between the new parameter substitution and custom value types I think Squel provides enough tools for safe querying. But if this is really a sticking point for folks then I can certainly look into implementing a more hard-core value sanitizer.

from squel.

Am closing this now. With [parameterized querying support(http://hiddentao.github.io/squel/#parameters) there's no longer any need for Squel to do value escaping.

from squel.