I am trying to determine if there are any good methods for scanning a website database to determine if the site has been compromised. I am reviewing a Drupal website which may have been exposed to an SQL injection vulnerability.
I understand that hackers will often hide code in the database using hexadecimal literals to avoid filters.
I am wondering if there was any method or tool one could use to scan a database for suspicious content?
If your database is changing constantly.. then it is very difficult to know if your database is exploited (involves cyber forensics).
Also, many of the SQL injection attacks involve gathering information than modifying.
There are tools for checking the vulnerabilities of a site. You can use them to patch the vulnerabilities instead.
You can use the following tools for this purpose:
SQLNinja
SQLMap
Source: Automated SQL injection Detection
Related
I am developing a client-side only web application for learning purpose, using WebSQL to store and query data, and Javascript to process it. WebSQL is not mantained anymore, but the question may be valid for all client side databases.
In the proposed specification for WebSQL from the W3C, §8.5 recommends a specific syntax (parameterized queries using ? as placeholder for values) to avoid SQL injection attacks.
Given that the user is free to modify the Javascript code used in the web page, including SQL statements (or alter the database using the development Console or other browser tools) why should the program be prepared to avoid SQL injections?
I found three StackOverflow questions related to SQL injection in WebSQL, this one, this one and this answer but none of them highlights why SQL injection is a concern on client side databases.
May someone else has a clear motivation, why SQL injection is a concern on client side databases?
SQL injection makes sense when considering unwanted third party operations on the database.
A client-side web application involves:
the developer, who designs the database and SQL statements;
the user, who can modify them using browser tools;
third-party scripts, such as libraries, which cannot access the application database.
Actually, databases are specific to one origin, so that a script cannot open a database belonging to an other origin:
If no database with the given name from the origin origin exists, then create the database
(§4.1 of the WebSQL W3C specification)
A third party attack script may use the DOM of the page to fill in form inputs with attack code, which will be injected when the form is submitted (possibly by the attacker itself, calling the submit() method of the form element). To avoid this, use parameterized queries: user input will never be interpreted as SQL code.
I would say that "an SQL injection attack" is distinct from a "I'm gonna modify the program, or better yet, just write my own" attack.
Yes, you are entirely correct in observing that a user can do anything he wants to, to a database and to software source-code that winds up on his computer. But, this is not an "SQL injection."
"SQL injection," I think, represents any case where an outsider effectively modifies the database structure or content from the outside, and without directly modifying the source-code or supplying new source-code of his own.
It could well be argued, as essentially you just did, that SQL injection is much less likely to occur with regard to a database that exists only on the client computer. I think that your argument is sustained. But, I don't think that this is a successful argument for abandoning the use of parameters. I flatly recommend that one should never insert literal, externally-provided values into any SQL string, "period."
I recently had to investigate an SQL incursion and noticed how -- is a great help for an attacker. Considering it's not a very useful instrument in many web environments, but seems to add to the damage potential of such vulnerabilities, why not disable it? I couldn't find a way, hence the question.
It is not possible to disable SQL comment parsing.
The correct solution is to ensure your application does not allow it to occur by always escaping user input, or better yet by using parametrised queries of some kind whether directly through the MySQL server API or through a user library that does it client-side.
Disabling comments may help a little, but it is very easy to do SQL injection without them, they can simply write the start of another complete query instead of commenting out the remainder of the statement.
If that is not practical for some reason, you may be able to consider the MySQL Enterprise Firewall (this is a commercial product and not open source) which allows you to setup a query whitelist:
https://www.mysql.com/products/enterprise/firewall.html
I record the search terms in on my e-commerce site and I the term
function.mysql connect
appears frequently. Immediately it concerns me that there may be some kind of automated bot looking for holes? SQL injection perhaps?
Could some one please explain what people are trying to do, and if this is indeed a signature of dodgy activity how can I check that I am protected against it?
Many thanks in advance
Most likely the search initiator is looking for dynamic pages that are displaying as plain text. Ie. if a webserver is misconfigured and displaying php files as plain text. In this case, there is a good chance that the mysql database credentials are exposed. This is a common way for malicious users/bots to search for database passwords and this is not SQL injection. For SQL injection, there would be part of a SQL query.
I'm investigating options for reporting on data in a custom salesforce application, since the built-in reporting tool is a bad joke.
The requirements are that the data needs to be accessible on-demand through the Salesforce website (likely through a web-tab, visualforce page, etc.), and must be able to do arbitrary joins of the tables, like ANY other relational database reporting tool. It is a huge plus to be able to give much of the specific report-design power to the end user, as well. Ideally it would play well with Oracle if an external DBMS is required, though this is not a strict requirement.
I hear good things about MS SQL Reporting Services, and there has been some talk around here about Crystal Reports. I'd be much obliged to get any thoughts and opinion on the various options and approaches out there.
It may be worth looking at tools similar to Teiid. What this does is provides a standard sql jdbc interface to any data source - including salesforce. With that in mind, that means you can then use any reporting tool. It also allows you to join across data sources etc.
I'm glad you call the current salesforce tool a joke! :)
As for reporting, we use Pentaho from the open source world, which is a very powerful tool, but does take some learning. Of course, the final decision wont just come down to functionality, but cost too, and this is where Pentaho is likely to win hands down. Pentaho plays very well with Oracle, and also MySQL too. (And many more dbs)
Finally you probably want to nail down your requirements a bit more. Do you need plain reporting, dashboards, more advanced analysis? Data mining? How far do you need to go..
Long story short, we found files promoting prescription drugs on our server that we didn't put there. The Windows server has very old applications and runs MySQL 5.1.11.
Beyond other security flaws, could SQL injection be used to write files to the server file system? I am certain that some of these old applications are vulnerable to SQL injection attacks. I would NOT think that this is possible, but I seem to remember reading somewhere that MySQL could access the "command line" and write files via it though I can not locate a source for that info. Then again, my mind could be playing tricks on me.
If this is possible, is there a setting that can disable it?
Also, I'm not looking for the answer that says get rid of the SQL injection vulnerability. While that obviously needs to be done; I'm looking for a quick short term fix that will prevent the rogue files from magically appearing again while the SQL injection vulnerabilities are being fixed. Fixing all the old applications is going to take lots of time.
Thanks.
It's possible, especially with suitably careless configuration.
For example, there is SELECT ... INTO OUTFILE 'file_name'
But it's also more likely to be a different security problem. I'd seriously consider taking the software offline quickly, especially if the database contains any confidential or private information
as Colin Pickard shows, yes.
but even if you can't update your application, i doubt it needs the rights it's currently running with. you need to check the user it logs in to mysql with and trip those permissions down to the minimum. specifically in this case, you should remove the FILE privilege if your app does not read/write files stored on the mysql server.
Setting the permissions of the application directory to read-only for the web account might work. This assumes that you're not already creating files in it like logfiles and such.