SitePoint Sponsor

User Tag List

Results 1 to 14 of 14
  1. #1
    SitePoint Enthusiast
    Join Date
    Jun 2006
    Posts
    26
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    sql injections with php...

    If i have magic_quotes enabled, why do i need mysql_real_escape_string, mysql_escape_string, add_slashes....
    isn't it all the same?

    Now, why when i use magic_quotes and then i use 'stripslashes' and print the result it still print the slashes?
    even tho it works fine when i compare it with the database.

    thx.

  2. #2
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by aleminio View Post
    If i have magic_quotes enabled, why do i need mysql_real_escape_string, mysql_escape_string, add_slashes....
    isn't it all the same?
    Yes, they do the same. You should however only use one of them, or you will encode your data twice, which corrupts the data. This is the problem, you're experiencing.
    If you do it correct, you do not need to run data through stripslashes, when you pull it back out from the database. If you find you need to do that, you have corrupt data. The reason is, that data isn't stored in the database, with slashes. It's only an encoding, which is used for transporting data from PHP to the database. Conceptually, the database runs stripslashes automatically, when it gets data from PHP.

  3. #3
    SitePoint Enthusiast
    Join Date
    Jun 2006
    Posts
    26
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    You're right, i didn't notice i have used it twice.

    now i don't understand why my code works as it works.

    When i register, it works fine, i see the username in the database without any slashes.
    Then when i login, i have the page which checks the username\password against the database.
    It works well but the problem is when i get the username out from the cookies.

    I have to first use "stripslashes" so i can compare the username against the database without getting any errors
    and then when i finish the comparison, i have to use "stripslashes" again so i could print the username without any extra slashes.
    does it add slashes again when i store the username in the cookies?

    There is something else i don't understand.
    How\why websites are being hacked by sql injections if magic_quotes is always 'on' ?

    sorry for my english and i hope you understand my questions.
    Last edited by aleminio; Aug 4, 2007 at 10:15.

  4. #4
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    magic_quotes does a fairly good job at protecting against SQL injection attacks. Unfortunately it tends to cause a lot of confusion, partially because it happens invisibly, and partially because it happens in the wrong place. When programmers get confused, one of two things happen; The first thing which happens is, that data become escaped more than once, thereby corrupting the data. A programmer noticing this will try to correct the wrong by applying stripslashes. He will often do it in the wrong place. Even if it's done in the right place, it reverses the protection given by magic_quotes, and injection attacks becomes possible.

    The best thing you can do is probably to understand exactly why escaping data is needed. It's simple enough once you understand it, but it normally takes a while to have it sink in properly. Did for me at least, and judging from the number of questions on the topic, I'd say I'm not alone.

    magic_quotes have officially been deprecated, and so they are often off by default. I suggest that you write your code without using magic_quotes. Not just because it's being deprecated, but because it causes confusion, and confusion leads to bad security. You will then need to escape data manually, but this isn't really a big issue. Just remember to do it in the proper place (Unlike magic_quotes). That is - use addslashes (or mysql_real_escape_string) when you create your SQL queries. Instead of doing this manually all the time, you can also use an abstraction layer to do it for you. If you are using PHP5, you can use PDO, which has parametrised queries.

    Your problem with cookies is directly related to magic_quotes, and further confused by you accidentally having double-escaped data. With magic_quotes on, cookies are escaped, so you don't have to quote it, when creating SQL queries. This means, that you can't compare a string in cookie to another variable (Not even one pulled from the database).

  5. #5
    SitePoint Wizard Hammer65's Avatar
    Join Date
    Nov 2004
    Location
    Lincoln Nebraska
    Posts
    1,161
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Close but not quite. addslashes and magic_quotes have serious vulnerabilities in them, related to character sets. The functions, mysql_real_escape_string and pg_escape_string (if you are using Postgres) do not have these security holes.

    They are both part of the client libraries that come with their respective databases rather than being part of the extension code. Because of this, you need to have a valid database connection first before using them.

    Magic quotes is depreciated (thank you lord) and will be gone from PHP in version 6. I would recommend disabling it or using stripslashes on all input if it's enabled. It's a big pain and should have never been in the language spec.

    The only way PHP has of communicating with MySQL is through SQL statements. SQL is a interpreted language just like PHP is. Just like PHP it has certain characters that have special meaning in the language. In order to avoid confusing the interpreter about where a string of text begins and ends for instance, you need to escape any double quotes that are intended to be part of the content of a string, if they are inside a double quoted string. The same goes for single quotes inside a single quoted string. No different than in PHP itself.

    If for instance you had a query like...

    Code:
    SELECT * FROM people WHERE name='O'Grady';
    The parser might think you had a string with just 'O' in it and then a unterminated string at the end, which would cause an error.

    Code:
    SELECT * FROM people WHERE name='O\'Grady';
    That will tell the parser that the string should contain O'Grady.

    There are also characters that the escape functions filter out to avoid injection of malicious SQL. Especially ";".

    addslashes/mq can be fooled.

  6. #6
    SitePoint Wizard cranial-bore's Avatar
    Join Date
    Jan 2002
    Location
    Australia
    Posts
    2,634
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    The problem with MQ is that it's applied automatically for all GET, POST and COOKIE values. It has no way of knowing whether any particular piece of data was headed for the DB, so you often get escaping when you don't need it.

    My advice is to turn MQ off and manually escape (or use DB abstraction) on the data that is actually used in a query.
    Use htmlspecialchars when displaying data, and you should never need stripslashes.

    As mentioned mysql_real_escape_string is more secure than addslashes because it takes the character encoding into account.

  7. #7
    SitePoint Wizard Hammer65's Avatar
    Join Date
    Nov 2004
    Location
    Lincoln Nebraska
    Posts
    1,161
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    This is true, in fact the the "GPC" in magic_quotes_gpc means GET POST COOKIE. Unfortunately if you are able to disable it depends on the control you have over the server you are using. It can be done via htaccess, if the Apache configuration allows it and if PHP is running as an Apache module.

    If you can't turn it off, you will have to use stripslashes on input you want to use. The best thing to do is craft a function that you can use anywhere. Make sure it can handle arrays as stripslashes does not. A little recursion will take care of that.

  8. #8
    SitePoint Wizard gold trophysilver trophybronze trophy dc dalton's Avatar
    Join Date
    Nov 2004
    Location
    Right behind you, watching, always watching.
    Posts
    5,431
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Hammer65 View Post
    Close but not quite. addslashes and magic_quotes have serious vulnerabilities in them, related to character sets. The functions, mysql_real_escape_string and pg_escape_string (if you are using Postgres) do not have these security holes.
    Was just going to say the same thing .... besides magic_quotes are the devil's spawn!

    BTW, you just gotta love the mysql_real_escape_string function, what in the HECK were they thinking about when they named that thing!

  9. #9
    SitePoint Enthusiast
    Join Date
    Jul 2007
    Location
    Virginia
    Posts
    87
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Here's another reason to go with mysql_real_escape_string instead of magic quotes, because on some servers people don't have this enabled or have the ability to change this configuration. So if your building a program to work on a wide range of servers with a certain version of php enabled you should look at it from this standpoint.

    Another poster above did explain about character sets and how you should use the mysql_escape... function to escape text instead of relying on addslashes.
    Mark A. Drake
    - Mark A. Drake
    - OnSlaught

  10. #10
    SitePoint Wizard Hammer65's Avatar
    Join Date
    Nov 2004
    Location
    Lincoln Nebraska
    Posts
    1,161
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    simple_function_with_really_long_name();

  11. #11
    SitePoint Enthusiast
    Join Date
    Jun 2006
    Posts
    26
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thank you all, just a few more things

    "Use htmlspecialchars when displaying data, "

    it's just a way of printing an escaped data without using stripslashes?


    and what functions should i use to check what chars the user has typed?
    i don't want the user to register with those special chars any way.

  12. #12
    SitePoint Wizard Hammer65's Avatar
    Join Date
    Nov 2004
    Location
    Lincoln Nebraska
    Posts
    1,161
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    No HTML has it's own set of characters that mean something in the language. If those characters appear in content, that output is invalid. In most programming languages, that would cause an error condition, with HTML it can cause problems as well.

    The main reason that the suggestion was made however is that there is a way, through user input that is later displayed, for someone to inject javascript or links to malicious sites into your document. htmlspecialchars and htmlentities will escape that kind of content and make it harmless (hopefully, although someone always finds a hole).

  13. #13
    SitePoint Wizard cranial-bore's Avatar
    Join Date
    Jan 2002
    Location
    Australia
    Posts
    2,634
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Even if you remove any HTML from data before storing, it's a good idea to use htmlspecialchars, especially for anything that'll be output as form field values.

    Imagine that someone stores the value Ian Mc'Bane and you want to pre-populate a form field with that value:
    Code HTML:
    <input type='text' value='Ian Mc'Bane'>
    <input type='text' value='Ian Mc& #039;Bane'>
    (The space after & is just to stop this forum software rendering the code as a single quote)

    The first line is what your resultant HTML might look like with no escaping. The single quote in the name Mc'Bane is going to bugger up the HTML, closing the attribute prematurely and causing problems.

    The second line has been run through htmlspecialchars and characters like < > ' " have been converted to their character codes. Your HTML is valid, the form will work, and the user doesn't see anything other than their original data.

    and as mentioned escaping data like this can be helpful to protect against XSS.

    You are right to limit the characters that can be used for a username. If you wanted to limit them to letters, numbers, the dash and the underscore you might have something like this as part of your registration code:
    PHP Code:
    if(!preg_match('/^[a-zA-Z0-9\_\-]+$/'$username)) {
        
    $error 'Invalid username. Only alphanumeric characters, the dash and the underscore can be used';


  14. #14
    SitePoint Wizard stereofrog's Avatar
    Join Date
    Apr 2004
    Location
    germany
    Posts
    4,324
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Hammer65 View Post
    addslashes/mq can be fooled.
    real_escape_string was buggy in mysql versions prior to 5.0.22, and could be "fooled" quite as easy as addslashes (under same conditions, i.e. using GBK charset or similar). See comments to that blog post.


Bookmarks

Posting Permissions

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