Results 1 to 9 of 9
  1. #1

    addslashes() and mysql_escape_string()

    Is addslashes() the same as mysql_escape_string() in php?

  2. #2
    Join Date
    Feb 2003
    Location
    Connecticut
    Posts
    5,441
    Addslashes only escapes quotes by putting a slash before them. You shouldn't use this with SQL because you need to use stripslashes on the data when you retrieve it.. and in some rare cases, where the data may already have escaped characters, you end up with extra slashes that can be hard to get rid of.

    mysql_real_escape_string (which you should be using) only escapes characters which would cause mysql a problem.

    That's only a very basic/mediocre explanation, but it's the gist of it.

  3. #3
    Join Date
    Jul 2007
    Posts
    205
    Quote Originally Posted by Dan L View Post
    Addslashes only escapes quotes by putting a slash before them. You shouldn't use this with SQL because you need to use stripslashes on the data when you retrieve it.. and in some rare cases, where the data may already have escaped characters, you end up with extra slashes that can be hard to get rid of.

    mysql_real_escape_string (which you should be using) only escapes characters which would cause mysql a problem.

    That's only a very basic/mediocre explanation, but it's the gist of it.
    yeap but it still puting \ before quotes and it do goes to the database...

  4. #4
    Join Date
    Aug 2001
    Location
    Central USA
    Posts
    200
    Dan L provided a good answer about the difference between the functions.

    But IMHO, you shouldn't be using either. What you need to be using is PDO and prepared statements with placeholders. It is the absolute most secure way to make SQL queries, and you don't have to deal with escaping quotes of any of that other nonsense.

    It would look something like this:
    PHP Code:
    // Prepare SQL statement
    $sqlStatement $this->db->prepare("
        SELECT *
        FROM customers
        WHERE customer_id = :customer_id
        ORDER BY lastname ASC
        "
    );
    $execute $sqlStatement->execute(array('customer_id' => (int) $customerId));

    // Check result
    if($execute) {
        
    $result $sqlStatement->fetchAll(PDO::FETCH_OBJ);
    } else {
        
    $result false;

    InvoiceMore - Online Billing & Invoicing
    phpDataMapper - Object-Oriented PHP5 Data Mapper ORM

  5. #5
    PDO doesn't add any more security than mysql_real_escape_string .. i'm sure it in fact uses mysql_real_escape_string under the hood.

    mysql_real_escape_string also handles any special needs if you are using different character sets and whatnot. It's the way to go.

  6. #6
    Join Date
    Apr 2000
    Location
    California
    Posts
    3,051
    Don't always just reply on escape string functions and do additional checks with regular expressions to ensure the data passes security/sanity checks as well.

  7. #7
    Join Date
    Aug 2001
    Location
    Central USA
    Posts
    200

    * Not true at all...

    Quote Originally Posted by shootout View Post
    PDO doesn't add any more security than mysql_real_escape_string .. i'm sure it in fact uses mysql_real_escape_string under the hood.

    mysql_real_escape_string also handles any special needs if you are using different character sets and whatnot. It's the way to go.
    That is absolutely wrong. I suggest you do more research on prepared statements with named placeholders or at the very least read up on PDO at the PHP website with the link I provided before making a comment like that. A prepared statement will send the query to the database ahead of time so it can map it out and optimize it's performance by compiling the query and creating a 'query plan'. When you call the execute function later, it then sends only the values to the database, which are inserted into the placeholders of the query you sent earlier by the database engine itself.

    Here's a direct quote from the PHP manual on the PDO page: (emphasis added)
    Prepared statements and stored procedures

    Many of the more mature databases support the concept of prepared statements. What are they? You can think of them as a kind of compiled template for the SQL that you want to run, that can be customized using variable parameters. Prepared statements offer two major benefits:

    * The query only needs to be parsed (or prepared) once, but can be executed multiple times with the same or different parameters. When the query is prepared, the database will analyze, compile and optimize it's plan for executing the query. For complex queries this process can take up enough time that it will noticeably slow down your application if you need to repeat the same query many times with different parameters. By using a prepared statement you avoid repeating the analyze/compile/optimize cycle. In short, prepared statements use fewer resources and thus run faster.
    * The parameters to prepared statements don't need to be quoted; the driver handles it for you. If your application exclusively uses prepared statements, you can be sure that no SQL injection will occur. (However, if you're still building up other parts of the query based on untrusted input, you're still at risk).

    Prepared statements are so useful that they are the only feature that PDO will emulate for drivers that don't support them. This ensures that you will be able to use the same data access paradigm regardless of the capabilities of the database.
    Meaning that if you always use prepared statements with placeholders in every part of your query, you're safe from SQL-injection attacks.

    And another gem from the PDO::prepare() function page: (emphasis added)
    Calling PDO->prepare() and PDOStatement->execute() for statements that will be issued multiple times with different parameter values optimizes the performance of your application by allowing the driver to negotiate client and/or server side caching of the query plan and meta information, and helps to prevent SQL injection attacks by eliminating the need to manually quote the parameters.
    InvoiceMore - Online Billing & Invoicing
    phpDataMapper - Object-Oriented PHP5 Data Mapper ORM

  8. #8
    Exerpt from the php documentation for mysql_real_escape_string

    Using mysql_real_escape_string() around each variable prevents SQL Injection. This example demonstrates the "best practice" method for querying a database, independent of the Magic Quotes setting.
    Given that this is a wrapper for the C call given to us by the people who wrote mysql, I think its probably pretty safe.

    Don't get me wrong, PDO is fine as well, it's just not magically more secure than proper string escaping. I'll correct my self and state that it isn't using mysql_real_escape_string under the hood, and so if you are doing large inserts it's likely going to be faster since it looks like it just sends the raw data to the server instead of building up strings, sending the strings to mysql, and letting mysql parse them back out again, however mysql_real_escape_string will indeed be just as secure.

    PDO is fine... but mysql_query is simpler to get going, clearer in code, and just as secure if used in conjunction with mysql_real_escape_string, so take your pick.

  9. #9
    Join Date
    Sep 2005
    Location
    Canada
    Posts
    645
    Quote Originally Posted by Adam Hallett View Post
    Is addslashes() the same as mysql_escape_string() in php?
    A small point, but I believe you also need an existing connection to mysql before you can call mysql_real_escape_string().
    VPSVille.com
    Toronto, London, Dallas, Los Angeles
    Quality VPS hosting on Premium bandwidth

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •