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
