MySQL root password and other configuration issues |
MySQL root password and other configuration issues |
Brian Chandler |
Jun 20 2010, 01:45 PM
Post
#21
|
Jocular coder Group: Members Posts: 2,460 Joined: 31-August 06 Member No.: 43 |
Or, simply use SQLite. But then the web host must have it also? No, not as far as I know. Read up at http://devzone.zend.com/article/760-SQLite-Introduction Um, well, unless I have misunderstood any of the words "No" and "Not", Christian is right -- of course the DB must be available on the web host if you want to run the same programs. But it is bundled with PHP5 (perhaps _not_ 4, if you're still on that), so the web host will almost automatically have it too. |
Christian J |
Jun 20 2010, 02:21 PM
Post
#22
|
. Group: WDG Moderators Posts: 9,630 Joined: 10-August 06 Member No.: 7 |
I guess being bundled doesn't guarantee all web host actually wants to enable it (editing the PHP configuration is mentioned in the article) though I can't see why not.
|
Christian J |
Jun 20 2010, 04:21 PM
Post
#23
|
. Group: WDG Moderators Posts: 9,630 Joined: 10-August 06 Member No.: 7 |
SQLite enabled and tested! Indeed it's much simpler than MySQL, all that's needed with PHP5 was adding
CODE extension=php_pdo.dll extension=php_sqlite.dll in the php.ini file. |
Christian J |
Jun 21 2010, 06:11 AM
Post
#24
|
. Group: WDG Moderators Posts: 9,630 Joined: 10-August 06 Member No.: 7 |
http://devzone.zend.com/article/760-SQLite...uction#Heading8 says:
"If any query in SQLite uses user-specified input you should take extra care to validate that input, to prevent SQL injection. Unlike in MySQL, where this would only cause an embarrassing query error, in SQLite it would allow the attacker to execute a query on your server, with potentially disastrous consequences." Could these potentially disastrous consequences make web hosts reluctant to allow SQLite? |
Brian Chandler |
Jun 21 2010, 06:46 AM
Post
#25
|
Jocular coder Group: Members Posts: 2,460 Joined: 31-August 06 Member No.: 43 |
http://devzone.zend.com/article/760-SQLite...uction#Heading8 says: "If any query in SQLite uses user-specified input you should take extra care to validate that input, to prevent SQL injection. Unlike in MySQL, where this would only cause an embarrassing query error, in SQLite it would allow the attacker to execute a query on your server, with potentially disastrous consequences." Could these potentially disastrous consequences make web hosts reluctant to allow SQLite? Could these potentially disastrous consequences make web hosts reluctant to allow SQLite? --- I don't think so. I don't understand the basis for claiming that in mysql there would "only be a query error". (You understand how sql injection works?) Simple program: sql_call("SELECT * FROM thing WHERE fish ='" . $_GET['breed'] . "'"); The user is supposed to supply something like 'salmon', and this forms a single query to do the obvious thing. But if the user supplies the string delineated by square brackets: [salmon'; DROP TABLE fish; 'x'='x] ... then this generates a perfectly valid sequence of SQL commands, where the middle one can do any mischief desired. This "works" just as well on MySQL as anywhere else. |
Christian J |
Jun 21 2010, 08:58 AM
Post
#26
|
. Group: WDG Moderators Posts: 9,630 Joined: 10-August 06 Member No.: 7 |
(You understand how sql injection works?) Only vaguely... QUOTE But if the user supplies the string delineated by square brackets: [salmon'; DROP TABLE fish; 'x'='x] ... then this generates a perfectly valid sequence of SQL commands, where the middle one can do any mischief desired. When I tried that I just got Warning: mysql_fetch_array(): supplied argument is not a valid MySQL result resource, and the table is still there. I simplified the code a little: CODE #$result = mysql_query("SELECT * FROM Thing WHERE Fish ='Salmon'"); // works $result = mysql_query("SELECT * FROM Thing WHERE Fish ='Salmon'; DROP TABLE Thing; 'x'='x'"); // doesn't work #$result = mysql_query("DROP TABLE Thing"); // doesn't work echo '<pre>'; while($row = mysql_fetch_array($result)) { print_r($row); } echo '</pre>'; Is something wrong with my code? Do I need the DROP privilege (how can I tell, or set it)? Or has MySQL prevented this? Haven't tested with SQLite. |
Brian Chandler |
Jun 21 2010, 10:08 AM
Post
#27
|
Jocular coder Group: Members Posts: 2,460 Joined: 31-August 06 Member No.: 43 |
QUOTE Is something wrong with my code? Do I need the DROP privilege (how can I tell, or set it)? Or has MySQL prevented this? Haven't tested with SQLite. I'm sorry, I was only sketching -- you need to work out the details (the script kiddies already have). The basic error is assuming that a user input will be the sort of string it is meant to be. So typically you use mysql_real_escape_string() to ensure that the string will not leak outside the surrounding quotes. That's why (I am told by people whose names I have fogotten) you can get into "signup" boxes you don't really belong to by entering in the password box ['; 'x'='x] which converts an SQL test for a password match into an expression with the value TRUE. Well, roughly. Anyway, I don't understand the details of SQL "privileges"; pair gives me three logins for each database: full access, read-write (can't create or drop tables), and read-only. Don't think that's the problem anyway: your error message says that $result is not a valid resource -- when the SQL command doesn't return rows (as DROP, or CREATE, etc don't), then I don't suppose you can expect to get a row with mysql_fetch_array(). More basically, one thing you can be *absolutely* certain of: MySQL has not "detected an unauthorised action" and stepped in to make sure all children are safe. |
Christian J |
Jun 21 2010, 12:11 PM
Post
#28
|
. Group: WDG Moderators Posts: 9,630 Joined: 10-August 06 Member No.: 7 |
typically you use mysql_real_escape_string() to ensure that the string will not leak outside the surrounding quotes. Can't quite understand how that leaking takes place (sorry about going more and more OT in my own thread ). In the example on http://php.net/manual/en/function.mysql-re...cape-string.php CODE "' OR ''='" apparently turns into CODE '' OR ''='' as if PHP/MySQL don't see the differentce between single and double quotes? QUOTE Don't think that's the problem anyway: your error message says that $result is not a valid resource -- when the SQL command doesn't return rows (as DROP, or CREATE, etc don't), then I don't suppose you can expect to get a row with mysql_fetch_array(). But shouldn't the table be dropped before the warning message? Tested some more, and this does drop it: CODE mysql_query("DROP TABLE Thing"); (and also as a variable: $result=mysql_query("DROP TABLE Thing"); --my previous post was wrong), but this does not drop: CODE $result=mysql_query("SELECT * FROM Thing; DROP TABLE Thing"); --could it be that you can't select and drop in the same query? |
Brian Chandler |
Jun 21 2010, 10:33 PM
Post
#29
|
Jocular coder Group: Members Posts: 2,460 Joined: 31-August 06 Member No.: 43 |
typically you use mysql_real_escape_string() to ensure that the string will not leak outside the surrounding quotes. Can't quite understand how that leaking takes place (sorry about going more and more OT in my own thread ). In the example on http://php.net/manual/en/function.mysql-re...cape-string.php CODE "' OR ''='" apparently turns into CODE '' OR ''='' as if PHP/MySQL don't see the differentce between single and double quotes? No, nothing "turns into" anything else. In the example given the "trick" password string passed is shown by: CODE $_POST['password'] = "' OR ''='"; In other words the *string* passed is the *contents* of the double quotes. Viz: CODE ' OR ''=' This is what gets concatenated into the query, resulting in "password matches blank OR blank=blank", which is always true. (Perhaps this is what unknown sources have said can be typed into a login box.) What I meant by "leaking" is: the programmer *intends* that the user input supplied is just a string to be compared with some DB value. But by not sanitizing any included quotes, this string can "leak" out to form a larger expression, with a different sort of value ("always true"). Hope this is clear now. QUOTE CODE $result=mysql_query("SELECT * FROM Thing; DROP TABLE Thing"); --could it be that you can't select and drop in the same query? Seems I was (partly) wrong: http://www.php.net/manual/en/function.mysql-query.php Quote: "multiple queries are not supported" -- which presumably means no semicolons. So it is not simple to execute arbitrary commands such as DROP as I thought, and perhaps this is what the SQLite people meant. In any case, it's good style to program defensively... |
Christian J |
Jun 22 2010, 11:04 AM
Post
#30
|
. Group: WDG Moderators Posts: 9,630 Joined: 10-August 06 Member No.: 7 |
This is what gets concatenated into the query So it's the single quotes here: CODE password='{$_POST['password']}' that become concatenated with the injection string CODE ' OR ''=' resulting in CODE '' OR ''='' ? QUOTE Seems I was (partly) wrong: http://www.php.net/manual/en/function.mysql-query.php Quote: "multiple queries are not supported" -- which presumably means no semicolons. So it is not simple to execute arbitrary commands such as DROP as I thought, and perhaps this is what the SQLite people meant. Yes, and indeed http://www.php.net/manual/en/function.sqlite-query.php says that "SQLite will execute multiple queries separated by semicolons" |
Brian Chandler |
Jun 22 2010, 01:16 PM
Post
#31
|
Jocular coder Group: Members Posts: 2,460 Joined: 31-August 06 Member No.: 43 |
This is what gets concatenated into the query So it's the single quotes here: CODE password='{$_POST['password']}' that become concatenated with the injection string CODE ' OR ''=' resulting in CODE '' OR ''='' ? CODE This isn't "code", but I need to be in monospace... I think you are confusing a *string* and a *representation of a string*. A string is a sequence of characters, any characters, including any sorts of quotes. But usually we show the string we mean (like a string representing a marine vertebrate) as "fish", or 'fish', using quotes to identify the string. But the quotes are not part of the string at all. It's easy to get confused when the string *does* include quotes. As in the string "'Bertie'", which is eight characters long, and consists of the name of said vertebrate enclosed in single quotes. (So immediately I think you do not mean this: $password='{$_POST['password']}' This is a syntax error, because the second ' closes a string. ) But anyway: I wrote $_POST['password'] = "' OR ''='"; This sets the variable $_POST['password'] to a string of nine characters, which are the following (just the string, not any normal indicating quotation marks): ' OR ''=' These characters get concatenated with SELECT * FROM thing WHERE password =' (before) and (afterwards) ' to form the invalid password check. HTH |
Lo-Fi Version | Time is now: 28th March 2024 - 11:28 AM |