From: Dan Guzman on 22 Jul 2010 06:55 > Everything is escaped properly and all numbers/IDs converted/checked to be > numbers before they hit the database. So you are not using parameterized queries? IMHO, that's an accident waiting to happen (or already has). -- Hope this helps. Dan Guzman SQL Server MVP http://weblogs.sqlteam.com/dang/
From: Mike Myers on 22 Jul 2010 08:49 "Dan Guzman" <guzmanda(a)nospam-online.sbcglobal.net> wrote in message news:FC615F27-F936-49E7-BACD-A437858588C2(a)microsoft.com... >> Everything is escaped properly and all numbers/IDs converted/checked to >> be numbers before they hit the database. > > So you are not using parameterized queries? IMHO, that's an accident > waiting to happen (or already has). > > -- > Hope this helps. > > Dan Guzman > SQL Server MVP > http://weblogs.sqlteam.com/dang/ > > > Hi Dan No, and I will now change this page to do so. I ran a trace for a while but it yielded nothing. Regards Mike
From: Bwig Zomberi on 27 Jul 2010 02:27 Bob Barrows wrote: > Conjecture B: > No sql injection is involved: a user of your app is purposely entering > that string into an input element and submitting it When the DB has become corrupted and the RDBMS tries to repair/restore data something like this may happen. I have a vague recollection of this happening a long time ago. Just open the data store in the latest version of the DBMS and do an export to another data store in the latest version of the DB. Then manually check all the data is fine. If okay, use that data store. This does not mean you should ignore possibilities that others have pointed out. -- Bwig Zomberi
From: Erland Sommarskog on 27 Jul 2010 04:17 Bwig Zomberi (zomberiMAPSONNOSPAM(a)gmail.invalid) writes: > When the DB has become corrupted and the RDBMS tries to repair/restore > data something like this may happen. No, if you get <!--<1586567094>--> inserted from nowhere, it is highly unlikely that this is due to corruption. On the other hand if you had 7 in a cell, and then the next day you have 2035 there, this is a very likely due to corruption. As for repairs, SQL Server would never tries to guess a value. Either it repairs without data loss, or it throughs the data away. (And you have explicitly to allow data loss for it to happen.) -- Erland Sommarskog, SQL Server MVP, esquel(a)sommarskog.se Links for SQL Server Books Online: SQL 2008: http://msdn.microsoft.com/en-us/sqlserver/cc514207.aspx SQL 2005: http://msdn.microsoft.com/en-us/sqlserver/bb895970.aspx SQL 2000: http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx
From: Mike Myers on 28 Jul 2010 06:09 "Mike Myers" <bookham_measures(a)yahoo.com> wrote in message news:%23QyMGFPKLHA.1996(a)TK2MSFTNGP06.phx.gbl... > Hello > > Periodically, some of the records in one table have one field updated to > the following value: > > <!--<1586567094>--> > > It is the most bizarre thing I have ever seen. We have checked all our > servers and stored procedures for any occurrence of this value in scripts > or ASP pages but none exist. We're fearing SQL injection or similar but > in our application this field is only updated from one place and it's > tight against hacking. > > If it was a hack we would think the value might be something else, so > we're presuming some sort of corruption or similar. We're at a loss. > > Does anyone have any suggestions? > > Thanks and regards > > Mike > Well thanks guys. We have found one other record in this same table with a similar value, similarly meaningless. We did some analysis and it seems that only records created before the 12th July were affected. This means the injection/corruption either happened on this date or some other conic. 23124 records have been affected out of a total of 45826, (some of which may have been updated back to a more meaningful description so are no longer included in the erroneous count). We've switched to using stored procedures for the updates to this table but I am not convinced we've found the problem. The database is 85GB so playing at restoring backups is a nightmare. Regards Mike
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 Prev: bcp format file - error SQLState HY000, NativeError = 0,IO Next: MSSQL$SQLEXPRESS |