From: Dan Guzman on
> 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

"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
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
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

"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