0

Detecting infected files in a website or web application is very easy: you just need to compare the files with a clean backup or the original source (for example with diff) and that's it. However, detecting an infection in a database does not seem so easy. Comparing databases is probably way too complicated in most cases, because of the large amount of data that is constantly changing: tables with logs, options, posts, etc. So I thought that maybe the only reasonable solution is to actually check the data in the database and see if there's anything unexpected. But apart from a couple of obvious things, I'm not sure what to look for and how to look for it. The obvious things are those related to accounts and permissions, so for example I know I should definitely check for any users with unexpected high permissions, and that's normally easy to do. But how about... stored XSS? Should I look for strings like "script" or "onload", etc.? What else should I look for and how should I do it?

I know all this is highly dependent on the specific details of the web application (what it stores in the database and how it uses it), however I'm just looking for general advice. Note that I'm not asking how to recover from an infection: I'm just asking how to detect it, supposing it's restricted to the database. Also, by "infection" I mean anything that can lead to unauthorized access.

Improve this question
1

1 Answer 1

Reset to default
1

This question is rather generic and I can't suggest a specific solution without more specific context as to what kind of web application and database you are operating on.

To detect a breach of integrity of a RDBMS (think MySQL/Postgres) table that you don't expect any updates or new entires on, you can parse the query log for INSERT, UPDATEs to that particular table. This doesn't scale in the end. I'd rather suggest you to setup some triggers to log for certain conditions (INSERT, UPDATE, ...) on tables that is reflected on your site. There is a good guide on how to achieve this with OSSEC HIDS and a custom UDF log function on https://blog.rootshell.be/2011/01/07/auditing-mysql-db-integrity-with-ossec/.

As for post-mortem/forensic examination after a breach to find particular entries that might contain Stored XSS, you'd have to look at how your data is structured and try to find anomalies rather than specific strings as XSS comes in many variations and depend on your server-side technologies, different evasion techniques used by the attacker etc.

I understand that your question is specific to databases, and post-breach examination. But best-practice is to monitor and catch these at a way earlier layer, such as some WAF/content filtering before even hitting your application such as ModSecurity[1] or IronBee[2].

[1] https://www.modsecurity.org/

[2] https://github.com/ironbee/ironbee

Improve this answer
1
  • 1
    I'd rather suggest you to setup some triggers to log for certain conditions (INSERT, UPDATE, ...).... or, you know, DENY write access to those tables, which would prevent the updates in the first place, except for specific upload accounts.
    – Clockwork-Muse
    Commented Jan 4, 2019 at 4:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .