Re: a sql injection attempt
On 13/02/2012 22:09, Haluk Karamete wrote: Gary, you've mentioned that the user would have had access to the sysobjects No, there's a difference. *If* they had access to sysobjects then it could've caused issues. Ideally, you should have some level of segregation within your database. That is, the user that is querying the database from the website doesn't have access (read/write) to sysobjects as this isn't required. To clarify - the credentials that are used on your website should only have the minimum level of access: If these details are for any reason compromised, then, should the person with those credentials get access to the back end, they'll only be able to see the information that they'd be able to on the website (albeit in a raw format). If they can see more than that, then the potential for damage increases significantly. Consider that you run your website with the root user credentials. These are compromised. The person with these now has your root user details and, as a result, makes a concerted effort to find a way in to your back end. Having successfully done this, they can then drop the database. Let's assume he did. The page that this attempt occurred is hard-wired to display a single record in detail view. In the code, I have a bunch of echo $row-title kind of statements... You could always escape these. Some SQL injection attacks do account for this kind of thing. They're typically much more sophisticated than the one you quoted. I'm even more curious now; what kind of goodies this evil user would have gotten with having access to the sysobjects from the query string? The family silver? Sysobjects contains pretty much everything about your database - information about tables, views, stored procedures. Consider it as something like a blueprint of your database. I mean how would my page display sysobjects data when I don't have anything to do with echo sysobjects stuff? It wouldn't be inconceivable to escape out of what you've done to protect yourself. I assume that if you're passing any input to the database that it's already escaped? can you shed some light maybe? Hopefully that helps. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
a sql injection attempt
My logs shows that we have tried with a SQL Injection attempt, but our engine has detected and avoided it but I am just curious, what are these SQL statements are intending to achieve? SELECT * FROM lecturer WHERE recID='25 ' and exists (select * from sysobjects) and ''='' ORDER BY EntryDate DESC and SELECT * FROM lecturer WHERE recID='25' and char(124)+user+char(124)=0 and '%'='' ORDER BY EntryDate DESC If these were let in, what would have happened? -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
Re: a sql injection attempt
On 13/02/2012 21:48, Haluk Karamete wrote: My logs shows that we have tried with a SQL Injection attempt, but our engine has detected and avoided it but I am just curious, what are these SQL statements are intending to achieve? SELECT * FROM lecturer WHERE recID='25 ' and exists (select * from sysobjects) and ''='' ORDER BY EntryDate DESC and SELECT * FROM lecturer WHERE recID='25' and char(124)+user+char(124)=0 and '%'='' ORDER BY EntryDate DESC If these were let in, what would have happened? Nothing on MySQL - however, if the back end was an MS SQL server then the first query would prove that the user had access to the sysobjects table (ie wasn't constrained within a view, etc). The second is - the char(124) evaluates to |user|=0. I'm not sure what this one does, tbh. Gary -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
Re: a sql injection attempt
sorry, i overlooked that this IS a mysql mailing-list and we are running ms-sql in this particular case. good catch... I'd appreciate any insight though. On Mon, Feb 13, 2012 at 1:56 PM, Gary Smith shady...@l33t-d00d.co.uk wrote: On 13/02/2012 21:48, Haluk Karamete wrote: My logs shows that we have tried with a SQL Injection attempt, but our engine has detected and avoided it but I am just curious, what are these SQL statements are intending to achieve? SELECT * FROM lecturer WHERE recID='25 ' and exists (select * from sysobjects) and ''='' ORDER BY EntryDate DESC and SELECT * FROM lecturer WHERE recID='25' and char(124)+user+char(124)=0 and '%'='' ORDER BY EntryDate DESC If these were let in, what would have happened? Nothing on MySQL - however, if the back end was an MS SQL server then the first query would prove that the user had access to the sysobjects table (ie wasn't constrained within a view, etc). The second is - the char(124) evaluates to |user|=0. I'm not sure what this one does, tbh. Gary -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
Re: a sql injection attempt
Gary, you've mentioned that the user would have had access to the sysobjects Let's assume he did. The page that this attempt occurred is hard-wired to display a single record in detail view. In the code, I have a bunch of echo $row-title kind of statements... I'm even more curious now; what kind of goodies this evil user would have gotten with having access to the sysobjects from the query string? I mean how would my page display sysobjects data when I don't have anything to do with echo sysobjects stuff? can you shed some light maybe? thx. On Mon, Feb 13, 2012 at 1:56 PM, Gary Smith shady...@l33t-d00d.co.uk wrote: On 13/02/2012 21:48, Haluk Karamete wrote: My logs shows that we have tried with a SQL Injection attempt, but our engine has detected and avoided it but I am just curious, what are these SQL statements are intending to achieve? SELECT * FROM lecturer WHERE recID='25 ' and exists (select * from sysobjects) and ''='' ORDER BY EntryDate DESC and SELECT * FROM lecturer WHERE recID='25' and char(124)+user+char(124)=0 and '%'='' ORDER BY EntryDate DESC If these were let in, what would have happened? Nothing on MySQL - however, if the back end was an MS SQL server then the first query would prove that the user had access to the sysobjects table (ie wasn't constrained within a view, etc). The second is - the char(124) evaluates to |user|=0. I'm not sure what this one does, tbh. Gary -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe:http://lists.mysql.com/mysql
