Re: [PHP-DB] SQL injection
On 21/06/15 20:14, Mark Murphy wrote: > But what does your application do when it gets an invalid SQL statement? > Maybe it is telling the attacker something important about your database so > that they can compromise it with the appropriate injection. It just defaults to the first news article in this case ... and counts it as another hit on that article. We have never allowed free text SQL to be included in any query, and any variable passed via the URL to provide navigation is only ever passed as a parameter, so even if there was no filtering of the parameter it would just fail. I'd only expect a continued 'attack' if the URL was returning something useful so to carry on just did not make sense ... -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] SQL injection
But what does your application do when it gets an invalid SQL statement? Maybe it is telling the attacker something important about your database so that they can compromise it with the appropriate injection. On 2:36PM, Sun, Jun 21, 2015 Lester Caine wrote: > On 21/06/15 18:55, Richard wrote: > >>> OK - this had no chance of success since publish_date_desc is > >>> >> processed using the _desc ( or _asc ) and any invalid data > >>> >> stripped > >>> >> > >>> >> > >>> >> &sort_mode=publish_date_desc%20or%20(1,2)=(select*from(select%20n > >>> >> ame_const(CHAR(111,108,111,108,111,115,104,101,114),1),name_const > >>> >> (CHAR(111,108,111,108,111,115,104,101,114),1))a)%20--%20and%201%3 > >>> >> D1 > >>> >> > >>> >> The question is more of interest in just what it was trying to > >>> >> achieve? I presume hack MySQL? So Firebird would barf anyway, but > >>> >> just trying to something that has generated some several hundred > >>> >> error log entries in the last two days ... > >>> >> > >>> >> Lester Caine - G8HFL > >>> >> > >>> >> > >> > The sub-query is invalid, if valid it would've been equivalent to: > >> > or (1,2)=(select*from(select 'b2xvbG9zaGVy' as 1, 'b2xvbG9zaGVy' > >> > as 1))a) -- and 1=1 > >> > > >> > Seems non threatening to me. > > Regardless of whether this specific attack could have resulted in > > harmful sql injection or not, user input should be sanitized so that > > things never get this far. > > ? That is taken direct off the URL! Sod all I can do to prevent it, but > I was simply asking if I was missing something as it did not make any > sense? It got no further than the error log but as I said several > hundred attempts via a few different filter options all of which > suggested something that was expected to work if the site was a > vulnerable mysql powered site ... which it's not. > > Seems that is just a pointless URL rather than some recently identified > potential vulnerability? > > -- > Lester Caine - G8HFL > - > Contact - http://lsces.co.uk/wiki/?page=contact > L.S.Caine Electronic Services - http://lsces.co.uk > EnquirySolve - http://enquirysolve.com/ > Model Engineers Digital Workshop - http://medw.co.uk > Rainbow Digital Media - http://rainbowdigitalmedia.co.uk > > -- > PHP Database Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Sent from my android
Re: [PHP-DB] SQL injection
On 21/06/15 18:55, Richard wrote: >>> OK - this had no chance of success since publish_date_desc is >>> >> processed using the _desc ( or _asc ) and any invalid data >>> >> stripped >>> >> >>> >> >>> >> &sort_mode=publish_date_desc%20or%20(1,2)=(select*from(select%20n >>> >> ame_const(CHAR(111,108,111,108,111,115,104,101,114),1),name_const >>> >> (CHAR(111,108,111,108,111,115,104,101,114),1))a)%20--%20and%201%3 >>> >> D1 >>> >> >>> >> The question is more of interest in just what it was trying to >>> >> achieve? I presume hack MySQL? So Firebird would barf anyway, but >>> >> just trying to something that has generated some several hundred >>> >> error log entries in the last two days ... >>> >> >>> >> Lester Caine - G8HFL >>> >> >>> >> >> > The sub-query is invalid, if valid it would've been equivalent to: >> > or (1,2)=(select*from(select 'b2xvbG9zaGVy' as 1, 'b2xvbG9zaGVy' >> > as 1))a) -- and 1=1 >> > >> > Seems non threatening to me. > Regardless of whether this specific attack could have resulted in > harmful sql injection or not, user input should be sanitized so that > things never get this far. ? That is taken direct off the URL! Sod all I can do to prevent it, but I was simply asking if I was missing something as it did not make any sense? It got no further than the error log but as I said several hundred attempts via a few different filter options all of which suggested something that was expected to work if the site was a vulnerable mysql powered site ... which it's not. Seems that is just a pointless URL rather than some recently identified potential vulnerability? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] SQL injection
> Date: Sunday, June 21, 2015 12:39:06 PM -0400 > From: Aziz Saleh > > On Sun, Jun 21, 2015 at 9:19 AM, Lester Caine > wrote: > >> OK - this had no chance of success since publish_date_desc is >> processed using the _desc ( or _asc ) and any invalid data >> stripped >> >> >> &sort_mode=publish_date_desc%20or%20(1,2)=(select*from(select%20n >> ame_const(CHAR(111,108,111,108,111,115,104,101,114),1),name_const >> (CHAR(111,108,111,108,111,115,104,101,114),1))a)%20--%20and%201%3 >> D1 >> >> The question is more of interest in just what it was trying to >> achieve? I presume hack MySQL? So Firebird would barf anyway, but >> just trying to something that has generated some several hundred >> error log entries in the last two days ... >> >> Lester Caine - G8HFL >> >> > The sub-query is invalid, if valid it would've been equivalent to: > or (1,2)=(select*from(select 'b2xvbG9zaGVy' as 1, 'b2xvbG9zaGVy' > as 1))a) -- and 1=1 > > Seems non threatening to me. Regardless of whether this specific attack could have resulted in harmful sql injection or not, user input should be sanitized so that things never get this far. -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] SQL injection
On Sun, Jun 21, 2015 at 9:19 AM, Lester Caine wrote: > OK - this had no chance of success since publish_date_desc is processed > using the _desc ( or _asc ) and any invalid data stripped > > > &sort_mode=publish_date_desc%20or%20(1,2)=(select*from(select%20name_const(CHAR(111,108,111,108,111,115,104,101,114),1),name_const(CHAR(111,108,111,108,111,115,104,101,114),1))a)%20--%20and%201%3D1 > > The question is more of interest in just what it was trying to achieve? > I presume hack MySQL? So Firebird would barf anyway, but just trying to > something that has generated some several hundred error log entries in > the last two days ... > > -- > Lester Caine - G8HFL > - > Contact - http://lsces.co.uk/wiki/?page=contact > L.S.Caine Electronic Services - http://lsces.co.uk > EnquirySolve - http://enquirysolve.com/ > Model Engineers Digital Workshop - http://medw.co.uk > Rainbow Digital Media - http://rainbowdigitalmedia.co.uk > > -- > PHP Database Mailing List (http://www.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > The sub-query is invalid, if valid it would've been equivalent to: or (1,2)=(select*from(select 'b2xvbG9zaGVy' as 1, 'b2xvbG9zaGVy' as 1))a) -- and 1=1 Seems non threatening to me.
Re: [PHP-DB] SQL Injection
On 16/05/15 14:51, Karl DeSaulniers wrote: > Interesting. I program in MySQL on a hosting plan by a third party. > I have heard/read MySQL is not an enterprise solution, but > for the basic business with say less than 100,000 customers, > it does the job and well. Larger than that I had hear Postgres > and oracle were good to look at. Havent heard any good things about > SQL server (.NET), but did't have too much trouble working with one a few > years back. > I guess I don't know enough about what is available to do with a good > database and which > to pick to do what I want with. There are so many. Hence my question here. That probably sums up 'hosted' plans. The number of available database engines has declined in recent years, and where a site 'outgrows' MySQL, there are a few custom developments, but bottom line ... there is not a single obvious answer ;) -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] SQL Injection
On May 16, 2015, at 8:42 AM, Lester Caine wrote: > On 16/05/15 10:00, Karl DeSaulniers wrote: >> That does clarify things a bit better on both the @ question >> and prepared statements. Thank you for the link as well. >> >> So new question.. what is the best type of database to use >> for someone who wants to start small and grow big? >> >> My findings led me to MySQL InnoDB. > > I'm somewhat biased since much of my data goes back to a time before > MySQL even existed. Using Interbase which is now open source as > Firebird. Early versions of MySQL were never stable enough to use in the > environments I work, and while Postgres was also appearing on the radar, > I've no reason to change. Little things like being able to run backups > automatically even if I've never actually had to use one. And some SQL > functions available in Firebird have yet to appear in other engines, and > having to decide if you want the security InnoDB provides is simply > standard in other engines. > > The first question is are you hosting yourself or using third party > hosting? MySQL tends to be available on all third party posting, with > some providing Postgres, while Firebird tends to be privately hosted. If > you are hosting yourself, then of cause MySQL may actually be MariaDB > and you end up with a mix of sources. It's a bit like Internbase and > Firebird where the commercial charges can affect one installation where > the other is totally free. > > If you are only looking for a single installation, then MySQL is > probably fine. I'm running 50+ databases and with Firebird each is > isolated in it's own directory and automatically backs up to the website > storage area. > > -- > Lester Caine - G8HFL > - Interesting. I program in MySQL on a hosting plan by a third party. I have heard/read MySQL is not an enterprise solution, but for the basic business with say less than 100,000 customers, it does the job and well. Larger than that I had hear Postgres and oracle were good to look at. Havent heard any good things about SQL server (.NET), but did't have too much trouble working with one a few years back. I guess I don't know enough about what is available to do with a good database and which to pick to do what I want with. There are so many. Hence my question here. Again, thanks for your response. Best, Karl DeSaulniers Design Drumm http://designdrumm.com -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] SQL Injection
On 16/05/15 10:00, Karl DeSaulniers wrote: > That does clarify things a bit better on both the @ question > and prepared statements. Thank you for the link as well. > > So new question.. what is the best type of database to use > for someone who wants to start small and grow big? > > My findings led me to MySQL InnoDB. I'm somewhat biased since much of my data goes back to a time before MySQL even existed. Using Interbase which is now open source as Firebird. Early versions of MySQL were never stable enough to use in the environments I work, and while Postgres was also appearing on the radar, I've no reason to change. Little things like being able to run backups automatically even if I've never actually had to use one. And some SQL functions available in Firebird have yet to appear in other engines, and having to decide if you want the security InnoDB provides is simply standard in other engines. The first question is are you hosting yourself or using third party hosting? MySQL tends to be available on all third party posting, with some providing Postgres, while Firebird tends to be privately hosted. If you are hosting yourself, then of cause MySQL may actually be MariaDB and you end up with a mix of sources. It's a bit like Internbase and Firebird where the commercial charges can affect one installation where the other is totally free. If you are only looking for a single installation, then MySQL is probably fine. I'm running 50+ databases and with Firebird each is isolated in it's own directory and automatically backs up to the website storage area. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] SQL Injection
On May 16, 2015, at 3:51 AM, Lester Caine wrote: > On 15/05/15 06:21, Karl DeSaulniers wrote: >> Oh ok. Now it makes a little more sense. >> I have worked in ASP before, but I am programming in PHP and MySQL at the >> moment. >> >> I am going to look into Prepared Statements. Thanks for your feedback. > > Just to clarify things a little here and explain > http://php.net/manual/en/pdo.prepared-statements.php a little more ... > > Many of the legacy injection problems where/are caused by building up > the query as a fully self contained string. Various methods like > 'magic_quotes' and wrapping $var in things like makesafe($var) were the > only way some database engines could handle adding variables to the SQL > string and much code still follows that style even today. Other database > engines have always had the ability to pass the variables as a separate > array of data, and the @x is more normally seen as a simple ? in the SQL > string, so PDO and other frameworks map the ':var' elements of the first > example to the relevant style used by the database. Actually naming > parameters is not the norm, so one has to have the right number of '?' > elements to go with the array of data passed, so PDO is adding a layer > of code which hides the underlying execute(sql_query, array_of_data); > > -- > Lester Caine - G8HFL > - > Contact - http://lsces.co.uk/wiki/?page=contact > L.S.Caine Electronic Services - http://lsces.co.uk > EnquirySolve - http://enquirysolve.com/ > Model Engineers Digital Workshop - http://medw.co.uk > Rainbow Digital Media - http://rainbowdigitalmedia.co.uk Thank you Lester. That does clarify things a bit better on both the @ question and prepared statements. Thank you for the link as well. So new question.. what is the best type of database to use for someone who wants to start small and grow big? My findings led me to MySQL InnoDB. Best, Karl DeSaulniers Design Drumm http://designdrumm.com -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] SQL Injection
On 15/05/15 06:21, Karl DeSaulniers wrote: > Oh ok. Now it makes a little more sense. > I have worked in ASP before, but I am programming in PHP and MySQL at the > moment. > > I am going to look into Prepared Statements. Thanks for your feedback. Just to clarify things a little here and explain http://php.net/manual/en/pdo.prepared-statements.php a little more ... Many of the legacy injection problems where/are caused by building up the query as a fully self contained string. Various methods like 'magic_quotes' and wrapping $var in things like makesafe($var) were the only way some database engines could handle adding variables to the SQL string and much code still follows that style even today. Other database engines have always had the ability to pass the variables as a separate array of data, and the @x is more normally seen as a simple ? in the SQL string, so PDO and other frameworks map the ':var' elements of the first example to the relevant style used by the database. Actually naming parameters is not the norm, so one has to have the right number of '?' elements to go with the array of data passed, so PDO is adding a layer of code which hides the underlying execute(sql_query, array_of_data); -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] SQL Injection
-Kevin Waddell Proverbs 3:5-6 On Fri, 5/15/15, Ruprecht Helms wrote: Subject: Re: [PHP-DB] SQL Injection To: php-db@lists.php.net Date: Friday, May 15, 2015, 10:16 AM On 15.05.2015 07:21, Karl DeSaulniers wrote: > On May 14, 2015, at 11:11 PM, Onatawahtaw wrote: > >> Hi Karl, >> >> If you look at the link you provided you'll notice that some of the code is for ASP.net and some is for PHP. I have looked in the link. Most problems by inject an sql-Code is to add something in the where-clause let it end with a semicolon and add an additional sql-command behind the semicolon. In this case you have two SQL-Command. The first maybe a Select-Command and the next can be to drop a whole table with all its content. One thing you can do is to trim the Select-Statement and trough all behind a semicolon in addition the semicolon away. To assume that any SQL injection is going to be by a second statement is very risky. Someone can simply add an "or" section to the where clause. It will still be one SQL statement and your trim will have done nothing to solve the problem. It is best not to make that assumption and not bother with trimming. Also, it would be tricky finding a proper trim function especially if your form input should contain semi-colons, etc. -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] SQL Injection
On 15.05.2015 07:21, Karl DeSaulniers wrote: On May 14, 2015, at 11:11 PM, Onatawahtaw wrote: Hi Karl, If you look at the link you provided you'll notice that some of the code is for ASP.net and some is for PHP. I have looked in the link. Most problems by inject an sql-Code is to add something in the where-clause let it end with a semicolon and add an additional sql-command behind the semicolon. In this case you have two SQL-Command. The first maybe a Select-Command and the next can be to drop a whole table with all its content. One thing you can do is to trim the Select-Statement and trough all behind a semicolon in addition the semicolon away. Another securitymethod of mysql that the fieldvarables are capseled by escaping. So mysql get note that this is a variable content for a formfield and should looked like that. Regards, Ruprecht -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] SQL Injection
On May 14, 2015, at 11:11 PM, Onatawahtaw wrote: > Hi Karl, > > If you look at the link you provided you'll notice that some of the code is > for ASP.net and some is for PHP. What of the two are you programming in? If > you are programming in ASP.net you are asking your question to the wrong > mailing list as this list is for PHP. If you are programming in PHP, then the > @ symbol does not apply to you. > > Both prepared statements and mysqli_real_escape_string do provide adequate > security (if used correctly). However, my recommendation is to learn how to > use PDO with prepared statements. PDO also offers the benefit of being able > to connect to multiple types of databases without needing to change your > code. If you use mysqli and down the road you decide you want to use Oracle, > MS SQL Server, or some other database server, you will ned to rework a lot of > your code. Not so with PDO. > > Hope this helps, > > -Kevin Waddell > Proverbs 3:5-6 Oh ok. Now it makes a little more sense. I have worked in ASP before, but I am programming in PHP and MySQL at the moment. I am going to look into Prepared Statements. Thanks for your feedback. Best, Karl DeSaulniers Design Drumm http://designdrumm.com -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] SQL Injection
Hi Karl, If you look at the link you provided you'll notice that some of the code is for ASP.net and some is for PHP. What of the two are you programming in? If you are programming in ASP.net you are asking your question to the wrong mailing list as this list is for PHP. If you are programming in PHP, then the @ symbol does not apply to you. Both prepared statements and mysqli_real_escape_string do provide adequate security (if used correctly). However, my recommendation is to learn how to use PDO with prepared statements. PDO also offers the benefit of being able to connect to multiple types of databases without needing to change your code. If you use mysqli and down the road you decide you want to use Oracle, MS SQL Server, or some other database server, you will ned to rework a lot of your code. Not so with PDO. Hope this helps, -Kevin Waddell Proverbs 3:5-6 On Thu, 5/14/15, Karl DeSaulniers wrote: Ok, so understand my own situation, the method I have been using, mysqli real escape string is suffice? Or is the @ symbol is the better preferred method? Best, Karl DeSaulniers Design Drumm http://designdrumm.com -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] SQL Injection
On May 14, 2015, at 8:37 PM, Jigme Datse Yli-Rasku wrote: > On 15/05/14 18:19 , Karl DeSaulniers wrote: >> On May 14, 2015, at 8:09 PM, Aziz Saleh wrote: >> >>> >>> >>> On Thu, May 14, 2015 at 9:05 PM, Karl DeSaulniers >>> wrote: >>> Hello Everyone, >>> Have a quick question. Was reading some material and wanted some Players >>> perspective. >>> I know w3schools is not the de-facto on everything, so I wanted to know how >>> reliable is the information on this page. >>> >>> http://www.w3schools.com/sql/sql_injection.asp >>> >>> Namely the @ symbol before SQL Values and because this talks about SQL and >>> not MySQL specifically, does this not apply to MySQL? >>> To my uneducated eyes it seems legit. Any clarification is greatly >>> appreciated. >>> >>> TIA, >>> >>> Best, >>> >>> Karl DeSaulniers >>> Design Drumm >>> http://designdrumm.com >>> >>> >>> >>> That is preferred in PHP as well. The SQL/MySQL isn't specifically doing >>> the replacement, but rather the driver object. Using parametrized queries: >>> >>> http://php.net/manual/en/pdo.prepared-statements.php >>> >> >> >> Thank you Aziz, >> Interesting link, thank you for that. I have not worked with prepared >> statements on my own, just in WordPress. >> >> So the @ symbol is a preferred method even outside the SQL world because? >> >> What specifically is the @ symbol doing? >> >> From what I read, and from what you just mentioned, >> it's the PHP->SQL driver that check this @ symbol and treats the data as >> literal text? >> Meaning it will not execute the text that comes after the @ symbol as code. > > If I understand correctly it is not the @ symbol itself which is the thing > you should be looking at. What you should be looking at is how your > programming language handles prepared statements. What I see is that the @ > symbol is how ASP.Net defines the variable name, and also the variable > position. > > I am not sure about this, but it looks like PHP uses : for the same function. > > I am even less sure about this, but I think with prepared statements you can > also define what "type" of data is being passed. So if you try to pass a > "string" (ie. something that cannot be converted to a number) to a "number" > defined variable, you will get an error thrown. If you use a catch statement > that error can be handled by your code, rather than PHP handling it in > default manner. > > It really has been a long time since I have been hands on with any of this, > and there is a good chance at least some of what I am saying is wrong. > > The point of prepared statements is that what variables you are passing > through them, they are passed as literal values, rather than simply putting > them through as straight text put into your string you are passing to SQL. > > Even if the string ends up "breaking" your query in a way that can harm > either security of data, or your database itself (also a security issue), it > is not passed in a way that SQL handles as such. > > I discovered an issue on one of the web apps I used where I would get a SQL > error message if I entered certain strings into the input field. Even though > what I was doing wasn't at all trying to test for it, my inputs made it clear > what was going on. > > With that amount of "what is going on" figured out. I could send a > meaningful bug report that got this issue fixed. Most people using the site > would have had no idea what was happening. > > If I recall, I was putting a " or ' in my input, thus closing the string, > which then left the rest being interpreted as SQL code. Thanks Jigme, Ok, so understand my own situation, the method I have been using, mysqli real escape string is suffice? Or is the @ symbol is the better preferred method? Best, Karl DeSaulniers Design Drumm http://designdrumm.com -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] SQL Injection
On 15/05/14 18:19 , Karl DeSaulniers wrote: On May 14, 2015, at 8:09 PM, Aziz Saleh wrote: On Thu, May 14, 2015 at 9:05 PM, Karl DeSaulniers wrote: Hello Everyone, Have a quick question. Was reading some material and wanted some Players perspective. I know w3schools is not the de-facto on everything, so I wanted to know how reliable is the information on this page. http://www.w3schools.com/sql/sql_injection.asp Namely the @ symbol before SQL Values and because this talks about SQL and not MySQL specifically, does this not apply to MySQL? To my uneducated eyes it seems legit. Any clarification is greatly appreciated. TIA, Best, Karl DeSaulniers Design Drumm http://designdrumm.com That is preferred in PHP as well. The SQL/MySQL isn't specifically doing the replacement, but rather the driver object. Using parametrized queries: http://php.net/manual/en/pdo.prepared-statements.php Thank you Aziz, Interesting link, thank you for that. I have not worked with prepared statements on my own, just in WordPress. So the @ symbol is a preferred method even outside the SQL world because? What specifically is the @ symbol doing? From what I read, and from what you just mentioned, it's the PHP->SQL driver that check this @ symbol and treats the data as literal text? Meaning it will not execute the text that comes after the @ symbol as code. If I understand correctly it is not the @ symbol itself which is the thing you should be looking at. What you should be looking at is how your programming language handles prepared statements. What I see is that the @ symbol is how ASP.Net defines the variable name, and also the variable position. I am not sure about this, but it looks like PHP uses : for the same function. I am even less sure about this, but I think with prepared statements you can also define what "type" of data is being passed. So if you try to pass a "string" (ie. something that cannot be converted to a number) to a "number" defined variable, you will get an error thrown. If you use a catch statement that error can be handled by your code, rather than PHP handling it in default manner. It really has been a long time since I have been hands on with any of this, and there is a good chance at least some of what I am saying is wrong. The point of prepared statements is that what variables you are passing through them, they are passed as literal values, rather than simply putting them through as straight text put into your string you are passing to SQL. Even if the string ends up "breaking" your query in a way that can harm either security of data, or your database itself (also a security issue), it is not passed in a way that SQL handles as such. I discovered an issue on one of the web apps I used where I would get a SQL error message if I entered certain strings into the input field. Even though what I was doing wasn't at all trying to test for it, my inputs made it clear what was going on. With that amount of "what is going on" figured out. I could send a meaningful bug report that got this issue fixed. Most people using the site would have had no idea what was happening. If I recall, I was putting a " or ' in my input, thus closing the string, which then left the rest being interpreted as SQL code. -- Datse Multimedia Productions http://DatseMultimedia.com/ Tel:250-362-5701 Mobile: 250-354-7094 -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] SQL Injection
On May 14, 2015, at 8:09 PM, Aziz Saleh wrote: > > > On Thu, May 14, 2015 at 9:05 PM, Karl DeSaulniers > wrote: > Hello Everyone, > Have a quick question. Was reading some material and wanted some Players > perspective. > I know w3schools is not the de-facto on everything, so I wanted to know how > reliable is the information on this page. > > http://www.w3schools.com/sql/sql_injection.asp > > Namely the @ symbol before SQL Values and because this talks about SQL and > not MySQL specifically, does this not apply to MySQL? > To my uneducated eyes it seems legit. Any clarification is greatly > appreciated. > > TIA, > > Best, > > Karl DeSaulniers > Design Drumm > http://designdrumm.com > > > > That is preferred in PHP as well. The SQL/MySQL isn't specifically doing the > replacement, but rather the driver object. Using parametrized queries: > > http://php.net/manual/en/pdo.prepared-statements.php > Thank you Aziz, Interesting link, thank you for that. I have not worked with prepared statements on my own, just in WordPress. So the @ symbol is a preferred method even outside the SQL world because? What specifically is the @ symbol doing? From what I read, and from what you just mentioned, it's the PHP->SQL driver that check this @ symbol and treats the data as literal text? Meaning it will not execute the text that comes after the @ symbol as code. Yes? Best, Karl DeSaulniers Design Drumm http://designdrumm.com
Re: [PHP-DB] SQL Injection
On Thu, May 14, 2015 at 9:05 PM, Karl DeSaulniers wrote: > Hello Everyone, > Have a quick question. Was reading some material and wanted some Players > perspective. > I know w3schools is not the de-facto on everything, so I wanted to know > how reliable is the information on this page. > > http://www.w3schools.com/sql/sql_injection.asp > > Namely the @ symbol before SQL Values and because this talks about SQL and > not MySQL specifically, does this not apply to MySQL? > To my uneducated eyes it seems legit. Any clarification is greatly > appreciated. > > TIA, > > Best, > > Karl DeSaulniers > Design Drumm > http://designdrumm.com > > > That is preferred in PHP as well. The SQL/MySQL isn't specifically doing the replacement, but rather the driver object. Using parametrized queries: http://php.net/manual/en/pdo.prepared-statements.php
Re: [PHP-DB] SQL Injection attack
Estimado veditio,
you wrote:
> I've got a ton of forms that use the $_POST variable to send
> information into the database [...]
> Any suggestions on how to tighten up the form security, or does
> magic_quotes help enough?
I'm not a security expert but after some attacks I have implemented
this simple thing. Until today it works for me.
You can put it before be connected to your database. I have one
only script to connect my database placed outside the /public_html.
It is and requested by means one include() in every oho script.
In this way, this security works in the whole site.
|%3c|%3e|SELECT|UNION|UPDATE|AND|exe|exec|INSERT|tmp/i';
...etc
// detecting
if (preg_match($inyecc, $resto)) {
// make something, in example sending an e-mail alert
$ip = $HTTP_SERVER_VARS["HTTP_CLIENT_IP"];
$forwarded = $HTTP_SERVER_VARS["HTTP_X_FORWARDED_FOR"];
$remoteaddress = $HTTP_SERVER_VARS["REMOTE_ADDR"];
$message = "attack injection in $mi_url \n\nchain: $resto \n\n
from: (ip-forw-RA):- $ip - $forwarded - $remoteaddress\n\n
- end ";
mail("[EMAIL PROTECTED]", "Attack injection", $message,
"From: [EMAIL PROTECTED]'SERVER_NAME']}", "[EMAIL
PROTECTED]'SERVER_NAME']}");
// kill execution
echo 'illegal url';
die();
}
// DB connection
$connection=mysql_connect(...etc.
?>
if you can encode this script with Zend Encoder or a similar thing.
It will be an additional measure to avoid the reading of this file.
hope it can be useful,
Vicente,
--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] SQL Injection attack
Haha.. what the hell? Ok, I know this is an older copy of the script I wrote
because I know I took out the "All this does is escape the data" comment and I
KNOW I saw the thing about mysql_escape_string() being deprecated... don't
know why it's still in there. Hah
Thanks for pointing that out. Now off to find my newer version and make sure I
chaned it there too.
-TG
= = = Original message = = =
no !!!
mysql_real_escape_string()
anyhow.. good luck with your security endeavors!
On 8/25/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> I'm pretty amateur at this too, but have done a little reading on the
> subject. Here's some nuggets to ponder while the real experts write their
> responses: :)
>
> 1. Magic quotes + mysql_escape_string = double escaped stuff. I think the
> general opinion is the magic quotes is evil, but I'm sure some people like
> it. I prefer to use mysql_escape_string() since it escapes things more
> specific to MySQL than magic quotes does. Using mysql_escape_string should
> be good enough by itself.
>
> 2. Check data type. If an item is supposed to be an integer, use intval()
> before inserting into the database.
>
> 3. What your SQL statements for variables that can turn your statement into a
> "WHERE 1 = 1" situation that will always return TRUE.
>
> Here's something I've been playing with.. a generic function to sanitize data
> before inserting into the database. You pass it the data and the type of
> data and it'll clean it up. Nice thing about this is I designed it so if you
> say type = "phone" and you process it the same as type = "numeric".. then
> later you decide you want to process "phone" and "numeric" types separately,
> you only have to check this function, not all your lines of code.
>
> If someone has better ways of doing this, I'm all for hearing it. Please
> opine or criticize what I've posted above too. I want to learn as well.
>
> -TG
>
> Code:
>
> /**
> *~DBSanitizeData() prepares data for inserting/updating into or selecting from
> * MySQL by making sure that string data is properly escaped so as not to allow
> * 'SQL injection' type security issues from happening. No direct $_POST or
> $_GET
> * data should ever be used in a SQL string.
> *
> * Returns sanitized copy of data sent to it.
> *
> * Current sanitization only performs a mysql_escape_string() function but
> could do
> * more later.
> *
> * Example: $result = mysql_query('INSERT INTO TableName (SomeColumn) VALUES
> (' . DBSanitizeData($_POST['somevar']) . ')');
> *
> *
> * Modification Log:
> * --
> * Created: ~~Trevor Gryffyn - 03/28/2005
> *
> *
> *
> * @author Trevor Gryffyn <[EMAIL PROTECTED]>
> * @category Database Functions
> *
> */
> function DBSanitizeData($dbdata, $datatype = "alpha")
>switch ($datatype)
> case "binary":
> case "truefalse":
>$trues = array("YES", "Y", "1", "ON", "TRUE", "T");
>$falses = array("NO", "N", "0", "OFF", "FALSE", "F");
>if (in_array(trim(strtoupper($dbdata)), $trues))
> $dbdata = "Y";
> else
> $dbdata = "N";
>
>break;
> case "phone":
> case "numeric":
> case "ssn":
>$dbdata = preg_replace ('/[^\d]+/s', '', $dbdata);
>break;
> case "float":
> case "money":
> case "percent":
>// TODO: Should this be handled with floatval() or something else?
>// Yes.. it probably should. Maybe this is better.
>if (strstr($dbdata, ".") AND trim($dbdata) <> "")
> #$dbdata = (preg_replace ('/[^\d]+/s', '', $dbdata) / 100) . ".00";
> $dbdata = floatval(preg_replace ('/[^\d]+/s', '', $dbdata) / 100);
> else
> #$dbdata = preg_replace ('/[^\d]+/s', '', $dbdata) . ".00";
> $dbdata = floatval(preg_replace ('/[^\d]+/s', '', $dbdata));
>
>break;
>
> case "name":
> case "address":
>$dbdata = ucwords($dbdata);
>break;
> case "state":
>$dbdata = strtoupper($dbdata);
>break;
> case "date":
>$dbdata = date("Y-m-d", strtotime($dbdata));
>if ($dbdata == "1969-12-31") $dbdata = "";
>break;
> case "alpha":
> default:
>// Nothing special, just jump down to the trim/escape
>break;
>
>return trim(mysql_escape_string($dbdata));
>
> ?>
>
> = = = Original message = = =
>
> Greetings all:
>
> Using PHP 4.3.xx and MySQL 4.1 (and 3.xxx sometimes).
>
> I've got a ton of forms that use the $_POST variable to send information into
> the database, and I'm worried about injection attacks.
>
> My server has magic_quotes enabled, which I thought would handle most things,
> but am wondering now if I need to use mysql_escape_string on everything,
> which would mean, of course, a lot of find-and-replace and rewriting.
>
> Also, REGISTER_GLOBALS is turned off, and errors are not shown t
Re: [PHP-DB] SQL Injection attack
NOTE: http://www.php.net/mysql_escape_string "Version: 4.3.0 Description: This function became deprecated, do not use this function. Instead, use mysql_real_escape_string()." Jordan On Aug 25, 2005, at 2:15 PM, <[EMAIL PROTECTED]> [EMAIL PROTECTED]> wrote: Using mysql_escape_string should be good enough by itself. -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DB] SQL Injection attack
I'm pretty amateur at this too, but have done a little reading on the subject.
Here's some nuggets to ponder while the real experts write their responses: :)
1. Magic quotes + mysql_escape_string = double escaped stuff. I think the
general opinion is the magic quotes is evil, but I'm sure some people like it.
I prefer to use mysql_escape_string() since it escapes things more specific to
MySQL than magic quotes does. Using mysql_escape_string should be good enough
by itself.
2. Check data type. If an item is supposed to be an integer, use intval()
before inserting into the database.
3. What your SQL statements for variables that can turn your statement into a
"WHERE 1 = 1" situation that will always return TRUE.
Here's something I've been playing with.. a generic function to sanitize data
before inserting into the database. You pass it the data and the type of data
and it'll clean it up. Nice thing about this is I designed it so if you say
type = "phone" and you process it the same as type = "numeric".. then later you
decide you want to process "phone" and "numeric" types separately, you only
have to check this function, not all your lines of code.
If someone has better ways of doing this, I'm all for hearing it. Please opine
or criticize what I've posted above too. I want to learn as well.
-TG
Code:
* Modification Log:
* --
* Created: ~~Trevor Gryffyn - 03/28/2005
*
*
*
* @author Trevor Gryffyn <[EMAIL PROTECTED]>
* @category Database Functions
*
*/
function DBSanitizeData($dbdata, $datatype = "alpha") {
switch ($datatype) {
case "binary":
case "truefalse":
$trues = array("YES", "Y", "1", "ON", "TRUE", "T");
$falses = array("NO", "N", "0", "OFF", "FALSE", "F");
if (in_array(trim(strtoupper($dbdata)), $trues)) {
$dbdata = "Y";
} else {
$dbdata = "N";
}
break;
case "phone":
case "numeric":
case "ssn":
$dbdata = preg_replace ('/[^\d]+/s', '', $dbdata);
break;
case "float":
case "money":
case "percent":
// TODO: Should this be handled with floatval() or something else?
// Yes.. it probably should. Maybe this is better.
if (strstr($dbdata, ".") AND trim($dbdata) <> "") {
#$dbdata = (preg_replace ('/[^\d]+/s', '', $dbdata) / 100) . ".00";
$dbdata = floatval(preg_replace ('/[^\d]+/s', '', $dbdata) / 100);
} else {
#$dbdata = preg_replace ('/[^\d]+/s', '', $dbdata) . ".00";
$dbdata = floatval(preg_replace ('/[^\d]+/s', '', $dbdata));
}
break;
case "name":
case "address":
$dbdata = ucwords($dbdata);
break;
case "state":
$dbdata = strtoupper($dbdata);
break;
case "date":
$dbdata = date("Y-m-d", strtotime($dbdata));
if ($dbdata == "1969-12-31") $dbdata = "";
break;
case "alpha":
default:
// Nothing special, just jump down to the trim/escape
break;
}
return trim(mysql_escape_string($dbdata));
}
?>
= = = Original message = = =
Greetings all:
Using PHP 4.3.xx and MySQL 4.1 (and 3.xxx sometimes).
I've got a ton of forms that use the $_POST variable to send information into
the database, and I'm worried about injection attacks.
My server has magic_quotes enabled, which I thought would handle most things,
but am wondering now if I need to use mysql_escape_string on everything, which
would mean, of course, a lot of find-and-replace and rewriting.
Also, REGISTER_GLOBALS is turned off, and errors are not shown to the user when
the site is live.
Any suggestions on how to tighten up the form security, or does magic_quotes
help enough?
For what it's worth, I've tried to enter things like "pw=''" and other
simulated attackes using the $_GET method, but haven't been able to crack the
site. But I'm a noob at that kind of thing, so I try not to get too carried
away with myself.
Thanks,
V
___
Sent by ePrompter, the premier email notification software.
Free download at http://www.ePrompter.com.
--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DB] sql injection attack, protection from
Personally, I always check variables that I'm using in a query. If I'm
expecting eg a session id (32 hex characters) I check that the session id is
a valid one - ie "!$[0-9a-f]{32}$!" (I use ! as delimiter in regexps).
Allthough mysql_escape_string will probably protects me from injections, I
still verify the data.
Jos
-Original Message-
From: mayo [mailto:[EMAIL PROTECTED]
Sent: 16 May 2005 23:55
To: php-db@lists.php.net
Subject: [PHP-DB] sql injection attack, protection from
I'm new to PHP and would like to make certain that I have the basic
protection for the site:
Use double quotes to contain variable
Use mysql_escape_string so that query is considered part of the WHERE
clause.
$result=mysql_query('SELECT * FROM users WHERE
username="'.mysql_escape_string($_GET['username']).'"');
I'm pulling prices from a database and sending the item ID which has 4
characters (1001, 1002, etc.)
Is the following unnecessary with mysql_escape_string?
if (preg_match("/^\w{4,4}$/", $_GET['username'], $matches))
$result = mysql_query("SELECT * FROM items WHERE
itemID=$matches[0]");
else // we don't bother querying the database
echo "itemID not accepted";
Thanks
--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
